7 ms·

Blubness of a language comes from its practitioners not knowing about useful features from a higher-level language (or not grasping the utility of such a featur

by jjs 16y ago

Blubness of a language comes from its practitioners not knowing about useful features from a higher-level language (or not grasping the utility of such a feature). If your favorite Lisp lacks a certain feature you want, it's easy to add, making Lisp the anti-Blub. (And if your favorite Lisp makes it hard to add it, you've picked the wrong favorite!)

fauigerzigerk 16y ago
Some things are difficult to add even to Lisp. Static typing being an example.
- lispm 16y ago
  right, that's a good example
  - fauigerzigerk 16y ago
    On the other hand you could make an argument that static typing isn't actually a language feature as much as it is a step in the process of programming. Static typing consists of (a) tagging variables with their type and (b) running a program that uses these type tags to check and/or rewrite the program. It's easy to add type tags to a lisp program. It's just that Lisp doesn't specify that second program that checks and transforms the first. So I would say Lisp is half way there when it comes to static typing. That's a pretty contrived argument though... :-)
    - lispm 16y ago
      no, adding type declarations to Lisp is the easy part. when it comes to static typing, standard Common Lisp offers very little. Declaring types? That has been done. In Common Lisp: (defun twice (n) (declare (number n)) (the number (* n 2))) The difficult parts are: * the type system and its capabilities * make the operations of the type system sound * determining sub-types * type inference * integration with the rest of the language (where data objects also have something like types) Common Lisp provides lots of infrastructure for all kinds of things, but very little for a type system. For example in Lisp one can determine the value of an expression via EVAL, but there is no function to compute the type of an expression (other than a type of the computed value).
- magv 16y ago
  Difficult, but not impossible. Qi and Typed Scheme are two examples.
  - Zak 16y ago
    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.
    - agentultra 16y ago
      ... 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 16y ago
        [deleted]
      - loup-vaillant 16y ago
        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.
- noelwelsh 16y ago
  As MagV mentioned, Typed Scheme (http://www.ccs.neu.edu/home/samth/typed-scheme/ http://www.ccs.neu.edu/home/samth/typed-scheme/) is an example of static typing in a lisp-like language. I've used it, and it is great. It interoperates smoothly with the normal dynamic typed Scheme. Typing is at the module level (a module must be either statically or dynamically typed) and contracts (http://doc.plt-scheme.org/reference/contracts.html http://doc.plt-scheme.org/reference/contracts.html) are used to enforce invariants at module boundaries.
olavk 16y ago
Some features are not easy to add. For example, one important feature of Python is that the language is designed with consistency and readability in mind, and combined with the "preferably one obvious way to do it"-ideal means that code written by other people is easier to read and understand. This makes code and knowledge sharing easier, and the network effect creates a blooming ecosystem for libraries. How do you easily add that feature to your favorite Lisp?
- floater 16y ago
  Your example is a feature of the Python philosophy (or community) not the Python language.
  - olavk 16y ago
    The philosophy is hardcoded in the design of the language. For example, the BDFL has explicitly stated he doesn't want macros because it will hurt the readability (1), and he rejected support for multi-line anonymous functions because he didn't find a syntax which he thought was clear and readable enough. Clearly this is a very different philosophy than the one behind Lisp. (1) The quote from Guido: 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. (http://mail.python.org/pipermail/python-3000/2006-April/000286.html http://mail.python.org/pipermail/python-3000/2006-April/0002...)
    - floater 16y ago
      >Clearly this is a very different philosophy than the one behind Lisp. Depends on which lisp you mean. There are many dialects of lisp and each have their own philosophies and ideals. Scheme, for example, is a minimalist lisp whose philosophy is probably not too different from python - although python has a far bigger standard library (but that is a separate issue).
    - swannodette 16y ago

by jjs 16y ago

fauigerzigerk 16y ago

Some things are difficult to add even to Lisp. Static typing being an example.

lispm 16y ago
right, that's a good example
- fauigerzigerk 16y ago
  On the other hand you could make an argument that static typing isn't actually a language feature as much as it is a step in the process of programming. Static typing consists of (a) tagging variables with their type and (b) running a program that uses these type tags to check and/or rewrite the program. It's easy to add type tags to a lisp program. It's just that Lisp doesn't specify that second program that checks and transforms the first. So I would say Lisp is half way there when it comes to static typing. That's a pretty contrived argument though... :-)
  - lispm 16y ago
    no, adding type declarations to Lisp is the easy part. when it comes to static typing, standard Common Lisp offers very little. Declaring types? That has been done. In Common Lisp: (defun twice (n) (declare (number n)) (the number (* n 2))) The difficult parts are: * the type system and its capabilities * make the operations of the type system sound * determining sub-types * type inference * integration with the rest of the language (where data objects also have something like types) Common Lisp provides lots of infrastructure for all kinds of things, but very little for a type system. For example in Lisp one can determine the value of an expression via EVAL, but there is no function to compute the type of an expression (other than a type of the computed value).
magv 16y ago
Difficult, but not impossible. Qi and Typed Scheme are two examples.
- Zak 16y ago
  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.
  - agentultra 16y ago
    ... 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 16y ago
      [deleted]
    - loup-vaillant 16y ago
      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.
noelwelsh 16y ago
As MagV mentioned, Typed Scheme (http://www.ccs.neu.edu/home/samth/typed-scheme/ http://www.ccs.neu.edu/home/samth/typed-scheme/) is an example of static typing in a lisp-like language. I've used it, and it is great. It interoperates smoothly with the normal dynamic typed Scheme. Typing is at the module level (a module must be either statically or dynamically typed) and contracts (http://doc.plt-scheme.org/reference/contracts.html http://doc.plt-scheme.org/reference/contracts.html) are used to enforce invariants at module boundaries.

olavk 16y ago

Some features are not easy to add. For example, one important feature of Python is that the language is designed with consistency and readability in mind, and combined with the "preferably one obvious way to do it"-ideal means that code written by other people is easier to read and understand. This makes code and knowledge sharing easier, and the network effect creates a blooming ecosystem for libraries. How do you easily add that feature to your favorite Lisp?

floater 16y ago
Your example is a feature of the Python philosophy (or community) not the Python language.
- olavk 16y ago
  The philosophy is hardcoded in the design of the language. For example, the BDFL has explicitly stated he doesn't want macros because it will hurt the readability (1), and he rejected support for multi-line anonymous functions because he didn't find a syntax which he thought was clear and readable enough. Clearly this is a very different philosophy than the one behind Lisp. (1) The quote from Guido: 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. (http://mail.python.org/pipermail/python-3000/2006-April/000286.html http://mail.python.org/pipermail/python-3000/2006-April/0002...)
  - floater 16y ago
    >Clearly this is a very different philosophy than the one behind Lisp. Depends on which lisp you mean. There are many dialects of lisp and each have their own philosophies and ideals. Scheme, for example, is a minimalist lisp whose philosophy is probably not too different from python - although python has a far bigger standard library (but that is a separate issue).
  - swannodette 16y ago