*RedSweater does a run on his thoughts*
Bishop Pass, Trzy or whatever...
What the hell are you talking about? I usually skip big paragraphs and only read the topic sentences, but god to hell, WTF?
Lisp is King
It doesn''t cost money to click on links to books(unless you pay directly for your bandwidth instead of a flat monthly fee)... I didn''t say books for purchase, and if you had looked, you would have noticed the several books free for legal download as PDFs linked to in that thread.
quote:Original post by trzy
When I said "implementing a solution", that implied the problem has been solved. The question is therefore which language (Lisp or C) is better at it. Merely making the problem go away isn''t the issue, because you can probably do it in both.
It is the issue though. When you have 100 lines of C++ code to one line of Lisp code, it''s clear that 99% of the problem went away when you chose Lisp. Let me put it this way: Lisp encapsulates virtually the entire concept of programming in a data structure which can be manipulated with ease with Lisp. Does C++ do that? Can a C++ class be manipulated or reprogrammed at runtime? Can the code of a C++ program be teased apart from within itself? Can a C struct dynamically change at runtime?
quote:Original post by trzy
Would Lisp be suitable for most of what is being done in C right now, whatever that may be?
C is suitable for driver coders. Are you coding drivers?
quote:Original post by trzy
One of the complaints about Lisp is that it isn''t a practical language for large projects, even if it is a very interesting way to approach problems.
Actually, Lisp is very suitable for gigantic projects. This is especially true when you wish to code that gigantic project with 10% of the manpower that you might require if doing something similar in C++.
quote:Original post by trzy
Perhaps a better request would have been: Write a high-performance real-time 3D engine in Lisp.
Sure, why not? The OpenGL library is where the driver code resides, and that has already been coded in C.
quote:Original post by trzy
Lisp doesn''t seem too interesting for the things I''m playing with now: 3D graphics and compilers.
Saying Lisp isn''t too interesting with regard to compiler development is like saying airplanes aren''t too interesting with regard to powered flight. Do me a favor. Get a better handle on Lisp as a whole.
quote:Original post by trzy
Arguably, Lisp could be handy for programs which need to process data such as BSP trees, etc. For sophisticated compilers, I''m not sure Lisp would be helpful.
Ah. Sort of like saying language wouldn''t be helpful for communication. Ok...
quote:Original post by trzy
What I would really find handy for writing programs to manipulate lots of complex data structures is a language that makes creating, manipulating, and managing data structures very easy.
Lisp makes managing and manipulating complex data so easy that you forget the data is complex at all. This is because with Lisp, all of a sudden there is no complexity with regard to the data. All of that complexity you''re thinking of is because it''s such a pain to do in a language like C or C++.
quote:Original post by trzy
I don''t see Lisp as being too practical for this in itself...
Like I said, get a better handle on what Lisp is, and then come back.
quote:
Can a C++ class be manipulated or reprogrammed at runtime? Can the code of a C++ program be teased apart from within itself? Can a C struct dynamically change at runtime?
No, neither C nor C++ can do that. However, if these languages could easily do that, I doubt this feature would be taken advantage of very often. Most of the time this isn''t something you want to do. In fact, most of the time this is exactly what you don''t want to do. When cases where this feature is useful do show up, noone''s stopping you from writing this particular module of your application in Lisp.
The point is, this feature is certainly fascinating and has very interesting applications, but how usable is it in real world applications?
quote:Original post by kill
The point is, this feature is certainly fascinating and has very interesting applications, but how usable is it in real world applications?
Very. The C++ paradigm has taught you to work within its own limitations. You must explicitly define the exact structure of a class or struct and then work with it. Lisp doesn''t impose this on you. Lisp works well with incomplete data, or data structures which grow according to the evolving data that is being acquired.
Hmm. Now I see what you meant when you said that often times C++ programmers implement a hacked up version of a Lisp interpreter. I have implemented code that deals with structures that evolve depending on the data... Can''t say my solutions weren''t elegant, but I am yet to see how Lisp solves this...
To me a language can be judged on two critereas: coverage area and elegance.
Coverage area is a product of horizontal and vertical coverage. Horizontal coverage is the number of programming paradigms a language supports: imperative, OO, generic, functional, etc. A vertical coverage is how well each facility scales in terms of low/high level code. An example of that is inline assembly and "register" keyword for low level code and reflection and scripting for high level code.
Elegance is how well the features listed above integrate into overall design of the language: how well they interoperate, how well they do things they were designed to do, etc. While many will say that Elegance is in the eye of the beholder, I strongly disagree, I''m sure we could all agree on an objective elegance measure.
In a perfect world determining whether language A is "better" then language B would be easy: look at the coverage area and scale it with elegance. Then compare both grades and you get a better language. In the real world, however, it''s extremely hard to design a language with high coverage area that still remains elegant. For instance, adding a Lisp style macro feature to C++ is simply impossible if one wants to keep a reasonable degree of elegance. Similarly you probably wouldn''t be able to add graceful custom memory management feature to Lisp. This is why most language debates don''t make sense: different languages have different coverage areas that are disjoint: one is not a subset of another.
A language debate makes sense when a coverage area of one language is clearly a subset of a coverage area in another. For instance, C# on .NET platform clearly has a coverage area that is larger then the coverage area of Java. Even more, coverage area of Java is a clear subset of coverage area of C#. Couple that with the fact that C# is often times more elegant then Java, and a debate which is better has a very simple answer. Anyone who thinks Java is better then C# either doesn''t have enough knowledge of both platforms or is simply a fanatic.
C++ vs. Lisp debate makes absolutely no sense because coverage areas of both languages often don''t overlap. Even more, it''s impossible to make them overlap: in practice if a language has a significantly low level feature, adding a significantly high level feature while remaining elegant is probably impossible. This is why we shouldn''t concentrate on anything vs. Lisp, instead it would be a lot more productive to outline the features Lisp has that other languages don''t (and can''t) posess.
To me a language can be judged on two critereas: coverage area and elegance.
Coverage area is a product of horizontal and vertical coverage. Horizontal coverage is the number of programming paradigms a language supports: imperative, OO, generic, functional, etc. A vertical coverage is how well each facility scales in terms of low/high level code. An example of that is inline assembly and "register" keyword for low level code and reflection and scripting for high level code.
Elegance is how well the features listed above integrate into overall design of the language: how well they interoperate, how well they do things they were designed to do, etc. While many will say that Elegance is in the eye of the beholder, I strongly disagree, I''m sure we could all agree on an objective elegance measure.
In a perfect world determining whether language A is "better" then language B would be easy: look at the coverage area and scale it with elegance. Then compare both grades and you get a better language. In the real world, however, it''s extremely hard to design a language with high coverage area that still remains elegant. For instance, adding a Lisp style macro feature to C++ is simply impossible if one wants to keep a reasonable degree of elegance. Similarly you probably wouldn''t be able to add graceful custom memory management feature to Lisp. This is why most language debates don''t make sense: different languages have different coverage areas that are disjoint: one is not a subset of another.
A language debate makes sense when a coverage area of one language is clearly a subset of a coverage area in another. For instance, C# on .NET platform clearly has a coverage area that is larger then the coverage area of Java. Even more, coverage area of Java is a clear subset of coverage area of C#. Couple that with the fact that C# is often times more elegant then Java, and a debate which is better has a very simple answer. Anyone who thinks Java is better then C# either doesn''t have enough knowledge of both platforms or is simply a fanatic.
C++ vs. Lisp debate makes absolutely no sense because coverage areas of both languages often don''t overlap. Even more, it''s impossible to make them overlap: in practice if a language has a significantly low level feature, adding a significantly high level feature while remaining elegant is probably impossible. This is why we shouldn''t concentrate on anything vs. Lisp, instead it would be a lot more productive to outline the features Lisp has that other languages don''t (and can''t) posess.
quote:Original post by trzy
Anyway, go write a complete modern operating system in Lisp. Have fun.
What makes you think that isn''t a good idea? It''s only circumstance that has resulted in C being the lingua franca for building OSs. Lisp OSs
quote:When you have 100 lines of C++ code to one line of Lisp code, it''s clear that 99% of the problem went away when you chose Lisp.
And how often does a real-world problem get reduced with such an impressive ratio?
None of the Lisp code I''ve seen seems appreciably smaller than C code trying to do the same thing.
I''d like to see a real problem solved with Lisp and C so I can compare them. Is there anything out there you could recommend to take a look at? Any sophisticated compilers written in Lisp?
quote:
Does C++ do that?
No, because it''s compiled into syntax trees, thus freeing the programmer from burden of having to think in terms of that sort of structure.
quote:
C is suitable for driver coders. Are you coding drivers?
C is suitable for a lot more than driver code. It''s been used for a lot things, you know, with spectacular results.
I''m not arguing it''s the be-all end-all of languages, because it certainly isn''t and it is slowly fading away, but it''s functionality is nothing to be scoffed at.
quote:
Actually, Lisp is very suitable for gigantic projects.
Such as?
quote:
Saying Lisp isn''t too interesting with regard to compiler development is like saying airplanes aren''t too interesting with regard to powered flight. Do me a favor. Get a better handle on Lisp as a whole.
Then why isn''t Lisp more popular in compiler development?
I can''t imagine something like GCC or ORC done in Lisp. Neither are pretty as it is, but I don''t think Lisp would cut down the code complexity and size significantly. The code would probably be a lot harder to follow and maintain.
quote:
Ah. Sort of like saying language wouldn''t be helpful for communication. Ok...
I''m not sure what that was supposed to mean, but I take it that this has something to do with your previous points about Lisp''s incredible flexibility -- being able to modify data structures and code on the fly.
quote:
Lisp makes managing and manipulating complex data so easy that you forget the data is complex at all. This is because with Lisp, all of a sudden there is no complexity with regard to the data.
I guess most of the complexity is moved to the nested lists?
Here''s quicksort in C.
Here it is in Lisp. Beautiful.
There''s another implementation here at 13.5.2. Not much more impressive.
----
Bart
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement