7 ms·

Lisp is a beautiful language but I think the biggest problem with it is its proponents failing to explain the merits. I'm sorry, this post would have probably m

by mojuba 17y ago

Lisp is a beautiful language but I think the biggest problem with it is its proponents failing to explain the merits. I'm sorry, this post would have probably made a bit more sense 15 years ago, but definitely not now. > (a) Very fast development that is enabled by CL (e.g., everything from hash tables to string-operators to memory management is automatically included - there is nothing that is not included). Name a modern mainstream language that doesn't have these things. > (b) Excellent programming environments - e.g., parentheses-savvy editor. You haven't seen XCode, Delphi or MS Visual Studio, where, for example, you can jump to the definition of a symbol with "one click", allow interactive step-by-step debugging with variable watch, disassembly, stack trace, etc - I shouldn't really name all the things that are possible in a typical modern IDE. And I don't know any text editor which is not paren-savvy. > (c) Excellent compiler, especially with declarations, enables very fast code. A compiler which doesn't "enable very fast code" has no place under the sun nowadays. > (d) Excellent system stability with no random crashes at all. Very exciting, although GC-based languages (i.e. those usually lacking pointers) should not crash at all, or if they do crash that's a shame. Stability and robustness of your compiler and your runtime system shouldn't really be mentioned as a merit. If it doesn't meet stability standards, it shouldn't be released. > (e) Macros and all that. Finally getting to the point and you say "and all that"? Btw, "all that" includes unification of code and data - something no other language provides, let's say, idiomatically. This is an amazing feature, and in fact Lisp macros are Lisp macros thanks to just that - unification of code and data and symbolic nature of the language. Memory footprint: megabytes do matter because of the CPU cache. A 30,000 LOC program should take a few megabytes at most and fit a modern CPU cache entirely. Compared to a 50MB program the performance gain can be enormous.

malkia 17y ago
LW (I have LW6) is really great system, for coding, experimenting, and the CAPI user interface is platform-independent (almost, there are some differences, but you can handle them). I do use MSVC all the time at work, XCode occasionally at home, and have used Delphi quite a lot before my current work. But I also bought Lispworks Mac/Win32 versions, and I feel much more productive there. Why? Because I have listener, I can quickly recompile the current buffer (Ctrl+Shift+B), or the current enclosing function (Ctrl+Shift+C), or if I'm at the end of expression evaluate it (Alt+X E). I can keep recompiling the buffer, and all variables declared with defvar would retain their values, I can change object definitions on the fly. It's just easier to experiment. Weaknesses - I'm so much used to the MSVC debugging (I Actually used to be Turbo Debugger junkie in the past), that I miss that - it's simply not easy to debug in LW (or EMACS + slime + any other lisp). But do I need to debug that much more? No - I don't, but that could be because I'm yet at the amateur level.
lispm 17y ago
a) Java is such an example. It does not offer fast development. Contrast it to so-called RAD (Rapid development) tools or rapid prototyping environments, ... Java is a mostly a batch language with a long edit/compile cycle. b) Right. There are several of those. c) For dynamic languages there are fewer excellent compilers. If you check the usual benchmarks, Lisp compilers are among the best in that category. d) That's true. But the reality is different. GCs have bugs. More complex GCs have even more bugs. The FFI may introduce possibilities for errors. I have seen Java guys struggle with obscure heisenbugs. In theory all is mature, in practice it took quite some time to get Java mature and if you read the SUN notes for some of their garbage collectors (the concurrent one, for example), they tell you that they are not stable enough for production. For example the release notes at some point said: "Garbage First (G1) garbage collector Improved reliability and performance Available as 'early access' software. Usage of G1 in production settings without a Java SE for Business support contract is not recommended." e) The 50 MB program usually will not touch all the code all the time - for example LispWorks can include the function compiler in the delivered application - it is likely not called very often. The 50 MB can also consist of a lot of Lisp data, not only code.
- tedunangst 17y ago
  a) The Java I'm familiar with includes hash tables, string-operators, and memory management. Java may or may not enable fast development, but the reasons actually given for why Lisp development is fast certainly apply equally to Java.
  - lispm 17y ago
    Read again what he writes: 'everything ... is automatically included - there is nothing that is not included'. LispWorks comes a huge image that contains all the necessary features, from graphics, networking, memory management, ... Actually you have to REMOVE things to make it smaller (for example using a so-called tree-shaker during 'delivery'). In Java you need to tell which classes/etc. to use. In LispWorks you just call the functions are instantiate the classes - every language feature/library. that he needed for his application, is already included. In LispWorks you start the image and type to the listener. For his task all the functionality was available then.
philwelch 17y ago
"You haven't seen XCode, Delphi or MS Visual Studio, where, for example, you can jump to the definition of a symbol with "one click"" That's an old feature. It used to be called "ctags" and even console-based text editors support it. "Finally getting to the point and you say "and all that"? Btw, "all that" includes unification of code and data - something no other language provides, let's say, idiomatically. This is an amazing feature, and in fact Lisp macros are Lisp macros thanks to just that - unification of code and data and symbolic nature of the language." Lisp's problem seems to be that, until you know how to use macros and code/data unification, you can't be easily convinced of their merits. It takes a considerable commitment to learn Lisp before you can reach that level, though.
- bitwize 17y ago
  That's an old feature. It used to be called "ctags" and even console-based text editors support it. Have you ever used IntelliSense?
  - philwelch 17y ago
    Yes, and it's a very useful feature I haven't found an equivalent to yet, That's not quite what we were talking about though--it's far beyond jumping to the definition of a symbol with a click. IntelliSense doesn't always work, either, at least when I used Visual Studio a lot.
    - city41 17y ago
      Which version of Visual Studio? Intellisense in VS, at least as of 2008, is pretty much rock solid. I can't think of a time when it has failed on me.
      - philwelch 17y ago
        In '03 and '05 Intellisense would intermittently quit, but start working again after a build.
    - 17y ago
gchpaco 17y ago
a) C and C++. Oh, but they're not modern, you say; balls, I say. Both standards were revised very recently and C++ is changing quite a bit. b) SLIME and SBCL (to pick freebies) crush any of those under their collective boot. Eclipse tries real hard but is let down in a number of ways by Java (instability, the fact that the environment is opaque to the user instead of malleable, etc). LispWorks's GUI is very good, at least as good as Eclipse at the things Eclipse is good at. c) You would be shocked at how bad things are. GCC, to pick on a weak and somewhat helpless example, tries really hard to optimize C code but is generally content to merely compile C++ code. XCode with its gcc backend does relatively little real optimization of Objective C, certainly nothing compared to what you expect from a modern JIT in Java. Not familiar enough with Delphi or MSVS to pick those apart but I doubt it's that much different. d) Ditto. Eclipse crashes at least once a day for me during heavy use and suffers bizarre and inexplicable errors even more frequently (fun experiment: create a file Foo.java. Rename it to Bar.java. Try to create Foo.java again. The editor cannot be convinced to read the new Foo.java off disk without a restart). Errors in the native code are not infrequent (I have a bunch of logs here from older Javas where the GC (I think) got confused in the middle of GCing and dumped core), although they seem to be better with Java 6. e) A comp.lang.lisp audience knows about macros and why they're nice. Other language zealots cannot have their minds made up by a simple reiteration of the benefits of code as data (which I agree are considerable). The other points are somewhat more relevant inasmuch as they challenge generally accepted but really wrong concepts. And re: memory footprint: be wary of comparing apples to rutabegas. Remember that every C program benefits from libc and its ancillary stuff; on this here Ubuntu system the system libraries required to bring the system up from a dead stop (not any of this /usr/lib detritus) is already 2.5 MB on disk. Also remember that the 50 MB program footprint likely includes the runtime compiler system (so you can hot swap code; very useful) which is something like 42 MB for gcc 4.4 alone (again, disk; memory usage is enormous). I would expect that the amount of code that needs to stay in the CPU cache is equivalent.
- palish 17y ago
  a) C and C++. Oh, but they're not modern, you say; balls, I say. Both standards were revised very recently and C++ is changing quite a bit. I develop quite quickly in C/C++.
jrockway 17y ago
You haven't seen XCode, Delphi or MS Visual Studio, where, for example, you can jump to the definition of a symbol with "one click" I have used XCode, Eclipse, and Visual Studio. Emacs' tag functionality is much easier to use than the equivalent functionality in those editors. ("C-u M-." and "M-star" are especially convenient. And I would have typed an asterisk there, but news' parser is busted.) The parentheses awareness he is talking about is paredit-mode, which changes Emacs' usual keybindings from operations on lines to operations on S-expressions instead. I never got the hang of it, but Emacs' built-in word/sentence/paragraph movement/editing functionality is essential. I have not seen these features in other editors, including Vim. The other feature that Emacs has over the "visual" editors that you mention is the ability to interactively change how the editor works. (This is especially nice if you're a lisp programmer, as there is nothing to be confused about; it's just Lisp.) I am not just talking about changing the colors or things like that, I am talking about writing new modes, changing the built-in behavior, and so on. I do this so often I don't even consider it unnatural. (Something I fixed today; when loading a ".chs" file into the inferior GHCI buffer via C-c C-l, GHCI complains "this is not haskell", which is true. Then it changes the prompt from "My.Module>" to ">", which makes the next C-c C-l command lock Emacs. I debugged this by seeing which command C-c C-l ran by pressing "C-h k C-c C-l". I then pressed ENT to visit the source code for that function, and noticed that it is programmed to hang until it gets output from GHCI that matches a regex. I changed the regex to something more liberal, hit C-M-x to load my changed function, and my problem was solved. Those two minutes of distraction will save me much frustration over the course of the rest of my life. When was the last time you fixed a bug in Eclipse or Visual Studio in two minutes?) But anyway, Emacs' functionality is not limited to Lisp. I mostly write Perl and Haskell, and Emacs excels at both tasks. It is also a good mail reader, web browser, and IRC client. (Why yes, I am composing this in Emacs.) allow interactive step-by-step debugging with variable watch, disassembly, stack trace, etc - I shouldn't really name all the things that are possible in a typical modern IDE But of course, no REPL. I still don't know what a C++ programmer does when he wants to figure out what regexp he needs to match something. Write a driver program around the library, compile it, debug it, recompile it, and finally run it and play with it? Sounds fun... A compiler which doesn't "enable very fast code" has no place under the sun nowadays. Apparently the real world is not under the sun. Memory footprint: megabytes do matter because of the CPU cache. A 30,000 LOC program should take a few megabytes at most and fit a modern CPU cache entirely. Compared to a 50MB program the performance gain can be enormous. Sure, but you have to realize that most applications that people build with big stacks like CL or Java or C# or whatever are not really CPU-constrained; the context switches kill them. (Wait for user to do something. Wait for database results. Wait to copy response buffer to web server.) Nobody wants code that runs slowly, but the trade-offs to get something really fast (or to fit in the CPU cache, etc.) are not worth the effort for most people. "80% solution" and all that. And, the CPU cache is all about critical sections, anyway; it's usually your data that doesn't fit in cache and slows everything down. So anyway, you are underestimating the capabilities of Emacs.
rosssd 17y ago
To be fair, this is on a Lispworks mailing list discussing Lispworks in particular, which has it's own IDE that provides all of these features. 'Go To Source', 'Edit Definitions', 'Edit Callers', 'Edit Callees', 'Display Backtrace' are all a keystroke (or extended command call way) along with various tools that may or may not be present in others (I've never used MS Visual Studio, which seems to be a leader in this field) One of the parts I miss from it was that break points are at a source level, not a line level, which allowed incredibly fine control when tracking down bugs.

by mojuba 17y ago

malkia 17y ago

LW (I have LW6) is really great system, for coding, experimenting, and the CAPI user interface is platform-independent (almost, there are some differences, but you can handle them). I do use MSVC all the time at work, XCode occasionally at home, and have used Delphi quite a lot before my current work. But I also bought Lispworks Mac/Win32 versions, and I feel much more productive there. Why? Because I have listener, I can quickly recompile the current buffer (Ctrl+Shift+B), or the current enclosing function (Ctrl+Shift+C), or if I'm at the end of expression evaluate it (Alt+X E). I can keep recompiling the buffer, and all variables declared with defvar would retain their values, I can change object definitions on the fly. It's just easier to experiment. Weaknesses - I'm so much used to the MSVC debugging (I Actually used to be Turbo Debugger junkie in the past), that I miss that - it's simply not easy to debug in LW (or EMACS + slime + any other lisp). But do I need to debug that much more? No - I don't, but that could be because I'm yet at the amateur level.

lispm 17y ago

a) Java is such an example. It does not offer fast development. Contrast it to so-called RAD (Rapid development) tools or rapid prototyping environments, ... Java is a mostly a batch language with a long edit/compile cycle. b) Right. There are several of those. c) For dynamic languages there are fewer excellent compilers. If you check the usual benchmarks, Lisp compilers are among the best in that category. d) That's true. But the reality is different. GCs have bugs. More complex GCs have even more bugs. The FFI may introduce possibilities for errors. I have seen Java guys struggle with obscure heisenbugs. In theory all is mature, in practice it took quite some time to get Java mature and if you read the SUN notes for some of their garbage collectors (the concurrent one, for example), they tell you that they are not stable enough for production. For example the release notes at some point said: "Garbage First (G1) garbage collector Improved reliability and performance Available as 'early access' software. Usage of G1 in production settings without a Java SE for Business support contract is not recommended." e) The 50 MB program usually will not touch all the code all the time - for example LispWorks can include the function compiler in the delivered application - it is likely not called very often. The 50 MB can also consist of a lot of Lisp data, not only code.

tedunangst 17y ago
a) The Java I'm familiar with includes hash tables, string-operators, and memory management. Java may or may not enable fast development, but the reasons actually given for why Lisp development is fast certainly apply equally to Java.
- lispm 17y ago
  Read again what he writes: 'everything ... is automatically included - there is nothing that is not included'. LispWorks comes a huge image that contains all the necessary features, from graphics, networking, memory management, ... Actually you have to REMOVE things to make it smaller (for example using a so-called tree-shaker during 'delivery'). In Java you need to tell which classes/etc. to use. In LispWorks you just call the functions are instantiate the classes - every language feature/library. that he needed for his application, is already included. In LispWorks you start the image and type to the listener. For his task all the functionality was available then.

philwelch 17y ago

"You haven't seen XCode, Delphi or MS Visual Studio, where, for example, you can jump to the definition of a symbol with "one click"" That's an old feature. It used to be called "ctags" and even console-based text editors support it. "Finally getting to the point and you say "and all that"? Btw, "all that" includes unification of code and data - something no other language provides, let's say, idiomatically. This is an amazing feature, and in fact Lisp macros are Lisp macros thanks to just that - unification of code and data and symbolic nature of the language." Lisp's problem seems to be that, until you know how to use macros and code/data unification, you can't be easily convinced of their merits. It takes a considerable commitment to learn Lisp before you can reach that level, though.

bitwize 17y ago
That's an old feature. It used to be called "ctags" and even console-based text editors support it. Have you ever used IntelliSense?
- philwelch 17y ago
  Yes, and it's a very useful feature I haven't found an equivalent to yet, That's not quite what we were talking about though--it's far beyond jumping to the definition of a symbol with a click. IntelliSense doesn't always work, either, at least when I used Visual Studio a lot.
  - city41 17y ago
    Which version of Visual Studio? Intellisense in VS, at least as of 2008, is pretty much rock solid. I can't think of a time when it has failed on me.
    - philwelch 17y ago
      In '03 and '05 Intellisense would intermittently quit, but start working again after a build.
  - 17y ago

gchpaco 17y ago

a) C and C++. Oh, but they're not modern, you say; balls, I say. Both standards were revised very recently and C++ is changing quite a bit. b) SLIME and SBCL (to pick freebies) crush any of those under their collective boot. Eclipse tries real hard but is let down in a number of ways by Java (instability, the fact that the environment is opaque to the user instead of malleable, etc). LispWorks's GUI is very good, at least as good as Eclipse at the things Eclipse is good at. c) You would be shocked at how bad things are. GCC, to pick on a weak and somewhat helpless example, tries really hard to optimize C code but is generally content to merely compile C++ code. XCode with its gcc backend does relatively little real optimization of Objective C, certainly nothing compared to what you expect from a modern JIT in Java. Not familiar enough with Delphi or MSVS to pick those apart but I doubt it's that much different. d) Ditto. Eclipse crashes at least once a day for me during heavy use and suffers bizarre and inexplicable errors even more frequently (fun experiment: create a file Foo.java. Rename it to Bar.java. Try to create Foo.java again. The editor cannot be convinced to read the new Foo.java off disk without a restart). Errors in the native code are not infrequent (I have a bunch of logs here from older Javas where the GC (I think) got confused in the middle of GCing and dumped core), although they seem to be better with Java 6. e) A comp.lang.lisp audience knows about macros and why they're nice. Other language zealots cannot have their minds made up by a simple reiteration of the benefits of code as data (which I agree are considerable). The other points are somewhat more relevant inasmuch as they challenge generally accepted but really wrong concepts. And re: memory footprint: be wary of comparing apples to rutabegas. Remember that every C program benefits from libc and its ancillary stuff; on this here Ubuntu system the system libraries required to bring the system up from a dead stop (not any of this /usr/lib detritus) is already 2.5 MB on disk. Also remember that the 50 MB program footprint likely includes the runtime compiler system (so you can hot swap code; very useful) which is something like 42 MB for gcc 4.4 alone (again, disk; memory usage is enormous). I would expect that the amount of code that needs to stay in the CPU cache is equivalent.

palish 17y ago
a) C and C++. Oh, but they're not modern, you say; balls, I say. Both standards were revised very recently and C++ is changing quite a bit. I develop quite quickly in C/C++.

jrockway 17y ago

You haven't seen XCode, Delphi or MS Visual Studio, where, for example, you can jump to the definition of a symbol with "one click" I have used XCode, Eclipse, and Visual Studio. Emacs' tag functionality is much easier to use than the equivalent functionality in those editors. ("C-u M-." and "M-star" are especially convenient. And I would have typed an asterisk there, but news' parser is busted.) The parentheses awareness he is talking about is paredit-mode, which changes Emacs' usual keybindings from operations on lines to operations on S-expressions instead. I never got the hang of it, but Emacs' built-in word/sentence/paragraph movement/editing functionality is essential. I have not seen these features in other editors, including Vim. The other feature that Emacs has over the "visual" editors that you mention is the ability to interactively change how the editor works. (This is especially nice if you're a lisp programmer, as there is nothing to be confused about; it's just Lisp.) I am not just talking about changing the colors or things like that, I am talking about writing new modes, changing the built-in behavior, and so on. I do this so often I don't even consider it unnatural. (Something I fixed today; when loading a ".chs" file into the inferior GHCI buffer via C-c C-l, GHCI complains "this is not haskell", which is true. Then it changes the prompt from "My.Module>" to ">", which makes the next C-c C-l command lock Emacs. I debugged this by seeing which command C-c C-l ran by pressing "C-h k C-c C-l". I then pressed ENT to visit the source code for that function, and noticed that it is programmed to hang until it gets output from GHCI that matches a regex. I changed the regex to something more liberal, hit C-M-x to load my changed function, and my problem was solved. Those two minutes of distraction will save me much frustration over the course of the rest of my life. When was the last time you fixed a bug in Eclipse or Visual Studio in two minutes?) But anyway, Emacs' functionality is not limited to Lisp. I mostly write Perl and Haskell, and Emacs excels at both tasks. It is also a good mail reader, web browser, and IRC client. (Why yes, I am composing this in Emacs.) allow interactive step-by-step debugging with variable watch, disassembly, stack trace, etc - I shouldn't really name all the things that are possible in a typical modern IDE But of course, no REPL. I still don't know what a C++ programmer does when he wants to figure out what regexp he needs to match something. Write a driver program around the library, compile it, debug it, recompile it, and finally run it and play with it? Sounds fun... A compiler which doesn't "enable very fast code" has no place under the sun nowadays. Apparently the real world is not under the sun. Memory footprint: megabytes do matter because of the CPU cache. A 30,000 LOC program should take a few megabytes at most and fit a modern CPU cache entirely. Compared to a 50MB program the performance gain can be enormous. Sure, but you have to realize that most applications that people build with big stacks like CL or Java or C# or whatever are not really CPU-constrained; the context switches kill them. (Wait for user to do something. Wait for database results. Wait to copy response buffer to web server.) Nobody wants code that runs slowly, but the trade-offs to get something really fast (or to fit in the CPU cache, etc.) are not worth the effort for most people. "80% solution" and all that. And, the CPU cache is all about critical sections, anyway; it's usually your data that doesn't fit in cache and slows everything down. So anyway, you are underestimating the capabilities of Emacs.

rosssd 17y ago

To be fair, this is on a Lispworks mailing list discussing Lispworks in particular, which has it's own IDE that provides all of these features. 'Go To Source', 'Edit Definitions', 'Edit Callers', 'Edit Callees', 'Display Backtrace' are all a keystroke (or extended command call way) along with various tools that may or may not be present in others (I've never used MS Visual Studio, which seems to be a leader in this field) One of the parts I miss from it was that break points are at a source level, not a line level, which allowed incredibly fine control when tracking down bugs.