The OP is going to have kittens when he finds out about hylang ( https://github.com/hylang/hy )
I recently found out about hy and I am seriously evaluating it for use with Django in production. Does anyone have experience using hy in production they could share?
Lisp: More is less
41–50 of 125 posts
Re: Lisp: More is less
#42Earlier quoted context omitted.
I mostly agree but fwiw, the usual counterargument on #2 is that those should be language facilities instead, which allows them to be carefully designed and then taken advantage of by the compiler. For example, in Racket (formerly PLT Scheme) you have: http://docs.racket-lang.org/guide/contracts.html
I'm not sure how well that specific example works. Are contracts built in to the language on a fundamental level, or are they just part of the standard library? Given that they're not included in racket/base, and given how flexible racket's core is, I would guess the latter, but I'm not sure.
One of the points of Lisp is that that difference doesn't matter.
But besides that, in this case it couldn't possibly matter. You write contracts for your functions. If they're violated at runtime you'll get a clear error that stops execution to contain damage, and assigns blame to the contract violator. At what point in that process does it matter whether contracts are "built into the language"?
Re: Lisp: More is less
#43Earlier quoted context omitted.
Although I love lisps, I'd rather jump in a very large Python project than a lisp one. Jumping into someone else Lisp code feels like a jungle to me. Jumping into someone else's Python code feels like my old good slipper. Part of it is due to the very strict Python standard of coding. But I think it's primarily because of the "One good way to do it" mentality. On the other hand, I feel telling a lisp programmer " Thi…
I hear a lot of bad things about large Java code bases.
Re: Lisp: More is less
#44The OP is going to have kittens when he finds out about hylang ( https://github.com/hylang/hy )
http://www.chiark.greenend.org.uk/~pcorbett/yvfc.html
Which, as you can immediately tell, is a Lisp interpreter written in Python, as a single expression. No macros, though.
Re: Lisp: More is less
#45Earlier quoted context omitted.
As a language geek, I tend to hunt the Internet for old papers and manuals related to OS and languages. The actual mainstream situation could be so different if the Xerox PARC research in terms of programming languages and OS besides the GUI, had become mainstream instead of the AT&T ones. The Interlisp, Smalltalk and Mesa systems were great computing platforms compared with what UNIX offered.
Still Lisp was on Unix on day two and was always a very popular platform for Lisp developers. You could even get Lisp Machines from TI with embedded Unix and Lisp Machines from TI and Symbolics which were embedded in Unix. Several Lisp companies made their entire business from Unix: Lucid, early Franz, early Harlequin/LispWorks, ...
Re: Lisp: More is less
#46The author of the blogpost is pretending to be "one of us" (people that get lisp) - in "Lisp devotees (myself once included)" - but apparently they never understood it if they're still thinking that lisps' advantages "make Lisp into an unweidly, conceptual sledgehammer that’s often out of scale with the problem being solved.". The word "often" there also makes me think they're making a point without experience or pro…
Re: Lisp: More is less
#47Haskell, by its lazy evaluation, is basically a macro-only language, and people seem to be doing fine in that end of the world. Granted, space leak issues are pretty difficult to analyse, so it makes the language seem hard to use in practice, but that's because all the low-hanging fruit like type errors are solved by how the language is designed, so you only end up with the hard bugs.
> Haskell, by its lazy evaluation, is basically a macro-only language, and people seem to be doing fine in that end of the world. They aren't that many to begin with, so it could just be (self-)selection bias. Forth people do fine using Forth too, but I don't see that as a point that it's an appropriate language for most projects and/or people.
Re: Lisp: More is less
#48This post repeats two memes that float around the programming language space. One is: "it's so powerful that it's bad". The other is: "it's ok, but not for large projects". I don't think I've ever seen any evidence attached to either. (If the OP contains any, I missed it.) But they're the sort of things that sound plausible and have more gravitas than "Here are my current preferences", so they get repeated, and no do…
> This post repeats two memes that float around the programming language space. One is: "it's so powerful that it's bad". Also known as "less is more", which is a well established point in programming, and with a lot of historical examples to showcase it. > The other is: "it's ok, but not for large projects". I don't think I've ever seen any evidence attached to either. Well, were are the sucesfull large projects wri…
In our field, tools get chosen not by merit but by what's the current fad. It's unfortunate, but this fact makes those two questions unhelpful in moving the discussion forward.
Re: Lisp: More is less
#49Earlier quoted context omitted.
I recently found out about hy and I am seriously evaluating it for use with Django in production. Does anyone have experience using hy in production they could share?
http://fraked.debian.net/ https://github.com/paultag/snitch/
P.S. I use Debian as my main OS for all my computers
Re: Lisp: More is less
#50"OOP is widely-used and easily comprehended because it is a fairly simple way of modeling reality that is compatible with how human beings do it."
Close, but no pants, Buckwheat!