2 ms·
"hack on cool, new things, to push boundaries, to explore, and so on" That sounds pretty good to me, actually. I don't see why aiming for "fun and experimenta
by pg 18y ago
"hack on cool, new things, to push boundaries, to explore, and so on"
That sounds pretty good to me, actually.
I don't see why aiming for "fun and experimentation" would put me in a different position from other language designers. It's not like anyone does this for a living. I bet most of them started out working on their language in the spirit of intellectual adventure, then gradually got dragged into being motivated more by duty and eminence, till eventually like poor Guido their time was all taken up thinking about character sets. That sounds to me like something one ought to resist. Doesn't it to you?
Amusingly enough, you can see the pressure in action all over this thread, e.g.
http://news.ycombinator.com/edit?id=343663 http://news.ycombinator.com/edit?id=343663
I'm pretty good at resisting though ;)
- deleted 18y ago[deleted]
- davidw 18y agoThen it becomes, as is so often the case, a question of proper marketing, and managing expectations. You seem to have acquired a group of users/interested onlookers expecting something they're not getting. Or at least a few loud ones:-) I'm actually fascinated by these 'social science' (i.e. not really a science) aspects of programming languages. If you think about it, programming languages are all about people, how they interact with computers, and how they interact with one another to solve complex problems.
- lacker 18y agoI don't see why you are so dismissive of Unicode handling as it relates to programming language design. To deal with string encoding correctly, your programming language needs to transparently deal with different types of strings, or a single string that has two ways to iterate over it. That's an interesting design problem. In particular, you do not want everything in Arc to be an object. But the typical way other programming languages deal with Unicode nicely is to have different classes that implement a common string interface. So how can Arc approach the string encoding problem without making everything an object? I don't know, but I do think it's an important question.