6 ms·

> If your language does not support natively the set of rules you really like to enforce, you can still work in a style you like provided you establishes conven

> If your language does not support natively the set of rules you really like to enforce, you can still work in a style you like provided you establishes conventions and abstractions around it. That only works if the language provides some way to define abstract types. For instance, ML doesn't have any concrete type only inhabited by balanced binary trees, but an abstract type can provide operations never destroy balance. All is good as well as long as clients don't inspect the internal representation, which ML can and does enforce. However, unenforced conventions are just wishful thinking. > but as a CL developer, you know that its bad to use it and that you should rely on accessors provided by the API. As a C programmer, I know that it's very bad to use memory after freeing it. > But maybe that's not enough for you, because there are not enough checks and you have your own idea of how things should work and you think you should do more compilation and less interpretation. More precisely, I think computers are several orders of magnitude better than humans at applying formal logic, which ultimately boils down to mechanically interpretable rules of inference. I want a division of labor between humans and computers that leverages the strengths of both to the maximum possible extent. Humans shouldn't be in the business of performing perfectly automatable trivial checks. > and can't do exactly the things we actually like to do in Common Lisp. Actually, mutable objects, even objects whose class (not to be confused with type!) can change at runtime, are easy to implement in ML. The main reason why this programming style isn't as popular in ML-land is because it results in code that's harder to understand both for humans and for machines. Metaprogramming itself is admittedly not ML's strength, though. Here I look up more to Racket's `syntax-parse`, which is both friendlier and more scalable than `defmacro`.

qwertyuiop924 10y ago
>Metaprogramming itself is admittedly not ML's strength, though. Here I look up more to Racket's `syntax-parse`, which is both friendlier and more scalable than `defmacro`. ...No, not really. syntax-parse and defmacro are good at different things. While unhygenic macros are useless, procedural macros have their place. >unenforced conventions are just wishful thinking. Tell that to everyone developing java. :-). But one of the good things about lisp is that using syntactic extensions, we CAN enforce our own conventions. Just so long as you remember to unbind the native functions... >Actually, mutable objects, even objects whose class (not to be confused with type!) can change at runtime, are easy to implement in ML. The main reason why this programming style isn't as popular in ML-land is because it results in code that's harder to understand both for humans and for machines. Look, you're clearly a hardcore ML fan. You're not going to like Lisp. Lisp and ML are polar opposites of each other. Lisp is hyper-dynamic, ML is incredibly static. If you're the kind of person who can't last 5 minutes without typechecking and immutability guarantees, you'll either flee lisp quickly, or build your own bizarre ML inside of it.
- catnaroek 10y ago
  > syntax-parse and defmacro are good at different things. Yes, `syntax-parse` is good at being compositional - writing macros that don't step on each other's toes, just like normal functions. > Tell that to everyone developing java. :-). There's a reason why writing Java programs is so painful. The language is like a third world country's bureaucracy: it doesn't do anything useful by itself, and gets in the way of anyone who wants to do anything useful. > Look, you're clearly a hardcore ML fan. You're not going to like Lisp. It's not a matter of what I think. You said: “If it [Lisp] isn't the best at something, you can MAKE it the best.” All I did was give an example of something you can't make Lisp do. > Lisp is hyper-dynamic, ML is incredibly static. Every programming language has both static and dynamic parts. For example, lexical scope is intrinsically a static notion. And ML's exception construction is dynamic. The question is which particular combination of static and dynamic parts is most profitable for one's purposes. In any case, I really didn't want to turn this into a debate about types. My original objection was that Lisp doesn't have compound values. A dynamically typed language can have compound values.
  - qwertyuiop924 10y ago
    >Yes, `syntax-parse` is good at being compositional - writing macros that don't step on each other's toes, just like normal functions. That's hygene. defmacro COULD have hygene, and indeed, some schemes provide ER macros, which are defmacro with hygene. What I was talking about was the fact that defmacro is imperative, and syntax-parse is declarative. The lack of hygene in defmacro is actually awful. >There's a reason why writing Java programs is so painful. The language is like a third world country's bureaucracy: it doesn't do anything useful by itself, and gets in the way of anyone who wants to do anything useful. I'll agree with that, but pretty much every java program out there is an example of guarantees maintained by the programmer, not the language. Not saying it's a good thing, am saying it's possible. >It's not a matter of what I think. You said: “If it [Lisp] isn't the best at something, you can MAKE it the best.” All I did was give an example of something you can't make Lisp do. Okay, but I didn't get it, because I'm still not sure what it was... >In any case, I really didn't want to turn this into a debate about types. My original objection was that Lisp doesn't have compound values. A dynamically typed language can have compound values. Do you mean ADTs? because if not, I'm not sure what you mean.

qwertyuiop924 10y ago

>Metaprogramming itself is admittedly not ML's strength, though. Here I look up more to Racket's `syntax-parse`, which is both friendlier and more scalable than `defmacro`. ...No, not really. syntax-parse and defmacro are good at different things. While unhygenic macros are useless, procedural macros have their place. >unenforced conventions are just wishful thinking. Tell that to everyone developing java. :-). But one of the good things about lisp is that using syntactic extensions, we CAN enforce our own conventions. Just so long as you remember to unbind the native functions... >Actually, mutable objects, even objects whose class (not to be confused with type!) can change at runtime, are easy to implement in ML. The main reason why this programming style isn't as popular in ML-land is because it results in code that's harder to understand both for humans and for machines. Look, you're clearly a hardcore ML fan. You're not going to like Lisp. Lisp and ML are polar opposites of each other. Lisp is hyper-dynamic, ML is incredibly static. If you're the kind of person who can't last 5 minutes without typechecking and immutability guarantees, you'll either flee lisp quickly, or build your own bizarre ML inside of it.

catnaroek 10y ago
> syntax-parse and defmacro are good at different things. Yes, `syntax-parse` is good at being compositional - writing macros that don't step on each other's toes, just like normal functions. > Tell that to everyone developing java. :-). There's a reason why writing Java programs is so painful. The language is like a third world country's bureaucracy: it doesn't do anything useful by itself, and gets in the way of anyone who wants to do anything useful. > Look, you're clearly a hardcore ML fan. You're not going to like Lisp. It's not a matter of what I think. You said: “If it [Lisp] isn't the best at something, you can MAKE it the best.” All I did was give an example of something you can't make Lisp do. > Lisp is hyper-dynamic, ML is incredibly static. Every programming language has both static and dynamic parts. For example, lexical scope is intrinsically a static notion. And ML's exception construction is dynamic. The question is which particular combination of static and dynamic parts is most profitable for one's purposes. In any case, I really didn't want to turn this into a debate about types. My original objection was that Lisp doesn't have compound values. A dynamically typed language can have compound values.
- qwertyuiop924 10y ago
  >Yes, `syntax-parse` is good at being compositional - writing macros that don't step on each other's toes, just like normal functions. That's hygene. defmacro COULD have hygene, and indeed, some schemes provide ER macros, which are defmacro with hygene. What I was talking about was the fact that defmacro is imperative, and syntax-parse is declarative. The lack of hygene in defmacro is actually awful. >There's a reason why writing Java programs is so painful. The language is like a third world country's bureaucracy: it doesn't do anything useful by itself, and gets in the way of anyone who wants to do anything useful. I'll agree with that, but pretty much every java program out there is an example of guarantees maintained by the programmer, not the language. Not saying it's a good thing, am saying it's possible. >It's not a matter of what I think. You said: “If it [Lisp] isn't the best at something, you can MAKE it the best.” All I did was give an example of something you can't make Lisp do. Okay, but I didn't get it, because I'm still not sure what it was... >In any case, I really didn't want to turn this into a debate about types. My original objection was that Lisp doesn't have compound values. A dynamically typed language can have compound values. Do you mean ADTs? because if not, I'm not sure what you mean.