In many cases being somewhat familiar with different languages is enough to judge what is suited for a given purpose (I'm somewhat familiar with Java, C, C++, Fortran, Cobol, Pascal, Ada, Algol68, Oberon, different dialects of Basic, Forth, Scheme, Lisp, Prolog, PHP etc, but nowadays I only really know Java, if any)

_________________
Offending ad removed

That's partly why I tend to avoid LISP (after doing a great deal of research into the language). I have learned to think in terms of breaking up the idea itself, and translating that directly into code. So I have tended to avoid langauges which have a large amount of esoteric syntax. LISP in particular contains a large amount of such. For example, the ",@" syntax for adding a list as an element of another list. Being familiar with many computer languages and how they are implemented I find the decision to include such syntax as part of the language incomprehensible. Then again, it was groundbreaking in the days when LISP was released -- but that was over fifty years ago. LISP isn't revolutionary anymore, and we've made great strides in understanding since then. The main problem here is that you need to think in terms of LISP and not in terms of the actual problem you're trying to solve. I just don't like doing that. I don't believe that LISP has a monopoly on good thinking, as fine a language as it really is.

I do not think that your research can have been very thorough after reading what you wrote in the following. You have never written anything serious in Lisp. Also, it is spelt "Lisp" nowadays.



No, it does not. In fact, it has almost no syntax at all. In other languages, you have three or four kinds of parentheses, a lot of keywords, precedence rules, perhaps even "structure by indentation" so that the amount of whitespace becomes part of the syntax.

You directly write the abstract syntax tree. This has several important advantages that set Lisp apart. For example, instead of writing "2 + 3 * 4", which has to be translated into an abstract syntax tree through the use of precedence rules and the shunting yard algorithm, you write "(+ 2 (* 3 4))", which directly represents the abstract syntax tree.



No, that is not right. ",@" is just a part of the "backquote" syntactic sugar, which is mainly used for macros. Adding a list to another list is done with normal operators like list or append. To elaborate, you might want to define a macro "with-foo" that can be invoked like this:



which will be interpreted as:



This macro can be defined like this, closely resembling the intent through the use of the backquote syntax:



which is much more readable than the more elaborate form:



which, however, works just as well. This is what ",@" is good for, not for generic list manipulation.



I think you just had a bad introduction to the language, or none at all.



Au contraire, in Lisp, you usually shape the language to your problem domain and then only think in that.



Who said that Lisp had such a monopoly?

I think the best introduction to Lisp for programmers is "Practical Common Lisp" by Peter Seibel. It is freely available on the net. Go read it.

_________________
A good system naturally covers all corner cases without further effort.

Thanks for the well-thought out response. I'm a computer guy, and understand the desire to code properly, so I'll listen carefully to what you have to say here and now.

Anyways, yes, you're right I've never written anything serious in Lisp. Who has? They don't have a compiler. Well, that isn't actually true, but no one has the libraries. Imagine "ls" written in lisp. How big is the binary? Writing something like a sgf editor or flashcard drilling program for sale and use would be a true nightmare for both programmers and end users, but easy tasks in more modern programming languages. Am I wrong in that assumption, that Lisp isn't nearly as suitable as, say, Java or C# for writing killer applications? And if I am right, what is it exactly that Lisp was designed to do?



I am not sure I understand. I find the point and the example difficult to understand. Perhaps I've been infected by the java way of doing things. But all joking aside, if you mean it's easier for the computer to understand "(+ 2 (* 3 4))" than "2 + 3 * 4", I'd be inclined to agree. But that isn't as important as it was 50 years ago. Computers are much, much faster now and the general consensus is that making it easier to understand code is a better way to do things -- in general. There will always be specialist applications. There will always be reverse polish notation, for example -- because it's useful. But it will remain a kind of small, specialist knowledge forever. But I don't think beginners should be introduced to such as a first language, that would be wrong.



Again I find the examples very difficult to follow. It's something of a maxim that the smaller the syntax the more difficult it is to understand -- just look at perl. But with Lisp it seems that the longer the syntax the more difficult it is to understand, and I think that is very odd. I almost want to say that it is because really the nested parentheses cause everything to be one expression and not multiple lines like how you've formatted it. Really and in truth, your program is this:


and that is simply incomprehensible to a beginner (even to me). But the point I was making is not that ",@" is readable or unreadable. The point I was making is that ",@" is esoteric and difficult for beginners to understand. I mean, look at the above Lisp. No wonder they invented syntactic sugar. But when do you stop? Why don't you just write
and be DONE with it all? Finally and forever?

I guess it's part of the Lisp way of doing things, that somewhat makes sense, but could be improved upon in a language for beginners. Beginners don't need to learn assembly language anymore.



That may be true, but including hardware kludges in software is an abomination, and Lisp shows it's age well with it's irregular syntax. Lisp's syntax was really designed to aid computer understanding and required "thinking in Lisp". In a funny sort of way, this made sense at the time (think, what were computers like in the late 50s), and enabled people to understand computers better. So I do understand the charm -- I programmed in assembly language for a long time. You know, back in the day. But each time I look at Lisp I have to ask myself, do I really want to learn all of that syntax? For what purpose? What does Lisp have to offer that any other modern language -- any at all -- does not? And I keep coming back with "Lisp is esoteric, and limited".



Yeah I get what you're saying. But you can do that in any language.

What I was referring to in a roundabout way was the syntax (aforementioned) screwups like incorporating hardware kludges into the software -- the "cons problem", which was designed to aid translation into assembly language and so forth. Then there is the single quote problem, where by you are quoting something, but there's no end-quote. But actually there is, it's a different character that looks like it belongs somewhere else. Like


Makes brilliant sense, in a way, but looks weird and is not good for beginners because it is esoteric.

Many, many, many advances have been made over the years not only in readability but in syntax. What people found is that by making a language easier to understand to beginners, it actually became more robust and this turned out not only better programmers but better programs, in the long run. People began to understand that the point wasn't how elegant a language was -- at least, that was not the only concern. The point was how quickly you could wrap your head around the language and then code anything in it without having to think about the language anymore.

Let me explain my idea this way. Let's say we are going to design a brand new computer language that will solve all of the world's software engineering problems. This language would be taught in every school to every child and the next ten years would all be about implementing it in EVERYTHING.

Let's say that to save time we were also going to start with Lisp, but it was going to be reviewed to make sure it was a suitable language -- just to be certain. During the review process someone says "Wait a minute, isn't Lisp, fundamentally, a language that manipulates lists?" and everyone says yeah, sure, of course. Then he says "Well then why does the list primitive which the entire language is build on only contain two elements? Why don't we update that one, small part of the language so that a list, natively, can have any number of elements that anyone would want?"

And everyone says sure, why not. But then some guy in the back says "Wait a minute! Computers 50 years ago had to do things this way!!" so they all agreed they would leave cons in, just in case. Just in case you needed to implement it on an IBM 704 or PDP, where including first, last, rest accessors would be somewhat problematic.

(from: http://www.faqs.org/faqs/lisp-faq/part2/section-13.html)

Then they said no, that's ridiculous, why should we cater to 50 year old hardware limitations? But, they still decided to leave cons in -- "We'll leave in the cons just in case there arises a problem for which higher level structures already present in Lisp (like arrays, hashmaps or using "proper lists") can't solve."

Thus you have the current Lisp style of doing things. But there are still big problems with this because cons are there, and the fact that there are alternate ways of doing things doesn't solve these problems. Example --> no copy list function. You have to write your own, from scratch, every time. Or, do I have that wrong? I might. It's true I don't have serious experience with lisp. Maybe someone wrote a library or something.

Example; I just wrote a few programs recently; a NetHack like program, an advanced SGF editor with tag-editing features, and a flascard program that drills CJK, which I actually use in the highschool classroom when I teach occasionally. If I wrote those programs in Lisp I would have had to write separate linked list libraries for EACH PROGRAM. Instead, I saved time by writing them in Java.

The end user doesn't care what language it is written in and I saved time by not having to reinvent the wheel three separate times. To tell you the truth Harlequin, I'm scared to try lisp because I don't want to end up proving to myself it is a giant waste of my time and then dumping it.



Maybe no one said it. But I remain puzzled by people's attachment to a 50 year old language with hard to grasp, irregular syntax, that has no higher level list operators. As such I believe it is a poor introduction to programming. I'd never recommend it to a beginner. Again I think it is fine for specialist applications and I even think it should be learned by computer science students, maybe during a masters program.

And, please let me qualify what I've said. Compiler technology today, is frighteningly orders of magnitude more better than it was 10 years ago, the same could be said 10 years ago, of 20 years ago. Nowadays there is no reason at all to choose any particular language for it's machine readability (for it's syntax). Even C compilers can produce better assembly language than most assembly language programmers -- a fact that got me to finally stop programming in assembly language, and that was a long time ago. The examples you give can all be written in one line of java (or whatever); something like CustomerList.add(CustomerRecord); where CustomerList and CustomerRecord are variables/lists/whatever. What you mentioned about coding your problem domain and thinking in terms of that has, generally speaking, already been done. So from the standpoint of someone who has a great deal of experience with languages, including Lisp, I wouldn't recommend for beginners.

There you have it, nagano. real men create their own language and use that .

_________________
19/02/2011: this grumpy person takes a voluntary holiday from L19.

One recent example is ITA software, who sold to Google for 700 million dollars this year. There are lots of success stories at the ALU wiki.



No, to both; these are common myths without any connection to reality. Almost all modern Common Lisp implementations have compilers and use them. Also, there are tons of libraries for any purpose you might imagine. The most popular can be installed through clbuild, the gentoo lisp overlay, asdf-install, or (brand new) quicklisp. You can also browse Cliki.



Well, it would have to include the basic Lisp system, so it would be comparatively big. C programs have the advantage that their runtime is already running on Unix-like systems, so they do not need to include it. This would be the other way around on a Lisp-based operating system.



What makes you say that? You can take some OpenGL binding or McCLIM and have it up and running just as easily as in other languages.



Yes, you are wrong.



I mean that it is easier for the programmer to reason about. Lisp syntax is extremely regular (not in the grammar sense) and explicit.



Yes, it is difficult to argue on the basis of your limited understanding of Lisp.



It is quite clear once you understand how macros work. "Practical Common Lisp" has a very nice explanation for that.



I do! I write



and that's it.



Lisp syntax is extremely "regular". It is always "(operator argument1 argument2 ...)". That is all there is to it.



Well, on the face of it, yes. This is also known as the Turing tarpit. However, it is easier to do in some languages than in others. Having real macros on the level of the abstract syntax tree is a feature the lack of which is difficult to work around.



Lisp just has support for lists on the basic language level. Modern applications usually do not even use cons, they use CLOS objects with explicit names from the problem domain.



Why is it esoteric? It is not difficult to understand that quote prevents a symbol from being evaluated, and that 'foo is an abbreviation for (quote foo)---unless you expect ALGOL syntax, of course.

Let us take a look at C syntax:



How can a be at the same time equal to 1 and to 2? It does not make sense!



"Let a be 1. Now, set a to 2."



Well, you have not understood lists. How would you construct a single-linked list? Each node would have two things, a value and a pointer to the next cell. That is exactly what a cons cell is: a container for two things. A list is then either the empty list, or a series of cells, where each has a value and a pointer to the next cell, terminated by the empty list. This has nothing to do with hardware. It is just a very simple data structure, which is very useful to implement a language with.

In fact, John McCarthy had first developed Lisp syntax as a way to write mathematical statements. It was then discovered that it was very easy to directly implement as a programming language.



Take a look at the source code of the old Intercom text adventures. They are written in a Lisp dialect, which allowed a very direct description of the worlds. Similar exercises seem to be in the new "Land of Lisp" book. You do not need linked list libraries, they are part of the language standard. If you want this kind of comparisons, here is a report on an experiment: http://www.flownet.com/gat/papers/lisp-java.pdf. Really, there is no problem writing the programs you mention in Common Lisp.



I call FUD. I have never seen a language where you can take the DRY (Do not Repeat Yourself) principle as far as in Lisp. Java is always "verbose language is verbose".



It is not irregular, it is easy to grasp (unless you cannot let go of ALGOL-derived syntax), and it has all kinds of higher level list operators, many of which you do not even find in Java and similar languages. Where is MAP, MAPCAR, MAPCON, MAPL, MAP-INTO, REDUCE in Java? What, you cannot pass functions? What kind of stupid language is that? You should consider that the people who are attached to Lisp even though they know the ins and outs of Java and similar languages perhaps have found something.



Again, you simply have no idea of even the basic functions Lisp provides. (Push customer-record customer-list). That is even without going into the power CLOS (the Common Lisp Object System) provides. I am pretty sure I can match any Java code snippet you provide with a more concise and at least as readable version in Common Lisp.



You obviously do not have any great experience in Lisp.

_________________
A good system naturally covers all corner cases without further effort.

Based on the general consensus here and some further research I've done, I've settled on Python, at least for the time being.

_________________
"Those who calculate greatly will win; those who calculate only a little will lose, but what of those who don't make any calculations at all!? This is why everything must be calculated, in order to foresee victory and defeat."-The Art of War

Good choice. Just learning the language and following how kombilo works will let you learn a lot.

The current leader of the google ai challenge is using Lisp.

Personally I think ASTs are for computers and I don't want to write one directly.

_________________
That which can be destroyed by the truth should be.
--
My (sadly neglected, but not forgotten) project: http://dailyjoseki.com

Originally, the intent was to have s-expressions (that is the name of the parenthesized notation) under the hood, and a more ALGOL-like syntax on top of that, which would have been the m-expressions. However, it was discovered that s-expressions were more expressive than what could be achieved through another syntax layer, so no one bothered to actually implement those m-expressions. S-expressions make the equivalency of code and data very obvious. You should really try it, s-expressions are damn s-exy!

However, I do not want to evangelize you. I just could not let the baseless language-bashing go unanswered. For those who want to read more about Lisp, Pascal Costanza's Highly Opinionated Guide to Lisp is a nice overview.

_________________
A good system naturally covers all corner cases without further effort.

Well, the features you mention are not found in Java (an effectively obsolete language, still hanging on but rapidly losing market share) but they certainly exist in C#, Python, Ruby, Javascript, Haskell and many other languages.

Lisp was certainly a revolutionary language at one point. Now all its good features are mainstream and incorporated into modern languages, together with a ton of other conveniences. (Certainly the macro capabilities of these languages tend to be more limited, if any. For many, this is a good thing.)

Thanks for the links. I took a look at some of them, interesting stuff.



Well, clbuild is not a compiler, it's a development tool that tries to find a compiler (such as SBCL, which is UNIX-only) to help Lisp progammers. I did find out however that there is CLISP for windows, which does include a compiler.

Hypothetical situation; You have written somtething in Lisp I would enjoy taking a look at -- Something small and cool. Could you send me a copy of the program? I don't have Lisp installed right now. Just to run said example program, what would do I need to do?



I wasn't implying Lisp has a lack of windowing capabilities. I was referring to having to rewrite a linked list library for Lisp for each program since it doesn't have any high level list processing capabilities. Such as a generic list copy function. This is actually what got me off C++ into Java, C++'s list management (and in general, STL and their object management in general) sucked in comparison. Now I may be wrong, but if C++/STL didn't have the generic OO-data structure I found useful in writing reusable code, I doubt Lisp would either. The information I found online only served to reinforce that. If I was going to reccomend a language to beginners. I don't know if that would be a major concern, but it would be up there.



Then why isn't Lisp used more often in a corporate/business environment? I don't think it is because C is so popular. Lots of programs are written in Delphi (i.e. pascal) or other languages. Even visual basic. But comparatively few real programs are written in Lisp. As a lisper yourself why do you think that is? There's got to be something about the language that is not suitable. I guess I am just speculating on what that might be. If it turns out that it's nothing but some sort of stigma due to the number of brackets or whatever, then so be it, I might learn Lisp in greater detail myself. But I'm finding it's a little more than that. There are barriers -- even just subtle ones, which prevent people from moving into Lisp. If those could be addressed, I believe it would be a better world. But they haven't been addressed for a long time, and I doubt they will be addressed in the future.



Well, it's my personal belief that (2 + 3) * 4 is easier to understand than (+2 (*3 4). BEDMAS is pretty explicit about such things. That's what I learned in school as a kid, so it makes sense to me to keep using it. I suppose if you learn (+ 2 (* 3 4)) in school you'd want to use that. But I can't imagine learning it for no reason other than "it's more clear". That's never true the first time you see it, so why bother learning it? Is there some flaw in BEDMAS?



No, I didn't mean I had a limited understand of Lisp and I therefore could not understand your examples; What I meant was that your examples were difficult to follow in a general sense. It appeared from your examples that you really didn't understand what I was trying to say. Even until just now, you seem to be making the case that abstract syntax trees are easier to understand than "that other way of doing things". My point is that they're not -- and the only reason Lisp does things that way was because it was easier to implementat on older computers. Starting from today and claiming it is easier to understand really isn't true.

One asks, what's the use of abstract syntax trees, anyways?

(from: http://stackoverflow.com/questions/3860 ... ntax-trees)

And there you have it.

Further.. I should probably comment on your tactic of claiming I don't understand Lisp. That is indeed true to a degree but it doesn't mean I don't know what I am talking about. Claiming that I don't know Lisp is a cheap shot, one which backfired here because I was able to show a strong knowledge not only of Lisp's history and reasoning during implementation but to provide actual code examples which clearly demonstrate what I was talking about. While at the same time you made claims about Java that aren't true (like, for instance, you can't pass functions).

Writing abstract syntax trees is a ridiculous expectation for first year computer science students, or really anyone doing programming as a day job these days because it is simply no longer necessary to cater to the vagaries of machine hardware AT ALL. Everyone understands "Let x = 2 + 3". No one understands "2 3 + x =" . Well okay, some people do. Engineers. Specialists. Oh, and Lispers, because they are using a mathematical expression language from the FIFTIES to do application and systems programming.

But most people don't understand, nor have a need, and there is really no reason to do things that way anymore. We're not programming on PDP-6's anymore. You ever use a PDP-6? I'm sure you have, welcome to the club. I prefer to use more modern computers nowadays.

Here is one very simple yet poigant example which I came up with in about 2 minutes playing around in JLisp51 (http://www.kenliu.name/software/lisp51/lisp51.html)

A.
(list 1 '(2 3) 4)
;Output ==> 1 (2 3) 4

B.
(list 1 (list 2 3) 4)
;Output ==> 1 (2 3) 4

From the examples above one would think (list 1 2 3) and '(1 2 3) would produce the same result. And indeed, they do.

The shocker comes when you try to actually use that in a real program, you know, to do something elegant:

C.
'(1 (list 2 3) 4)
;Output ==> (1 (LIST 2 3) 4)

D.
'(1 list(2 3) 4)
'Output ==> (1 LIST (2 3) 4)

E.
'(1 '(2 3) 4)
'Output ==> (1 (QUOTE (2 3)) 4)

Do you see what the problem is? You can '(2 3) or you can (list 2 3). You can '(1 2 3) or you can (list 1 2 3). But there is a difference between "'(1 (list 2 3) 4)" and "(list 1 (list 2 3) 4)". Therefore, the syntax is irregular. Understanding oddities like this is non-intuitive and I, personally, view that as a problem and that is one reason why I don't think Lisp is good for beginners. It can and will cause massive problems for people trying to write programs for the first time.



I believe it can be clear, and I believe, like a PERL program, it can be prohibitively un-clear to a beginner. Kind of like BASIC spaghetti code. People do it because it's there. If you remove that part of the language they do it another way because they have to. Lisp is part of a family of very old computer languages that allow people to do things in certain ways that really aren't very good ways. We know that now. If Lisp simply removed things like "syntactic sugar", it would be a better language for it. But that would expose other design flaws in the language. Don't get me wrong -- every language has design flaws. Including Lisp. But Lisp's flaws in particular make it a poor language choice for beginners, as I have outlined.



Why didn't you just write that in the beginning? Why all the examples with list? You're right that I don't understand Lisp very well, although I gurantee I know more about it than any other Java programmer you're likely to encounter. But this is all part and parcel of what I am talking about. Lisp is difficult to follow.




Of course they don't use cons. Cons are CAR, CBR, etc. which come from IBM 704 hardware address register names -- i.e. Contents of Address Register (CAR). On the surface not even the name makes sense until you realise memory space was SO limited on early computers they had to do addition in the address pointer register. It was a hack. It was done that way because it was the only way to do it. And it was a kluge. Carrying that over into software was neccessary at the time, but nowadays it's just an ugly kudge. If CONS was deprecated and people were forced to use the other ways of doing it in Lisp, then Lisp would instantly gain popularity.

Really, if I wanted to use cons I'd program in assembly language. Modern languages don't use cons because they implement real linked lists with first, last, rest, etc. accessors and people just use those. There is really no need for cons at all. Anymore.



It's esoteric because no one does anything like that anymore. The reasoning has mostly been lost but it had a lot to do with how people conceived AI and computer science in general in the fifties. They were still banging it out back then discovering elements of good style and why they were important. Using a single escape character to qoute inside a single expression-program encased in brackets? You've got to be kidding. There are STRONG benefits to the Lisp way. But it is not for beginners. Not for a first language.



Every first year comp.sci student is taught how to implement linked lists. We don't need cons to understand that. You probably meant to say "you have not understood how Lisp implements lists". But indeed I do.

And therefore, that cons aren't actually lists at all is precisely the point I was making. That is what leads to the problems I mentioned about not having higher level list manipulation functions, and having to reinvent the wheel each time you write a program. We don't need cons. We need higher level list functions. It's simple, without higher level list functions you will forever be writing and rewriting your own, or you simply won't have higher level list functions.



I was taking a look at those studies yesterday, actually. I read an interesting take on it from a D programmer, who completed the challenge in something like 1.5 hrs (faster than anyone else) because, as he said, D contained all the structures neccessary to tackle that particular problem. I suspect if the test were different, the results would be completely different. Those test results also show that the difference between programmers was larger than the difference between languages, suggesting that spending time training programmers was time better spent than figuring out what language to use.



Okay, then does Lisp have STL or anything like it, which would enable people to use, for example, a generic list copy function?




You can't seriously believe that there is something in Lisp that can't be done in a serious, modern programming language. No one here, not even I, made the claim that Lisp can't do something -- I even said 'well that's not entirely true' when claiming they didn't have a compiler. The problem is that it is esoteric and irregular, at the very least in comparison to what people are taught in comp.sci programs and what they experience working as programmers.

For example? Okay. You can pass functions in Java. That's how I wrote my SGF editor; using a hash map of SGF tags to functions which would evaluate their contents.
MAP and associated? Well I don't think you really mean to say that Java (and just for example, again, I know many other languages) doesn't have something whereby you can apply function to successive lists of arguments.

Hell I could even write a MAPC function if I really wanted to, something which would allow me to do mapc(function, arguments), just like in Lisp. The question is why I would want to. If there was a pressing need to do that I could do it.


Now consider lisp. There is a pressing need for a generic list copy function. What do I do? Help me solve this problem! I ask because I really want an answer -- it's probably the one thing keeping me away from trying something in Lisp.



Of course you could. I can do the same in Java; you just write a macro or function or class or whatever to do whatever you want and then call that. "push" is, in fact, a Lisp macro. Real lisp takes several lines to do that as you demonstrated in an earlier post. But in Java (for example) .add a feature of the language itself; it is not a macro. The difference is that push can not redefine the core structures used by Lisp. .add, in Java (for example) IS the core structure of the langauge, and it works on anything. Unlike push.



No, for the reasons I mentioned, I do not have any great experience in Lisp. But that isn't really an answer to what I said -- it's just trying to discredit what I said by claiming I don't know what I am takling about. I think we have seen I know more about Lisp than you give me credit for (I have provided unique, concrete examples of Lisps), while at the same time you yourself have demonstrated a lack of knowledge about other languages, such as Java (claiming that you cannot pass functions, and that it can not do stuff like MAPCON, etc. which is also not true).

Believe me, if there were answers, I might try Lisp more. It's just I don't have time right now...

A lot of what you said does indeed make sense, but please keep in mind you can code any language to do whatever you want. There is hardly a language alive today where you CAN'T code your way out of whatever wet paper bag you find yourself in. Those arguments works Lisp and Java, and C and whatever. The only problem I have here is that I don't think Lisp is really a language suitable for beginners because the paper bag functions like an event horizon. After looking at lisp for a long time you begin to consider that perhaps not every problem is a nail, and maybe the real problem is that you are trying to use Lisp for something it isn't designed to do.

Whether or not I am an experienced Lisper has no bearing on that. You do not have to be an experienced Lisp programmer to understand the history, implementation and use of a language.

Let's not clutter up nagano's thread.

_________________
19/02/2011: this grumpy person takes a voluntary holiday from L19.

nagano, out of curiosity, what is your background (maths, etc.) ? Are you a student or are you taking up programming as a hobby?

_________________
19/02/2011: this grumpy person takes a voluntary holiday from L19.

Might I point something out?

Most discussions like this on about "the best language" have already lost their way. When we tackle any substantial problem we should be doing that at a level of abstraction which makes differences between implementation language trivial.

Even restricted to the "procedural" approach ---- if the task is beyond my ability to "see" the entire solution in one step my first step is to ask "can a finite state machine solve the problem" or will it require a "stack machine" (one of those is powerful enough to solve any problem that is computable). If as usual I can "see" the FSM that solves the problem I define the states and their legal transitions. I then don't "code the problem" but simply code the states and for those routines and easy to build "test drivers" to debug each of them. In other words you can think of the problem as being solved "in assembler" for an imaginary machine which has precisely the "instruction set" wihich makes solving the problem easy. Almost any language can be used for the actual coding.

Note -- in the final program may either leave in what makes it obvious that this approach was used or not. I've done both "on the job" with "leaving in" mainly as a guide to less experienced programmers how to attack a problem this way. Like any time we code programs, there may be bugs, but if so, any error not at the design level (not a mistake because left a "hole" in some state) has to be confined to just one state procedure (although the state and its legal transitions properly defined that wasn't implemented correctly).

I'm a student but I'm not doing this project for any class.

_________________
"Those who calculate greatly will win; those who calculate only a little will lose, but what of those who don't make any calculations at all!? This is why everything must be calculated, in order to foresee victory and defeat."-The Art of War

If knowing backgrounds any help, I'm a retired senior systems analyst with a several decades in the cypher mines and a few hundred thousand lines of code under my belt. Fluent in (for writing) half a dozen langauges but can read most anything.

I'll repeat what I said earlier -- the language you choose to learn programming is of much less importance than the quality of the text from which you are trying to learn. Best is one that has an approach "data structures + algorithms". It really doesn't matter whether you chosen language provides this or that data structure or algorithm as a built in or if you have to roll your own if you don't know what they are and what they represent in the abstract.

What would you say is the purpose of this project? Is it to help you learn to program? Reflect on your own go knowledge? Is the go part of it incidental to other things? Such as the maths or pattern recognition? Perhaps there are specific features/calculations you want (for the purposes of studying go) that existing programs don't provide?

_________________
19/02/2011: this grumpy person takes a voluntary holiday from L19.

Let's just say that I have an image in my mind of a go database program which is far more extensive and sophisticated than any that currently exists. If I manage to implement even half of my ideas, it will be revolutionary. I know it will probably take me a long time, and eventually I'll need to bring others on board. I don't want to give specific features away at this point since I don't want my ideas stolen, as the program could potentially become a commercial venture.

_________________
"Those who calculate greatly will win; those who calculate only a little will lose, but what of those who don't make any calculations at all!? This is why everything must be calculated, in order to foresee victory and defeat."-The Art of War

Nagano - I think your emphasis early on on speed is misplaced. It's easy to say "code that runs faster is better" but that really isn't the case. Either your program runs fast enough, or it is too slow, in most applications (including this one) faster makes it no better once it is fast enough.

In addition, it sounds like you will be working with large on-disk databases. Any mainstream language will be faster than your disk. Furthermore, a higher level language (which according to some benchmarks may be slower) may make it easier for you to select the right data structures and algorithms, reducing the algorithmic complexity of your end result and actually giving you a program that solves the problems you are interested in faster. And that's even aside from the potentially shorter coding time.

Overall, I think picking C++ because "it runs faster" is a terrible mistake. C++ might be a good language for you, but "it runs faster" should be very low on your priority list, if it is there at all.

(For an example, KGS 2.0 had a server in C. When I started the rewrite in Java, which became KGS 3.0, many people said I was crazy and that a Java-based server would be way too slow. But I was happy to see that KGS 3.0 actually ran *FASTER* than the 2.0 server, and could handle more users at once without bogging down, because Java made it easy for me to use more efficient data structures and algorithms.)