| HN Mirror

Learning Lisp is easy. Learning Haskell is hard. But unlearning either is next to impossible. So anyone writing a new functional language would be best advised to not have that problem.

Now, one might feel differently if Lisp, or Haskell, or any other functional language, was such a conspicuous market success. Under the circumstances, however, I don't think one can be faulted for the suspicion that perhaps functional programming is too important to be left to the functional programmers.

I think we'll have to disagree about whether or not Lisp is a typed language. I realize that people with IQs of 175 have an uncanny knack for taking indefensible positions and then defending them, but I'll just have to take this one on trust.

While we're measuring our respective equipment, however, we can agree that Lisp has macros. Hoon does not have macros, because it's a pure typed language and a pure typed language doesn't need macros.

If Hoon did have macros, however, they would be inherently hygienic, without anything like a gensym. If this is a good time for you to favor us with a lecture on the virtues of Lisp, perhaps you could start with gensyms and their place in "Maxwell's equations of software."

lisper 3675 days ago

> I think we'll have to disagree about whether or not Lisp is a typed language.

That seems like a peculiar position to take in light of your self-avowed and (apparently) carefully cultivated ignorance of Lisp. If you don't know Lisp, how would you know if it's typed or not?

BTW, here's a clue. (Spoiler alert! You may learn something about Lisp by reading the following.):

  Welcome to Clozure Common Lisp Version 1.10-r16479M  (DarwinX8664)!
  ? (type-of (sqrt -2))
  (COMPLEX (SINGLE-FLOAT 0.0 1.4142135))
  ? (sqrt 'x)
  > Error: The value X is not of the expected type NUMBER.

> anyone writing a new functional language would be best advised to not have that problem.

I am reminded of this koan:

  In the days when Sussman was a novice, Minsky once came to him as he sat hacking at the PDP-6.
  "What are you doing?", asked Minsky.
  "I am training a randomly wired neural net to play Tic-tac-toe", Sussman replied.
  "Why is the net wired randomly?", asked Minsky.
  "I do not want it to have any preconceptions of how to play", Sussman said.
  Minsky then shut his eyes.
  "Why do you close your eyes?" Sussman asked his teacher.
  "So that the room will be empty."
  At that moment, Sussman was enlightened.

> Hoon does not have macros

Most languages don't.

> a pure typed language doesn't need macros.

Of course. No language needs macros. That's why most languages are serviceable despite not having them.

> favor us with a lecture

You should be careful. As you yourself have just observed, losing your ignorance is a one-way street. The more you let me teach you, the closer you get to the edge.

Actually, if you watch the video of the LambdaConf talk, I believe you'll see me deride Lisp as having (and needing) dynamically typed atoms.

I had no idea the concept of an atom had indeed degenerated all the way into complex numbers, which to me and to all decent Americans will always be a "cons" cell. Obviously I had not reckoned with the full and complete degeneracy of Clozure Common Lisp Version 1.10. Or something. If I knew Lisp, I could perhaps condemn it correctly.

In any case, sir: you are misinformed. A "dynamic" type system isn't actually a type system. At best, it's a sort of crutch for retired Jedis who can barely swing their obsolete, one-ended lightsabers.

Or do you wish to become enlightened? Come visit our library, old Jedi. At urbit.org, we have all the enlightenment you need. The age of Lisp was glorious, true. But much time has passed and much we have learned. The times change, uncle, and we must change with them.

http://stackoverflow.com/questions/3323549/is-a-statically-t...

lisper 3675 days ago

> A "dynamic" type system isn't actually a type system.

I didn't say it was. I said Lisp was a typed language. Different claim. Lisp can be either dynamically or statically typed, though dynamic typing is more common. See:

https://www.quora.com/Why-is-Lisp-dynamically-typed

But see my earlier warnings about the possibility of losing your carefully cultivated ignorance.

If you really want to play with fire, read these too:

https://en.wikipedia.org/wiki/Type_system

http://blogs.perl.org/users/ovid/2010/08/what-to-know-before...

Pay particular attention where it says, "Type systems are commonly classified by several words, of which the most common are ... dynamic ..."

> If Hoon did have macros, however, they would be inherently hygienic, without anything like a gensym

Everything we know about hygienic macros is mainly the result of research in Lisp dialects.

Everything that has syntax has macros. Just not necessarily user definable macros.

Syntax takes some clumps of symbols and converts them to some other symbols. When that is user-defined, we call it a macros; when it is hard-wired in some parser, we call it a grammar production.

"You don't need macros" is reminiscent of "why would you need more than 640 Kb of RAM?"

If you don't need macros, it means that the language syntax has provided exactly the right set of hard-coded ones in the parser.

If that is true, why are there different languages without macros with different syntaxes? And which one is right?

Hoon is mainly built on a fixed set of hardwired, built-in macros. This is how I can be so confident about not needing anything like gensyms (what eliminates gensyms is having a subject which is navigated geometrically, not symbolically).

The advantage of fixing the set of hardwired macros is that, when reading code, everyone knows exactly what every line is doing, without having to indirect through the local macro environment. Macros are the first step toward a DSL.

DSLs are always and everywhere a bad idea. They may make code slightly cleaner or better-looking. In exchange, they add a level of indirection to the task of trying to understand it. This is the source of the nickname "write-only code," a common failure mode in FP. Write-only code can also be created by extravagant and pointless use of higher-order or non-strict programming, both of which complicate the task of reading code.

For instance, Hoon has a rune (keyword or digraph) for a 2-tuple, a 3-tuple, a 4-tuple, but not for a 5-tuple or up. Why? The 4-tuple cons pulled its weight, the 5-tuple didn't. For every special form you add to Hoon's fixed, limited set, you're imposing a cost on anyone who has to learn Hoon.

I hope you can see the UI advantage to functional programming in an environment of controlled evaluation complexity. IMHO, too much of FP is a world in which every program is its own language.

Which one is right? Actually, I feel it's possible that the only real language is K, and the rest of us are just phonies.

> everyone knows exactly what every line is doing

At least, until you start to define functions, whereby a line now says "something happens according to a definition elsewhere which is just invoked here".

Oh wait, that's also what a piece of syntax or macro also says, pretty much.

> I hope you can see the UI advantage to functional programming in an environment of controlled evaluation complexity

What I do know is that big programs written in C can be pretty difficult to understand, even though most of their bulk hardly uses much more than what's covered by the operator precedence table on page 53 of Kernighan and Ritchie, 2nd ed. A lot of that has to do with the fact that foo_bar(ptr_widget, 42, gadget_struct) can mean anything whatsoever, even though it isn't a special operator or macro call. The small assurance that three word-sized chunks are passed somewhere by value doesn't actually buy a whole lot of understanding.

(Brain* * * * * * has a nice, small, inextensible set of operators. Does it help?)

The dictionary you have to comprehend is not that of the language, but of the language, plus that of the code base written in it. What good is it if some language has 20 entities rather than 30, if the code base you're grappling with has 10,000.

The difference between a language with symbolic names, and a language with names and macros, is a difference between one level of indirection, and two levels of indirection. My view is that one is hard enough.

Macros aren't functions. A function call is one thing. A macro can expand to arbitrary code. This code may contain function calls or other symbols.

Before you can even interpret these symbols, you have to expand the macros in your head. This is two steps, rather than one. Expanding is not tracing. This extra step is why whoever is reading your code is so easily tempted to give up and writes it again herself, with her own macro language.

I was not comparing FP to C. If you look at actual Hoon code, it's pretty comparable in size to other functional languages, and also in clarity once you learn to read it. Obviously C is much fatter and harder to understand (and has macros, of course).

A function can contain arbitrary code behind the call. It can be a remote procedure call to a server, such that it is impossible to reverse-engineer what it does, beyond black-box testing.

> I think we'll have to disagree about whether or not Lisp is a typed language

Only if you're willing to insert "<qualifier> typed". Without at least one <qualifier>, the debate is meaningless: every party assumes that unqualified "typed" means "<qualified> type" for some different choice of <qualified> and then it's just about asserting word semantics.

And, here we go: dug up this gem from elsewhere in this comment tree:

> A "dynamic" type system isn't actually a type system.

"<foo-berly> type" isn't "type". Use my definition, god damn it! "Type" really refers to "<bar-istic> type".

(Dynamic is scary, so scare quotes are fitting, by the way).