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."
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.
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.
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.
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.
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:
http://stackoverflow.com/questions/3323549/is-a-statically-t...
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 ..."
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?
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.
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.
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).
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.
> 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).
It is not hard to re-invent/re-discover Lisp. In fact, it happens all the time. So just because you don't know Lisp doesn't mean you haven't re-invented it, though it does likely mean that you have re-invented it badly. Re-inventions of Lisp are sadly common. Good re-inventions of Lisp are rare. And good re-inventions of Lisp by people who don't know Lisp are unheard of.
I have never understood, and still don't understand, why you choose to wear your ignorance with such pride.
BTW:
> Hoon is a typed language
So is Lisp.