• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Archived

This topic is now archived and is closed to further replies.

Forcas

Is LISP fluency worth it?

46 posts in this topic

Quote:
Original post by Sneftel
Lisp is kinda fun, but it feels inelegant and pieced-together. Just as the first airplane ever probably ended up with a lot of ugly nailed-on afterthought pieces, so does this pioneer of functional languages.


Elegance is the first thing I'd claim in favor of Lisp. For instance, I love how lists are used everywhere - including the &rest parameters of a function and the apply function. The cons pair is a pinnacle of elegance.

Can you give some examples of ugliness?

Quote:
Scheme may be more to the liking of the programmer who wants to make use of functional programming.


Lisp is not necessarily functional, nor is functional programming the high point of Lisp.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by xg0blin
Did SabreMan leave the forums or something? You'd think he'd be all over this.

i was wondering the same thing
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Diodor
Elegance is the first thing I'd claim in favor of Lisp. For instance, I love how lists are used everywhere - including the &rest parameters of a function and the apply function. The cons pair is a pinnacle of elegance.

While it's elegant, it's also oversimplified. Good Lisp implementations work like hell behind the scenes to make everything *look* like neat cons lists, while tossing that structure out behind the scenes wherever possible in favor of something more efficient. A good Lisp programmer needs to be aware, to some extent, of when and how such optimizations are being made (so he doesn't quixotically try to improve performance with something like RPLACD) even though he is encouraged by the interface to put such matters out of mind. Admittedly, any language is to some extent a compromise between a simple and usable interface and support for inherently efficient constructs, but I think Lisp leans a little too far towards the former.
Quote:
Can you give some examples of ugliness?

The number-one issue I'd point to is the bloated list of standard forms. Quick, what's the difference between (NTH 3 X) and (THIRD X)? Why is LENGTH called LENGTH, and LIST-LENGTH called LIST-LENGTH? Over time, the disparate and aggressively incompatible variants have merged into a more-or-less standard language, but IMHO the standards committee wasn't proactive enough in reforming the best pieces of each into a coherent whole.
Quote:
Lisp is not necessarily functional, nor is functional programming the high point of Lisp.

That's a good point. I'd hasten to point out, though, that virtually all Lisp primers strongly encourage a functional style of programming.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
While it's elegant, it's also oversimplified. Good Lisp implementations work like hell behind the scenes to make everything *look* like neat cons lists, while tossing that structure out behind the scenes wherever possible in favor of something more efficient. A good Lisp programmer needs to be aware, to some extent, of when and how such optimizations are being made (so he doesn't quixotically try to improve performance with something like RPLACD) even though he is encouraged by the interface to put such matters out of mind. Admittedly, any language is to some extent a compromise between a simple and usable interface and support for inherently efficient constructs, but I think Lisp leans a little too far towards the former.


I'll disagree here. There's no such thing as "oversimplification" - anything that will make programming easier at the expense of efficiency is desirable.

Your argument is that because Lisp is too far removed from the "raw metal" when one _needs_ to optimize it's much harder to do so. It is argued that it is possible to optimize Lisp code, but I don't know much about doing that.

If I understand correctly, the standard counter to this is the "early-optimisations are bad" argument. Lisp allows one to code quickly without much care for efficiency, get the program working correctly early (!), and, _if_ necessary, optimize the bottlenecks. The flexibility of the language makes high-level algorithmic optimisations a lot easier too (while it makes low level ones harder).

Quote:
The number-one issue I'd point to is the bloated list of standard forms. Quick, what's the difference between (NTH 3 X) and (THIRD X)? Why is LENGTH called LENGTH, and LIST-LENGTH called LIST-LENGTH? Over time, the disparate and aggressively incompatible variants have merged into a more-or-less standard language, but IMHO the standards committee wasn't proactive enough in reforming the best pieces of each into a coherent whole.


THIRD (or CADDR) is a special case of NTH - I'd assume the compiler would like me more for using THIRD instead of NTH 3 if I can.

I knew LENGTH can tell the length of lists, arrays, strings and bit arrays. If I was smart enough I could have assumed LIST-LENGTH only tells the length of lists (although I've never encountered this one), but as it is I had to spend fifteen seconds to fire up Corman Lisp and write and execute (list-length '(1 2 3)) and (list-length "foo-bar") to make sure.

Anyway, I only know parts of the language well enough so I can't say much about how coherent the whole is.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
That's a good point. I'd hasten to point out, though, that virtually all Lisp primers strongly encourage a functional style of programming.


Macros aren't functional programming are they? :)

That being said, I understand why keeping my functions functional is an advantage when looking from the outside of the function. Inside the function I really appreciate the freedom to setq and setf left and right - if no side effects are visible from the outside there should be no complaints.

But functional programming is only allowed in Lisp - the language itself has plenty of functions that perform destructive operations on their arguments (functions like sort or mapcan have caused me quite a bit of pain).
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Diodor
THIRD (or CADDR) is a special case of NTH - I'd assume the compiler would like me more for using THIRD instead of NTH 3 if I can.

Yeh, except that NTH counts from zero, not one. Thus, NTH 3 is equivalent to FOURTH. Wacky, no?
Quote:
LIST-LENGTH only tells the length of lists

That's part of it, but the real feature of LIST-LENGTH (and the reason it's in the language at all) is to avoid infinite loops with circular lists.

Why not implement NTH from 0, or put in a ZEROTH and shift the other operators accordingly? Why not rename LIST-LENGTH ACYCLIC-LENGTH or something? because those changes took CL too far from the proprietary Lisps. And although most of those Lisps haven't been in general use in years, their egos still contribute to the cruft of the language.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Yeh, except that NTH counts from zero, not one. Thus, NTH 3 is equivalent to FOURTH. Wacky, no?


You've got me there :)

Quote:
That's part of it, but the real feature of LIST-LENGTH (and the reason it's in the language at all) is to avoid infinite loops with circular lists.


That's good to know, thanks.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
And although most of those Lisps haven't been in general use in years, their egos still contribute to the cruft of the language.


list-length (and many of the other non-trivial Lisp functions) can be implemented in Lisp. It depends on the implementation of course, but really, it's part of the library, and not the language.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by MadKeithV
list-length (and many of the other non-trivial Lisp functions) can be implemented in Lisp. It depends on the implementation of course, but really, it's part of the library, and not the language.


I don't think you can usually separate the library from the language, and even less so in the case of Lisp. Here even basic operators like and or or are implemented in Lisp.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Diodor
I don't think you can usually separate the library from the language, and even less so in the case of Lisp. Here even basic operators like and or or are implemented in Lisp.


I feel exactly the opposite: what makes a library a library is that it is separate from the language. Note though: that doesn't take away the fact that libraries are important in the Real World (tm) to make a language useful.

I can agree with "Lisp has some pretty strange library functionality", because it's just downright true, but the language itself is quite clear and concise. It is testament to its conciseness and power that even some of the operators that are considered "basic" are in fact library code. If tomorrow you wake up and decide you need a "list-length" that operates differently (perhaps even written in a different language, though I have no experience doing that in Lisp), you can actually do it.

Important side note: I'm still pretty much a C++ programmer for all this Lisp evangelism ;)


0

Share this post


Link to post
Share on other sites
Quote:
Original post by MadKeithV
Quote:
Original post by Sneftel
And although most of those Lisps haven't been in general use in years, their egos still contribute to the cruft of the language.


list-length (and many of the other non-trivial Lisp functions) can be implemented in Lisp. It depends on the implementation of course, but really, it's part of the library, and not the language.

I agree. I believe that with Corman Lisp (as is likely with many others), only the most basic functionality (car, cdr, symbols etc) are written in C++, and the rest is written in Lisp itself. IIRC, you can actually see the Lisp code for the "fluff."
0

Share this post


Link to post
Share on other sites
> Good Lisp implementations work like hell behind the scenes to make everything *look* like neat cons lists, while tossing that structure out behind the scenes wherever possible in favor of something more efficient.

I think he's talking about CDR-coding. Boy, I haven't thought about that in a long time. Do any implementations still use that?

0

Share this post


Link to post
Share on other sites
Here is an example of why LISP is harder than C++:

I just spent an hour debugging a program consisting of three functions. I kept getting "WRONG-NUMBER-OF-ARGS", but couldn't find a function with the wrong number of args.

I ended up having to trace just about every function I used and finally discovered that in an if statement, the function for a non-nil predicate was being called even though, in this particular case, the predicate evaluated to NIL.

How do you pick up on the numerous intracacies of LISP? Are they consistent in any way?

0

Share this post


Link to post
Share on other sites
Post the code - I don't really understand what went wrong with your program.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Forcas
Here is an example of why LISP is harder than C++:

Maybe your inexperience is a slight factor? :p
0

Share this post


Link to post
Share on other sites
Yeah. I don't need to post the code, I already figured it out. My inexperience is definitely to blame.
0

Share this post


Link to post
Share on other sites
Quote:

anything that will make programming easier at the expense of efficiency is desirable.


By that token, we should all be using interpreted languages that can barely churn out a 2-d image in 30 seconds.

0

Share this post


Link to post
Share on other sites
Quote:
Original post by Etnu
By that token, we should all be using interpreted languages that can barely churn out a 2-d image in 30 seconds.


Yes you should. Well, not in your inner loop I suppose, but scripting languages are definitely useful. "Fast" languages are useful too, for about 10% of your application's code.

Now that you mentioned it, Lisp doesn't really need to use "interpreted scripting languages". With Lisp you can design some custom scripting language and have your program load the "scripts" at runtime and compile them on the spot, enjoying all the benefits. In fact, you can modify everything in your program while it's running! Neat, isn't it?
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Forcas
Given that LISP is used in few commercial games, is it worth becoming fluent in anyway?

Err... yes. If you stick to only following the crowds, then you may be denying yourself an opportunity for being any better than the crowds. Try exercising free-thought. Learn enough about Lisp to decide for yourself whether it's worth becoming fluent. You can't expect someone else to do your thinking for you.
Quote:

A.) It is used in academic papers. Being fluent in LISP allows a person to stay on top of the latest developments in AI.

It's not so much used in academia these days, since academia has been watered down by institutions pandering to what industry thinks it needs.
Quote:

B.) It can be embedded into game engines. I heard that Halo uses an embedded LISP-like language for AI. Could embedded LISP-style languages benificial in the long run?

Yes of course. See Franz success stories for more.
Quote:

I''ve been reading through LISP by Winston & Horn in my free time for the past year, and I have to say that while I''m familiar with many of LISP''s features, when it comes to coding in LISP, I have the speed and effectiveness of a slug.

Then you need to do more coding.
Quote:

What''s with this language? There are too many parenthesis and stuff.

If you haven't yet realised why the parentheses are necessary, then continue learning. `There are too many parenthesis' is not a well-considered criticism.
Quote:

I really like the transparency of lists in LISP, and have researched the benefits of functional programming, but I''m still not convinced that I can code anything in LISP with more ease than I could in C++.

Presumably that means you know C++ better than you know Lisp.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by DeVla
Hello i'm a novice programmer and i'm trying to write the lesson 40
in Scheme (original coded in C++) it's quite hard ... i finished it but i got some performances problems, i've done some optimisations but it's not enough ...

As you know Scheme is a lisp dialect, maybe some gentle peeps could see at my code and give me an advice ? :) plz

Well, for starters I'd post your question in the For Beginners forum. Also, mention exactly what lesson 40 is, as that doesn't help at all.
0

Share this post


Link to post
Share on other sites
Quote:
Given that LISP is used in few commercial games, is it worth becoming fluent in anyway?


Do you plan on writing clones of those games? If not, then it's irrelevent what game companies are using to code their games. I'm sure that those companies chose Lisp because it gracefully provided a solution to game functionality. That in itself is the best reason to choose a language. There is absolutely no reason to shoe-horn any language into a solution just because it may be popular or likewise exclude it because it is not, be it Lisp, C, Java, BASIC, or IBM 370 assembly language. Pick the language that best solves your problem.

Quote:
A.) It is used in academic papers. Being fluent in LISP allows a person to stay on top of the latest developments in AI.


Perhaps, but there are also quite a few AI papers out there based on Prolog, CLIPS, Haskell, Scheme, Java, C, C++, etc...

Quote:
B.) It can be embedded into game engines. I heard that Halo uses an embedded LISP-like language for AI. Could embedded LISP-style languages benificial in the long run?


In reality any language can be embedded into a game engine, it just so happens that Lisp-like interpretters can be implemented in a relatively small code-base. Note: For every Lisp-like game scripting language, there are probably dozens of proprietary solutions used.

Quote:
What''s with this language?


Writing Lisp code requires a massive paradigm shift from writing procedural or OO code.

Quote:
There are too many parenthesis and stuff.


The parenthesis problem is laughable compared to the truly hairy features that Lisp has (Macros and Closures for example). If after a year the parenthesis are still a sticking point for you, then perhaps you might consider this a failed expiriment and move on.

Quote:
not convinced that I can code anything in LISP with more ease than I could in C++.


This is really a two-way street. That is, there are certain problems (list processing for example) that are huge undertakings in C++ (bare C++ that is), and the reverse holds true for Lisp as well. If you feel that you can easily perform a given task with C++ over Lisp, then by all means run with it.

Quote:
Should I persue LISP until I am fluent in it? Any advice?


I personally love Lisp because it is extremely extensible and therefore extremely powerful. However, in day to day application development, it is not my choice of language. There is a lot to learn from using Lisp. A lot, that is, that may never present itself ever again outside of a Lisp problem. Just about anything that can be done with Lisp can be done with any other language. However, Lisp promotes elegance because of its nature. Lisp's very nature contains many core concepts at the foundation of computer science; and for that reason alone it is worth researching.
-m

0

Share this post


Link to post
Share on other sites
Quote:
Original post by civguy
Quote:
Original post by Dobbs
Most of the book focuses on teaching you the tools you need to do this (Lisp macros), and the real meat (where these specialized languages are implemented using macros) isn't until the end.
Disagreed.. "How macros work" was actually explained pretty quickly, and then there were all these different techniques using variable capture and other stuff with small examples. The very last chapters weren't that interesting IMO, but pretty specific and almost tiresomely lenghty examples of how macros can be used in some particular problems. Not so useful as the chapters before those, which had more general ideas that you can apply to your own macros.


Personally I think you sort of missed the point of the final few chapters. Yes, the middle chapters are very good for teaching you how to write macros, and how to use a couple of interesting techniques like variable capture. But, to me, "how macros work" is sort of useless without "the big picture," if you'll pardon the cliche, that is concrete examples of intelligent and creative macro use to create specialized languages. In my mind that's where the last few chapters of the book came in, starting with the fact querying database and moving on to continuations, prolog etc. (although good god the continuations part was painful).

Or maybe we just have very different perspectives. C'est la vie.
0

Share this post


Link to post
Share on other sites