Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Lisp a Blub Language?

coding.derkeiler.com

Post reply on HN
Print view View original

71–80 of 81 posts

Re: Is Lisp a Blub Language?

#71

Post by ramchip »

mixmax wrote: post #56

Aren't all languages blub languages depending on the usecase? If you write AI programs c++ is a blub language. How can you get anything done without macros? If you program drivers PHP is a blub language. How can you get anything done without direct access to the hardware? If you're doing webapps lisp is a blub language. How can you get anything done with a syntax that's so different from HTML and so difficult to read…

A "blub language" isn't an inferior language, or one with less features. It's a language in the middle of the ladder that goes from assembly to the ideal language. All the languages you described except Lisp are, in PG's mind, blub languages. Notice that Lisp can be applied to every of your examples: just use it as a code generator (which is very commonly the case for HTML, and I've seen it done for C as well), or use an appropriate dialect (eg. bitc for low-level, arc or clojure for web programming, CL for AI).

What you're describing is just a less powerful or a less appropriate language.

Re: Is Lisp a Blub Language?

#72

Post by ramchip »

zephjc wrote: post #70
mixmax wrote: post #56

Aren't all languages blub languages depending on the usecase? If you write AI programs c++ is a blub language. How can you get anything done without macros? If you program drivers PHP is a blub language. How can you get anything done without direct access to the hardware? If you're doing webapps lisp is a blub language. How can you get anything done with a syntax that's so different from HTML and so difficult to read…

Disclaimer noted, but as to your lisp/HTML example, HTML and lisps actually have a lot in common - if you strip away the end tags and the angle brackets, you get something very lispy looking Hello has the same (prefix) order of operators and operands as (div (span "Hello")) Off the top of my head, the "hiccup" package for Clojure has an 'html' function (macro?) that translates just that sort of stuff directly into ht…

Also, AFAIK people generally use Lisp to generate HTML, not as a replacement to HTML.

Re: Is Lisp a Blub Language?

#73

Post by lispm »

demallien wrote: post #64
swannodette wrote: post #57

Earlier quoted context omitted.

Programmable syntax is not in Python's future -- or at least it's not for Python 3000. The problem IMO is that everybody will abuse it to define their own language. And the problem with that is that it will fracture the Python community because nobody can read each other's code any more I like Python and use it everyday, and I this is simply FUD. Sadly it's the kind of argument I hear coming too often from people in…

Is it really FUD though? Having gone through a few bruising experiences with different libraries having incompatible object systems built in Javascript, I have come to appreciate the advantages of only having one way to implement certain types of structures. It doesn't need to be hard-coded into the language though - a decent Standard Library showing how things should be done, and a culture maintained by the communit…

I think macros do have certain disadvantages (they make debugging seem to look harder, more syntax, etc, ...).

But I find things like extensive use of MOP also make maintenance of programming more challenging.

Common Lisp has never tried to take away 'power' from users.

Scheme had a different philosophy: reduce everything to the most basic and pleasing constructs. But that approach has its own disadvantages - if one arrives at the bottom of programming language constructs, working 'upwards' is a problem.

Take for example the argument lists: Common Lisp has things like keywords, optional and rest arguments. Plain Scheme only has rest arguments. Adding other argument interpretation is possible, but is only really use if the language would support it and would make use of it.

Re: Is Lisp a Blub Language?

#74

Post by [deleted] »

agentultra wrote: post #43
Zak wrote: post #33

Earlier quoted context omitted.

It's hard to add static typing (and get much utility out of it) without forcing its use. If you do that, you lose dynamic typing.

... and that's bad because? If you want static typing, then I don't think trading out dynamic typing is a big deal to you. Though as pointed out else where, many implementations allow you to give their compiler type hints... which is a sort of half-way "best of both worlds" system.

[deleted]

Re: Is Lisp a Blub Language?

#75

Post by silentbicycle »

Zak wrote: post #22

I find in certain cases that I'm looking across the power spectrum from the Lisp point of view. I recently ported some code from Haskell to Clojure and occasionally found myself missing Haskell's amazingly expressive type system. Trying to give Lisp such a type system would make a lot of things that are currently easy in Lisp hard or impossible. There are certain kinds of mutually exclusive features that make certain…

> There are certain kinds of mutually exclusive features that make certain kinds of problems easier or harder.

Right. The fundamental problem with the whole "blub" argument is that there isn't one linear continuum of language power. There are problems for which Erlang's supervision hierarchy and distribution primitives or Prolog's backtracking are a killer feature. This doesn't mean they're "More Powerful than Lisp", just better suited to certain kinds of problems because they committed to some very specific trade-offs.

But, these same trade-offs have far-reaching implications for the language semantics, so you can't just use macros to graft them on after the fact. You can embed a mini-Prolog in Lisp, sure, but adding fully native logic variables (as in Prolog or Oz) would be far from trivial.

Re: Is Lisp a Blub Language?

#76

Post by mixmax »

zephjc wrote: post #70
mixmax wrote: post #56

Aren't all languages blub languages depending on the usecase? If you write AI programs c++ is a blub language. How can you get anything done without macros? If you program drivers PHP is a blub language. How can you get anything done without direct access to the hardware? If you're doing webapps lisp is a blub language. How can you get anything done with a syntax that's so different from HTML and so difficult to read…

Disclaimer noted, but as to your lisp/HTML example, HTML and lisps actually have a lot in common - if you strip away the end tags and the angle brackets, you get something very lispy looking Hello has the same (prefix) order of operators and operands as (div (span "Hello")) Off the top of my head, the "hiccup" package for Clojure has an 'html' function (macro?) that translates just that sort of stuff directly into ht…

Interesting. Do you by any chance have links to some newbie resources? Maybe it's worth reading up on some sort of lisp. Clojure maybe?

Re: Is Lisp a Blub Language?

#77

Post by loup-vaillant »

agentultra wrote: post #43
Zak wrote: post #33

Earlier quoted context omitted.

It's hard to add static typing (and get much utility out of it) without forcing its use. If you do that, you lose dynamic typing.

... and that's bad because? If you want static typing, then I don't think trading out dynamic typing is a big deal to you. Though as pointed out else where, many implementations allow you to give their compiler type hints... which is a sort of half-way "best of both worlds" system.

The halfway "best of both worlds" is impossible to attain, in my opinion. As far as I understand it, dynamic typing (meaning, extensive usage of runtime type information) has unmatched flexibility. Static typing (meaning, extensive analysis of syntactic types at compile time) completely prevent large classes of errors.

If you want a middle ground, you may lose some of the flexibility, and you still won't be able to prove as much as a full static type system. In the end, the "best of both world" could rapidly become the worst of both worlds.

As I see it, we have to compromise. When you design a type system, you want to maximize 3 virtues: flexibility, simplicity, and error sensitiveness. Alas, of these 3, you can only have 2. Dynamic type systems typically are simple and flexible, but hardly prove anything (which explain why unit tests are so useful). Advanced type systems like Haskell's are quite flexible and prevent many errors, but they are complex. Others, like Java's, are simpler but not as flexible (nor as error proof). And of course you have horrible type systems, like C++'s, which lacks all 3 virtues.

Re: Is Lisp a Blub Language?

#78

Post by zephjc »

mixmax wrote: post #76
zephjc wrote: post #70

Earlier quoted context omitted.

Disclaimer noted, but as to your lisp/HTML example, HTML and lisps actually have a lot in common - if you strip away the end tags and the angle brackets, you get something very lispy looking Hello has the same (prefix) order of operators and operands as (div (span "Hello")) Off the top of my head, the "hiccup" package for Clojure has an 'html' function (macro?) that translates just that sort of stuff directly into ht…

Interesting. Do you by any chance have links to some newbie resources? Maybe it's worth reading up on some sort of lisp. Clojure maybe?

clj-html - http://github.com/mmcgrana/clj-html

which is deprecated by

hiccup - http://github.com/weavejester/hiccup

though the latter has pretty lame examples

Re: Is Lisp a Blub Language?

#79

Post by Zak »

mixmax wrote: post #76
zephjc wrote: post #70

Earlier quoted context omitted.

Disclaimer noted, but as to your lisp/HTML example, HTML and lisps actually have a lot in common - if you strip away the end tags and the angle brackets, you get something very lispy looking Hello has the same (prefix) order of operators and operands as (div (span "Hello")) Off the top of my head, the "hiccup" package for Clojure has an 'html' function (macro?) that translates just that sort of stuff directly into ht…

Interesting. Do you by any chance have links to some newbie resources? Maybe it's worth reading up on some sort of lisp. Clojure maybe?

Generating HTML from Lisp is very easy and natural. Of course, there are situations where it might be better to use an HTML template, and there are libraries for that too. Here are a few more examples of HTML generation in Lisp:

A tutorial about writing an HTML-generating DSL in Common Lisp: http://gigamonkeys.com/book/practical-an-html-generation-lib...

The Common Lisp HTML generation library most people actually use[0]: http://weitz.de/cl-who/

HTML generation in PLT Scheme's Continue framework: http://docs.plt-scheme.org/continue/index.html#(part._.Rende...

Arc's built-in HTML generation (powers this site): http://files.arcfn.com/doc/html.html

[0] I'm not actually certain about that, but I think it's the most popular.

Re: Is Lisp a Blub Language?

#80

Post by jpr »

loup-vaillant wrote: post #77
agentultra wrote: post #43

Earlier quoted context omitted.

... and that's bad because? If you want static typing, then I don't think trading out dynamic typing is a big deal to you. Though as pointed out else where, many implementations allow you to give their compiler type hints... which is a sort of half-way "best of both worlds" system.

The halfway "best of both worlds" is impossible to attain, in my opinion. As far as I understand it, dynamic typing (meaning, extensive usage of runtime type information) has unmatched flexibility. Static typing (meaning, extensive analysis of syntactic types at compile time) completely prevent large classes of errors. If you want a middle ground, you may lose some of the flexibility, and you still won't be able to p…

I find that with a good, type-aware compiler such as SBCL, Common Lisp hits a really sweet spot on the typing issue. It catches a crapload of mistakes at compile time that would be runtime errors in Python (the language, incidentally the SBCL compiler is also named Python) and most other dynamic languages. The type-language of CL is also more expressive than anything else I have seen, featuring unions, intersections, predicates, subtyping etc. But most importantly, it stands in the background, and doesn't stop you from executing programs that don't conform to some preconceived notion of what typing should be like.
Post reply on HN