|
Member 10389821 wrote: LISP = Lots of Incessant Stupid Parenthesis 
Wow, you brought a bunch of memories back from a LONG time ago.
Sorry for your pain.
|
|
|
|
|
I don't know of many commercial applications, though reading some stuff (perhaps dubious) that may be because companies don't want their competition to know about their competitive advantage.
I can only speak from my own experience. Other than some indicating that Lisp is more a university teaching tool, I found it the other way round: At uni I learned Pascal, C++ & Java. I learned Basic & Lisp for myself before I went to uni. And because I do a lot of work in CAD I've been using AutoLisp "in anger"  since the early 90's. Though AutoLisp (and even the Visual Lisp since the late 90's) is far removed from a full-fledged Lisp/Scheme - it still indicates a lot of stuff where other languages (at least of the time) struggled or made the programmer's life difficult. So you can imagine how I find a full Lisp in comparison to something like Java/C#. Only later did I see languages such as Python, which I consider to have come close enough to Lisp to be deemed "as powerful" - to an extent. Linq gives C# "some" of Lisps abilities, but far from all.
I'm NOT trying to say any language is "bad" or "inferior" to any other, each one I learned taught me something (at least). And I might even go as far as to say some excel in certain uses. Though I must say that Lisp has yet (for me) to be relegated to a superseded language, it's still the only one which has so much scope, multi-paradigm mix-ability, concise code, decent-to-excellent compiler optimization, ease of patching / debugging on the fly, etc.
Remember, Lisp was actually invented "by accident" - it was intended as an intermediate step to inventing a more Fortran-like language which would incorporate all the special constructs and use cases which Fortran lacked at the time. Only that last took too long and people started seeing just how simple Lisp is to use while adding so much power for so little input.
This last thing is still an issue today: I can attest to using C# and AutoLisp to do the exact same thing inside AutoCAD. The Lisp code is on average 1/3 of that which I need to actually type into the C# (note not counting the "autogenerated" stuff or the pre-made templates, otherwise it would be more like 1/5) in order for the 2 to do exactly the same thing. Many say less code is not a big issue, but I have to state that my Lisp code tends to take not just less time to type but also a lot less time to debug - it's a near exponential increase in my productivity.
|
|
|
|
|
irneb wrote: Lisp code tends to take not just less time to type but also a lot less time to debug - it's a near exponential increase in my productivity.
Intersting.
|
|
|
|
|
JimmyRopes wrote: Intersting.
I must state though: My personal experience is a bit unique in that the AutoCAD DotNet API and the AutoLisp integration into ACad both give the same (to a point) functionality. So here I can actually compare apples with pears 
For the general case though, Lisp is not used as much as other languages. E.g. if you need to do something in DotNet and you want to use Lisp, then there are only 2 (that I know of) variants which might work: IronScheme (Scheme direct inside DotNet) and ABCL (Armed Bear Common Lisp inside the JVM) / Clojure through the JVM-Net-bridge. Otherwise you can write unmanaged Lisp code in CL and then use the DotNet libraries through CL's RDNZL library (similar to Java's bridge idea), but I don't know how you'd create new DotNet execs/libs from such.
If you're writing unmanaged code (i.e. direct compile to hardware's instruction set - not through a virtual machine like DotNet/JVM) then your options are greatly increased. Most Lisp implementations would compile to something similar as C would, in fact a lot of them actually use C as a form of assembly - i.e. translating the Lisp-code to C code and then using a C-compiler to produce the executable.
|
|
|
|
|
Thanks for the information
|
|
|
|
|
I program in Emacs Lisp (ELisp) all the time, and love Lisp in that application, so much that I would like to use Lisp for other things.
However, I've only used Common Lisp a little bit, for very small things, and almost always opt for something else when I have something that needs to get done.
I think the difference is the "atoms". The atoms in Emacs Lisp are geared for text processing and it makes Emacs a very effective text processing framework, for me, anyway. Apparently only 1% of Emacs users actually write ELisp. Common Lisp I guess just doesn't appeal to me as a general purpose language, because in my limited experience with it, the atoms just don't do it for me. Maybe if I gave it a harder push, but in the presence of other options, I tend toward the other options.
I would not discourage you from learning Lisp, because it changes how you think about programming and yes, will make you a better programmer in any language for the experience. If you google Paul Graham, he provides some advantages of Lisp; he used it to write I believe Yahoo's Shopping Cart. A more interesting story for me can be found if you google "Lisping at JPL".
|
|
|
|
|
|
Not personally but my brother does. There are certain types of research and engineering problems that LISP handles well (which is the type of work he does). The language is fully recursive in nature so imagine using it to solve a problem which is also recursive in nature.
|
|
|
|
|
Thanks for the information
|
|
|
|
|
|
|
Haven't used it since my Artificial Intelligence term project in grad school. It was a frame-based system for playing chess endgames. The ability to treat LISP code as objects was convenient for this application. Haven't had the opportunity or inclination to use it since then.
|
|
|
|
|
Thanks for the information.
|
|
|
|
|
Lost In Stupid Parentheses (LISP)... Yes, I did use LISP about 20+ years ago. Didn't know it was still used or even known!?
|
|
|
|
|
bwallan wrote: Didn't know it was still used or even known!?
I was reading something written by Alan Kay[^] and he mentioned LISP as being the best computer language. It was probably written many years ago. It got my curiosity up about if it was still used and if it was worth learning.
|
|
|
|
|
Since Alan K. was playing around with LISP in the late 1960's, I would assume the quote came from around then. LISP appears to be one of most enduring languages (along with Fortran), originating in 1958.
Reading the Wikipedia article on LISP it would look like it has had a resurgence in recent years. I might dig up my old LISP code and see if it is still viable...
bwa
|
|
|
|
|
bwallan wrote: Since Alan K. was playing around with LISP in the late 1960's, I would assume the quote came from around then.
Quite likely.
|
|
|
|
|
After reading through some of the other comments, these things come to mind:
1. I agree, after learning Common Lisp for a few days, I was like "What on earth will I ever use this for?"
2. After spending a couple of days with Clojure, I was like, "Oh man, I wish I could use this to write ALL of my code!"
So if you're going to look into it, I can personally recommend Clojure for the following reasons:
1. It's fun (at least in my opinion)
2. It will absolutely change the way you think about programming (even in OO contexts)
3. It's a JVM language, so you can use it along with Java code (or Scala, or Groovy, or ...)
4. You have the functional paradigm (it's a LISP dialect) but you can also do object-oriented things (it runs on the JVM) if that makes sense for the situation.
5. It IS in active use in a number of projects today (though I can't remember them off the top of my head; that's fine, go ahead and call me out for that; or better yet, just google it)
6. It has an active user community. I've always found answers to my questions on Stack Overflow.
As for why to learn functional programming in general, I agree with one of the posters who said that it increases his productivity. In my experience, functional programs are easier to reason about. If you can break your entire program down into a set of small functions, you can test each of the functions individually. (If you put in the same arguments you should always get the same result.) If you can determine that each of your smaller functions is logically correct, then it becomes easier to reason that your full program is logically correct. And if your program has fewer bugs, you won't spend as much time debugging.
Thinking functionally requires me to think more about what I want to DO, and much less about HOW I want to do it. (I know everyone says that about functional languages, but it is true in my experience!)
I have also found that my programs in Clojure are more concise than what I write in other languages. This is partially due to the syntax (come on, guys, the parentheses really aren't that bad; Emacs formats it REALLY nicely) but it is also due to the functional paradigm---it just forces you to think straight to the point of what you're trying to do.
Having a REPL (Read-Eval-Print Loop) is EXTREMELY helpful in learning a new language. Try stuff out in real time in the interpreter (just like with Python, etc.) Decreases the amount of time to master a given concept, in my opinion. Because of this, it's also awesome as a prototyping language. I sometimes use Clojure to make a prototype before coding it up in the language that we'll use for production.
The things I've learned from Clojure have changed the way that I do things in R, C#, Java, and Python (the languages I use more frequently at work.)
So, in conclusion, I'd highly recommend that you learn a functional programming language, and I personally recommend Clojure as a viable way to do that. (I haven't used Scala, etc., so I can't speak to their merits.)
Some Clojure resources:
* Mark Volkmann's Clojure Page[^]: A lengthy tutorial on Clojure broken up by topics. REALLY good resource
* Leiningen[^]: a build automation tool that makes library dependencies REALLY easy. Go check this out for sure.
* Clojars[^]: a repository of third-party clojure JAR libraries that is checked automatically by Leiningen
* The Clojure Toolbox[^]: A list of clojure libraries broken up by purpose. (Need an HTML parser? How about clj-tagsoup?)
Hopefully that's enough to get you going if you decide that it has piqued your interest. Good luck!
|
|
|
|
|
Thanks for the information and links. I will have to look into Clojure.
|
|
|
|
|
Hi,
I've used AutoCAD for 20+ years. For almost all of those I've used AutoLISP to get AutoCAD to do what I want it to. It's obviously not Common Lisp, but I've found it to be extremely useful when trying to automate tasks. In AutoCAD you can almost use it as a scripting language - it's easy to make changes on the fly (no code compilation required).
I've never touched Common Lisp though!
Cheers.
|
|
|
|
|
Thanks for the information
|
|
|
|
|
Anyone who use emacs or works with HLA (a lot of the defence simulation industry) or one of the SAFs (modsaf, onesaf etc) will use lisp as the configuration language. They won't call it lisp: they will give it some configuration language name but it is still lisp in syntax.
Do you use lambda functions? They started in lisp.
|
|
|
|
|
Member 4608898 wrote: Do you use lambda functions? They started in lisp.
Yes I do and didn't know the originated in LISP.
|
|
|
|
|
JimmyRopes wrote: Yes I do and didn't know the originated in LISP.
You'd be surprised just how many things originated from lisp. Even the ubiquitous if-then-else wasn't in Fortran before it was taken from Lisp, it only became ubiquitous in other languages when it was shown to be so much easier to use than conditional goto-statements. Map functions (i.e. the functional method of iterating over a list/array and modifying each item to produce a list of results) was originally in the oldest of Lisps - generally known as the mapcar function.
Chances are that whatever language you're using, about half of it stemmed from Lisp originally. Lisp was the first language to actually have all of the now "new" concepts incorporated in one package: iterative, imperative, functional, recursive, object oriented, meta (macros), etc. It allows you to mix-n-match any of these interchangeably so you can choose which works the best for the scenario at hand. That is probably why it makes you able to program in other languages a lot better after you've done some Lisp.
Note though, Lisp comes in 3 major dialects: Common, Scheme & "Other". Clojure and NewLisp can be seen as examples of the "Other" type, while they are still Lisps, they don't conform to the strict specifications of Common / Scheme - it would be like a new type of C where it's not conforming to the general principles of C (you could see it like the difference between Java and C#, both look reasonably the same and do the same things, but in slightly different detail).
Scheme is generally used in universities since it's a minimalist language, i.e. only the basics are incorporated into its spec. You're supposed to generate your own libraries or use others' libraries - these are usually not included into the language. Common Lisp is at the other end of the spectrum, it's specification tries to encompass all generally needed libraries and functionality. The Others tend to be a mix or they're built on top of existing libraries.
Here's one thing which opened my eyes quite wide: The creator of IronScheme first started to make an IronLisp (intended to be a Common Lisp on the DotNet VM). He gave up on this because it was too difficult. One aspect (of many) which is very dificult to near impossible to implement in the CLR is Common Lisp's object orientation (known as CLOS - Common Lisp Object System) and especially the MOP (meta object protocol). It simply doesn't translate into something which the CLR can do. Scheme was then chosen, since it doesn't specify an object oriented system, thus the built-in DotNet system can be used.
|
|
|
|
|
I sometimes develop some small applications, data-centric, using VBA and MSAccess.. Say, software for a swimming club (members, competitions, records,....), ... about 10 tables plus the lookup table, multilange, data oriented, almonst no graphics (pictures of people, maps for locating the clubs for next competitions, tables of results,... ). Modest volumes, clubs with 1000 members as a maximum
Now it is time to turn to a moden environment: I think VBA is stuck in the same flavour as 15 years ago, so .NET should be the target
Database_ SQL-Server Express or MySQl
Problem comes with language: C# o VB? I prefer VB because I am more familiar, and (at least some years ago), there were only 15% performance increase in favour of C#, which was absolutely irrelevant for me. No idea of what is the point today. Both languages are just instruments to manage the underlying .NET framework
Visual Studio Express (Windows 8.1) comes in 5 formats: Web, Windows, Windows Desktop, Team Foundation and Windows Phone
No idea what to get: my software will be used by few people (from 1 to 10 as a maximum), in the premises of the swimming club (so, no web....),.... but,.... everyone things today in checking things from a web browser (last results of a given swimmer, payment status of a given member, dates for next competitions,...), ... or even from an Android....
I remember Windows Forms allowed more "complex" forms (in terms of data interation), some years ago...
Additionally, if I develop the sw in 3-tier, theoretically changing the display tier would allow to move to another platform, which forces me to use Web Services or another current technology to communication between tiers.... so, more complexity for a simple, basic application...
Any hints on that please? I would like a rapid development, but I wouldn't like hearing potential clubs saying this is an "old" application because it is not web-based...
thanks
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
