|
Paul Watt wrote: My instinct tells me that any of the math equations or collection of similar constructs is a good place to start.
Yes there are a lot of math equations. In fact, all of the analysis are mathematical interpretations of the market data. I will look into the implication of a functional language to do the calculations.
I will have a look at your blog to try to understand TMP to see if it has utility in any of the systems I am building.
Thanks for the information.
|
|
|
|
|
I used it for a while years ago at college and Uni. Horrible language in my opinion that seemed pretty pointless. Other languages seem to do list processing quite well these days now anyway. LISP was incredibly hard to read.
|
|
|
|
|
Mike Diack wrote: Other languages seem to do list processing quite well these days now anyway.
That is what I was thinking that it had it's day in the mid 20th century. I just always hear mention of it while reading what some of the pioneers of computer science say so I wondered if it was still relevant.
|
|
|
|
|
Using LISP currently... First it is not crazy efficient, and is usually interpreted.
But it was the key for me learning OOP at the university in the late 80s.
The concept of a function was such that you could subclass your class, and then
declare EITHER (before, after, instead of) function, which simply determined when it
would execute your code, relative to the original code.
CDR = Contents of Destination Register
CADR = Contents of Address Register
LISP = Lots of Incessant Stupid Parenthesis 
Wow, you brought a bunch of memories back from a LONG time ago.
EMACS uses LISP for macros/extensions. So, one way to learn LISP in a functional way, would be to learn to write extensions for the editor (or read a bunch of them).
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
