|
|
NP. A cursory search revealed TASC[^] is hiring Lisp programmers.
/ravi
|
|
|
|
|
Yes[^].
If I remember correctly, it was an early garbage collected language, and is functional, generating immutable data ... features which facilitate use on multiprocessor machines which just about everybody knows are becoming more prevalent today.
Never moon a werewolf.
- Harvey
|
|
|
|
|
Thanks for the information.
|
|
|
|
|
I do not use LISP, Clojure, Scheme or any of those variants. However, there is much to be gained by learning a different programming style than the imperative form that most of us are used to with C-like languages.
Functional programming is based on functions and variables. For any value x that you pass into function f(x), you will always get the same result. There are no side-effects, state, or mutable data.
The concept sounds foreign and useless at first. However, I recently wrote a library with Template-Meta Programming (TMP), and to my surprise, TMP in C++ is basically functional programming. I had to go about solving my problems in different ways.
When I completed the library, and returned to my normal programming tasks, I found that I approached my problem solving in a different way, even though I was no longer using a functional programming language.
One of the things that I learned to do was complete a complex task in a very elegant manner, with very little code when I was using functional programming constructs.
To know and not do, is not yet to know
http://www.codeofthedamned.com
|
|
|
|
|
Paul Watt wrote: I found that I approached my problem solving in a different way, even though I was no longer using a functional programming language.
Interesting. I am interested in learning functional programming, but haven't had the time yet.
I am currently working on developing agents to do robotic trading on the Foreign Exchange market. Do you think functional programming will have relevance in market analysis?
Paul Watt wrote: One of the things that I learned to do was complete a complex task in a very elegant manner, with very little code when I was using functional programming constructs.
Very interesting. Can you be coaxed into an article explaining how to implement functional programming constructs in non-functional languages?
Thanks for the insight.
|
|
|
|
|
JimmyRopes wrote: Do you think functional programming will have relevance in market analysis?
I am sure that there is some place for it, but I do not have enough knowledge of ForEx or the market itself to make a suggestion. My instinct tells me that any of the math equations or collection of similar constructs is a good place to start.
JimmyRopes wrote: Very interesting. Can you be coaxed into an article explaining how to implement functional programming constructs in non-functional languages?
Yes, however what I plan on doing is building up a TMP-based solution on my blog. The blog is also fed into CodeProject so you will be able to follow it as I build up the solution. I wrote an initial entry on TMP here: Template Meta-Programming[^].
The short answer, is that you think of everything like a function in math. Zero or more inputs are passed in, and only one result at most is returned. If you pass in that same set of inputs to the same function, you will get the exact same results every time. This is very valuable when you want to prove that something is working properly because there is only one possible answer for any set of inputs. Contrast this with the potential of programming with global variables, intermediate state, and potential side-effects.
It does take some practice to get used to solving problems this way. In the end, it becomes another tool in your belt to solve problems. If you keep your mind open, programming in other languages even just casually, can help you expand your approach to solving problems. The key is to not try and use every language like it is C++, or whatever your programming language of choice happens to be.
I am surprised how interested programmers have become with TMP recently. The TMP blog entry I gave you the link to has been one of my more popular entries. So, once I am done building up the solution through the series of blog entries, I could imagine writing a summary article.
To know and not do, is not yet to know
http://www.codeofthedamned.com
|
|
|
|
|
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!?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
