chess engine in LISP

[Tord]

LISP is too slow. All functional languages are too slow.

There are very fast Common Lisp implementations out there (give SBCL a try, for instance), and Common Lisp is not a functional language. It's a multi-paradigm language that among other things support functional programming, although functional style in Common Lisp is a bit more awkward than in more purely functional Lisps like Clojure. Most of the large-scale Common Lisp programs I have seen are heavily object-oriented rather than functional, and some of the most brilliant Lispers I have worked with have a quite strong distaste for functional programming.

I've used Common Lisp for performance-intensive tasks in the past, including some chess programming tasks (but no complete chess engine). These days, I do chess programming in Julia, a more recent Lisp dialect. Again I have no chess engine, but a perft search (a quite good measure low-level speed for chess programming) to depth 7 (3,195,901,860 positions) from the initial position takes 16 seconds on a single core of my Intel MacBook Pro. This is not ridiculously slow, especially when considering that I have made no particular effort to optimize.

I have full confidence that I could write a competitive chess engine in Julia. It would probably not be quite as fast as what I could make in C/C++, but it would be close enough.

They have only theoretic value.

I've used Clojure (which is a functional Lisp) as my main language in my job for years, and find it to have tremendous practical value. Sure, it's nowhere near as fast as C, C++, Common Lisp, or Julia, but for most tasks, it's more than fast enough. It's an order of magnitude faster than Python, and nobody would say that Python has only theoretical value.

[Tord]

Zig, Nim, Odin, Pony

Nim is extremely nice. I don't understand why it doesn't get more attention. To me it feels simultaneously like a better Rust than Rust, and a better Go than Go.

[Henk]

I saw a video a year ago that Haskell was a fine language but they only used it at Universities.

LISP is no functional language. It has the SETQ statement. But you can do functinal programming in LISP by using association lists I remenber.

[j.t.]

Zig, Nim, Odin, Pony

Nim is extremely nice. I don't understand why it doesn't get more attention. To me it feels simultaneously like a better Rust than Rust, and a better Go than Go.

Exactly! And I feel also like a better C++ than C++, if it weren't for the very mature environment that C++ enjoys (libraries, tutorials, tools, compiler support/research). I wrote mostly Nim code this year, and now each time I have to write in other languages (Java, C++) I miss stuff, starts with the syntax(and the sugar) and doesn't end with the strong type reflection.

[emadsen]

i want to make clear that i never copied code from other people...

Yes, I never thought you did. I'm sorry, I did not mean to imply you copied anything.

i don't want to end up with a mess. for example i look for what i might need and then implement it from the start but this method doesn't work because i get overwhelmed quickly (here shows my lack of experience in writing software).

I think for someone new to software development, a little bit of a mess is OK. Sometimes you have to write the naive solution first. It gives you experience in the form of contending with unexpected complications, difficult debugging, overly rigid code structures that resist refactoring efforts, etc. Having struggled through that you'll better appreciate when, where, and why more advanced data structures, design patterns, and coding techniques provide value when you hear more senior developers discussing or debating them. You'll understand more than just the what of the advanced techniques. You'll understand the tradeoffs:

• Coding discipline now traded for easier refactoring later.
• More complex data structures created at program startup for better runtime performance in the hot path.
• Defensive coding now for faster bug resolution later.
• Etc.

If you only know the what, you're only capable of mimicry, not understanding. Raymond Chen says it best:

Good advice comes with a rationale so you can tell when it becomes bad advice. If you don’t understanding why something should be done, then you’ve fallen into the trap of cargo cult programming, and you’ll keep doing it even when it’s no longer necessary or even becomes deleterious.

Hopefully you can persuade a more experienced developer to explain the rationale. But sometimes you have to discover it for yourself.

Sorry if I came off too harsh in my earlier post. I'm not advocating an all-or-nothing approach. I don't want you to drive the car blindfolded and crash. It's perfectly OK to look at other people's code. Just don't use it as a crutch and cheat yourself of the experience of learning the when, where, and why.

what if i make a mistake where the only solution is starting over again?

That's too fearful and fatalistic of a sentiment. You will make mistakes. And they hardly ever require starting over again.

[tcusr]

no no you did not imply anything, you were super clear actually, i just wanted to explain why i read other people's code.
with my little experience in my previous engine i already more or less why i need to something, but from now on i will continue on my own and learn on the go.
my statement about starting over was about design choices, which i am very bad at. but again, without experience i won't actually know why i should prefer A over B.
again, thank you very much