Posted by Daniel Lyons
Fri, 05 Oct 2007 08:31:00 GMT
I find it amusing that most women writing personals on Craigslist want a “decent” guy, but would never dream of dating a conservative religious person. They want a decent guy who is OK with getting an abortion if they have sex without a condom. They want a decent guy, but aren’t looking for a long-term relationship. They want a decent guy who will put up with all of their quirks and hangups without having any of their own. On top of all this, they want a guy without an ulterior motive. It should be obvious that all of these things are, taken together, insane.
I’d like to say this reflects poorly on women, but we all know that in reality it’s just economics. Women on any personals service can make arbitrary or insane demands because they will get a ton of responses either way. Though I find it hard to understand why the world’s most completely generic personals ads get a bunch of responders, I’m sure that they do. As an ex of mine once observed, every woman has three guys who are dying to sleep with her.
And then there is the attractiveness of the blank slate. Kate’s character in Dodgeball is a perfect example: very attractive, apart from the scene when you see inside her house and everything is covered in cheesy unicorn art. A pretty girl loses some luster when she reveals her passion for orthodontics. In Free Enterprise, Claire is completely detached from our experience in reality through her complete detachment from other people. In reality, getting to know a person involves getting to know their parents, their best friends, their siblings, their roommates, their coworkers. In the movie, Claire has none of those complicating aspects. We want to fall in love with someone simple, a free radical bouncing around the universe unattached to anything, ready to bond into our molecule without any entanglement with foreign substances.
Online personals really represent a hilariously horrible dilemma. We are becoming more isolated like these atoms, bouncing around unattached. We wind up trying to be explicit about what we’re looking for, but we lack any kind of network that might produce what we really need. The eye cannot see itself, yet we are expected to write to the world what we are with the hopes that another eye which cannot see itself can perceive in this note that we are what it needs to complete itself. Wouldn’t our family and friends do a better job if they had a chance?
We have, really, no chance of communicating what is essential about ourselves in one paragraph of text written specifically to woo someone we haven’t met. Our friends and family have an image of ourselves in their minds. They can talk about our qualities generally. We can only mime it based on what we have heard from them about ourselves. A human can hold an image of another human within, and it is mostly valid. It can be off by a tone or two, and certainly lack some of the details, but this image is almost completely inaccessible to ourselves. If you have the slightest clue what you’re all about, it’s only because you’ve had someone tell you or a guess you’ve made based on looking at your bookshelf or your CD collection.
This leads us back to the number one thing people talk about in personals, their likes and dislikes. What could be less relevant? Yet it’s the only thing we can talk about that differentiates us from each other spiritually. Our souls all crave the exact same things, but our minds naturally appreciate different things to different degrees. And of course tribal affiliations are handy for weeding people out. But when we are trying to create relationships for ourselves, it’s always a process of weeding people out, disqualification. If we actually were being treated as people, as images within the minds of those who know and love us, then the process is completely different. I don’t have much first-hand knowledge of it except that every time I ever entered an intense relationship, we both suddenly felt like experts on all matters of the heart and tried to set up our friends, and it never worked. But we weren’t working from a basis of lists of mutually exclusive qualifications, but more like from the thought of finding two colors that complement each other. (There is a joke that a Jewish matchmaker calls any two Jews who are about the same height as one another a match.)
I don’t really know where I’m going with all this, except to say that dating is miserable and I think I can blame the country and the culture.
Tags relationships, whining
Posted by Daniel Lyons
Thu, 04 Oct 2007 02:27:00 GMT
I noticed something interesting the other day about the functional and object-oriented languages.
Consider Python, where you can write functions like:
def foo(first, second=0, *rest, **kwargs):
return first + second / len(rest) * kwargs['multiple']
Compare to a functional language like Haskell, where you can’t do that, but you can create types like:
data MyThing = YourThing Integer
| AnotherThing (Int, Char, Float)
| NoThing
Weird that in Haskell, a functional language, you don’t get keyword arguments or arbitrary numbers of arguments, but you do in Python, whereas in Python, you’re confined to a rather small set of built-in types or full-on objects.
Of course in Lisp, you get really ornate functions and the ability to make new types through OOP. But you don’t get strong typing. ;)
Tags haskell, languages, programming, python | 2 comments
Posted by Daniel Lyons
Fri, 28 Sep 2007 09:11:00 GMT
My faith in Haskell has wavered somewhat lately, and all because of Reddit. Essentially, three things:
- Haskell’s fixed-point combinator,
y f = f (y f).
- The ramifications of Haskell’s purity on abstraction.
- Haskell’s epidemic academia.
The first is really two problems. One is that the usual definition of the Y-combinator is not itself recursive. Obnoxious. The second problem is that, though it’s beautiful, there are a number of problems that you can’t express in Haskell using the above combinator which you could in an untyped language. This isn’t, apparently, news to anyone but me. I can’t see how to use the above Y-combinator. This is an incredibly academic problem, like most Haskell problems, but it bugs me a little.
The second was elucidated by Peter Van Roy on Lambda the Ultimate’s forum:
“True state lets information pass “underground” between two interfaces, i.e., the information passes without any apparent connection between them. This is because the connection is the shared state, which is shared by the two interfaces yet hidden from the outside. The shared state is a kind of covert information channel: it lets a module pass information to other modules (or to itself in the future) without anybody else seeing it.”
His point has to do with the fact that Haskell’s purity means that in order to get data from some point A to some point B through a number of other modules, each of the intermediate modules will have to carry the information around, even if it doesn’t do anything with it.
I would like to hate that, really, I would. But I can’t, because I programmed Voltaire in a very functional and abstract way in PHP partly because I could count on a handful of global variables passing some state around “underground” between modules that were loosely connected. In particular, Voltaire creates a region context and a template context in which each script is evaluated. The database connection is also shared clandestinely like this. If I were using Haskell, every function in the system would have to take an extra four parameters to get the current region, template, path and database connection, even if it wasn’t going to use it or pass it directly to a child.
It’s easy to denounce. At the same time I feel blameless for having done it, because while the state is “available” to anything beneath, nothing should be changing these variables outside the core. It’s available in a read-only way. Later on I wrote a plugin for rendering templates programmatically, and that involved understanding the inner state, and another plugin for producing lists which also involved understanding the inner state. But languages like Lisp provide interesting semantics for those times when you would want to change the behavior of a global variable safely.
Which brings me back around to Lisp, the language I have paid the least attention to of the four or so that I decided were “safe” so long ago when I started to force myself to use functional programming. And, truly, there are things about Lisp which are hard to love. The principle advantage of Lisp is that it permits you syntactic innovation. It’s certainly the only language that provides it meaningfully (let us not quibble about Lisp/Scheme differences or bizarre languages like Pliant). But doesn’t this seem like the fundamental abstraction of programming languages?
Aren’t we always starting with some problem and selecting a language based on its syntactic abstraction of some part of the problem domain? I mean, I pick Lisp because I want the ability to create my own structures. That comes in handy against every problem domain. But if I want to write a blog, well, Rails makes it a lot easier up front. Maybe I don’t get linguistic abstraction, but the starting abstraction is quite close. Michael chooses REALbasic for application development, I choose Cocoa. Both of us are making certain sacrifices in the name of abstraction. I lose defmacro. He loses the most recent Cocoa innovations. If I pick Lisp for my blog, then I’m sacrificing the fast start. The laziness of later syntactic abstraction had better pay off. The up-front cost is higher. For any given reasonable language, there is going to be a situation in which its abstraction is an up-front benefit that beats the up-front cost of using Lisp.
You see, these languages are compression algorithms. They compress your explanation of how to solve a problem. Like any compression algorithm, there are problems for each language that compress so badly you wind up writing a different language inside the language. This is Greenspun’s law all over again. Lisp wins frequently because it makes it easy to create a sublanguage for a subproblem that compresses it better. Ruby wins frequently because it encompasses most problem domains.
And Haskell wins frequently in academia because academia is interested in representative subproblems rather than complete problems. My experience on the ICFP this past year was that when you give Haskell a pure math problem, it will beat nearly anything else hands-down for both readability and speed. Now sprinkle some I/O on the problem. How about a non-local return? Perhaps a bit of, dare I say it, destructive state? Suddenly you find yourself looking up “monad transformer,” wondering what the hell you got yourself into.
And Justin, G-d bless him, is a Haskell wizard. I can sort of read the code he wrote. My contribution to that code was negligible. I wasn’t much help debugging it. But at the end, we had a performant Haskell version using prominent Haskell performance themes. But it was also 300 lines of code. I remain convinced against any of that pesky proof stuff that an OCaml implementation would have been half the length, more understandable, maintainable and debuggable. I believe Justin came away from the contest with the opposite conclusion: proof, solid proof, that Haskell can be made to attack the kinds of domains that other languages are generally selected for. In other words, his success with Haskell encourages him to use it more, whereas it filled me with doubt.
And today I see on Reddit a link to the paper introducing Haskell Server Pages. Not to the code itself, or the documentation talking about it, or to a page talking about it or some examples, but to an academic paper about it. I write on Reddit that “I have to admit I’m getting a bit tired of seeing things that should be cool Haskell libraries show up as academic papers. It’s as though the whole industry has turned its gaze to Haskell, exasperatedly asking to see something practical, and instead of turning out practical things, the Haskell world turns out academic papers about practical things. “Proof” that Haskell can be used practically is not the same as people using Haskell practically, nor the same as people practically deciding to use Haskell.”
Let’s face it. I really enjoy Haskell in part because of its snobbery, but that’s really a part of what it is. And the posturing about how mind-expanding it is. Haskell is addicted to academia. You’re much more likely to see a paper about some neat library than a neat library. When you go look at the code, it’s untested, only works on one platform, is broken or partially implemented. Academics are not rewarded for having good, useful code. They’re rewarded for writing papers.
Look at the Wash page and tell me who’s going to use this framework. Look at the first four links. Notice these PDFs and PS files are all LaTeX output. What kind of web people would do this? Academic web people.
So here we are. I suppose every language has its vices. I’m particularly drawn to languages that do a lot of posturing, apparently. Beyond that I’m not sure what to conclude. Every language that isn’t pure offal (Java) seems to have a place in the world. It would be better not to get too worked up about it, but it’s probably impossible.
Tags academia, haskell, languages, lisp, programming | 1 comment
Posted by Daniel Lyons
Fri, 28 Sep 2007 08:59:00 GMT
In a sense, isn’t writing a language in itself the supremely audacious act of intellectual hubris?
“Behold, my language. You want my language so badly, you’re already going to have my language around to compile it in. My language is best for a variety of tasks—for example, see how well it works for that most important and complex of tasks, implementing my language? Don’t you want to use my language for your next project? Especially considering how much effort and hard work I donated to the world, making my language and then implementing it? Bearing in mind as you decide that my language is better than any predecessor language, because it builds on their strengths without their weaknesses? Did I mention my language is a mathematical formalism? Yeah, it is.”
Tags humor, languages, programming | 1 comment
Posted by Daniel Lyons
Fri, 28 Sep 2007 08:18:00 GMT
The other day I was talking to a friend about what one does to unwind. I mentioned that I program for fun, and he immediately asked me how large the kind of program I write for fun is. I said, they almost never get beyond a couple hundred lines. Rarely do they surpass 100 lines. And this is with my usual commenting ratio of about a comment per line or two, with lots of whitespace. Contrast with my for-pay programs, which start in the thousands and reach up into the tens or (in one case perhaps) hundreds of thousands.
Michael’s son Adeo and I have been learning Inform 7 in tandem for much of the year. Most of my programs have been short explorations of a single theme or programming concept. It’s more natural to talk about an Inform program in artistic terms than a conventional program; let’s call these poems or vignettes. That’s the category most of my small programs fall under. Adeo, however, has been writing one extremely large program, clocking in at about 3000 “words,” which looks like 400 or 500 lines of code.
I usually stop myself from starting on projects that look like they’re going to get to that size. As I put it to Michael metaphorically, I never build a garage at home; just wrenches. I make tools for myself, but not applications. I would never dream of coming home to work on DanApp. I get stalled pretty early on with stupid architectural things.
Another friend was telling me recently about the importance to his relationship of taking one day at a time, corny as it sounds. Somehow, the belief that you can put it down and never come back is important to undertaking large tasks. My fear of starting a huge program is really a fear of maintaining a large program after it isn’t fun anymore. It’s fear of deciding 1000 lines in that it should have been written in a different language, or with a different data storage system. It’s a fear of time, or of having to work hard. Yet Adeo doesn’t harbor any fears about his large Inform story. He can walk away from it at any time—and it has been weeks since he’s worked on it. Someday he will probably stop working on it altogether, but it will be a silent kind of stopping, a finding of other things to work on.
Soon I’m going to be starting on a side project at home. What comes to mind is a tumblog, a blog consisting primarily of a list of links with a very small amount of commentary. This has become necessary because, through Reddit, Anarchaia, and a variety of other sources, I gather a lot of interesting links which I mostly email to my friends. This is handy for me and for them, because I get a record in my inbox and they don’t have to police these sites looking for interesting stuff. But it also sucks because I usually leave out people who would or might be interested, and because I never can find the link again even though it’s in my email somewhere. I’d particularly like for it to have a link back to some kind of personal wiki or CMS that I could set up for certain topics, based on what my room mate David Baird does for himself.
Immediately I am assaulted by various hangups. Which language should I use? I’ve more or less decided on Lisp, not just because I am having doubts about Haskell, but also because I want to learn it better. Even setting that up worries me. Will it hog resources on Bill’s server? Will people be able to hijack it through Slime (probably)? Should I use a database or a list in the language? What am I going to do with this blog? What about forward and backward compatibility with the URL? Separate subdomain?
If I were smart, I would try to just take it one day at a time and address each of these things in sequence. Instead I try to design it up front, eat the whole elephant in one bite. If I were smart, I would just do what Adeo does: work on it when I feel like it, making what I want to have happen, one day at a time.
Here’s hoping I can figure out how to do that.
Tags blogging, inform, lisp, programming, projects | no comments
Posted by Daniel Lyons
Thu, 20 Sep 2007 07:14:00 GMT
For a good time, please read a very twisted analysis of the benefits of performing poorly. (To my new anal-retentive readers: you try and figure out this guy’s name, and then I’ll cite it).
I have some remarks on Reddit which I’m proud enough of that I thought I’d share them with you sharks here. I wonder if the author has really listened to his own argument. I find it somewhat lacking in the “holding water” department:
“If you know the language to be dog slow any way, you’re much less likely to waste your time on the pointless microoptimizations that geeks so love…”
I think this one works equally well in reverse: if you know the language is already quite fast, you’re much less likely to waste time on pointless micro-optimizations that geeks so love. In fact, if your language is dog slow, there are probably more optimization opportunities than there are if it’s already quite fast, as a matter of diminishing returns.
“The fact that non-standard library code is inherently somewhat inferior adds further incentive to attempt community wide standardization…”
This fails rather spectacularly to explain why the Common Lisp standard includes such a huge standard library. Consider the inverse argument: “the fact that your library code runs as well as built-in code removes incentive to use the standard library.” In the magical imaginary world I pretend to live in, people apply appropriate abstractions without much regard for the performance—abstractions that perform radically poorly being considered inappropriate, I guess—but I would never imagine sitting on my hands, wondering whether or not I can “afford” the overhead of a function call.
“Python’s very slowness represents part of its competetive edge over languages that are in some ways better engineered and more capable…”
What is this, things that are poor in one area tend to be good in others?
I could only consider agreeing if somehow it were a zero-sum equation: all languages have equal amounts of effort applied to them, and some of it goes to performance. But it’s not a zero-sum equation, languages receive differing amounts of attention to different strengths for different reasons. Moore’s law and the rapidly increasing demand for programming alone have enabled Python to compete against a language three times older, better designed, implemented and specified.
Actually, no, that’s flat-out nonsense.
“I’d not be suprised if on the whole it greatly increases programmer productivity and results in clearer and more uniform code…”
I would tend to expect uniformity from any language which syntactically enforces it. :)
I certainly would not expect a poorly-performing program to go through as many stages of evolution as a rapid program. You have to factor in the compilation phase—but one usually doesn’t compile in-development Lisp programs while working on them. They evolve much more organically, because there’s not necessarily a separation between development and testing, whereas in Python there is to a larger extent. Supposing the compile-time differences are negligible (which, they are, if you are careful) I have a hard time believing that Python programs running more slowly permits more evolution to take place.
“Also, since only builtins have reasonable performance there’s added motiviation to become very familiar with the available builtins and far less temptation to roll one’s own version of say dict.setdefault (even if it it sucks)...”
I think the existence of sucky built-ins like setdefault contradicts the point about the quality of the standard library. From where I’m sitting, the quality of the standard library is a function of backwards-compatibility more than community involvement. Lisp has a larger, somewhat clunkier one because it is much older. Ruby’s library is much cleaner because it went through a lot of life without having to worry about backwards compatibility very much. Io is doing even better, having been designed by language aesthetes like Steve Dekorte who are familiar with a lot of good and bad APIs, and who aren’t afraid to break backward compatibility to make a global improvement in expressiveness.
This article nicely dovetails with an argument my friend Pi has been having with various cornholes on IRC about Python and Ruby. Ruby’s standard library is just plain nicer. Which do you prefer, based on your gut instinct:
foo.bar.baz.split.collect { |x| x.bazzle }.join(' ')
Or this:
' '.join([ bazzle(x) for x in string.split(foo.bar()) ])
Hell, for good measure, let’s toss in some Haskell:
unwords $ map bazzle $ words $ foo bar
I’m talking about your aesthetic reaction here. Your artistic reaction. You know which of these you prefer. You want the agglutinative glory of Ruby or the isolating awesome of Haskell. Follow your eyeballs on the above Python example. Compare to Ruby and Haskell. Your eyes hop around on the Python, trying to figure it out. Haskell and Ruby, your eyes slide across from left to right. You feel like you’re reading a language, not decoding one.
As an aside, slap the next person you meet who, ignorant of Haskell, rants about static typing. They’ve never used it, they have no idea what they’re talking about. They’re actually giddy or incensed about type annotations and other forms of busy-work. Don’t put up with it.
Tags haskell, languages, programming, python, ruby | 4 comments
Posted by Daniel Lyons
Mon, 17 Sep 2007 19:50:00 GMT
Planet Erlang used to be in my list of aggregated sites. It’s not anymore, and because I don’t see a good place on the site to leave feedback, I’m leaving it here.
- Planet Erlang is the only RSS feed that spams me. There’s no excuse. Planet Io doesn’t, Planet Haskell doesn’t, Planet Lisp doesn’t, Planet Erlang had better figure out how that’s happening and make it stop. Killing the item after it gets posted isn’t good enough if it still winds up in my RSS reader, which it does.
- Planet Erlang’s RSS feed is one point shy of completely useless to begin with. The whole point of an RSS feed is to bring me the content without me having to ask. Planet Erlang brings me a one sentence description of the content—in the title and the body. Who thought this was a good idea?
- Finally, when I do click on the title of the story, I wind up not at the story, but at Planet Erlang’s web page with Planet Erlang’s one-sentence summary of the story. Then I have to click again to get to the site.
Here’s a refresher on how RSS is supposed to work:
- I sit on my ass, reading news.
Here’s what actually happens with Planet Erlang:
- I sit on my ass, getting spam.
- Once in a while I see an interesting article’s title.
- I click on it to read it, because it isn’t already there in my news reader where it should be.
- I click on it again to get away from PE’s site and read it.
All this so I can see comments from someone about the site being linked to. Invariably, there are none for me to see. I’m invited to vote on the story. Invariably, the story has one vote.
I don’t know what you guys think running a Planet-style aggregator is all about, but you’re failing it, and you’re being an obstacle to the information I’m there to get.
Tags bitching, erlang | 7 comments
Posted by Daniel Lyons
Fri, 14 Sep 2007 06:15:00 GMT
Someone on Reddit shared the most cogent summary of DHH’s philosophy. Love him or hate him, he deserves most of the credit for Rails (and indirectly much of the recent furor over DSLs), and understanding him will get you far in understanding those things. He’s also a Web 2.0 personality of no small importance.
It must be very gratifying to be David Heinemeier Hansson. After all, he’s entered that quite small group of people in the programming world who are known by their very own TLA. Designers and programmers of various stripes regard him very highly. Of course, this has only happened to three or four other geeks in all of time: ESR, RMS, DJB, and maybe EWD. In short, it only happens to blowhards.
DHH is a blowhard and you know it. 37signals’ products tend to be so “opinionated” as to be anti-user. Lots of people have walked away from Basecamp because part of having “vision” is apparently knowing and understanding your tool so well that no customer—no matter how much they use your tool—can possibly have a suggestion for you that you should even bother responding to with anything less than total contempt. Want some proof? There’s even a hilarious parody of 37signals’ blog.
Without a bunch of highlighter, let’s skip to the point: Lots of companies achieve success, make a blog, and rant about their awesome formula. Lots of fans arrive, read the blog, and start to copy the formula. You shouldn’t, though, because mixed in with “good” companies are bad companies with crap products. They’re just as successful. DHH believes that his formula is perfect and it’ll work for everyone, but he has no way to know which parts of his formula are brilliant and which parts are bullshit. If you start your company ready to say “fuck you” to the users, well, you might be successful, but you might not.
I’m really glad someone as surly as myself managed to start a company and get invited to talks to put up slides that say “fuck you” on them. Really. It makes me feel really good about myself. The cult behavior is what’s pissing me off. Hating users is not a road to success. It’s an obstacle to success that, in DHH’s case, was apparently not enough of one to stop it from happening.
37signals used to have a great page comparing the cost of Basecamp to their competitors. The competition, if they’re still around at all, was charging hundreds or thousands of dollars for comparable or less functionality with really bad UI. Basecamp showed up and for $20 you could use it and it was easy. Might the real take-away here be the oldie-but-goodie “find a niche and fill it?” Do I need to point out the utterly missing runaway success with their other programs, largely warmed-over versions of Basecamp with different UIs? Does anybody really use Backpack? I’m sure twenty people will show up to point out that they do, but it’s hardly the millions who are using Basecamp. Campfire? Writeboard? Please.
So let’s be serious. They’re a one-hit wonder and their success has everything to do with capitalism and nothing to do with their cult of personality. That may sound depressing, but it should be liberating. You don’t need to drink any kool-aid. You just need to find a niche and fill it. You can be the biggest asshole in the world, and you’ll still get stinking rich. If you play your cards right, you too can be reduced to just three little letters.
Just be sure to give DKL some the credit when that happens.
Edit: comments are closed. Please see my commenting policy, my response to another troll on Reddit, and think about why you wanted to waste your time insulting someone on their blog when you could just get one of your own. Thank you.
Tags bullshit, rails, rants
Posted by Daniel Lyons
Tue, 11 Sep 2007 05:38:00 GMT
One thing Michael and I often discuss theologically is G-d’s perspective of the world. I have a particular thought about His reasoning which seems unusually lucid right now, so I thought I’d put it down here.
Reason is accepted as a gift of G-d to man in the Catholic and I believe also my own Rabbinic traditions. That we live in a rational universe whose laws can be determined scientifically and which can, to some extent, be understood is also an important given. But does G-d reason as we do?
If we accept that G-d exists outside time then perhaps causality still exists, but without time to give it duration, the effect of reasoning would be instantaneous. Understanding reason as a gift to man, I do not see any reason to assume that G-d also employs reasoning the same way. Indeed, isn’t reasoning mainly the creation of useful abstractions that enable our feeble minds to make observations in general? Without time, but with causality, wouldn’t these derived relationships appear instantaneously to G-d? If G-d can perceive these relationships instantaneously and G-d’s omniscient mind can contain all of everything, then He hardly is in need of abstractions: He understands, instantly, everything. Logic would therefore seem to be a needless crutch to G-d, about as useful as a blind person’s cane to a man who can see.
And in that light, it seems that G-d would have no need to deal with us categorically. In fact He would by necessity deal with us individually, since there would be nothing to be gained by dealing with us categorically. He has no shortage of time or mental effort, and wastes none in performing the steps of a logical derivation.
All of which brings us back to the notion of a personal G-d, elemental to both Judaism and Christianity. It’s the only kind of G-d there could be. Why would a creator of the universe, outside of time and with no limit on “processing power” opt to be distant or deal with humanity in general instead?
This line of reasoning also helps explain why firm ethical rules are handed down to us to be implemented in practice, but which G-d bends in the biblical narrative. Reason is our tool to approach G-d, not G-d’s limitation to us.
Tags philosophy, religion | 2 comments
Posted by Daniel Lyons
Fri, 07 Sep 2007 19:12:00 GMT
I have a theory about the respective OO capabilities of Lisp and OCaml, but I’m not quite sure who to ask.
In Lisp, when you make some class and some methods, those methods look like regular functions. In fact, in a sense, they are regular functions which happen to have more than one definition depending on the types of their parameters. So functional-style programming isn’t hampered.
I’m wondering to what extent functional and OO programming styles intermingle in Lisp and OCaml. My suspicion is that OCaml suffers from a lower degree of functional/OO integration because it provides object#method syntax instead of method object syntax which would be analogous to its function call syntax and closer to Lisp’s (method object) syntax.
Tags languages, lisp, ocaml, oop, programming | 1 comment
