The OP is going to have kittens when he finds out about hylang (https://github.com/hylang/hy)
Lisp: More is less
11–20 of 125 posts
Re: Lisp: More is less
#12A large reason there is fewer large lisp projects, is that its pretty hard to get a team of lisp developers. Also, many programmers who do know languages like a lisp or Haskell are often going to be better programmers and will require a higher salary. Not everyone who codes in these languages is a great programmer, but I suspect there is some correlation.
Re: Lisp: More is less
#13If I had the choice to develop a functionality as a Lisp macro or alternatively as an XML-based DSL for Java, I would know what I'd prefer...
Re: Lisp: More is less
#14A large reason there is fewer large lisp projects, is that its pretty hard to get a team of lisp developers. Also, many programmers who do know languages like a lisp or Haskell are often going to be better programmers and will require a higher salary. Not everyone who codes in these languages is a great programmer, but I suspect there is some correlation.
Another reason: they don't tell you or it is in a domain which the average developer does not know anything about.
How large is the scheduler for the Hubble Space Telescope, which has been adopted for many other telescopes?
Who are the users of AllegroGraph?
How complex is PTC's CAD system which uses Common Lisp? A few years ago they mentioned 7 million lines of Lisp.
Re: Lisp: More is less
#15> How can a static analysis tool keep up with a language that’s being arbitrarily extended at runtime? The prospect is daunting. I don't really understand that point. In Racket, for example, programs macro-expand down to a very small set of primitives, such as `let-values` and `lambda`. This makes it easier to do analysis, not harder. For example, this is how something like Typed Racket can support every idiom in unt…
and more importantly macros are expanded at compile time, not runtime, so static analysis is still possible, and this makes that statement a bit wrong.
Re: Lisp: More is less
#16The 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?
Re: Lisp: More is less
#17> 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.
Have we not learn by now that these systems are not easy to reason about. Are not all the things one first learns (ie Animal -> Dog) bullshit and should be avoided.
Why is it in every good OO book that, composition is better then inheritance. Why is every OO book full of examples about how to avoid mutabiltiy and make the system easy to reason about?
The idea that OOP systems (as generally) thougth of goes completly out of the window as soon as you have any kind of concurency, even just event handling.
> which rejects OOP
It does not reject, it takes the usful features like polymorpism and gives them to you. Protocols are better then interfaces, better then duck typing.
> In Clojure, if I want to define a symbol there are nine different ways of doing so.
There are a lot more then nine. But I would recomend rich or stus talks on simple vs easy. Just saying there is nine of something and thus its complicated is idiotic.
Java has only one thing, classes, does that make it simply, or does that just mean that its hoplessly overloaded?
Clojure is extreamly simply. State can only live in a var, atom, ref or agent. Every one of these has clear semantics, this includes clear sematnics in a multithreaded world. No other language has such clearly defined state management.
> Clojure claims to include these language features as a way to mitigate the complexity of parallelism; frankly, I’ve never found threading or interprocess communication to be any sort of conceptual bottleneck while working on some fairly complex distributed systems in Python.
Distributed system != Shared Memory
Nobody, really nobody can say taht distributed systems are easy. Just listen to the people that implment this stuff. But it is clear that a language generally does not really help you with reasoning about that system.
However when you run on a 16 core with shared memory and you have to do lock ordering and all this stuff,then you will defently be happy for the tools that clojure provides.
> Less is more (as long as “less” is sufficiently convenient).
Clojure is actually a much smaller and much simpler langauge then python every can hope to be. Clojure is simple, and strives for simplicity in every feature of the langauge. See here:
- Simplicity Ain't Easy - Stuart Halloway http://www.youtube.com/watch?v=cidchWg74Y4
- Simple Made Easy http://www.infoq.com/presentations/Simple-Made-Easy
Re: Lisp: More is less
#18Most of the complaints in this article boil down to "macros are too powerful." I think this is the key part of the argument: "A smart programmer is not necessarily an empathetic language designer; they are occupations that require different skillsets. Giving any programmer on your team the ability to arbitrarily extend the compiler can lead to a bevy of strange syntax and hard-to-debug idiosyncrasies." There are at l…
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
The problem with this argument is, that you will never have the amount of independned development on every feature. There are usually only a relativly small amount of people at the core of a langague.
If I want a new feature in the language is very hard to get it in and once its in its in. With macros diffrent people can do there own thing and indepently develop it.
Look for example at core.match, in every other language something like it would have been a new language feature. Clojure now has a state of the art pattern matcher without Rich or anybody doing anything.
Re: Lisp: More is less
#19> How can a static analysis tool keep up with a language that’s being arbitrarily extended at runtime? The prospect is daunting. I don't really understand that point. In Racket, for example, programs macro-expand down to a very small set of primitives, such as `let-values` and `lambda`. This makes it easier to do analysis, not harder. For example, this is how something like Typed Racket can support every idiom in unt…
Furthermore: Lisps tend to prefer staged metaprogramming (eg. macros) over dynamic metaprogramming eg. python's __whatever__, Ruby's method_missing, and JavaScript's obj[foo + bar](). I'd much rather debug static metaprogramming techniques over dynamic ones any day of the week.
The fact is that Clojure/etc is much easier to analyze statically than the popular everything-is-a-dictionary scripting languages. That should be obvious given that the reference implementation is a compiler, not an interpreter. But stuff like Typed Racket and Typed Clojure should eliminate any remaining doubt.
Re: Lisp: More is less
#20The 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?
Played with it for some Bottle apps and otherwise boring scripts (which are now half the size and easier to maintain). No ill effects so far, but dealing with classes is... Un-hythonic somehow :)
(Edit: typo)