On Mon, 24 Dec 2001, Jeffrey Siegal wrote: > Andreas Bogk wrote: [snip] > > For the language user, there may be no middle ground. From the > > perspective of the language designer, the syntax is just one issue of > > many, so even if you prefer S-expressions, there's still a lot of Lisp > > to discover in Dylan.
> Did you mean "A lot _for_ Lisp to discover?" There is little in Dylan > that didn't originate with Lisp, except the syntax. What does Dylan > have that Scheme + CLOS + "a collections library" doesn't have?
I don't know if there's a *lot* for Lisp to discover, at least in the sense of finding new constructs or general programming techniques. I suspect that what there is to be learned from Dylan (for dynamic langauges) are in the following three areas:
1) What compromises with conventionality work and don't work.
To wit, if you're going to abandone Lispy syntax, a *Pascal like* syntax probably isn't a good idea?
2) What compromises with staticness work and don't work.
Does sealing really help? How much? How constraining is it? What does it permit by way of optimization that CL doesn't?
Both the above hold only for the limited range of compromises Dylan actually made. But at least there's some more or less production experience with this range.
3) How not to sell a language.
After all, Dylan is *substationally* worse off than Common Lisp. Clearly, Dylan is the *much* more lost cause. One can blame historical circumstances (e.g., Apple's dropping the ball), but, after all, Dylan wasn't resiliant enough to take that blow easily.
It does make me wonder how much of the goals of Dylan would have been better realized as an extention of Common Lisp (e.g., a bunch of packages) rather than merely having been implemented in it.
I still have a soft spot for Dylan, not least because it was reading a Dylan book that introduced me to generic functions, which I think are *incredibly* cool, even if I don't use them :) It was eye-opening. The Lisp (ok, mostly Scheme, but there was some CL in there) documentation I'd read to that point either didn't mention them, or deferred discussion until *much* later in the game. If I'd had Keene's book then, I suspect it would have done the job (it's really quite hard to say enough nice things about her book).
Bijan Parsia <bpar...@email.unc.edu> writes: > To wit, if you're going to abandone Lispy syntax, a *Pascal > like* syntax probably isn't a good idea?
I don't think that introducing a Pascal-like syntax was a bad idea. Dropping the Lispy syntax was the bad idea.
In the static language camp, I can happily mix libraries from Fortran, Pascal, C and C++. If there were interoperability between an infix and a prefix Lisp-like language, that would be a huge win.
> Does sealing really help? How much? How constraining is it? > What does it permit by way of optimization that CL doesn't?
One instance where sealing really helps is arithmetics. Witness Java for a language that gives up it's OO approach for fast integers, and the problems this introduces. In Dylan, integers are objects like all others, still arithmetics is fast, because operations are sealed.
> It does make me wonder how much of the goals of Dylan would have > been better realized as an extention of Common Lisp (e.g., a bunch > of packages) rather than merely having been implemented in it.
I like the "objects from the grounds up" approach, and Dylan feels very clean and consistent to me. That couldn't have been achieved by a couple of libraries.
Andreas
(Followup-To set to comp.lang.dylan)
-- "In my eyes it is never a crime to steal knowledge. It is a good theft. The pirate of knowledge is a good pirate." (Michel Serres)
Jeffrey Siegal <j...@quiotix.com> writes: > I agree about modules, although I don't really like the way Dylan uses > multiple files to define a simple module. There should be a way of
The idea behind Dylan was that the source code resides in a code database, and the file format is just used for interchange. Of course, in reality there are source files, and the interchange format is a little awkward to use. That should be easier, I agree.
> doing that in-line. A CLOS-style object system does have type > annotations, at least at the method level (which is probably enough), > because they're necessary for dispatch.
Having type annotations for bindings gives the optimizer a lot of meat to work on.
> As for conditions, I prefer > passing condition handlers as explicit arguments. With proper tail > calls and limited use of call/cc to escape out of CPS, it works fine.
I don't think so. Having to pass around handlers for all sorts of conditions is a nuisance. This is something CL and Dylan got right, IMHO.
> > Oh, and dynamism vs. performance tradeoffs like sealing, > > primary classes and limited types. > I think these are overhyped features which have been adaquately > addressed in Lisp/Scheme using either different implementations as > needed, declarations, etc.
The point is that you can start writing code without caring about performance. Once the design has settled, you can sprinkle some adjectives here and there, and the code becomes fast, without having to re-implement performance-critical code. I consider sealing to be a good thing.
Andreas
-- "In my eyes it is never a crime to steal knowledge. It is a good theft. The pirate of knowledge is a good pirate." (Michel Serres)
> > To wit, if you're going to abandone Lispy syntax, a *Pascal > > like* syntax probably isn't a good idea?
> I don't think that introducing a Pascal-like syntax was a bad idea. > Dropping the Lispy syntax was the bad idea.
Well, it depends on what you want to do. If you abandon (or deprecate, or hide) a Lispy syntax, presumably it's because you want to please or placate folks who are turned off from Lispy syntaxes. *Developer* type folks (i.e., we're not talking scripting langauges for non-programmers). The only remotely Pascal like syntaxed language that's gained traction in the past decade that I know of is Python, and it dumped begin/end.
(Hmm. Ruby has a bit of that too, IIRC.)
(This is in contrast with Delphi, which is a *holdover*.)
Myself, I don't care at all for C like syntaxes, but I concede that they're more popular. If you're goal is to be popular, you might try past successful moves :) Dylan's syntax wasn't successful for *any* camp.
[snip]
> > Does sealing really help? How much? How constraining is it? > > What does it permit by way of optimization that CL doesn't?
> One instance where sealing really helps is arithmetics. Witness Java > for a language that gives up it's OO approach for fast integers, and > the problems this introduces. In Dylan, integers are objects like all > others, still arithmetics is fast, because operations are sealed.
Eh. I didn't mean these to be questions you answer, but I'll note that you didn't answer 'em. The interesting question is sealing *vs.* a CL like approach.
(Smalltalk looks to this question, too. Optional type declarations plus inferencing are seen as wins; sealing isn't.)
> > It does make me wonder how much of the goals of Dylan would have > > been better realized as an extention of Common Lisp (e.g., a bunch > > of packages) rather than merely having been implemented in it.
> I like the "objects from the grounds up" approach, and Dylan feels > very clean and consistent to me. That couldn't have been achieved by > a couple of libraries.
Is that a *goal* of Dylan, or just something it did?
In any case, that makes me think that you don't know Common Lisp very well :)
>> > To wit, if you're going to abandone Lispy syntax, a *Pascal >> > like* syntax probably isn't a good idea?
>> I don't think that introducing a Pascal-like syntax was a bad idea. >> Dropping the Lispy syntax was the bad idea.
>Well, it depends on what you want to do. If you abandon (or deprecate, or >hide) a Lispy syntax, presumably it's because you want to please or >placate folks who are turned off from Lispy syntaxes.
Then you are no longer practicing technology, but psychology or politics.
> non-programmers). The only remotely Pascal like syntaxed language that's > gained traction in the past decade that I know of is Python, and it dumped > begin/end.
[...]
There is still Ada95 which I consider quite cool. A language that really works platform-independently (Perhaps as there is only one free compiler.... *g*) and deserves more attention.
Regards, Julian Stecklina
PS. I come from the PASCAL camp, so don't blame me too much. ;)
In article <3C27C7BC.DECCE...@quiotix.com>, Jeffrey Siegal
<j...@quiotix.com> wrote: > Andreas Bogk wrote: > > I suggest to take a look at Dylan. It's a pretty recent Lisp-like > > language, and it's got a few things right (but on the other hand > > omitted some features some people consider essential).
> I consider Lisp syntax (or something similarly elegant) to be > essential. I suspect that many proponents of Dylan-like languages would > consider it unacceptable. I strongly suspect there is no middle ground.
I can happily use either. Or paren-less prefix (Logo, ML). Or postfix (PostScript, Forth). But even after much use of the others I find that I do prefer "conventional" syntax.
> (Yes, I'm aware of Lisp-syntax Dylan, but I think there's a reason it > got abandoned.)
The reason as I understand it is that no one could figure out how to bidirectionally map macros between infix and prefix.
I'm not sure whether this is impossible or merely hard.
It's interesting that some of the more complex macros in Common Lisp look uncommonly like the "infix" syntax in Dylan. e.g. the "loop" macro, which is nearly identical to the Dylan "for" statement macro. Thus it might be acceptable to the Lisp-syntax people to essentially retain (nearly?) the same syntax for statement macros in both modes. Function macros are easy to translate. That leaves Dylan's declaration macros to think about.
Another solution might be to explicitly define both syntaxes when you define a macro. More work, but then you don't define new syntax quite as often as you define functions.
<j...@quiotix.com> wrote: > Andreas Bogk wrote: > > > I consider Lisp syntax (or something similarly elegant) to be > > > essential. I suspect that many proponents of Dylan-like languages > > > would > > > consider it unacceptable. I strongly suspect there is no middle > > > ground.
> > For the language user, there may be no middle ground. From the > > perspective of the language designer, the syntax is just one issue of > > many, so even if you prefer S-expressions, there's still a lot of Lisp > > to discover in Dylan.
> Did you mean "A lot _for_ Lisp to discover?" There is little in Dylan > that didn't originate with Lisp, except the syntax. What does Dylan > have that Scheme + CLOS + "a collections library" doesn't have?
Perhaps not a lot that is radical, but simply a lot of nice cleaning up.
- having a "let" where the scope is implicit (to the end of the current progn) is a big win in unclutering code
- Dylan's ":=" and CL's "setf" are the same idea, but := is easier to read for some people.
- same goes for "[]" vs "element()".
- why do aref and gethash in CL have opposite argument orders?
I think you get the point.
None of these (or other) items are critical in themselves, but I find that put all together they provide a cleaner, easier to use (and remember) language.
In article <Pine.A41.4.21L1.0112251208250.33498-100...@login9.isis.unc.edu>, Bijan
Parsia <bpar...@email.unc.edu> wrote: > To wit, if you're going to abandone Lispy syntax, a *Pascal > like* syntax probably isn't a good idea?
I'm not sure what you mean here. Dylan is a lot closer to Modula-2 or Ada than to Pascal. Would you prefer a {}-rich C syntax?
Some people might prefer that -- certainly everything from Perl to Java to Corba has adopted a C-like syntax even if the semantics are way different.
I'm not sure this is easily compatable with an extensible syntax, though. Dylan gets a lot of parsing certainty and error-checking out of having definition macros and statement macros *always* ending in "end". You could easily enough change the parser to look for } instead, but then where would you hang the name of the macro or of the thing being defined e.g. "end" vs "end method" vs "end foo" vs "end method foo", all of which are automatically valid (and checked) in Dylan.
Of course Lisp gets away with just ), so maybe this error checking is overrated.
> 3) How not to sell a language.
> After all, Dylan is *substationally* worse off than Common > Lisp. Clearly, Dylan is the *much* more lost cause. One can blame > historical circumstances (e.g., Apple's dropping the ball), but, > after all, Dylan wasn't resiliant enough to take that blow easily.
Well dispite that Dylan hasn't gone away. The number of users is small, but it seems to be growing. I wonder if Andreas has any stats on the number of hits or downloads at gwydiondylan.org?
Is the number of CL users increasing? Or has it just been around a lot longer?
Hundreds of millions of dollars being spent promoting Java at the same time that Apple dropped the ball certainly didn't help Dylan. But people are starting to see through that, a little.
In article <3C28500F.6652B...@quiotix.com>, Jeffrey Siegal
<j...@quiotix.com> wrote: > Andreas Bogk wrote: > > > What does Dylan have that Scheme + CLOS + "a collections library" > > > doesn't have?
> > That would be conditions, type annotations and a useful module/library > > system.
> I agree about modules, although I don't really like the way Dylan uses > multiple files to define a simple module. There should be a way of > doing that in-line.
No one does. That was supposed to be just an interchange format, not something that users had to deal with. That was the case in the Apple IDE, where all the code was kept in a database.
We've had a bit of discussion recently on a way to put various modules into the same source file. Nothing has been agreed yet, but in Gwydion we have recently done a related thing in implementing a "single-file mode" that lets you write small programs without a library or module declaration at all, with a default set of imports. If/when your program outgrows that you can always add the .lid file.
The ability to put imports/exports in the same file with code is something we definitely plan for fairly soon.
>>>> To wit, if you're going to abandone Lispy syntax, a *Pascal >>>> like* syntax probably isn't a good idea?
>>>I don't think that introducing a Pascal-like syntax was a bad idea. >>>Dropping the Lispy syntax was the bad idea.
>>Well, it depends on what you want to do. If you abandon (or deprecate, or >>hide) a Lispy syntax, presumably it's because you want to please or >>placate folks who are turned off from Lispy syntaxes.
> Then you are no longer practicing technology, but psychology or politics.
<jn...@houseofdistraction.com> wrote: >>>Well, it depends on what you want to do. If you abandon (or deprecate, or >>>hide) a Lispy syntax, presumably it's because you want to please or >>>placate folks who are turned off from Lispy syntaxes.
>> Then you are no longer practicing technology, but psychology or politics.
>Successful language design is all these things.
True. Unless one gets mind share ( and consequent market share ) language design is meaningless.
Bruce Hoult <br...@hoult.org> writes: > Well dispite that Dylan hasn't gone away. The number of users is small, > but it seems to be growing. I wonder if Andreas has any stats on the > number of hits or downloads at gwydiondylan.org?
I don't have reliable download stats, since there are a lot of mirrors, but a new release generates a few hundred downloads at the main FTP site. The web server served about a million requests since I keep stats (beginning October 99), and currently about 1500 pages are requested per day.
Andreas
-- "In my eyes it is never a crime to steal knowledge. It is a good theft. The pirate of knowledge is a good pirate." (Michel Serres)
>>>I suggest to take a look at Dylan. It's a pretty recent Lisp-like >>>language, and it's got a few things right (but on the other hand >>>omitted some features some people consider essential).
>>I consider Lisp syntax (or something similarly elegant) to be >>essential. I suspect that many proponents of Dylan-like languages would >>consider it unacceptable. I strongly suspect there is no middle ground.
> I can happily use either. Or paren-less prefix (Logo, ML). Or postfix > (PostScript, Forth). But even after much use of the others I find that > I do prefer "conventional" syntax.
It isn't a question of using. It is a question of being able to define new syntax without stretching or breaking the inherent limits of the existing syntax. Lisp lives essentially forever in the world of computer languages because it almost can't be outgrown. To the extent that Dylan lives at all, it will still die when the world decides that objects aren't that central to programming after all, and moves on to some other model, or when someone comes up with a new syntactic construct that it is incompatible with Dylan's syntax. Lisp will live on.
>>(Yes, I'm aware of Lisp-syntax Dylan, but I think there's a reason it >>got abandoned.)
> The reason as I understand it is that no one could figure out how to > bidirectionally map macros between infix and prefix.
> I'm not sure whether this is impossible or merely hard.
And the reason the decision was made to drop prefix rather than infix when that happened was the overriding goal of trying to sell Dylan alongside Java or C as a language for the great masses. (Which today seems utterly absurd.)
Many smart people have observed that when you encounter a "hard" (if not impossible) problem, you have already made a mistake somewhere back down the road. Trying to "add" an infix syntax without recognizing that this almost certainly means losing expressive power and generality was just such a mistake.
> Another solution might be to explicitly define both syntaxes when you > define a macro. More work, but then you don't define new syntax quite > as often as you define functions.
Andreas Bogk wrote: >>doing that in-line. A CLOS-style object system does have type >>annotations, at least at the method level (which is probably enough), >>because they're necessary for dispatch.
> Having type annotations for bindings gives the optimizer a lot of meat > to work on.
I'm not so sure about that, given good type inference, and methods that are kept reasonably small. In any case, it is a trivially small matter to add type bindings to let statements one they exist for methods.
>>As for conditions, I prefer >>passing condition handlers as explicit arguments. With proper tail >>calls and limited use of call/cc to escape out of CPS, it works fine.
> I don't think so. Having to pass around handlers for all sorts of > conditions is a nuisance. This is something CL and Dylan got right, > IMHO.
Chocolate and vanilla. I would add that explicitly passing condition handlers around is a bit like explicit typing, becuase it prevents you from leaving conditions unhandled.
>>>Oh, and dynamism vs. performance tradeoffs like sealing, >>>primary classes and limited types.
>>I think these are overhyped features which have been adaquately >>addressed in Lisp/Scheme using either different implementations as >>needed, declarations, etc.
> The point is that you can start writing code without caring about > performance. Once the design has settled, you can sprinkle some > adjectives here and there, and the code becomes fast, without having > to re-implement performance-critical code. I consider sealing to be a > good thing.
I do this in Scheme today, and I don't even sprinkle adjectives here and there, by developing in a developer-friendly environment and then switching to a highly-optimized block compiler for tuning and production.
> >>>I suggest to take a look at Dylan. It's a pretty recent Lisp-like > >>>language, and it's got a few things right (but on the other hand > >>>omitted some features some people consider essential).
> >>I consider Lisp syntax (or something similarly elegant) to be > >>essential. I suspect that many proponents of Dylan-like languages would > >>consider it unacceptable. I strongly suspect there is no middle ground.
> > I can happily use either. Or paren-less prefix (Logo, ML). Or postfix > > (PostScript, Forth). But even after much use of the others I find that > > I do prefer "conventional" syntax.
> It isn't a question of using. It is a question of being able to define > new syntax without stretching or breaking the inherent limits of the > existing syntax. Lisp lives essentially forever in the world of > computer languages because it almost can't be outgrown.
That's true only in the trivial sense that Lisp has no syntax, so Lisp syntax can't be outgrown. Dylan has pretty much all the same semantics as Lisp, and a malleable syntax.
> To the extent > that Dylan lives at all, it will still die when the world decides that > objects aren't that central to programming after all, and moves on to > some other model, or when someone comes up with a new syntactic > construct that it is incompatible with Dylan's syntax. Lisp will live on.
There is no such construct. If it can be fitted into Lisp's functions-only notation then it can also be fitted into Dylan's functions and function-macros. In Dylan in may well be *better* fitted into statement macros, but that's an additional possibility, not a restriction.
> >>(Yes, I'm aware of Lisp-syntax Dylan, but I think there's a reason it > >>got abandoned.)
> > The reason as I understand it is that no one could figure out how to > > bidirectionally map macros between infix and prefix.
> > I'm not sure whether this is impossible or merely hard.
> And the reason the decision was made to drop prefix rather than infix > when that happened was the overriding goal of trying to sell Dylan > alongside Java or C as a language for the great masses. (Which today > seems utterly absurd.)
Why? Since that decision was made, the great masses have adopted both Java and Perl, while Lisp has remained in the wilderness. I don't see any reason to think that infix syntax is a *disadvantage* to the goal of attaining popularity. The time may simply be not yet right. After all, it is only just now that reasonably mature Dylan implementations are becoming available.
> Many smart people have observed that when you encounter a "hard" (if not > impossible) problem, you have already made a mistake somewhere back down > the road.
Or no one had the correct "ah-ha" moment yet.
> Trying to "add" an infix syntax without recognizing that this > almost certainly means losing expressive power and generality was just > such a mistake.
In your opinion.
> > Another solution might be to explicitly define both syntaxes when you > > define a macro. More work, but then you don't define new syntax quite > > as often as you define functions.
> That would be very error prone.
A great many things in programming are error prone. In fact anything in which it is impossible to make a mistake is almost certainly not powerful enough to be useful. It is reasonable to expect that programmers have *some* skill. Also, even if a compiler can't reasonably translate an infix macro to a prefix macro (or the reverse), it seems entirely reasonable for it to apply some consistency checks to two such macros supplied by a human.
Bruce Hoult wrote: > That's true only in the trivial sense that Lisp has no syntax, so Lisp > syntax can't be outgrown.
Hardly. It just has a syntax with a very simple and powerful basic construction rule. However, on top of that construction rule, enormously powerful syntactic abstractions can be (and are) built. What Algol-like languages lack is the basic construction rule which allows you to decompose the syntax down into elemental componets. That makes any macro system either enormously complex or lacking in power, or both.
Consider, for example, what low-level Lisp macros would look like in an Algol-like language. They can be done but the result is enormously complex (and also fragile; if the language syntax is extended, macros written that way will likely break).
> There is no such construct. If it can be fitted into Lisp's > functions-only notation then it can also be fitted into Dylan's > functions and function-macros.
Of course it can, just as you could write a Lisp interpreter in Dylan and use that. But at some point it becomes language-abuse, not language-use, becuause the facilities the language provides to help you end up either being in the way, or being useless warts. I can tell you from experience that trying to do extremely complex things with function-style macros in an Algol-like language is far, far worse than doing the same thing in Lisp, since such things are a natural extension of the Lisp syntax but stronly conflict with the flavor of an Algol-style langauge. Yes, it can be done that way, but it might as well not be possible because no one will want to use it.
> > And the reason the decision was made to drop prefix rather than infix > > when that happened was the overriding goal of trying to sell Dylan > > alongside Java or C as a language for the great masses. (Which today > > seems utterly absurd.)
> Why?
I didn't mean the decision was absurd at the time, just that the possiblity of Dylan being sold to the great masses today is absurd. Dylan is a useful niche language, which is all it will ever be. As a niche language, though, you don't need to sell it with a candy-coated syntax. I might be using it today if the Lisp syntax had been retained, but I have no interest whatsoever in an Algol-syntax niche langauge. If I'm going to use such a langauge, it is going to at least be a mainstream one with all of the benefits that acrue from that status (i.e., all things considered I'd rather use Java, and I do, than Dylan, despite recognizing that Dylan is a much nicer language).
> Since that decision was made, the great masses have adopted both > Java and Perl, while Lisp has remained in the wilderness. I don't see > any reason to think that infix syntax is a *disadvantage* to the goal of > attaining popularity.
I wasn't suggesting that.
> The time may simply be not yet right. After all, > it is only just now that reasonably mature Dylan implementations are > becoming available.
With all due respect, I think you are dreaming, and I think some honest self-reflection would confirm that.
> > Many smart people have observed that when you encounter a "hard" (if not > > impossible) problem, you have already made a mistake somewhere back down > > the road.
> Or no one had the correct "ah-ha" moment yet.
Taking a path which requires an as-yet-unknown "ah ha" to suceed is a design error. It is those moments which make new paths feasible. Blind leaps occasionally do lead there (I'm a big fan of evoluationary learning), but when they don't, you should be willing to accept that the leap was a mistake and backtrack.
> > Trying to "add" an infix syntax without recognizing that this > > almost certainly means losing expressive power and generality was just > > such a mistake.
> In your opinion.
Absolutely true.
> > > Another solution might be to explicitly define both syntaxes when you > > > define a macro. More work, but then you don't define new syntax quite > > > as often as you define functions.
> > That would be very error prone.
> A great many things in programming are error prone. In fact anything in > which it is impossible to make a mistake is almost certainly not > powerful enough to be useful. It is reasonable to expect that > programmers have *some* skill.
Requiring a programmer to maintain two distinct pieces of code which are supposed to have the same effect is something that experience shows to be extremely difficult and error prone. As development practices go, such an approach is best avoided.
On Wed, 26 Dec 2001, Kaz Kylheku wrote: > In article > <Pine.A41.4.21L1.0112251809070.29424-100...@login6.isis.unc.edu>, Bijan > Parsia wrote: > >On 25 Dec 2001, Andreas Bogk wrote:
> >> > To wit, if you're going to abandone Lispy syntax, a *Pascal > >> > like* syntax probably isn't a good idea?
> >> I don't think that introducing a Pascal-like syntax was a bad idea. > >> Dropping the Lispy syntax was the bad idea.
> >Well, it depends on what you want to do. If you abandon (or deprecate, or > >hide) a Lispy syntax, presumably it's because you want to please or > >placate folks who are turned off from Lispy syntaxes.
> Then you are no longer practicing technology, but psychology or politics.
Well, some others have responded, and I'd hoped not to get dragged back it, but I think that if this was intended as a criticism, it was misguided. First off, I'm not sure what "practicing technology" means. Second, presumably when you're designing something to be used by humans, attending to psychology is important. Third, presumably language design, if it is practically and production oriented, has to take account of economic and political factors. From the postings of many, e.g., Kent Pitman, I see the design of Common Lisp very strongly governed by the psychology, politics, and economics of its varying user base. Pure technical "goodness" is to be weighed against lots of other things.
I was trying to suggest that there may be stuff on the *political* side for Lisp to learn from Dylan. Is it really controversial that it's a fairly risky move to adopt a Pascal like syntax than can't be easily mapped back into a Lispy one? I mean, who do you win over with that move?
OTOH, given Python's growing user base (and note, python's syntax is an *issue* for many folks; witness the whitespace wars on comp.lang.python) there might be some lessons to draw from Dylan for either Python (how to smoothly integrate more Common Lisp stuff into Python) or Common Lisp (how to layer a popular syntax on top). Not that Dylan necessarily has to have the *answers*, but even if it screwed all these up, it might be worth examining a worked out failure.
In article <jd1j2uggcr52j22jtk7cu43crp41l75...@4ax.com>, israel r t wrote: >On Tue, 25 Dec 2001 23:12:51 -0800, jeff ><jn...@houseofdistraction.com> wrote:
>>>>Well, it depends on what you want to do. If you abandon (or deprecate, or >>>>hide) a Lispy syntax, presumably it's because you want to please or >>>>placate folks who are turned off from Lispy syntaxes.
>>> Then you are no longer practicing technology, but psychology or politics.
>>Successful language design is all these things.
A psychologically successful design arises out of psychology. A technically successful design arises only out of good technology.
>True. Unless one gets mind share ( and consequent market share ) >language design is meaningless.
That is utter nonsense.
A machine can understand whatever language you want it to understand. Users are usually not aware of what language a delivered program is written in.
There have existed programming languages which were unique to the application that they were integrated into. That application was successful nevertheless, nonexistent mind share of the hidden language notwithstanding. Thus even completely unknown, unique programming languages can be used successfully in a program that has a shot at becoming widely used.
It's nice to have a community surrounding a programming language; there are benefits from not being the only one using it. You're unlikely to have a high quality implementation for multiple platforms if you're the only user. But if 99.999% of the apparent community is clueless, then the real community is just the remaining 0.001%.
For instance, out of all the C++ programmers, how many really know the ISO standard C++? Informally, one gets the impression that the proportion is vanishingly small.
Somehow, the bulk of the remaining users don't manage to contribute to the quality of the language or of the available tools. They don't even know exactly what those tools are supposed to implement.
So in the end, popularity of a language is something that only matters to the inventor and to some tool vendors. To the developer, it provides no useful benefit. In fact, it is a liability. Language popularity makes the tool vendors complacent, and at the same time ensures that the job market is full of programers who all cite knowledge of that language on their resumes. If you need a developer, you get a truckload of resumes, most of which are chaff. If you need a job, your resume ends up in such a truckload. Microsoft Visual C++ is undoubtedly the most popular C++ implementation; perhaps not by coincidence, has the worst standard compliance, and is packaged in a horribly inefficient, buggy, unreliable development environment. There is zero motivation to do anything about it.
The decision about what language to use should be made on purely technical and economic grounds, because the success of the software depends on it. There are sound technical reasons for preferring Lisp syntax, whereas there is no technical reason for preferring, say, Pascal or C syntax. People who only know non-reflexive languages think that syntax is just such a matter of taste. Or worse, that its details are somehow semantically significant: that, for instance, being able to write while (*s) *d++ = *s++; is somehow inherently powerful, compared to splitting the operation into several expressions, when in fact the clueful user writes a call to strcpy(). People who understand Lisp know that seemingly convenient syntax can actually become a huge barrier between the user and the language. So the choice of syntax actually has real implications; it's not just some emotional matter of taste, but another techical decision. You're not selling the language, but software. Catering to tastes may not be the best thing for the end result you are trying to achieve.
Yes, psychology must be taken into account when designing software for people. And there is a domain where those considerations are appropriate: human-computer interface design.
There is another domain in which psychology is relevant: software engineering. The success of large scale development is critically tied to the limitations of the human brain. Programming languages which are designed to exhibit a convenient syntax in tiny programming examples are successful at seducing naive programmers, so on one level they are the result of successful psychology. But the important psychology, which has an impact on the technical success of software development, is overlooked. Human beings require abstraction in order to avoid cognitive overload: trying to understand the large scale pattern in a morass of insignificant details. Therefore programming languages need to be able to express abstractions. The choice of syntax becomes important, because it affects how easy it is to make the syntax of the language programmable, at the right level of abstraction, where the programmer can have the illusion that he's working directly with that syntax, rather than some translated representation of it.
In article <bapW7.51884$cv4.1651...@news1.calgary.shaw.ca>,
Kaz Kylheku <k...@ashi.footprints.net> wrote: >In article <jd1j2uggcr52j22jtk7cu43crp41l75...@4ax.com>, israel r t wrote: >>On Tue, 25 Dec 2001 23:12:51 -0800, jeff >><jn...@houseofdistraction.com> wrote:
>>>>>Well, it depends on what you want to do. If you abandon (or deprecate, or >>>>>hide) a Lispy syntax, presumably it's because you want to please or >>>>>placate folks who are turned off from Lispy syntaxes.
>>>> Then you are no longer practicing technology, but psychology or politics.
>>>Successful language design is all these things.
>A psychologically successful design arises out of psychology. >A technically successful design arises only out of good technology.
Ergonomics and interface design are aspects of technology that take into account the physiology and psychology of the users.
One could claim that assembly or machine language is the best technical solution to programming computers, because it allows you to take advantage of all the computer's features. But this discounts the psychological effort that it takes to program in machine language compared to high level languages. HLL's owe their existence to psychological needs.
-- Barry Margolin, bar...@genuity.net Genuity, Woburn, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Jeffrey Siegal <j...@quiotix.com> writes Re: New Lisp ?
> Consider, for example, what low-level Lisp macros would look like in an > Algol-like language. They can be done but the result is enormously > complex (and also fragile; if the language syntax is extended, macros > written that way will likely break).
I wonder what you think or someone who knows them as well as LISP macros thinks of CamlP4 or of parse-tree filtering in Erlang. These may not be as seamlessly integrated in their mother language as are LISP macros, but they look very promising.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] [ TUNES project for a Free Reflective Computing System | http://tunes.org ] A language that doesn't affect the way you think about programming, is not worth knowing. -- Alan Perlis
In article <uhpW7.14$Mv6.32437@burlma1-snr2>, Barry Margolin wrote: >In article <bapW7.51884$cv4.1651...@news1.calgary.shaw.ca>, >Kaz Kylheku <k...@ashi.footprints.net> wrote: >>In article <jd1j2uggcr52j22jtk7cu43crp41l75...@4ax.com>, israel r t wrote: >>>On Tue, 25 Dec 2001 23:12:51 -0800, jeff >>><jn...@houseofdistraction.com> wrote:
>>>>>>Well, it depends on what you want to do. If you abandon (or deprecate, or >>>>>>hide) a Lispy syntax, presumably it's because you want to please or >>>>>>placate folks who are turned off from Lispy syntaxes.
>>>>> Then you are no longer practicing technology, but psychology or politics.
>>>>Successful language design is all these things.
>>A psychologically successful design arises out of psychology. >>A technically successful design arises only out of good technology.
>Ergonomics and interface design are aspects of technology that take into >account the physiology and psychology of the users.
That's correct; that's who you are trying to sell some product to, or so I'm assuming.
>One could claim that assembly or machine language is the best technical >solution to programming computers, because it allows you to take advantage >of all the computer's features. But this discounts the psychological >effort that it takes to program in machine language compared to high level >languages. HLL's owe their existence to psychological needs.
Which is something that I mention at the bottom part that you snipped. Those psychological needs are still driven by the need to create sophisticated, reliable software. Making a language popular requires a different use of psychology manipulation that has nothing to do with enabling users to make software; it has to do with manipulating their egos and insecurities, or appealing to what they find familiar. There is a difference between using the psychology to create acceptance, and using psychology to best adapt the machines and tools to human capability.
So it boils down to what you mean by successful language design. Israel R T, for instance, thinks that successful equals popular. Thus, for instance, Visual Basic is a successful design.
Francois-Rene Rideau wrote: >>Consider, for example, what low-level Lisp macros would look like in an >>Algol-like language. They can be done but the result is enormously >>complex (and also fragile; if the language syntax is extended, macros >>written that way will likely break).
> I wonder what you think or someone who knows them as well as LISP macros > thinks of CamlP4 or of parse-tree filtering in Erlang.
I have not looked at them before so I am not very familar with them. I looked quickly at CamlP4 and it looked very similar to what I've seen before in terms of attempts to do this. In particular, fairly complex, and requiring the programmer to understand quite a bit about parsing theory and practice (an interesting field, but not one that every programmer necessarily knows about or wants to know about).
Anyone who can not see that the complexity of such things is a strong argument in favor of a simple Lisp-like syntax[*] is blind or prejudiced. Perhaps not an overriding argument that would cause one to use a Lisp-syntax despite other issues, but still...
[*] By "Lisp-like" syntax I mean a syntax that can be constructed and decomposed using a few simple, easy-to-understand rules. It doesn't neceessarily need to be Lisp-syntax itself. For example, it might use indentation rather than parenthesis to indicate nesting. Or it might be something else. But whatever it is, it should reduce to some sort of logical and simple internal form, not some mostly random collection of Algol-like constructs that exist largely the result of a string of historical accidents.
k...@ashi.footprints.net (Kaz Kylheku) writes: > People who only know non-reflexive languages think that syntax is > just such a matter of taste. Or worse, that its details are somehow > semantically significant: that, for instance, being able to write > while (*s) *d++ = *s++; is somehow inherently powerful, compared to > splitting the operation into several expressions, when in fact the > clueful user writes a call to strcpy().
To pick an OT nit, that won't do what strcpy() does; it won't copy the null terminator. What you want is while (*d++ = *s++) ;
