I hear this commotion about Lisp Vs C++.... I beleive the best language is the one that gets the job done the quickest. After all computers are supposed to makes things quicker, easier and be more efficient than the alternatives. Multi-Lingual programming is necessary to get the job done.
I use Lisp for applications under Interleaf and AutoCad, for Access Programming I use BASIC, for Oracle I use SQL, for MS-DOS simple functions I have batch functions, for complex functions Pascal and C, for simple UNIX functions Shell scripts, for some engineering functions Fortran. The choice of launguage is based on what language I have the best set of tools for. I would not begin to try and develope OS file manipluations under Access Basic, nor would I try to write a Lisp function for something that could be thrown together in a few minutes in a Batch file (You should see some of my batch files).
To insure a profitable future in programming, we need to evaluate the language for the problem, not the problem for the language. This flexability will provide our employers with the best solution which, in turn, will hopefully convince them to listen to us when we suggest using something different in the future.
As for Microsoft, I have mixed feelings about them but I wont discuss all of them now. There is one project that I have heard they are undertaking but I do not know the full details. They are suppossedly working on a method of 'UNICODE' where multiple languages can be intermingled and allowed to work together. In theory this sounds good. If anyone knows more, please enlighten me.
| I beleive the best language is the one that gets the job done the | quickest.
I have mixed feelings about this. Too frequently "gets the job done" means 90% of the job and exponential costs to approach 100% asymptotically. Too often, this is because getting 100% of the job done requires as much effort in a very powerful language (abstraction-wise) as is needed to get 90% of the job done in less powerful languages that focus on manual labor instead of mental labor to solve the problems. With the experience that getting 100% will mean skyrocketing costs, managers won't listen to arguments against "get the job done" until they know what it _could_ mean with very different tools. If you're an expert at hacking your way through the jungle around a mountain, and want to build a road there, it takes courage to investigate the option of digging a tunnel through the mountain, and vastly different tools. I wouldn't want the decision to be based on who gets to the other side first.
| As for Microsoft, I have mixed feelings about them but I wont discuss | all of them now. There is one project that I have heard they are | undertaking but I do not know the full details. They are suppossedly | working on a method of 'UNICODE' where multiple languages can be | intermingled and allowed to work together. In theory this sounds good. | If anyone knows more, please enlighten me.
That's ISO 10646 Universal Multiple-octet Coded Character Set (UCS), also known as Unicode 1.1, a character set standard that was intended to serve as the foundation for the next generation of computer representation of text, respecting all the world's written languages, extant and historic. It embraces natural languages and a rich array of mathematical and other symbols. I do not look forward to the time when programming language or utility designers discover that they can use all of these symbols in their syntax instead of inventing more and more complex multi-character "tokens", but other than my fears (and a fundamental problem of implementability and deployment in programming environments), it has very little to do with programming languages.
#\Erik -- I could tell you, but then I would have to reboot you.
In article <3052988043127...@naggum.no> e...@naggum.no "Erik Naggum" writes: > | I don't doubt it - I've done it myself. I've just not met many people > | who've also done it. Are you saying that because a few people discover > | Lisp, that's enough? I hope not.
> I'm not interested in the mass market, if that answers your question. I > think mass popularity is a liability, too, but obscurity is no guaranteed > asset, either. Come to think of it, most of the things I like are obscure, > off-off-mainstream kinds of things. Except coffee.
Ahh, elistism. You're the problem. Why is Lisp not more successful? Because you're don't care about that. Stop looking at the past, and let Lisp move on. Then perhaps more people might use it, and we'd never need to ask if "Lisp is alive?"
> | What I'm saying is that it has a hard time competing with languages > | like C++.
> But don't you see? It _doesn't_. It _can't_. Lisp is about programmer > productivity and abstraction, C++ is about exploiting hardware. C++ is the > assembly language of an object machine. If your task is to program that > machine, fine, do it, but you don't _have_ to do it at the assembly level!
I know that - so what? Most programmers are using C++. That may be why they're not using Lisp. You seem to think they have a choice. I think they don't. Why should MS etc give them a choice?
Do you understand what I'm saying? What the hell is a programmer supposed to do when they told to use C++? Quit? No way. Only an elitist can do that.
> | What makes Java so different from Lisp, so that it should be so > | successful? It could well be the syntax. ... I'm not sure that > | Smalltalk created this kind of excitement, and I remember some people > | being critical of the ST syntax. Perhaps syntax is more important to > | people than you think?
> Probably not more than _I_ think, since I don't buy the "semantics is more > important than syntax" argument, and have frequently argued against it. As > a friend of mine said when we discussed just this the other day, all the > relevant languages are turing complete, anyway, so they differ not in > _semantics_ per se, but in pragmatics, which is closely tied to syntax and > questions of ease of expressibility.
Fine, perhaps we agree on that point.
> How could the syntax of C++, Perl, Java, etc, be so important? Well, my > take on this is that programmers don't have the needs that would warrant a > more powerful syntax. They _have_ needs that ask for tons of menial labor, > and that's when (apparent) brevity of syntax becomes so important. If you > wanted to think about complex issues, you would want readability of complex > ideas, and you would invent Lisp if it wasn't already there. If you wanted > to hack and slash your way through a jungle of murky ideas and bad design > just to get some already annoying task done, you would want a syntax that > could do it fast, and you would invent Perl if it wasn't already there.
Yep, that's how I see it too. It's a load of crap, but that's what people seem to want. They don't appear to want Lisp. It could be that they don't want what Lisp currently is, but until a radically different Lisp (Dylan?) becomes commecially available, we won't know.
> Only a few people in each generation discover Aristotle and read his works. > This is sufficient to continue his massive influence on Western thought. I > care about the spread of the ideas in Lisp more than actual language, just > as I care about the concept of structured information more than I care > about another language with which I have spent an inordinate amount of > time: SGML, a language I dropped because its syntax is contradicting its > semantics, i.e., they communicate widely disparate ideas. If the ideas can > penetrate the programmer community and they want what Lisp can offer, it > doesn't really matter what the language looks like, as long as it is still > possible to read and write the language with standard language functions, > which is why the list form beats any alternative hands down in my eyes. > Unfortunately, programmers still think of themselves as feeders of machines > and not machines as their _partners_ in their job.
What a lot of programmers need is strong support for the platform they're using. I've yet to find a Lisp that can compete with the Win32 support in VC++, VB, Delphi, etc. I can't comment on Unix develop tools, as I've never developed for Unix. Nor the Mac.
If there was a Visual Scheme, with the same kind of platform specific support that VB has, who knows? Since such a product has a yet to appear, it's impossible to say what effect it might have. On the other hand, Java is here today, and in a few years, we may see Dylan systems becoming available. There isn't yet much, if any, platform specific support in Java (I'm thinking of individual Java developments sustems, like Cafe, Visual J++, etc). While we can hope that platform independance will gain some popularity due to Java, I doubt this will have much of an impact for some time, if it ever does,
So you don't give a shit about this. That may explain why so few people give a shit about Lisp. _I'd_ like that to change, so that I might one day say that I use Lisp because I'm paid to, instead merely, "because I can". I'd like to see more apps written in Lisp, because I don't have much hope for apps written in C++. The more I read about C++, the more problems it appears this language has, and the more trouble it'll be for anyone using apps written in C++, as they get worse.
If you're fortunate enough to never worry about this stuff, then good luck to you. I hope that your luck lasts a long time. Meanwhile, please forgive me for worrying about it _now_, as I have to live with it. It's not so easy for me to refuse to code in C/C++, so I sympathise with anyone in a similar position, and who doubts that Lisp is for them. I _know_ Lisp is for me, but it's not necessarily the same Lisp that you want.
Ok, go stick your head in the sand and say, "This has nothing to do with me, it's not my problem." You _are_ the problem. I've refered to memes before, and I'll do it again. There are Lisp memes, like yours, that hold the language back. -- <URL:http://www.enrapture.com/cybes/> You can never browse enough Future generations are relying on us It's a world we've made - Incubus We're living on a knife edge, looking for the ground -- Hawkwind
> I have mixed feelings about this. Too frequently "gets the job done" means > ... > I wouldn't want the decision to be based on who gets to the other side
first.
Let me explain what I mean by 'getting the job done'. That means completing the job in a professional manner with all the bells and wistles. It includes updateablilty, ease of maintenance, functionality and efficiency. If you go back to my first letter you will notice my choice of language for the project. For developing MS Access applications, BASIC is my choice since access basic integrates efficiently with Access. If I chose lisp, fortran, C++, ..., I would have to develop / aquire a set of tools and library functions to perform the marriage. By using Access basic and choosing something well integrated for the task, I have an application that when I upgraded it from Access 2.0 to Access 7.0, I did not have to rework a single function. I Choose Lisp for Interleaf and AutoCAD because they integrate well there. I have a Lisp Shareware Package for AutoCAD that provides functionality and Cross Platform Independance. If I have developed in C++ for AutoCAD, I would have needed a seperate compiler and tool set for every platform that AutoCAD exist on. (Not a financial possibility.) By selecting the appropriate language for the Job, not the Job for the Language, I have been much more efficient and productive.
> That's ISO 10646 Universal Multiple-octet Coded Character Set (UCS), also
..
I am not referring to UNICODE character set. The article I read (about 6 moths ago so I dont remember the source) was concering a multi-language integrator. It allowed code written in any language to be readily interpreted based on standard computer operations thus allowing programmers to develop in both lisp, C++, Fortran, ... and have all programs communicate together. All computer operations reguardless of the language can be broken down to some basic functions line add two integers, store a variable, compare two values, .... Once a program is broken down to this level, Communication in the form of data exchane becomes relativle simple. Function A in language X requires and Integer parameter and returns a string. Function B in language Y calls Function A with an integer and a string is returned. Extrapolated to OOP - Object A has a run function. Programming language X can tell the object to run as well as programming language Y. I realize this is a highly simplified explanation but It explains the jist of the article. I have not seen anything else about it since then so I don't know if someone was misinformed or what.
I agree with Cybersurfer's contention that wider use of Lisp would be a good thing. I'm also in a position of needing to do my work in C (luckily no C++), on Unix boxes luckily. In my spare time I have been tinkering with Scheme as a language in which to do molecular modeling. Scheme gives a good tradeoff between rapid prototyping and speed.
Cybersurfer's point about tools is a good one. There isn't a GDB for Lisp or Scheme. When I need to debug, I put in printf statements. At one point while developing a GUI chemistry program I elected to switch from STk to MrEd to make my program run on a wider range of hardware platforms, but there's a wonderful little debugging feature in STk that MrEd lacks, where when an error occurs, a window pops up with a collection of stack frames and you can select a frame and use its variable bindings. This is a tiny fraction of what you'd get with something like GDB; there's no way that I'm aware of to set up breakpoints or watchpoints, or do single-stepping.
I would suspect that even elitists would benefit if Lisp/Scheme were widely used. There would be a wider range of tools available, and there would be more people to turn to for questions or general discussion. It would be easier to get jobs writing Lisp, and nobody would be worrying about the language's long-term viability. -- ------------------------------------------------------------- Will Ware <ww...@world.std.com> web <http://world.std.com/~wware/> PGP fingerprint 45A8 722C D149 10CC F0CF 48FB 93BF 7289
In article <52b8tu$...@universe.digex.net>, Janice M. Eisen <j...@universe.digex.net> wrote:
>Has anyone checked out the STELLA language concept, which can be >translated into either Common LISP or C++?
It's hard for me to take seriously any evaluation of Common Lisp's state that includes the following (directly from their home page):
... However, Common Lisp has several drawbacks: Its performance is slow (as compared to a C++ program); it does not interface well to tools and applications in commercial environments (e.g., to C++ and CORBA); and it fails to incorporate recent object system trends (e.g., collections, iterators, and parameterized types). As a result, customer demand and vendor support for Lisp is declining, creating yet another reason to abandon Lisp.
The "drawbacks" are the usual collection of misrepresentations and half-facts.
The first "drawback", Common Lisp's speed, which while not down to the C level of machine efficiency, can certainly be more than adequate for many applications. All it takes is the right algorithm for the problem, care in coding, and a modern optimizing compiler, as with any other language. Look at Fateman's work with arithmetic optimization for a reality check.
I contend Lisp's biggest problem, discounting parenthetophobia, is that it is taught poorly. People still think it's about linked lists and recursive programming, when clearly there's a lot more to modern Lisps than just cons cells and lambda expressions. The resulting code uses large lists like arrays (I have actually seen this!), runs slower than molasses in January, and management winds up blaming the language rather than the inadequately trained programmer.
The second "drawback", interfacing, is a bit of a chicken-and-egg problem. Languages that aren't "popular" (read: promoted by mass marketers like Microsoft, IBM, Borland, et al) don't get included in the creation of standards like CORBA. Because they aren't included, they become less "popular".
Meanwhile in the real world, our team is working in C++ and Lisp, integrated with some pain but running smoothly now.
The third "drawback" mentioned is actually a drawback of C++!! I believe that collections, iterators, and parameterized types are merely programming idioms that a generalized macro facility could handle. Common Lisp doesn't have these "features" because *it doesn't need them*.
Given this bogus justification for STELLA's existence, I am not really encouraged to investigate it any deeper. -- Chuck Fry, Lisp bigot -- Chuck Fry Work: chu...@ptolemy.arc.nasa.gov Play: chu...@best.com I alone am responsible for the contents of this post. Keep NASA and Caelum Research out of this.
Martin Cracauer wrote: > 4) Is there a cheap Smalltalk system? It is some time since I looked > into Smalltalk prices, but they were at least 3 times as high as > Borland/Visual C++. Really, let me know.
There are a couple of new vendors with beta Smalltalk systems on the Web. And ParcPlace-Digitalk now has an older version of their Smalltalk/V for Windows *free* including the WindowBuilder GUI builder and TCP support.
Search for "Smalltalk MT", "Dolphin Smalltalk", and "Smalltalk Express".
In article <3053078000286...@naggum.no> e...@naggum.no "Erik Naggum" writes: > I have mixed feelings about this. Too frequently "gets the job done" means > 90% of the job and exponential costs to approach 100% asymptotically. Too > often, this is because getting 100% of the job done requires as much effort > in a very powerful language (abstraction-wise) as is needed to get 90% of > the job done in less powerful languages that focus on manual labor instead > of mental labor to solve the problems. With the experience that getting > 100% will mean skyrocketing costs, managers won't listen to arguments > against "get the job done" until they know what it _could_ mean with very > different tools. If you're an expert at hacking your way through the > jungle around a mountain, and want to build a road there, it takes courage > to investigate the option of digging a tunnel through the mountain, and > vastly different tools. I wouldn't want the decision to be based on who > gets to the other side first.
The word I associate with this is 'leaverage'. Some tools give you a lot of leaverage in a particular app domain. while others just suck. I think this may have been what James was refering to. The ability to reuse existing code gives you tremendous leaverage, and many tools give you the ability to do this. Some techniques will be specific to an individual platform, like Tk widgets (are they available for NT, as well as Unix? I don't know), or OCX controls. Some will depend on a specific language, like a class or class library for C++, Smalltalk, CLOS, etc.
And then there are tools that generate code for you, from CASE tools all the way down to silly little things like 'Wizards' and 'Experts'. The interface builders you get with some Lisps and Lisp tools are in this group of tools.
One big difference between Lisp and C++ tools is that with Lisp, the tools are likely to be integrated into the enviroment the app runs in, along with the compiler and everything else, while C++ development tools (the compiler, wizards, resource editors, source editor etc) will tend to all be individual programs called from a 'workbench' program.
Does this remind you of the distinction between an OS and a Lisp Machine? Perhaps it's not just programming languages that shape the way we look at software. It might be great if we could convince people that integrating software into a single, seamless, whole is a good idea, but there may be technologies (like OLE) making this possible already, but without doing it via a programming language, but the OS.
When you're only tools is a hammer, everything looks like a nail. Could this work both ways? What should we really be focussing on, the OS, the language, or the documents? Apple and MS, and others, are saying it should be documents.
What's an application? A collection of things that don't fit into a document? ;-) -- <URL:http://www.enrapture.com/cybes/> You can never browse enough "An operating system is a collection of things that don't fit into a language. There shouldn't be one." -- 'Design Principles Behind Smalltalk', Daniel Ingalls, Byte August 1981
| Let me explain what I mean by 'getting the job done'.
Thanks.
| I am not referring to UNICODE character set.
Since Microsoft is a pusher of Unicode (ISO 10646) in Windows NT and also a member of the Unicode Consortium, I find it amazing beyond compare if they have called something else "Unicode", as well. Somebody must have confused the name, at least.
| All computer operations reguardless of the language can be broken down | to some basic functions line add two integers, store a variable, | compare two values, ....
There's an ISO standard at some stage called "Language-independent procedure calling". It sounds vaguely like the effort you mention. That standard is highly optimized for languages with trivial representation of objects, as found in languages with values and storage locations that are typed at compile-time, only. It fails utterly to address the needs of dynamic languages, of which several have arrived on the scene "recently".
I believe in creating "interfaces" or "trampolines" or whatever between different languages' optimal data representations and function calling mechanisms. Languages just differ too much in how they do things beyond the most basic to be able to agree on a common format without seriously hurting performance. Assuming, that is, that "performance" still means something when this gets used. (In some existing systems, this overhead can be ignored because it will always be much smaller than the next most costly overhead, typically interprocess communication mechanisms.) I have found that function calling mechanisms have been getting more and more complex in recent years both on the CPU level and in the coding conventions employed, to the point where a function should be quite long before it pays to call it instead of inlining its body. Inlining code between languages will be tricky at best, so the standard practice of creating large amounts of teeny-weeny functions as accessors into larger objects will have a tremendous cost overhead if those objects are not interchanged at the highest possible level. This means that type definitions (e.g., struct and class declarations) need to be shared across the language interface. This is a non-trivial problem, not at all solved by reducing function calls to interchange of some notion of "basic" building blocks. That whole concept is seriously dated; I'd say it's _pre_-object-orientation.
#\Erik -- I could tell you, but then I would have to reboot you.
| Ahh, elistism. You're the problem. Why is Lisp not more successful? | Because you're don't care about that.
That's _such_ a cheap argument. I can only hope you don't mean it.
First, I don't control the Lisp world in any way, and I have no expectation or even desire to have any impact on the mass market for _anything_. I don't care about it, remember? I mean that _literally_.
Second, elitism is rejection of the masses. I don't reject the _masses_. I reject the mass marketing techniques employed to affect them -- a very big difference. I also reject the products marketed by such fraudulent means as is used in the software world for PCs. Just as I thought "there _must_ be a better way" for years while I was finding small ways to write better programs in C until I could write them in Lisp and transcend it all, "there _must_ be a better way" to affect programmers than to hit them with the same kind of shit that sells the current generation of languages and tools, indeed which makes them the only viable solutions in certain settings, as you have pointed out repeatedly.
In brief: we can't win by engaging in mass marketing techniques on their premises. We haven't in the past, and we won't in the future. We must do something entirely different. What? If I knew, I'd already have done it.
#\Erik -- I could tell you, but then I would have to reboot you.
> I find it amazing beyond compare if they > have called something else "Unicode", as well. Somebody must have confused > the name, at least.
Thay would be me. I read the article a while ago and I don't remember what they called it.
As for the inefficiencey in implementation of the concept. The system was supposed to to read the language source code and generate compiles/run-time code. This would simplify the whole process since the actual internalization of all variables and code would be done by it. It additionally needed an intepreter defined for each language it supported. This allows you to still write code in whatever language you prefer and still intermingle the operations. Again, I said the concept sounds good, the implementation remains to be seen.
cyber_sur...@wildcard.demon.co.uk (Cyber Surfer) writes: > My goal is not to replace an existing web server with one that uses Lisp, > but to make writting CGI code using C++/ISAPI easier.
If what you need is a Lisp that integrates well with C++, and are willing to accept Scheme as your Lisp, you could consider esh (for Solaris/SunOS) or DEC's Scheme->C (for Solaris/SunOS, most other UNIX platforms and Windoze).
Both systems are designed for embedding into C/C++ applications (allowing C/C++ to call Scheme) and make calling C/C++ code from Scheme easy by automagically generating Scheme wrappers from header files (using "ix" for esh and "cdecl" for Scheme->C).
Both are available via anonymous ftp. What else do you need?
In article <3052849568663...@naggum.no>, e...@naggum.no says...
> Embellish >it to produce that abominable C++ code your _environment_ wants as input >from you. Nobody should be interested in the tools you use as long as the >product you deliver meets the (tacit and explicit) requirements that would >have been met if you had used the tools they think you're using. I know >this works, because this is how I moved to programming in Lisp from menial >labor in C and C++.
It isn't allways that easy. I work for a state government agency. I use the product approved, or I give up health insurance, retirement, & etc for the privilage of programming in what I prefer. Think about it: Not every body works under the same conditions and as a result what works in theory & practice may not work legally. Sorry if that disturbs you ...
>#\Erik >-- >Those who do not know Lisp are doomed to reimplement it.
Cyber Surfer wrote: > A few of us will be priviledged enough to not have to worry about > this. I'll gladly write Lisp code for food, but nobody is asking > me to, or any other Windows developer I know. I blame memes from > MS for this sad state of affairs, and a complacency from the Lisp > community. On the other, to be fair, it looks like not many Lisp > people are using Windows, so why care?
> I only care coz I've use Lisp for some of my own projects, and > I'd love to use it for the stuff I get paid for. Nobody I know > gives a shit about that, but it doesn't change how I feel. I still > prefer Lisp every time - it just makes no difference when I have > a deadline to meet, as it's always easier to use C/C++ instead. > It should be different, but the tools available for C/C++ (for > Windows) do actually make it _easier_. Go figure.
Well, why not try using the GCC compiler (c/c++) in conjunction with some of the that take Lisp code and convert it to C or C++? Then you can _write_ in Lisp, but compile in C/C++. I don't even know if you have to use GCC, maybe the MSVC compiler would handle it too.
> Yes, I should be writing Lisp code to make it easier to do these > things in Lisp, but as I've said repeatadly, I'm not paid to write > Lisp code - how do I get the time to use Lisp? How do we convince > the idiots who insist one creating and _selling_ so many C++ tools > that they should be using Lisp? While those tools exist in such > abundance, developers will be expected to use them.
So use the above - will your employer know the difference? Especially if the utility outputs C++ - nobody really understands C++ code anyway. :-)
In article <l3d8z1wjs6.fsf...@OASIS007.msc.ie> ritch...@msc.ie "Russell Ritchie" writes:
> If what you need is a Lisp that integrates well with C++, and are willing > to accept Scheme as your Lisp, you could consider esh (for Solaris/SunOS) > or DEC's Scheme->C (for Solaris/SunOS, most other UNIX platforms and Windoze).
I need Win32 support. Not "Windoze".
> Both systems are designed for embedding into C/C++ applications (allowing > C/C++ to call Scheme) and make calling C/C++ code from Scheme easy by > automagically generating Scheme wrappers from header files (using "ix" for > esh and "cdecl" for Scheme->C).
> Both are available via anonymous ftp. What else do you need?
Full Win32 support. The C++ tools I have aren't even up to date. It doens't look like the Windows support in DEC's compiler has been updated for well over a year, and is Win16, not Win32.
I could in theory add Win32 support. In practice, who knows? That'll depend on how much work would be required. A DIY solution isn't available to everyone. If I had the time to work on such things, then I would. If somebody else did, then they might have done it already.
Any tool that already has Win32 support will get looked at before one that doesn't. This is just being practical. There are quite a few of these tools...
I'm not giving up on the idea of using Lisp, of course. I'm just not restricting myself to Lisp, or the Lisps currently available. However, if I ever get the time, I'll see what I can do with DEC's compiler. You never know, do you?
Thanks. -- <URL:http://www.enrapture.com/cybes/> You can never browse enough Future generations are relying on us It's a world we've made - Incubus We're living on a knife edge, looking for the ground -- Hawkwind
In article <3254B0F1.4...@earthlink.net> pg...@earthlink.net "Patrick Giagnocavo" writes:
> Well, why not try using the GCC compiler (c/c++) in conjunction with > some of the that take Lisp code and convert it to C or C++? Then you > can _write_ in Lisp, but compile in C/C++. I don't even know if you > have to use GCC, maybe the MSVC compiler would handle it too.
I'm writing a Lisp to C compiler (very slowly, of course), using MSVC++. Either the GNU C++ docs I have aren't complete, or there isn't support for producing DLLs, so I MSVC++ looks like a better candidate. I can be certain that MSVC++ can do what I require.
> > Yes, I should be writing Lisp code to make it easier to do these > > things in Lisp, but as I've said repeatadly, I'm not paid to write > > Lisp code - how do I get the time to use Lisp? How do we convince > > the idiots who insist one creating and _selling_ so many C++ tools > > that they should be using Lisp? While those tools exist in such > > abundance, developers will be expected to use them.
> So use the above - will your employer know the difference? Especially > if the utility outputs C++ - nobody really understands C++ code anyway.
I'll need to get my compiler to support all the features needed for writing the code I'm paid to write. I'm working on it, but the compiler is currently at a very basic stage.
My plan is simple: write an incredibly simple compiler, ignoring performance and concentrating on getting a compiler working with a minimum of effort (i.e. time, which is short). Instead, I'll concentrate on supporting the Win32 features I need to use. That way, I'll be able to use the latest APIs from MS, and let the OS do all the hard work.
So far, it looks like there should be very low runtime overheads, despite the crude techniques I'm using. The GC was designed to perform well with only a very small amount of memory, so it's a mark/compact GC, instead of generational.
I'm optimistic. -- <URL:http://www.enrapture.com/cybes/> You can never browse enough Future generations are relying on us It's a world we've made - Incubus We're living on a knife edge, looking for the ground -- Hawkwind
Cyber Surfer wrote: > I'm asking why nobody is selling a Lisp that is well known > (to non-Lisp people), and which can equal C++ at writing apps. > Apart from a few exceptions, like HotMetal Pro, it's damn hard > to find any popular, examples of apps written in Lisp. I.e. an > app for a domain with a lot of media attention, and/or a product > that has been reviewed in mainsteam computer magazines.
Well, I couldn't resist. Go to Franz' home page http://www.franz.com under "Company News" for more details...
"Super Mario 64 System Gets Raves
The new Nintendo N64 game platform was released on Sept. 29th, and Nintendo is projecting that within nine months of launch, five million units will have been shipped worldwide. Fueling sales of the N64 is the incredibly successful Super Mario 64 game, which critics everywhere are calling the best game ever. Time magazine says "Playing Super Mario 64 is like jumping inside the movie Toy Story." .... more rave reviews omitted ...
The programming system behind Super Mario 64? Allegro CL...."
Nichimen Graphics package up a game development system (N World, which is built in CLOS) modeled the characters in Super Mario 64.
In article <3256F8DE.7...@franz.com> j...@franz.com "Jim Veitch" writes: > > I'm asking why nobody is selling a Lisp that is well known > > (to non-Lisp people), and which can equal C++ at writing apps. > > Apart from a few exceptions, like HotMetal Pro, it's damn hard > > to find any popular, examples of apps written in Lisp. I.e. an > > app for a domain with a lot of media attention, and/or a product > > that has been reviewed in mainsteam computer magazines.
> Well, I couldn't resist. Go to Franz' home page http://www.franz.com > under "Company News" for more details...
I didn't say that nobody was using ACL. Obviously _somebody_ is, otherwise you wouldn't be in business. A point that I've made before is: who knows this? How many people know that HotMetal was written in Lisp? Where else might I read about software written using ACL? I'd like to know so that I can read such magazines, instead of the mags that endlessly push C++.
> "Super Mario 64 System Gets Raves
> The new Nintendo N64 game platform was released on Sept. 29th, and > Nintendo is projecting that within nine months of launch, five million > units will have been shipped worldwide. Fueling sales of the N64 is the > incredibly successful Super Mario 64 game, which critics everywhere are > calling the best game ever. Time magazine says "Playing Super Mario 64 > is like jumping inside the movie Toy Story." .... more rave reviews > omitted ...
Did Time mention that ACL was used to develop this game? I hope so, as I'd like Time readers to know that Lisp is still being used to develop software.
> The programming system behind Super Mario 64? Allegro CL...."
> Nichimen Graphics package up a game development system (N World, which > is built in CLOS) modeled the characters in Super Mario 64.
Excellent. How many people will know this? No matter, as I'll be sure to tell anyone who asks. However, as I've said before, very few people listen to me, and those that do still tell me to develop in C/C++. -- <URL:http://www.enrapture.com/cybes/> You can never browse enough Future generations are relying on us It's a world we've made - Incubus We're living on a knife edge, looking for the ground -- Hawkwind
JT>All computer operations reguardless of the language JT>can be broken down to some basic functions line add two integers, store JT>a JT>variable, compare two values, .... Once a program is broken down to JT>this
That's only partially true. Of course you can break down even Haskell or Scheme down to simple machine operations. But what would be the price? If you go down to this low abstraction level to get a machine-independend code, optimizations get problematic. That's the reason why the RTL of the GNU compiler is a quite high level of abstraction - so you can do some optimizations. The lower you go the lesser optimizations you can do (you should have done them to get that far ;-) ).
JT>level, Communication in the form of data exchane becomes relativle JT>simple.
Hmm. Look at the backend of GNU-C and you will see that "relative" is really relative in this case ;-)
And with higher languages you get the problem that every nice feature must be reduced to simple abstract machine instructions. For example closures must be completely removed, because there is no place in a abstract von-Neumann machine for things like closures.
I doubt that Microsoft will respect things like this in there project - I think that they will focus more on different hardware aspects, to be able to develop and create native code for all supported NT-platforms. So the abstraction level of there abstract machine will be quite low, I think.
But to look at it the other way: it's better to have an abstract machine on lowest level, than haveing some higher-level abstract machine with the wrong abstractions (Java-VM for example).
The problem is definitely solvable, as GNU-C shows. That brings me to a point: why did no one ever write a RTL-interpreter?
In article <3256F8DE.7...@franz.com>, j...@franz.com wrote:
Hi Jim,
> Well, I couldn't resist. Go to Franz' home page http://www.franz.com > under "Company News" for more details...
don't forget to mention your story about "Crash Bandicoot". Is saw the game at the latest CeBIT Home in Hannover/Germany running on a Sony Playstation.
> > I'm writing a Lisp to C compiler (very slowly, of course), > > using MSVC++. [...]
> No surprises here. Why don't you write it in Lisp?
No, no. The compiler code is in CL, but the target code is for MSVC++. Sorry for not making that clear. My goal is to be able to write code for the Win32 platform, but if I can, I may also support a more portable compiler, like GNU C++. Currently, there's some code in the runtime that prevents this, and I'd like to place the runtime code in a DLL, so until I discover how to create a DLL using GNU C++, I'll have to continue with MSVC++ only. -- <URL:http://www.enrapture.com/cybes/> You can never browse enough Future generations are relying on us It's a world we've made - Incubus We're living on a knife edge, looking for the ground -- Hawkwind
cyber_sur...@wildcard.demon.co.uk (Cyber Surfer) writes: > I didn't say I chose C++. I said that I'm _paid_ to use it. > There's a hell of a difference. Show me a Lisp that can produce > a DLL using ISAPI, and I'll happily use it. Meanwhile, C++ is > what MS design their tools to use. If Franz or Harlequin could > offer us tools that support the _same features_ as C++, it would > be easy.
Ilog Talk generates DLLs on Windows NT and 95. I just checked out the ISAPI spec to see how hard it would be to support using Talk, and the answer looks good. Apparently the ISAPI spec requires your DLL to export two functions: GetFilterVersion and HttpFilterProc. Producing an ISAPI-compatible DLL with Talk would require you to write stub versions of these functions in C++ which would call into Talk to do the actual work. You could then link this tiny stub DLL with a DLL produced by Talk's module system which does the actual implementation.
The structures used in these functions and any auxiliary API which works on these structures can be bound to Talk using the automatic C++ binder, and you can also write the callback functions needed in the _HTTP_FILTER_CONTEXT structure in Talk.
We're ready to take your order! Please contact i...@ilog.co.uk to talk with our UK subsidiary.
-- Harley
------------------------------------------------------------------- Harley Davis net: da...@ilog.com Ilog, Inc. tel: (415) 944-7130 1901 Landings Dr. fax: (415) 390-0946 Mountain View, CA, 94043 url: http://www.ilog.com/
In article <joswig-ya023180000710961702220...@news.lavielle.com> jos...@lavielle.com "Rainer Joswig" writes:
> > before is: who knows this? How many people know that HotMetal was > > written in Lisp?
> Only parts of it were written in Lisp.
The fact that some parts were written in Lisp should be significant enough. VB apps tend not to be written entirely in VB, but we can still consider the VB parts as more significant.
> > Did Time mention that ACL was used to develop this game?
> Sure "Time" mentions for every software what it is written in?
I'm not sure why it might be relevant that Time mentions some software. It only means that the software is newsworthy enough for that publication to report it. If they didn't mention ACL, does that mean that they don't consider ACL to be newsworthy, or just that it isn't of interest to their readers?
I'd be more interested in how a magazine mainly read by developers reported software that used ACL.
> > I hope so, as I'd like Time readers to know that Lisp is > > still being used to develop software.
> Write an article.
Sure, but I only get asked to write about C++. Of course I'll suggest Lisp instead, after pointing out that I'm unable to say anything positive about C++. However, I've not been asked by Time, nor am I likely to be. How significant this may be will depend on relevant Time is to developers.
> > Excellent. How many people will know this?
> More if you tell them.
As I've said before, and I'll probably say again, who listens to me? Not many. I've been plugging Lisp for years, but C++ people tend to give me all the crap that comp.lang.lisp readers will be familiar with. Perhaps it's a matter of faith: mere words won't convince these people - they "know" what works and what doesn't.
> > However, as I've said before, very few people listen to me,
> Hmm, what can you do to change *that*?
I'm doing it. I'm writing a Lisp to C++ compiler, and then see if I can use it instead of coding in C++ directly. I'll then be sure to tell whoever I can that's what I've done.
> > and those that do still tell me to develop in C/C++.
> These are clearly the wrong guys.
Yeah, but who else is there? If somebody would give me a job writing Lisp code, working from home, then I'd take it.
How do you think that _I_ feel? All you're saying is that you don;t have a problem, coz you can use MCL. Great. Good luck to you. You're fortunate enough to be able to do that.
> What actually do we have got from this discussion?
What have we learned? That there are one or two elists here insisting that there's no problem, coz they're ok.
> Are there any actions to be taken? Will anybody write a > useful line of code or will we sit here and cry all > day how hard this cruel world is?
Obviously we should all buy a Mac, then the world might be a little kinder to Apple. You don't care about Windows, and I don't expect you to. Neither of us can change the world on our own. That's why this is worth discussing on UseNet, and presumably why this subject has been discussed here for more years than I've been reading UseNet. I expect it'll still be discussed 10 years from now, tho I hope that by then, the situation will look a little more positive. No doubt by then the C++ situation will be so much worse that more people will be looking at Lisp - or Dylan, or Java, or whatever.
> Writing the nth Lisp interpreter is sure no answer.
I agree. That's why I'm writing a compiler. ;-)
Thanks for your support... -- <URL:http://www.enrapture.com/cybes/> You can never browse enough Future generations are relying on us It's a world we've made - Incubus We're living on a knife edge, looking for the ground -- Hawkwind
