I will also note that all it would take to convince me that I'm wrong is to demonstrate an alternate system that is just as short and extensible as message passing. I have not seen such a system.
rocketnia seems to dislike types, and I agree: a proliferation of types is troublesome. But we only have two routes: we can accept that types exist in Arc, or we can make Arc typeless, like GEDANKEN [1].
Simply saying "don't use isa" doesn't solve the problem... because you still need to extend everything. I have clearly demonstrated that with the current type system, creating new types, or variants of existing types, is far too difficult. But with message passing, it becomes trivial. Do you have a better suggestion?
A few random observations, in case they are helpful to you:
- I often don't get anyone agreeing with me in the forums (http://arclanguage.org/item?id=14263 notwithstanding :)... I notice that people often will spend their time instead to share their own ideas, concerns, and criticisms... or say nothing if they don't have anything additional to contribute. (Some of my best hacks have gotten little response in the forum when I first post about them). Thus I suspect you shouldn't necessarily take lack of positive agreement as evidence of disagreement.
- One pattern I've noticed on the forum is that someone will drop by and say "Arc would be a better solution for my problem if it had (immutable lists | software transactional memory | message passing | documentation | unit tests | libraries | ...)". It's more rare for this to be followed up by an actual runnable implementation of the feature.
- When someone does provide an implementation, they sometimes appear to be disappointed when their solution isn't adopted by other people. I suspect maybe there may be some confusion about the nature of problems and solutions: even if say X is an excellent and succinct solution to problem A, someone like myself for example may not take the trouble of adapting it if I happen not to have problem A. And... even if I do have problem A, X may or may not be a useful contribution to a solution for my problems A+B. When I'm trying to solve A+B, I may remember X and then try it out and see if it is useful for A+B, but it can be hard to know in advance whether I'll personally find X useful until I'm seriously looking at the details of A+B.
- I enjoy sharing solutions I've implemented to problems I've had, and I'm pleased when I learn that someone else has found them useful as well. But it can take a year or more after I first publish a hack for me to learn that someone is using it... which is fine for me since I'm aware that there can be a long feedback cycle, but I notice other people become discouraged when nothing seems to be happening in a shorter time frame.
To maximize the likelihood that other people will be able to make use of your solution, you may find this template helpful:
- explain the problem the solution solves. (People often omit this step: they immediately start off with describing the solution. But while it may be easy to see that a solution is elegant, it can be hard to see what it's a solution for).
- describe the solution. (Most people do this part).
- demonstrate how the implementation solves the problem. (This part is also often omitted, but a few concrete examples can do wonders to help people make the connection between the solution and a problem they have).
The forum itself tends to be a poor place to do this because of its modest formatting capabilities and the inability to edit posts later means that descriptions become disjointed, spread over multiple comments and posts.
I agree with most of what you're saying, but I will add a few things:
There are, generally speaking, two types of people who visit this forum. The first, type-A let's call them, are hardcore hackers, like yourself(ves), who are interested in the language design and the underbelly mechanics of language assembly. Then there are people, like myself, whom are only interested in using the language to build applications.
When I read: > "Arc would be a better solution for my problem if it had...", "It's more rare for this to be followed up by an actual runnable implementation of the feature." I will suggest the two types of people represent the divide within the pattern you're recognizing and I will going to even further to suggest this is not a bad thing. I would like to encourage more type-B user engagement - even, if only, so that I am not all alone :)
While I don't have the time or inclination to understand the full content/depth within these type-A posts, I do try to learn what I can even if only at a surface level. I really do enjoy reading these posts and do appreciate them so I hope they don't go to a back channel as akkartik has mentioned a possibility for.
Furthermore, I would like to highlight some of the points aw's message that I feel are really important (and with my interpretation):
* Inline comments are not the best way to present your ideas. I've struggled assembling all the bits and pieces and knowledge requirements from prior posts/threads. The order alone messes everything up and I simply do not have the time to do the paper chase.
* Writing an external blog post will likely force you to present a fuller picture, with its surrounding context, to an audience that can't always be on top of things.
All that said, please don't give up on the ideas, we need more of them - not less.
Oh, and by the way, there's an infinite amount of room available in the wiki for other things such as proposals, ideas, arguments, implementation approaches, and so on. So if you're looking for a place where you can write things out and edit them later, the wiki is great place to do that. (You can of course also write your own blog post if you want, and we can link to it from the wiki as well).
I took a break to write a blogging platform from scratch that includes my own custom markdown.
I even posted my first arc topic here: http://blackstag.com/blog.posting?id=2. I then quickly discovered the auto spam bots are moving from the arc forum to my blog site every night. So I took another break, lol, just to put some spam management code in. I'm glad had read enough of pg's code to implement some good techniques similar to news.arc.
Now I'm ready to do more blogging - I hope. I've accumulated a list of 9 or 10 posts and I plan to get some arc stuff in there as well.
I notice other people become discouraged when nothing seems to be happening in a shorter time frame.
I went through the five stages of grief after submitting http://arclanguage.org/item?id=12657. It took me literally weeks to get right, and it sat at I think 1 point for nearly a week (with just evanrmurphy's positive comment[1]).
But eventually I realized much of what you said :) I have more realistic expectations now. Points are nothing, and responses come in time.
[1] While evan was active you could tell when he'd seen something because it would go to 2 points :) (without suggesting that he upvoted everything)
Evan would often articulate agreement or admiration even if he had nothing to add, and it was useful. But I'm not sure we should all do it.
Perhaps all this is a sign that we need a back channel.
Yeah it seems people here don't express agreement unless they can add something useful.
Some of my best hacks have gotten little response in the forum when I first post about them
Because some of your best hacks left me speechless :)
Things I see here often take a while to digest, days or weeks. It's taken me over a year to fully appreciate extend, a road that took me through various dead-ends.
It was just when I got up this morning (thinking about http://arclanguage.org/item?id=14253) that I realized what you were suggesting wasn't just a syntactic thing of putting objects before methods, but doing away with types altogether. You're saying the language shouldn't allow us to say isa x 'table, only responds_to x tableness (http://arclanguage.org/item?id=14258).
So yeah sometimes it takes people a while to digest the implications of a solution (http://arclanguage.org/item?id=14264), but sometimes they just haven't understood what you're saying :)
What I'm suggesting is to get rid of the current view of types. The `type` and `annotate` and `isa` functions would still be used, just for a different purpose: defining interfaces.
So in that sense, yes, you're right. But it's not to the extreme of rocketnia; I'm merely suggesting to change how they're used.
Hmm, I wonder if you're getting Pauan and me mixed up. >.> I'm against 'isa and 'type almost altogether, but I think Pauan considers 'type to be part of the high-level interface of a value:
I consider it to be a part of an interface. If we're using duck typing (which I recommend), what happens when two functions define different behavior, but with the same names? All sorts of subtle bugs ensue. But by leveraging the type mechanism, we can group these differing behaviors into interfaces, avoiding the problem completely.
