but writing say Karatsuba multiplication in functional languages can be a pain
It's interesting that you should pick this particular example. It's one of the
early examples in Ullman's Elements of ML Programming, for example, and I don't think it's all that difficult.
The reason I mentioned ML in particular in this context is that ML datatypes can correspond pretty naturally to abstract notions of data structures. Then algorithms on them are often easily expressed using pattern matching. Once again, it is (IMHO, of course), a matter of picking the language so that language issues avoid clouding the real concepts, which here are (IMHO again) understanding how the structures and algorithms are useful and how to analyze their properties. (You are of course right that there are some potential difficulties (or perhaps it would be more accurate to say differences) if one commits oneself to remaining exclusively in the functional realm; however, I don't know if I really believe that this is that much of an issue for a first course in data structures and algorithms.)
(As an aside, let me plug Okasaki's Purely Functional Data Structures as a reference for data structures in functional languages.)
I think 3+ semesters of one given language is essential to deep understanding of a lot of what Computer Science is.
Well, at the risk of just making up numbers, let us say that one gets significant exposure to six or seven different languages and has to take 12-16 classes that involve programming of some sort. Then isn't it pretty likely that at least one of them is used for three semesters? (Especially considering the likelihood that in the later semesters there is some sort of specialization in the direction of study.)
And teaching students several new languages each semester moves the emphasis to new syntaxes and away from new perspectives.
I think this is a red herring. Learning a syntax ought to be relatively easy for a CS student. And presenting a concept in a suitable language would seem to me to emphasize that concept. Let us say that (just as an example), the introductory course is in C. Won't the concepts of OOP come through better in Smalltalk? Functional programming and its related issues in ML? AI in Prolog or Lisp? To understand what is going on in the hardware with assembler? I agree that the language is not the main point - I don't advocate learning a lot of languages just for the sake of knowing a lot of languages; the point (IMHO) is that using an appropriate language makes it easier not to be distracted by the language itself and to see the important points and concepts of what one is actually studying.
Well, I agree with you about Lisp. The language I use most is Common Lisp, and I feel it works very well on a wide range of problems (yes, including real-world ones, for the skeptics out there). If someone had merely asked me what I'd recommend as a first language, it would be my pick. There seem to be a lot of lingering prejudices against it though (which seem to be mostly based on the state of Lisp 20-30 years ago); if there's any one result that I am grateful for coming out of my lack of formal CS training, it's that I never picked up this bias and thereby missed out on Lisp.:-)
Certainly a valid concern. Perhaps I should have qualified as well that I'm one of those old school people who feel that college should be about learning rather than job preparation (perhaps I did say this implicitly when I pointed out that I came from mathematics:-); I will freely admit that the opposite viewpoint is perfectly reasonable as well. I guess my feeling is that if I were in the process of hiring people (I'm not, and it seems unlikely that I ever will be, but who knows?), I'd (in general) be more concerned with someone's intelligence and capacity for learning rather than if they had one particular skill that isn't really that hard to learn. In essence, I'd feel that the former person could become accomplished in whatever was necessary, whereas the latter would have little use outside that one specialized area.
Actually, I was primarily addressing the question regarding college CS, not the part about AP programming. I don't expect that one should necessarily pursue several languages in one course. But in the course of working through a (let us say) eight semester college CS degree, one surely has enough time to learn a goodly number of languages. As I suggested, Smalltalk would be good for a course emphasizing OO programming and concepts. A nice functional language like ML might be good for algorithms and data structures. When looking at lower level issues one could work in the context of C and assembler. And so on. And one gains because one is actually using tools appropriate for the problem at hand. I don't think it's an unreasonable thing to ask that a college student majoring in CS learn a language or two a semester, especially when it is relevant to the topic actually being studied (where we realize that the languages are indeed most often secondary to the other concepts being expressed).
As I qualified before, I did not go through a CS program, but this is more or less what I would want to see (and be willing to do) if I did. (And who knows, perhaps someday I'll get the chance.:-)
For the express purpose of teaching OOP, why not use Smalltalk, which makes it difficult to fall into other methodologies and easy to use OO techniques?
But as a greater question, why restrict the field to one or a few languages? I'd think that in a CS curriculum (I insert the disclaimer that I came from mathematics and not from such a curriculum) one would want students to explore as many languages and paradigms as possible, ranging all the way from assembler to Prolog. This would presumably encourage a student both to develop many different ways of thinking about any given problem and to be able and willing to select an appropriate tool for any problem encountered. Far too often we see (as evidenced by responses on Slashdot to articles like this one) that many people are rather narrow-minded about language selection and unwilling to deviate from using their one pet language. Why not start to discourage that immediately in the course of formal CS training?
This sort of thing depends on the particular Smalltalk that one is talking about. Every one that I know about has support for Sockets. I've never really looked for serial port support. Squeak seems to have it. Dolphin doesn't, I think, but classes are available to add it, I'm fairly sure. I'd be pretty surprised if it weren't in VW and VA too.
One cannot reasonably deny that some of the work in Smalltalk is for maintaining legacy systems, so I shan't. Plenty of new development is going on as well, though.
As for COBOL, RPG, etc., the poster's original question was about RAD environments. And Smalltalk is quite suitable for that sort of thing.
How can one pass by a starving troll on the street and not toss some crumbs his way?
Do you want this poor slobbering VB coding neanderthal to never get a job?
There seems to be a fairly steady stream of job announcements on comp.lang.smalltalk, for example. And there are other resources. Moreover, I'm sure there are plenty of jobs that are like mine - an employer wants things done but doesn't care how they get done. In such cases, one is pretty much free to apply whatever tools one thinks best. If the poster is in such a situation, he may well find Smalltalk helpful.
Smalltalk is DEAD
Really? Tell that to the likes of FedEx, Sprint, Wall Street banks and all these people
Yes, I'm familiar with that, but the original poster may possibly be interested in using his newfound environment for commericial purposes. If not, VW would be okay. If so, then the price issue has to be considered.
I agree with the notion of Smalltalk, but if the original poster is hesitant to spend $1000 or so for Delphi/Kylix (judging from the article, price does seem to be an issue), don't you think he might faint at the price for VA or VW?:-)
Squeak might be an acceptable alternative, although I don't know how well it really supports typical RAD type applications. I don't know of any other inexpensive cross-platform Smalltalks, though.
(As an aside, if the original poster is ever interested in a different Windows-only tool, he might check out
Dolphin Smalltalk. Once you get used to just about anything except VB, though, it's incredible how much it will annoy you if you're ever forced to use it again.:-)
I don't think Dolphin has a regex class built in, but I'd be surprised if such weren't readily available for Smalltalk - there are some pretty sizeable code archives out there. And perhaps some of the bigger implementations do have them built in.
I was thinking about it some more, and it's not to hard to do in an ML either (and at least some of these do have regexes included - SML does, and OCaml does too):
map (fn x => if String.isPrefix "comment" x then concat ["! ", x] else x) foo;
I'm not so familiar with the ML regexes, but I suspect it's merely a matter (instead of the String.isPrefix "comment" x part) doing something along the lines of (ML pseudocode follows:-)
Regex.match (Regex.regex "^[0-9][A-Z][A-Z] etc.") x. I don't know offhand what the exact syntax would be, though. Not as compact as Perl, to be sure, but certainly nothing difficult.
How many lines of C would you have to write for that? How many lines of Java? How many lines of C++? How many lines of some-other-language? How much time would it take you to do so? Can you write it without a second thought?
Well, this isn't exactly the same, since it returns a new collection without mutating the old one, but in Dolphin Smalltalk one could do:
Actually, this is (mostly) false. Emacs Lisp is dynamically scoped as you described. Common Lisp and Scheme are lexically scoped, although in Common Lisp (I don't know about Scheme) you can set things up to be dyamically scoped when you need them to be.
Which book do you have? It may or may not be a good place to start. (Graham's own ANSI Common Lisp is a good starter.)
There are plenty of good implementations.
XAnalys Lispworks,
Corman, and
Franz have
free trial versions of their environments which are suitable for learning. Also
CLisp is a free (GPL) Common Lisp for Windows. All of the preceding except for Corman are also available for various Unices (although there may well only be free trial versions for Linux), and
CMUCL is also available there. You'd be hard pressed to go too far wrong with any of those (I use Lispworks for most of my work and like it).
Have you actually used a Lisp environment in the past twenty years or so? Every major Common Lisp implementation has a compiler, and at least one doesn't even have an interpreter. What specifically about the condition system do you find inadequate compared to other languages? It definitely offers support at a level at least as high as something like C++ or Java.
As far as doing real work in functional languages, perhaps you ought to ask the
Erlang
people about that. Or check out
this link.
LISP isn't really
good for much, outside of artificial intelligence or other heuristical analysis-type applications.
Really? Discounting the fact that the article linked to in the story demonstrates a quite non-AI use for Lisp, there are others as well. I, for example, use it for business programming.
I don't know if I qualify as a Lisp zealot, but
I primarily use Lisp for my work, so maybe I'm close enough.
It's actually really easy to keep the parentheses in order. Just use a reasonable editor. And in other languages I have trouble
keeping the bizarre syntax with all of those (){};:,'"[]{}|&^%#$@!->s
straight. (Okay, maybe I don't have that much of a problem, but perhaps you get the point.)
There's no a priori reason that it should be harder to understand Lisp code (assuming that one
knows Lisp and that the code is decently written)
than it would be to understand, say, C code (assuming that you know C and the code is decently written). The issues are essentially the same: are things well named, are functions sufficiently short and focussed, etc. I'd say debugging in general is easier, but this is because of the interactive nature of Lisp rather than the language itself; write a function, go to the listener and test it, refine until it works correctly.
It is true that in some respects the idioms one uses to program in Lisp are different. So one does need to expend a little effort to understand those idioms; once this is done, however, one may find that Lisp code is even clearer than other code.
If it bothers you to write all that, why not make adjustments? First of all, you can control the prefix of the readers using:conc-name when you define the structure, so you could really shorten them to member1 and member2 (this would be a little dangerous for structs because of possible clashes, but less so for classes, where if this happened you'd just wind up with different methods). So now you'd just have:
(setf (member1 struct)
(+ 10 (member2 struct)))
If this is still too onerous and you are doing things that fall into the same sort of pattern, it wouldn't be too difficult (although enough care would be required that I don't care to attempt it here:-) to define a macro that would let you write something like:
etc. If you really want to go overboard, name
the macro:= (remember to escape it so it doesn't get regarded as a keyword).
I don't think I would go to such extremes just to simulate some other language, but the point is that you can bend Lisp to be what you want it to be, which is largely why we Lispers well love it.
Recently I came across the following story, which tells of Paul Graham's use of Lisp in his company, creating web-based store program, which was to become Yahoo stores.
Slashdot Mirror
IBM recently released a preview version of VisualAge Smalltalk for Linux, so maybe you have hope.
It's interesting that you should pick this particular example. It's one of the early examples in Ullman's Elements of ML Programming , for example, and I don't think it's all that difficult.
The reason I mentioned ML in particular in this context is that ML datatypes can correspond pretty naturally to abstract notions of data structures. Then algorithms on them are often easily expressed using pattern matching. Once again, it is (IMHO, of course), a matter of picking the language so that language issues avoid clouding the real concepts, which here are (IMHO again) understanding how the structures and algorithms are useful and how to analyze their properties. (You are of course right that there are some potential difficulties (or perhaps it would be more accurate to say differences) if one commits oneself to remaining exclusively in the functional realm; however, I don't know if I really believe that this is that much of an issue for a first course in data structures and algorithms.)
(As an aside, let me plug Okasaki's Purely Functional Data Structures as a reference for data structures in functional languages.)
Well, at the risk of just making up numbers, let us say that one gets significant exposure to six or seven different languages and has to take 12-16 classes that involve programming of some sort. Then isn't it pretty likely that at least one of them is used for three semesters? (Especially considering the likelihood that in the later semesters there is some sort of specialization in the direction of study.)
I think this is a red herring. Learning a syntax ought to be relatively easy for a CS student. And presenting a concept in a suitable language would seem to me to emphasize that concept. Let us say that (just as an example), the introductory course is in C. Won't the concepts of OOP come through better in Smalltalk? Functional programming and its related issues in ML? AI in Prolog or Lisp? To understand what is going on in the hardware with assembler? I agree that the language is not the main point - I don't advocate learning a lot of languages just for the sake of knowing a lot of languages; the point (IMHO) is that using an appropriate language makes it easier not to be distracted by the language itself and to see the important points and concepts of what one is actually studying.
Well, I agree with you about Lisp. The language I use most is Common Lisp, and I feel it works very well on a wide range of problems (yes, including real-world ones, for the skeptics out there). If someone had merely asked me what I'd recommend as a first language, it would be my pick. There seem to be a lot of lingering prejudices against it though (which seem to be mostly based on the state of Lisp 20-30 years ago); if there's any one result that I am grateful for coming out of my lack of formal CS training, it's that I never picked up this bias and thereby missed out on Lisp. :-)
Certainly a valid concern. Perhaps I should have qualified as well that I'm one of those old school people who feel that college should be about learning rather than job preparation (perhaps I did say this implicitly when I pointed out that I came from mathematics :-); I will freely admit that the opposite viewpoint is perfectly reasonable as well. I guess my feeling is that if I were in the process of hiring people (I'm not, and it seems unlikely that I ever will be, but who knows?), I'd (in general) be more concerned with someone's intelligence and capacity for learning rather than if they had one particular skill that isn't really that hard to learn. In essence, I'd feel that the former person could become accomplished in whatever was necessary, whereas the latter would have little use outside that one specialized area.
Actually, I was primarily addressing the question regarding college CS, not the part about AP programming. I don't expect that one should necessarily pursue several languages in one course. But in the course of working through a (let us say) eight semester college CS degree, one surely has enough time to learn a goodly number of languages. As I suggested, Smalltalk would be good for a course emphasizing OO programming and concepts. A nice functional language like ML might be good for algorithms and data structures. When looking at lower level issues one could work in the context of C and assembler. And so on. And one gains because one is actually using tools appropriate for the problem at hand. I don't think it's an unreasonable thing to ask that a college student majoring in CS learn a language or two a semester, especially when it is relevant to the topic actually being studied (where we realize that the languages are indeed most often secondary to the other concepts being expressed).
As I qualified before, I did not go through a CS program, but this is more or less what I would want to see (and be willing to do) if I did. (And who knows, perhaps someday I'll get the chance. :-)
I think you mean "interactive" rather than "interpretive".
For the express purpose of teaching OOP, why not use Smalltalk, which makes it difficult to fall into other methodologies and easy to use OO techniques?
But as a greater question, why restrict the field to one or a few languages? I'd think that in a CS curriculum (I insert the disclaimer that I came from mathematics and not from such a curriculum) one would want students to explore as many languages and paradigms as possible, ranging all the way from assembler to Prolog. This would presumably encourage a student both to develop many different ways of thinking about any given problem and to be able and willing to select an appropriate tool for any problem encountered. Far too often we see (as evidenced by responses on Slashdot to articles like this one) that many people are rather narrow-minded about language selection and unwilling to deviate from using their one pet language. Why not start to discourage that immediately in the course of formal CS training?
This sort of thing depends on the particular Smalltalk that one is talking about. Every one that I know about has support for Sockets. I've never really looked for serial port support. Squeak seems to have it. Dolphin doesn't, I think, but classes are available to add it, I'm fairly sure. I'd be pretty surprised if it weren't in VW and VA too.
One cannot reasonably deny that some of the work in Smalltalk is for maintaining legacy systems, so I shan't. Plenty of new development is going on as well, though.
As for COBOL, RPG, etc., the poster's original question was about RAD environments. And Smalltalk is quite suitable for that sort of thing.
How can one pass by a starving troll on the street and not toss some crumbs his way?
There seems to be a fairly steady stream of job announcements on comp.lang.smalltalk, for example. And there are other resources. Moreover, I'm sure there are plenty of jobs that are like mine - an employer wants things done but doesn't care how they get done. In such cases, one is pretty much free to apply whatever tools one thinks best. If the poster is in such a situation, he may well find Smalltalk helpful.
Really? Tell that to the likes of FedEx, Sprint, Wall Street banks and all these people
Yes, I'm familiar with that, but the original poster may possibly be interested in using his newfound environment for commericial purposes. If not, VW would be okay. If so, then the price issue has to be considered.
I agree with the notion of Smalltalk, but if the original poster is hesitant to spend $1000 or so for Delphi/Kylix (judging from the article, price does seem to be an issue), don't you think he might faint at the price for VA or VW? :-)
Squeak might be an acceptable alternative, although I don't know how well it really supports typical RAD type applications. I don't know of any other inexpensive cross-platform Smalltalks, though.
(As an aside, if the original poster is ever interested in a different Windows-only tool, he might check out Dolphin Smalltalk. Once you get used to just about anything except VB, though, it's incredible how much it will annoy you if you're ever forced to use it again. :-)
I don't think Dolphin has a regex class built in, but I'd be surprised if such weren't readily available for Smalltalk - there are some pretty sizeable code archives out there. And perhaps some of the bigger implementations do have them built in.
I was thinking about it some more, and it's not to hard to do in an ML either (and at least some of these do have regexes included - SML does, and OCaml does too):
map (fn x => if String.isPrefix "comment" x then concat ["! ", x] else x) foo;
I'm not so familiar with the ML regexes, but I suspect it's merely a matter (instead of the String.isPrefix "comment" x part) doing something along the lines of (ML pseudocode follows :-)
Regex.match (Regex.regex "^[0-9][A-Z][A-Z] etc.") x. I don't know offhand what the exact syntax would be, though. Not as compact as Perl, to be sure, but certainly nothing difficult.
Well, this isn't exactly the same, since it returns a new collection without mutating the old one, but in Dolphin Smalltalk one could do:
foo collect: [:x | (x beginsWith: 'comment') ifTrue: ['! ' , x] ifFalse: [x]].
so I'd have to answer 1, about 20 seconds, and yes. It's pretty easy in Common Lisp too.
Actually, this is (mostly) false. Emacs Lisp is dynamically scoped as you described. Common Lisp and Scheme are lexically scoped, although in Common Lisp (I don't know about Scheme) you can set things up to be dyamically scoped when you need them to be.
Which book do you have? It may or may not be a good place to start. (Graham's own ANSI Common Lisp is a good starter.)
There are plenty of good implementations. XAnalys Lispworks, Corman, and Franz have free trial versions of their environments which are suitable for learning. Also CLisp is a free (GPL) Common Lisp for Windows. All of the preceding except for Corman are also available for various Unices (although there may well only be free trial versions for Linux), and CMUCL is also available there. You'd be hard pressed to go too far wrong with any of those (I use Lispworks for most of my work and like it).
Well, let us just say that we disagree on this.
MCL is the most popular Mac environment, it seems.
Have you actually used a Lisp environment in the past twenty years or so? Every major Common Lisp implementation has a compiler, and at least one doesn't even have an interpreter. What specifically about the condition system do you find inadequate compared to other languages? It definitely offers support at a level at least as high as something like C++ or Java.
As far as doing real work in functional languages, perhaps you ought to ask the Erlang people about that. Or check out this link.
Really? Discounting the fact that the article linked to in the story demonstrates a quite non-AI use for Lisp, there are others as well. I, for example, use it for business programming.
I don't know if I qualify as a Lisp zealot, but I primarily use Lisp for my work, so maybe I'm close enough.
It's actually really easy to keep the parentheses in order. Just use a reasonable editor. And in other languages I have trouble keeping the bizarre syntax with all of those (){};:,'"[]{}|&^%#$@!->s straight. (Okay, maybe I don't have that much of a problem, but perhaps you get the point.)
There's no a priori reason that it should be harder to understand Lisp code (assuming that one knows Lisp and that the code is decently written) than it would be to understand, say, C code (assuming that you know C and the code is decently written). The issues are essentially the same: are things well named, are functions sufficiently short and focussed, etc. I'd say debugging in general is easier, but this is because of the interactive nature of Lisp rather than the language itself; write a function, go to the listener and test it, refine until it works correctly.
It is true that in some respects the idioms one uses to program in Lisp are different. So one does need to expend a little effort to understand those idioms; once this is done, however, one may find that Lisp code is even clearer than other code.
Of course, you could just use OCaml to generate the C code. :-)
Just to be pedantic, (in Common Lisp, please excuse the indentation - in spite of my best efforts it's getting screwed up a bit), you'd
:conc-name when you define the structure, so you could really shorten them to member1 and member2 (this would be a little dangerous for structs because of possible clashes, but less so for classes, where if this happened you'd just wind up with different methods). So now you'd just have:
:-) to define a macro that would let you write something like:
:= (remember to escape it so it doesn't get regarded as a keyword).
write this as:
(setf (mystruct-member1 struct)
(+ 10 (mystruct-member2 struct)))
If it bothers you to write all that, why not make adjustments? First of all, you can control the prefix of the readers using
(setf (member1 struct)
(+ 10 (member2 struct)))
If this is still too onerous and you are doing things that fall into the same sort of pattern, it wouldn't be too difficult (although enough care would be required that I don't care to attempt it here
(set-mystruct-slot struct member1 member2 + 10)
(set-mystruct-slot struct member3 member1 / 20)
etc. If you really want to go overboard, name
the macro
I don't think I would go to such extremes just to simulate some other language, but the point is that you can bend Lisp to be what you want it to be, which is largely why we Lispers well love it.
Recently I came across the following story, which tells of Paul Graham's use of Lisp in his company, creating web-based store program, which was to become Yahoo stores.
Beating the Averages
Needless to say, Graham attributes to Lisp itself a large part of the credit in being able to accomplish what he did.