.. and just one more point from your last posting.
Why do you keep telling people how much you dislike me? Do you think that there is anyone reading this newsgroup who really cares about that? Don't you realize that it reduces your credibility to near zero when you then make some statement about me because people now see that the motivation for your post may not be to provide information to the readers of this group but instead is just a lie to get back at me for whatever it is that I did to you (which is still a mystery to me).
[...] CR> Sometimes, I suspect that dealing with the lower-level OS CR> calls becomes necessary, no matter how good the CR> abstractions.
I agree with this. The the frequency with which this happens depends on whether the abstraction was appropriate for the problem you are trying to solve. Maybe one way to measure it is to think if the OS interface abstractions will get in the way, _other_ stuff will also, causing one to write very specialized code (eg: real time stuff).
CR> However, by their nature, it would seem silly to CR> standardize on an interface given that to at least some extent CR> there's a moving target.
I don't know why I didn't think to say this last night, but there is POSIX at least which even NT+ Windows purport to support AFAIR.
CR> However, what would make me feel good is to see (public) CR> debate on what a current interface would be like, just so that CR> I (and others) can see what has been considered and rejected, CR> and so that where there are good ideas others can use them.
I would like that also. Two things have come up relatively recently in this NG that I remember: timer/timeout stuff, and event-driven IO as opposed to multiple blocking threads. Maybe we could come up with some small set of programs that expose those bits of OS-assisted functionality to be rewritten in multiple implementations as a starting point.
Also note that my feeble attempt to change the course of this thread to something technical has failed, so maybe we should top post a new thread and hope for interest there.
[...] CR> There are several approaches that can be taken here. One is as CR> a wrapper to exec() and friends, so that its signature would CR> look something like:
CR> Another approach could be to use system() (or /bin/sh -c); CR> then run-unix-program would be like:
CR> run-unix-program (string)
CR> So far, so non-controversial.
Even then, I worry about details. At the lower level this is traditionally done by fork+exec. Unless a variant of fork (vfork afair) is used, you might actually be forking a huge process which w/o overcommit might exhaust your vm. This is not necessarily a made-up example, think of a long running AI-ish program that grows to 1gig and then 'system's out a sendmail to let you know about progress...
CR> However, there's a certain CR> amount of pain and suffering involved if you are porting CR> between implementations; in particular, if you've used the CR> first form and are trying to implement it in an implementation CR> with only the second.
Yes, maybe in this case the thing to think about is whether or not the Unix people were drunk when they came up with the 4(?) variants of exec. Maybe that was the best compromise? I often find that bits of odd looking functionality in syscalls/libc is actually necessary. They may not be pure and elegant, but given what you are dealing with (unix), they are not gratuitious monstrosities. Now, CL folks usually have a pragmatic approach to elegance and minimalism as evidenced by other useless threads here I won't name. Maybe that approach should carry over?
[good stuff deleted]
CR> The point I'm trying to make is that a certain amount of CR> public discussion on these non-standard features (not just OS CR> interaction) might be beneficial, both for implementors and CR> users, even if it's only to the level of making some CR> suggestions for differences to expect between :unix and CR> :windows on the *features* list.
> > So maybe there isn't only one Lisp vendor, maybe there are 1.84, maybe > > even 2. > What interesting implications. How many vendors are there for Perl? > Python? Ruby? Smalltalk? OCaml? Haskell?
The only one of these people pay for, and probably the only one acceptable for developing more than cgi-like applications or doing glue-work in a reasonable number of organizations, is Smalltalk. At my last count there were six commercial vendors, plus Squeak - a product available for free but built by a large team of full time professionals, and relatively easy to port and maintain. Ocaml is about equivalent to Squeak (and there are non-Ocaml commercial ML's). Perl, Python and Ruby have adequate, well-supported, portable, constantly maintained implementations that make up for the lack of a commercial system. (Plus for several of them you can call on ActiveState etc for support, if your tastes run that way.) Even Haskell has university funded teams updating and fixing compilers. As good is it is as a language, Lisp is way behind on these issues, which do figure in a lot of organisations decision making.
> I just want to add my support to this posting as a new Lisp possible > user. I have come lately to both Lisp and Python and although coming > to Lisp has been like a coming home. This is a really amazing > language, so much power, elegance, and readable code. It is amazing > to me that I could go into the source files of clisp and not only > understand the code, but feel confident enough to make changes that > worked.!!!
...
> As an outsider looking in I see an amazing tool and language that is > not supported by much of its users which to me makes no sense. If you > don't like it why do you use it? And I hope the sparks that are there > do start to grow and become a fire. Personally when I know enough > about the language enough I am going to be doing all I can to improve > the libraries out there where I can, I have never been so caught by a > language and I would consider it a major tragedy that it disappeared > due to lack of support.
Maybe they are bunch of old foggies who forgot how to laugh!
What you say is definitely true and I am glad you are one the people who has made a sincere effort to learn Lisp. The main fret in this thread is about getting other people to support Lisp's use in (money-making) circumstances. I did some work awhile ago for one of those dot-coms. Just five people, two programmers (one guy doing dynamic web-page generation in PHP, the other using Java to build tools to populate the database), the owner, a documentator and me (part-time project manager/filler-in). There was a part do be done that had automatic newsletter generation from a database and eventually into PDF/Postscript files. The guy doing that part spent 6 weeks using PHP and in that time had nothing to show for it. The endeavour was next to failing, so I thought, hey, I will try to do that part in Lisp (originally ACL/FreeBSD then CMUCL/FreeBSD). One week later (40 hours in total) I had the first version running, complete with a web interface to see the generated newsletters. I showed the work to the others in the group and the other programmer looked at it and said, "Thats good, if you had to do it over in Java it wouldn't take much time at all". Now why would he say that? He's been a programmer for a long time. He has seen Lisp (he loves Emacs!). The primary reason I believe is that he was trying to get more money out of the owner by using things that
1) Are preceived as awesome technology, like Java, so they will pay more for a precieved race-horse. 2) Which stretch out the job, so you have more chargable hours
Guess what? The company did not deliver then folded. Wasted time, wasted effort, I just pity the owner who shelled out for it from his own pocket.
Lisp is really awesome. But there is story I have to relate..
I worked as a construction coodinator earlier in my life. We subcontracted out the welding of a new pipeline system for delivering natural gas. This company hired this old experienced welder who on his first morning welded 13 pipe joints. That afternoon the other welders approached him and pointed out the average (and acceptable) number of welds to do in the morning was 2. The next day he was gone.
The beef is not really with Lisp, its with people.
Tim Moore wrote: > On 2 Sep 2001, Erann Gat wrote:
> Maybe we're too busy writing Lisp programs to take silly polls?
> I use Common Lisp to do my income taxes. This year I had work under way > to automatically fill out the IRS pdf forms, but then I saw how much I > owed and lost interest.
> Tim
Tim:
This looks like an interesting thing to do. Would you mind sharing how you did it? Even better, can we get handle on the code (or parts fo it) if it is not part of any proprietary product you are developing.
In article <MPG.15fd385e636fc08f989...@news.dnai.com>, John Foderaro wrote: > In article <3208515900839...@naggum.net>, e...@naggum.net says...
>> I am not sure what would constitute sufficiency in doing your bidding. >> Would you please explain how you arrived at "He couldn't find a single >> one" so I can see what kind of proof you require?
> Sure. here's what I wrote in the message you replied to:
> From now on please don't tell people what you *think* I said:
> John Foderaro expresses a very strong hatred for the standard as > such, and the standardization process in particular.
> Instead go to http://groups.google.com and find the exact message I sent and post the > exact text I wrote along with a link to the article so everyone else can see the > context. You can start with the message from which you derived the above statement.
> So I'm asking that you produce postings or writings by me that would backup your > statement that I've been out trying to get people to disregard the standard.
>> I would also like to >> see you find the actual references for the following statement:
>> > Your insistence that people knowledgeable about Common Lisp pretend that >> > the langauge has no flaws means you want us to appear to be stupid or >> > liars.
> That's fair. In this case there's lots of quotes to choose from but for simplicity > let's go to your original message that started this thread. You classify people as > sane or insane based simply on whether they agree with you on what you like in the > language: > erik: > Now, when I approach a Common Lisp vendor, I fully _expect_ him to share > my enthusiasm for the technology I want to purchase from him and probably > to exceed mine because he created something great for a great language > and since I have discovered both the great language, the great product, > and the great vendor, we should be able to share a _lot_ of enthusiasm. > If the vendor does not share my enthusiasm, there is something _wrong_ > with him. If the vendor insults what I think is great, he is insane -- > no two ways about that.
> In other words you want vendors to mindlessly echo back your enthusiasm. You don't > want to hear what the vendor may have learned through years of experience about what > could potentially be a problem for you using the language in your project. You don't > want the truth. You can't handle the truth.
I think Erik was looking for mindful agreement and enthusiasm. Every vendor I have worked with will always try to put there products in the best possable light and this is the 'sane' thing to do. If you do not do this then it is not sane or insane. I am doing this from what I rember of what he wrote and the above quote in this thread and any mistakes are mine.
I just took a look at opensource.franz.com/postoffice project and when looking at the source(imap.cl and smtp.cl) and saw the 'if*' macro in the code for both files, with no pointer to an auxilary file where it is defined. Now I go to the hyperspec and look for 'if*' and its not there and I am using cmu for example and it blows up. Here is the only pointer to how to try to figure out where is this odd 'if*' thing: imap.cl:;; imap.cl:;;- This code in this file obeys the Lisp Coding Standard found in imap.cl:;;- http://www.franz.com/~jkf/coding_standards.html imap.cl:;;- so I finaly go and read the coding standard in hopes of finding a url or pointer to fix my problems. Mow the first sentence of the first rule, on a document on franz's website starts like this:
Use if* instead of the bogus-three-conditionals: if, when and unless
This is an odd way for franz to show that they support common lisp and would at the very least make me look for someone else to give my money to or just pick another language for the project. That you put it up is one thing, that your management lets it stay up in its current form is realy amazing to me. This document bites the standard that feeds franz and you. Now 2 lines down you insult my inteligence with the following:
Glancing at the form (if aaaaaaaa bbbbbbbb cccccccc) you tend to see that three values are being evaluated in order: aaaaaaaa then bbbbbbbb and then cccccccc
What I think a incomptent or better lisp programmer would have figured out that (if a b c) is a special form and that only b or c is evaluated based on the truth value of a, this is exactly how it worked in basic in highschool and pascal, cs101, in college. Currently I am an incomptent lisp programmer, I am trying to fix that though. I will skip commenting on rule 2 because I do not know enough to have an oppinion yet. On to rule 3 here is one sentence from it:
At the same time, don't obscure the important comments by surrounding them with trivial comments.
and here are some comments from imap.cl:
imap.cl:136: ((mailbox-name ; currently selected mailbox imap.cl:141: ;; string that separates mailbox names in the hierarchy imap.cl:145: ;;; these slots hold information about the currently selected mailbox: imap.cl:147: (message-count ; how many in the mailbox imap.cl:151: (recent-messages ; how many messages since we last checked imap.cl:155: (uidvalidity ; used to denote messages uniquely imap.cl:160: :accessor mailbox-uidnext ;; predicted next uid imap.cl:163: (flags ; list of flags that can be stored in a message imap.cl:167: (permanent-flags ; list of flags that be stored permanently imap.cl:171: (first-unseen ; number of the first unseen message imap.cl:210: name ;; often the person's full name imap.cl:212: mailbox ;; the login name imap.cl:213: host ;; the name of the machine
Some of these seem trival in the extreme, line 213 for example. If your standard is so good why is it not followed by source files that have it listed in there comments for reference. One last thing when you have code that is diffacult to read you should fix the code not explain it. I have many english teachers tell me not to explain your paper but to write it clearly in the first place. Using excessive comments is telling me about your code.
I would like to thank franz for writting smtp.cl and imap.cl I have a project that I would use it on after I get all the if* stuff out of it.
And I think that everyone has the right to use whatever macros they want. But with that said from looking at it I think cond is much better to look at then your stuff. I always thought a case, switch. cond statement was MUCH clearer then a long series of nested if statements to read.
One last thing in the source code please put a reference to where to get the macro source, just for clarity sake.
John Foderaro <j...@unspamx.franz.com> writes: > Are you purposely trying to confuse people here?
> I'm not the one who made the big deal of that document on if*, you are. > You took it as an attack on the Common Lisp standard. In fact it > is just the opposite. It shows that Common Lisp gives you the > flexibility to define forms that make your code easier for you to > read. Java doesn't allow that. C and C++ give you a very weak > macro extension language.
There is a difference between showing people that they can define their own little convenience macros, and publically calling upon people to use a particular macro as a replacement to standardized core language constructs, claiming along the way that those constructs are bogus, with little to no objective evidence.
There is a reason that nearly every language in existence standardizes a certain amount of basic control-flow operators, even if it could get away with far less due to the existence of syntax-extension mechanisms.
There are reasons for including such constructs as IF, WHEN, UNLESS, CASE, TYPECASE, etc. in the core language standard, even if all of them can just as easily be defined by each user with macros based on COND. And that reason is _WIDE READABILITY_! IF, WHEN and UNLESS aren't readable based on their own merits, or not. They are readable by the whole community because they are part of the shared understanding, because they are part of the standardized language. If a reader sees an IF, WHEN or UNLESS, they don't have to worry about the exact semantics those constructs might currently have, because the exact semantics have been prescribed, once and for all, in the ANSI CL standard, and are not subject to changes.
If we follow down the John Foderaro route of everyone inventing their own basic control-flow operators, we will soon have 10s of IF*, BIF, IFF, etc. operators, each one with their own little syntactic sugar, and their own little semantic idiosynchrasies, understandable only upon studying yet another specification (if there is one, besides the implementation code).
And since basic control-flow operators are central parts of any language, what this will basically mean is that we will have 100 twisty little Common Lisp dialects, all different. We've been there before, when we had 10 industrial-strength Lisp dialects, all differing in little details even on the constructs they shared. This is something that Common Lisp was created to avoid happening again.
Even with C's pre-processor macros it is possible to do
#define BEGIN { #define END }
or even
#define IF(x,y,z) ((x)?(y):(z))
But no serious C user will ever contemplate doing such a fundamentally stupid thing, let alone any expert C user. Try posting such suggestions on comp.lang.c, and you will get a serious lecture as to why this would be fundamentally stupid, and don't you want to go over there to comp.lang.pascal, or wherever you came from?
Yet somehow over here in Common Lisp land, we are supposed to hail people who publically advance such dubious proposals, outside any relevant standardization effort, as saviours of Common Lisp, and demonstrators of its power?
And for what gain are we deliberately risking the splintering of Common Lisp into mutually incompatible sub-dialects? If this was some fundamental advancement, like e.g. a fully reflective Lisp system, I could maybe see the sense of this. But for an improvement that (if it was there to begin with), can only be described as a small, incremental improvement, I just cannot see how it would be wise to incompatibly change the status quo (and incompatible change is needed, since the supposed readability of IF* can only be realized if it supplants IF/WHEN/UNLESS in time). And the improvement (again I really doubt there is a general improvement) can only be described as light, since it seems that many, many programmers have been able to read code using IF/WHEN/UNLESS without undue problems, it seems, otherwise we'd probably have regular criticism of IF/WHEN/UNLESS on c.l.l all the time.
I'm afraid it seems to me that certain members of the CL community seem to have not a clear enough understanding of the fundamental values of a standard, and a community-wide consensous, prefering instead to go off on a wild chase of their own personal ideal Lisp.
This seems quite unlike most other language communities I've encountered.
Regs, Pierre.
-- Pierre R. Mai <p...@acm.org> http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein
Discussion subject changed to "McCLIM and other GUI's was: Re: What I want from my Common Lisp vendor and the Common Lisp community" by Peter Van Eynde
Can I just mention that the Eclipse guy found a bug in CLX that probably has been in there since the dawn of time. Nobody ever tried to write a window manager with CLX it seems :-(.
Anyway, the fix is in the new-CLX CVS tree on sourceforge in the cclocc project. I've been trying to rejuvenate CLX by porting it to the cclan/port interface, so far it works on cmucl and should on ACL, LW and clisp. It features XAUTHORITY support and using PF_UNIX sockets.
Patches are welcome.
> I profit by the occasion for thanking all of you.
McCLIM is maybe the most exiting thing happening in the Common Lisp work for the last few years...
(with-mode (:dark) Can I just mention that it is strange how much people complain that nothing is happening and yet I always see only the same brave souls on cliki, cclan, cclocc, McCLIM, etc. Why this indifference? Why this complaining without taking the situation in hand? I think the agol languages has succeeded. At least in pulling away most of the people with some energy left...)
Groetjes, Peter
-- It's logic Jim, but not as we know it. | pvane...@debian.org "God, root, what is difference?" - Pitr| "God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd/
Espen Vestre <espen@*do-not-spam-me*.vestre.net> writes: > BUT I still think the "simple interaction with the OS" argument is valid. > It's still less painful to use perl for a lot of these tasks, and that's > a real shame.
Because "interaction with the OS" isn't the "simple" problem some people here think it is. I'll use Unix for my example since I don't know enough about Windows but I assume the problems are similar or worse.
Writing a low level wrapper around most of the POSIX interface isn't difficult when you know the FFI of your implementation a bit. It's a big job and it's tedious. But all that buys you is the ability to write C with parentheses. Consider the simple problem of listening to a port on a service. Given your POSIX wrapper you can write this in a sequence of calls to getservbyname/socket/accept/bind/listen and I'm probably forgetting some. All with weird encodings of error situations etc. What you really want is something like LispWorks COMM:START-UP-SERVER. Designing these chunks of functionality with usable interfaces and decent error handling is a lot of work.
-- Lieven Marchand <m...@wyrd.be> She says, "Honey, you're a Bastard of great proportion." He says, "Darling, I plead guilty to that sin." Cowboy Junkies -- A few simple words
we've been through this before in the other thread (about loop) but I'll just fill you on what you missed.
In article <slrn9p7f72.2tns.m...@oscar.eng.cv.net>, m...@oscar.eng.cv.net says...
> This is an odd way for franz to show that they support common lisp and > would at the very least make me look for someone else to give my money > to or just pick another language for the project.
You've read the web page describing the coding standards but apparently missed this sentence at the beginning:
The opinions in this document are those of its author (john foderaro) and may or may not reflect those of anyone else at Franz Inc.
These are my opinions. All mine. They would be my opinions if I worked for any company or university. I would not work for a company that didn't allow me to have my own opinions on things and neither should you.
My opinions are based on 23 years of programming experience in Lisp. That doesn't mean that you have to agree with them but at least it should cause you to pause and think for a bit. I don't think that you gave what I wrote much thought at all.
I've contributed a lot of Lisp code to the community even before the term opensource existed. What have you contributed? Suppose I was looking for a module to do X and found that you had an opensource version. You sent it to me and I found that it was using a private interation or condition macro of your own design. I sent you a letter asking for a copy of that macro and you emailed it to me. What should I then do? Post something in comp.lang.lisp saying how you're denegrating the Common Lisp standard by inventing your own control macro? That's not what I'd do. I'd send you a letter thanking you very much for the code. Then I'd congratulate you for being a Lisp programmer and realizing that Lisp is a language designed to be extended.
If you look at one of the programs I've contributed (AllegroServe) you'll find a number of ACL only macros. A quick grep reveals: excl::atomically, excl::fast, excl::with-dynamic-extent-usb8-array. Why don't you now get on my case for including uses of these macros and not giving you the source code for the macros? Could you stand to use AllegroServe because it included these macros or would you have to remove them before using it? The alternative I'd suggest is rather than get confrontational you should send a friendly letter to the author of the program and say "I'm trying to run your program X on Lisp Y and it doesn't include macro Z could you tell me what that macros does or better yet give me the source?" That's a much better solution than telling someone who is doing you a favor by releasing his code for free to change his code to suit your personal coding standards.
How dare you insinuate that I'm not enthusiastic about Common Lisp? The programmers working in companies producing commercial Common Lisp systems are the most enthusiastic people about Common Lisp you will ever find. These people know that they are the last thing standing in the way of the Lisp language returning to its position of an academic oddity. It takes a tremendous amount of work to maintain Lisp while the computing world changes rapidly. Here it is a holiday in this country and while this is a day off at Franz and it's a beautiful sunny day ouside there has been a steady stream of email all day between developers about lisp-related issues.
It pained me to read your message. You're progamming in Lisp but you are still thinking like a C programmer. A C programmer can't extend the syntax of the C language. Neither can a Java programmer. [A C++ programmer can extend operators but this often makes the code just more unreadable and undebuggable].
How do you think that we got to where were are now with the current set of control form macros? Were they spontaneously created by the standards committee? No. For the most part all those forms existed in pre Common Lisp lisps. They were invented by people in those lisps to solve a need.
Not all needs are met by the standard common lisp macros. For example there's a dolist but there's no dovector to map over items in a vector.
> If we follow down the John Foderaro route of everyone inventing their > own basic control-flow operators, we will soon have 10s of IF*, BIF, > IFF, etc. operators, each one with their own little syntactic sugar,
I'm never swayed by this scare tactic argument. If you can prove this statement I'd like to see it. As I said in an earlier message I've programmed in Lisp for 23 years but have only found it necessary to create one control macro (If in Franz Lisp, if* in Common Lisp). I suspect that most people will create no control macros but some people will create some great control macros that will make us think "how could we have lived without this for so long?". At that point the Common Lisp community will make an evolutionary step forward (and this would not in any way affect the standard since the ability to define macros is part of the standard).
We can't live in fear of what may happen and let that control us to the extend that it inhibits growth.
> Tim Moore <mo...@herschel.bricoworks.com> writes:
> > I use Common Lisp to do my income taxes. This year I had work under way > > to automatically fill out the IRS pdf forms, but then I saw how much I > > owed and lost interest.
> Hey,
> I was wondering: how would you go about filling a PDF from Lisp? > Would you use a library like the one used by gv or xpdf or is there > a simpler way?
The approach I was taking was to generate FDF for a given PDF form. FDF is a very simplified version of PDF that enumerates form field names and values. You can (on Unix, at least) use the Adobe Acrobat reader to print a PDF with form field values supplied by an FDF document.
From a Lisp point of view, generating the FDF is pretty trival; it's plain text with a regular syntax. FORMAT is your friend.
Figuring out the field names and meanings is very tricky; I mostly did that by writing a Perl script to extract the field names, then by hand generating a simple FDF for each field, then seeing how the resulting PDF printed. This was a huge pain; a PDF parsing library might have made this easier, but you still have to figure out what each field "means"...
In article <MPG.15fd84e57d0615f5989...@news.dnai.com>, John Foderaro wrote: > we've been through this before in the other thread (about loop) but I'll just fill you > on what you missed.
> In article <slrn9p7f72.2tns.m...@oscar.eng.cv.net>, m...@oscar.eng.cv.net says... >> This is an odd way for franz to show that they support common lisp and >> would at the very least make me look for someone else to give my money >> to or just pick another language for the project.
> You've read the web page describing the coding standards but apparently missed this > sentence at the beginning:
> The opinions in this document are those of its author (john foderaro) > and may or may not reflect those of anyone else at Franz Inc.
I do not care about a PC disclaimer, my point was and is franz is giving your claim's weight because it is on there web site. This is where I would expect to see stuff about how CL is wonderful and ACL is even beter then that. Instead I see your poorly thought out and fundmentaly flawed rant about CL. If you must do less then optimal things you should not do them at work and franz's web space is part of your work enviorment.
> These are my opinions. All mine. They would be my opinions if I worked for any > company or university. I would not work for a company that didn't allow me to have my > own opinions on things and neither should you.
Part of being a good employee is to not harm your employer. What you have done is harm your employer with this stupid and insulting coding standard and wierd if* macro( yes it is wierd and looks ugly) is to make me think if this is who they show the world who do they keep hidden?
> My opinions are based on 23 years of programming experience in Lisp. That doesn't > mean that you have to agree with them but at least it should cause you to pause and > think for a bit. I don't think that you gave what I wrote much thought at all.
If you want to start a civil discussion then start it in a civil manner, your coding standard is rude, condisending and insultiong. Why do think that being a asshole in writting for all the world to see and biting the hand that feeds you should make me think you are worth listening to? I tend to judge people by the quality of there writting on usenet, its all I have, and by that yard stick you are IMO not worth the effort to take seriously. You do not have the saving grace of being correct in your thoughts. I went to your home page and there were no links just "jkd styff" and nothing else, www.franz.com/~jkf .
> I've contributed a lot of Lisp code to the community even before the term opensource > existed. What have you contributed? Suppose I was looking for a module to do X and
at the present time nothing. But with that said it does not change the fact that it was a stupid page that does a disservice to the CL community and to your employer.
> found that you had an opensource version. You sent it to me and I found that it was > using a private interation or condition macro of your own design. I sent you a letter
if I put up a package I would hope to do a complete job of it, ie to get this to work you need this file also in the comments at the top of the file or a tar file with everything in it that you need including any custom stuff that is neded to support the other stuff.
> asking for a copy of that macro and you emailed it to me. What should I then do? > Post something in comp.lang.lisp saying how you're denegrating the Common Lisp > standard by inventing your own control macro? That's not what I'd do. I'd send you a > letter thanking you very much for the code. Then I'd congratulate you for being a > Lisp programmer and realizing that Lisp is a language designed to be extended.
extended not mutated/fragmented, your if* in code put up as something that franz is giving to the CL community says among other things that your convienence is more important then franz's adhearence to the CL standard and this is bad in s company that's product is suposed to fathfuly reproduce the standard and not gratuitisly ignore parts of it whenever they feel/you feel like it.
> If you look at one of the programs I've contributed (AllegroServe) you'll find a
I looked at it and if I remember correctly it is copy right franz inc. If this is true then did you donate it to franz or was it part of your job?
> number of ACL only macros. A quick grep reveals: excl::atomically, excl::fast, > excl::with-dynamic-extent-usb8-array. Why don't you now get on my case for including > uses of these macros and not giving you the source code for the macros? Could you
well IFF you insist I can, but I realy have better things to do. Also are you planning on responding to KMP's reply to why the if* macro is a bad idea, he had a much better argument including been ther don that it stank and CL was suposed to fix it. Since his message was posted before mine I would expect you to have a repled by now or are you being selective in who you respond to? After all I am unknown and Erik has a bunch of people who do not like him that you can tap into for support.
> stand to use AllegroServe because it included these macros or would you have to remove > them before using it? The alternative I'd suggest is rather than get > confrontational you should send a friendly letter to the author of the program and say > "I'm trying to run your program X on Lisp Y and it doesn't include macro Z could you > tell me what that macros does or better yet give me the source?" That's a much > better solution than telling someone who is doing you a favor by releasing his code > for free to change his code to suit your personal coding standards.
again is it a favor or part of your paid work for franz? If it is the latter then you should only deviate from the standard when you must, networking come to mind, not where you want, if* cones to mind.
> How dare you insinuate that I'm not enthusiastic about Common Lisp? The programmers > working in companies producing commercial Common Lisp systems are the most > enthusiastic people about Common Lisp you will ever find. These people know that they
well you do hide the fact that your the saviors of the modern world quite well, does anybody recognize you with your glasses on?
> are the last thing standing in the way of the Lisp language returning to its position > of an academic oddity. It takes a tremendous amount of work to maintain Lisp while > the computing world changes rapidly. Here it is a holiday in this country and while
I am sure it does, so why add more gratuitus ans unneeded changes on top of it?
> this is a day off at Franz and it's a beautiful sunny day ouside there has been a > steady stream of email all day between developers about lisp-related issues.
And I am in the offfice also and have been working on a project all weekend that I was told about on thursday that goes live on tuesday and your point is?
> -john foderaro > franz inc.
Since there is no disclamer on this message I have a question for someone that you work for, is this an offical posting from franz?
> Are you purposely trying to confuse people here?
So quoting me is too much for your need for references? *snicker*
> I'm not the one who made the big deal of that document on if*, you are.
Oh, right. Sorry. John Foderaro should be allowed to criticize anything, but criticize John Foderaro, and you are his enemy. Remember that line about "enemy list"? Could you cough up a reference to that list, please? I regret that I have temporarily taken my machine off the web for security reasons, but I can assure you that no such list exists, either published or unpublished, but still John Foderaro accuses me of having one and being on it. So, I should say that you are the one that made such a big deal of being my enemy. Does this help anyone understand how you have reacted from day one? It explained a lot to me, at least.
> You took it as an attack on the Common Lisp standard.
It is not? Geez.
> In fact it is just the opposite.
Oh, I see. I have not been attacking you, either, John Foderaro, in fact, just the opposite. You see that now, too, I hope.
> It shows that Common Lisp gives you the flexibility to define forms that > make your code easier for you to read.
Why did you have to knock the standard conditionals just to say that? I have asked you repeatedly, yet you never answer, so I guess you cannot answer (in the spirit of your own style of argument, I am allowed to assume something from a lack of answer, right?), whether you could have expressed your new, f*king brilliant IF* shit in positive terms that did not reflect your stupid personal hangup with aestetics in the standard.
> Java doesn't allow that. C and C++ give you a very weak macro extension > language.
Who cares? Are you using Java a lot? Last I heard, you rant even more irrationally about Java than about the "braindamage" in Common Lisp.
I happen to like Java, too. That is probably because I have figured out that it sometimes makes sense to appreciate things on their own terms, as opposed to some completely different terms that makes everything look bad.
I have certainly not stopped liking C. On its own terms, it is a good language. There are a lot of things in C that I would like to see in a Common Lisp system. Access to machine words and the machine operations on them is the only way to achieve high efficiency in some algorithms. Writing sufficiently complex code that it needs macros in C is a mistake -- if you need that, write in Common Lisp and generate the code you want; C is not that hard to generate human-readable code from.
> In other words you want vendors to mindlessly echo back your enthusiasm.
Wrong. _Everybody_ else understood something else by what I said.
> You don't want to hear what the vendor may have learned through years of > experience about what could potentially be a problem for you using the > language in your project. You don't want the truth. You can't handle > the truth.
If you believe this idiotic crap was uttered by anyone but yourself, you are quite simply insane, John Foderaro, and nothing can be done about you.
> I'm never swayed by this scare tactic argument. If you can prove this statement I'd > like to see it. As I said in an earlier message I've programmed in Lisp for 23 years > but have only found it necessary to create one control macro (If in Franz Lisp, if* in > Common Lisp). I suspect that most people will create no control macros but some > people will create some great control macros that will make us think "how could we > have lived without this for so long?". At that point the Common Lisp community will > make an evolutionary step forward (and this would not in any way affect the standard > since the ability to define macros is part of the standard).
> We can't live in fear of what may happen and let that control us to the extend that it > inhibits growth.
During this on-going discussion about if* I have had the oppurtunity to "try it on for size". The thenret control statement I found unatural and took some getting used to. But all in all I have found it a fine macro. Of course its "just" an if/then/else/elseif construct.
I totally agree with the living in fear bit. I would not have learned CL if I had lived in fear of learning yet another programming language.
> My opinions are based on 23 years of programming experience in Lisp. > That doesn't mean that you have to agree with them but at least it should > cause you to pause and think for a bit. I don't think that you gave what > I wrote much thought at all.
How much thought do you expect anyone to give a paper that calls itself "lisp coding standards" and which contains two grave insults and a silly comment on comments that is completely useless? And this is the result of 23 years of programming in Lisp? Sheesh!
> I've contributed a lot of Lisp code to the community even before the term > opensource existed. What have you contributed?
Is this intimidation tactic a way of saying that you are _entitled_ to destroy and denigrate Common Lisp, but those who criticize you for it are not entitled to criticize because of their lack of contributions? Where do you _get_ all this arrogance? What are you trying to defend?
> Post something in comp.lang.lisp saying how you're denegrating the Common > Lisp standard by inventing your own control macro?
Why are you constantly _not_ getting that it is your very unintelligent insults that cause the majority of the hostility and not your very silly macros?
> Why don't you now get on my case for including uses of these macros and > not giving you the source code for the macros?
Because it is your gratuitous insults that get people on your case, not your macros. How _can_ you fail to understand this? You act like a person who _knows_ he is guilty as sin and tries very, very hard to pretend he has done nothing wrong by trying to deflect all criticism. So many people have pointed out to you that this is about your attitude that it _must_ be a matter of will that you do not get it. Otherwise, 23 years of experience with that level of inability to understand things is not really worth a lot.
> That's a much better solution than telling someone who is doing you a > favor by releasing his code for free to change his code to suit your > personal coding standards.
I remember three distinct occasions when I mailed real bug-fixes to your code and received _very_ hostile comments back that you could not use it because it used loop and if and when and unless. I believe at least one of those incidents prompted your writing your digusting Lisp Coding Standards document. Suffice to say that from then on, I viewed your ability to think straight to be permanently impaired. The bugs were still unfixed for at least one release, by the way, and there are still bugs in that code: The symbol printer and reader in Allegro CL does not conform to the standard and violate print-read consistency expectations. After having tried to explain to you how you could have avoided those bugs, you simply failed to implement them because I use a much richer set of conditionals in Common Lisp than you do. I do not string a whole bunch of if* together in an unreadable mass of spaghetti code, I choose the most readable form with care. Therefore, I manage to find and fix such bugs only after converting the if* mess to something readable, while your code has been buggy for over a decade, but you do not wany my fixes. In other words, I have solid evidence that your personal coding standards are much more important to you than working, conforming Common Lisp.
> How dare you insinuate that I'm not enthusiastic about Common Lisp?
Try reading your own language. Try remembering how you react when people say that upper-case names symbols are required the standard. Try actually _answering_ some of the many questions you have been asked, to which positive answers would really have helped, while double negatives really do not help at all. Instead of attacking people with the above negative, try writing something _positive_ for a change.
> The programmers working in companies producing commercial Common Lisp > systems are the most enthusiastic people about Common Lisp you will ever > find.
I would have expected some humility in such a statement, such as at least including a "probably" or "in my experience". Making it sound like a universal truth means it can be shot down as false or dishonest with a single counter-example. Such a universal statement is also an insult to the many people who clearly exceed you in terms of enthusiasm and a strong reason not to work with you. This is probably what you want.
The reason I have not applied for a job at Franz Inc. and probably never will is that your statement is manifestly untrue. A few people at Franz Inc. have really gone out of their way to destroy the credibility of the standard, imply very strongly that you are in a market position where you can dictate the standard and lock people in. Most of them fortunately quit and others have assured me that they really had no effect on policy, but they got _hired_. I would have loved to work full time with most of your staff, but you, in particular, and a few others, have really managed to rub me the wrong way, and you, in particular, have done everything you can to make my insistence on conformance be unwelcome and result in no action when I point out conformance problems. Your insane ranting here is not doing anything to help this, and your idiotic "religious zealot" stamp because I do not approve of your if* stunt and particularly do not approve of your constant need to denigrate the standard and the people behind it. I have very high respect for some of the people you have spent _hours_ insulting to my face. I have _none_ for you, anymore. You have done more to destroy that respect in this thread than anything else you have done, however, including your pathetic passive-aggressvieness, your dishonesty, and your personal need to misrepresent me and _pretend_ that you do not have a clue what I am talking about.
I would have thought the most enthusiastic people about Common Lisp I would ever find would be a lot smarter about expressing it positively, and _definitely_ not so pathetically self-defensive about his own destructiveness as you are.
> My opinions are based on 23 years of programming experience in Lisp.
I _really_ hope I have had more to contribute by the time that I have as much experience than some silly rewrite of cond and personal distaste for a powerful iteration macro. Most of the other people who have had in excess of two decades of Lisp experience have been fantastically helpful to me and have imparted so much wisdom about the language that I feel that my 6-8 years of Common Lisp and Emacs Lisp have been much more, although I met my first Lisp in 1978 or 1980. That is part of the reason I feel disappointed, and more than that, almost betrayed, when someone with so much more experience chooses to sully the language and present his experience as insulting comments about standard features. (Again, never mind the infinitely silly if* macro -- it is of minimal material consequence compared to the insulting attitude -- it makes you look really ignorant and _far_ from really experienced.)
John Foderaro <j...@unspamx.franz.com> writes: > It pained me to read your message. You're progamming in Lisp but > you are still thinking like a C programmer. A C programmer can't > extend the syntax of the C language. Neither can a Java > programmer. [A C++ programmer can extend operators but this > often makes the code just more unreadable and undebuggable].
So if I read your argument correctly, anyone who thinks it is a bad idea to replace perfectly good standard constructs in CL with different, unstandardized personal macros is still thinking like a C programmer? Oh my god!
Just because one can do certain things in a language doesn't mean it is a good thing to do in all cases. It somehow seems to me that this is a concept totally alien to you.
> How do you think that we got to where were are now with the current > set of control form macros? Were they spontaneously created by > the standards committee? No. For the most part all those forms > existed in pre Common Lisp lisps. They were invented by people in > those lisps to solve a need.
Of course they weren't spontaneously created by the standards committee (neither the ANSI working group, nor the orginal ad-hoc standardization group that led to ClTl1 and later morphed into X3.J13), and it would indeed be to their discredit if they had done this in large amounts. That's not what standards are for, as you well know. Standards are for exterminating minor differences where broad consensous can be reached on infrastructure, not for inventing the best control-flow operator in the world.
And yes, lots of slightly differing control-flow operators where invented, and re-invented in many dialects. And that was fine, when the new operator solved a real need that was otherwise unfulfilled, and it was sad when people solved similar needs slightly differently in different dialects, making knowledge (much more so than code) less portable than it could have been.
And that's why Common Lisp was such a huge step in the right direction, by canocalizing lots of those operators into one form.
> Not all needs are met by the standard common lisp macros. For > example there's a dolist but there's no dovector to map over items > in a vector.
And no-one would be giving you any kind of resistance if you had implemented dovector. I can't believe you don't see a difference between creating a new control-flow operator for some functionality that is not covered by the standard, and replacing standard operators with your own personal definitions which are functionally identical, only offering a slight syntactical variation, especially if you then go on to call on people to replace uses of if/when/unless with if* unconditionally.
Exactly because CL gives you the power to extend the language, and create new languages embedded within/replacing the standard language, it is even more important to use that power wisely.
Even C has enough power to replace certain syntactic constructs of the language with your own "improved" versions, as I mentioned in my posting. And even this limited power can be thus abused, in the name of personal persuasions of what constitutes readability. But in that community I have yet to encounter anyone with any kind of experience seriously suggesting that such a thing is something desirable.
> > If we follow down the John Foderaro route of everyone inventing their > > own basic control-flow operators, we will soon have 10s of IF*, BIF, > > IFF, etc. operators, each one with their own little syntactic sugar,
> I'm never swayed by this scare tactic argument. If you can prove > this statement I'd like to see it. As I said in an earlier message > I've programmed in Lisp for 23 years but have only found it necessary > to create one control macro (If in Franz Lisp, if* in Common Lisp).
What kind of proof do you need? We already now have IF* and if. The reason we don't have 10 IF*'s lies in the fact that most CL users are more prudent in the use of their powers than you seem to be. If everyone followed your example, we _would_ have more syntactic sugar macros, because it is unreasonable to assume that you are the only person who is dissatisfied with some construct in the language (or in your words considers some part of the standard "bogus").
We have seen the consequences of this in stuff that hasn't become part of the standard: Just take a look at all the ITERATE macros that were (mostly) created as a reaction to complex LOOP. To the best of my knowledge there are at least 4 slightly different ITERATE constructs in current use out there, and I haven't looked at all widely for others.
I contend (and of course I cannot prove this in any rigorous sense of the word, but who are you to call for proofs, when the best of evidence you seem to feel necessary to underscore your dismissal of IF/WHEN/UNLESS are completely subjective comments) that the fact that we haven't seen similar things happen for constructs that are part of the standard is that most CL users do in fact understand the values of a commonly shared _basic vocabulary_, and have refrained from creating their own variant macros.
> I suspect that most people will create no control macros but some > people will create some great control macros that will make us think > "how could we have lived without this for so long?". At that point > the Common Lisp community will make an evolutionary step forward (and > this would not in any way affect the standard since the ability to > define macros is part of the standard).
You still seem not to grasp the difference between inventing a new control-flow operator like e.g. WITH-STATE-MACHINE, or PATTERN-CASE (to name just two that I personally "invented" -- along with scores of others, I'm sure -- for certain libraries[1]), that can stand besides the standard-provided basic operators, and replacing one of the most fundamental (by your own reasoning in coding-standards.html[2]) control-flow operators in the language standard with your own personal version?
Can you imagine that there is a difference between inventing a new word for a new concept for which no word already exists in a natural language, and insisting on replacing 'if' by 'fi' in all your natural language sentences? And this isn't less of a problem in CL just because you can automatically map the semantics of fi onto if via macros, because macro-expansions are _not_ part of the readability of code, unless as a last resort, if all else fails, on par with reverse-engineering.
> We can't live in fear of what may happen and let that control us to > the extend that it inhibits growth.
We can't let blind belief in the obvious superiority of our own ideas blind us from the likely consequences of our deeds.
But somehow I'm slowly coming to the conclusion that you don't want to understand the criticism aimed at your stance, but would rather prefer to dismiss it out of hand, calling everyone who doesn't agree that the introduction and promotion of IF* as a replacement for IF/WHEN/UNLESS is a completely grand idea, as religious zealots, thinking like C programmers, scare mongers, or whatever, and debating straw-man arguments that bear little to no resemblence to the arguments that people really are levelling against your stance.
Regs, Pierre.
Footnotes: [1] See also my response to a recent request for meta-programming and language creation examples in CL for another example.
-- Pierre R. Mai <p...@acm.org> http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein
> Why do you keep telling people how much you dislike me?
Because you have made your dislike for me the core your responses to me. Remember, _you_ invited people to take part in a popularity contest with the clear aim of defeating me through misrepresentation of what I said. Such behavior pisses me off tremendously. I merely followed up on that because it would be a _disaster_ if you won.
> Do you think that there is anyone reading this newsgroup who really cares > about that?
Yes. You, for one. Those who want to vote with their wallet to remove a cancer from the Common Lisp community.
> Don't you realize that it reduces your credibility to near zero when you > then make some statement about me because people now see that the > motivation for your post may not be to provide information to the readers > of this group but instead is just a lie to get back at me for whatever it > is that I did to you (which is still a mystery to me).
Er, _what_ was it that I should realize in that garbled sentence?
If something still remains a mystery to you, talk to your colleagues. Several of them got the point quite early, while you keep _not_ getting it on purpose, or so it seems.
In article <3208551490117...@naggum.net>, e...@naggum.net says...
> Because it is your gratuitous insults that get people on your case, not > your macros.
Remember, due to your bias against me (how many ways have you told me you hate me in the last week?) and your many misrepresentations of things I've said, we agreed that you would not speak for me any more and would instead just quote me and give the context for that quote.
Please now provide the quotes which show me insulting people.
> I remember three distinct occasions when I mailed real bug-fixes to your > code and received _very_ hostile comments back that you could not use it > because it used loop and if and when and unless.
Again we will have to assume that this is yet another lie unless you provide the proof. If you can give the time of the supposed response from me and the subject of the message I can attempt to locate it in our support archive and post it for all here to see and judge if it's "_very_ hostile".
> Therefore, I manage to find and fix > such bugs only after converting the if* mess to something readable, while > your code has been buggy for over a decade, but you do not wany my fixes.
please post the letter from me refusing your fixes.
Now do you understand? Make no statements about me unless you can substantiate them. Otherwise the good people who read this newsgroup will think that you are wasting their precious time persuing your own personal vendetta
John Foderaro wrote: > It pained me to read your message. You're progamming in Lisp but you are > still > thinking like a C programmer. A C programmer can't extend the syntax of > the C > language. Neither can a Java programmer. [A C++ programmer can extend > operators but this often makes the code just more unreadable and > undebuggable].
That is true - but one of the reasons _I_ do not like IF* is that it leads to code that looks astonishingly like C... (Look at AllegroServe for what I mean) This does not have to be a bad thing at all - but it is simply not the style I want to write Lisp. IF* encourages _big_ control-statements, since it makes small ones bigger that using IF/WHEN/UNLESS.
If we take a look at this code-snipped from AllegroServe (taken from GET-REQUEST-BODY)
In article <871ylnx1pw....@orion.bln.pmsf.de>, p...@pmsf.de says...
> So if I read your argument correctly, anyone who thinks it is a bad > idea to replace perfectly good standard constructs in CL with > different, unstandardized personal macros is still thinking like a C > programmer?
No, you didn't read my argument correctly. A C programmer knows he can't extend the language he merely writes in it. A Lisp programmer knows he can extend the language. That doesn't mean that he has to in all cases, but if it leads to sufficiently better code then he should.
Let me as you this: are when and unless good or bad? I'll be you say "good" since they are part of the ANSI spec.
Now what if they weren't part of the ANSI spec. What if now I introduced them to you. Would they be good or bad? Now you would say "bad" since they don't give you anything that if, not and progn can't give you.
I consider that a strange way of looking at things but sadly very common here. To me something is either good or bad. I don't need the approval of the ANSI committee to tell me that it's good.
> Exactly because CL gives you the power to extend the language, and > create new languages embedded within/replacing the standard language, > t is even more important to use that power wisely.
Would you consider writing one control flow macro in 23 years of programming to be using that power wisely? Or for you is 'zero' the only wise number of new control flow macros that should be written.
> Even C has enough power to replace certain syntactic constructs of the > language with your own "improved" versions, as I mentioned in my > posting. And even this limited power can be thus abused, in the name > of personal persuasions of what constitutes readability. But in that > community I have yet to encounter anyone with any kind of experience > seriously suggesting that such a thing is something desirable.
If you ever looked at the source code for the 1978 version of Unix for the Vax that came out of Bell Labs you may have read the source for the adb debugger program. The author of this program (who was famous but whose name I don't remember) was a bigger fan of Algol than C. Thus he wrote a complete set of C macros that allowed him to write that debugger in an Algol like language that got macro expanded into C. So yes, it has been done in the C community. The C macro facility is very weak as I've said so the reason it's not been done more has, I believe, more to do with the lack of power of the macroexapander than the lack of desire to extend the control forms of C.
> What kind of proof do you need? We already now have IF* and if. The > reason we don't have 10 IF*'s lies in the fact that most CL users are > more prudent in the use of their powers than you seem to be.
wait a minute. You're proving my point not yours. my point is that most users know that have the power to write control flow macros but choose not to do it. That says that there won't ever be 10 if*'s. You have nothing to worry about.
> But somehow I'm slowly coming to the conclusion that you don't want to > understand the criticism aimed at your stance, but would rather prefer > to dismiss it out of hand, calling everyone who doesn't agree that the > introduction and promotion of IF* as a replacement for IF/WHEN/UNLESS > is a completely grand idea, as religious zealots,
you're completely wrong. I'm not asking you to embrace if* and give up if, when and unless. I'm telling you that I've done that and I'm shocked that people are angry at me for making a personal choice like that. A zealot insists that only he is right and everyone must believe the same. How many people have told me on this very forum that I can't give away for free lisp source code that includes a macro that they don't like? It is absolultely unbelievable.
You've altered the readability of the code by factoring part of it out (enhancing readabilty at a cost in speed if the function isn't compiled inline)
In doing so you've introduced a bug (if read-char-no-hang returns nil you'll call unread-char passing it nil as the first argument (and the first argument should be a character)).
If you really want to compare apples/vrs/apples you should take the if* code exactly and put in if/when and unless and see what it looks like.
It may just be my newsreader but the indenting on both examples is messed up on my screen so in particular for those who haven't seen if* and who run a lousy newsreader don't be put off by the less than readability of the if* example.
