LISP always manages to confuse me even more each time I hear an explanation of its features. Objects and methods as the same? I had heard of this before when learning Ruby, I knew the compiler took everything as a an object, be it a string, int, boolean, an actual object, or even a teeny tiny char. This seemed logical, every value type has its on inherent characteristics that couldn't be treated the same between data types.
What I find so mind numbing is the fact that LISP just creates objects for every line, if you see a parenthesis in my code (which you will find in industrial quantities in LISP) you should know that an object starts at its openning, and closes at its closing parenthesis.What does this mean to the average object-oriented programmer? A true matrioska doll of unadultered and low leveled code, objects within objects within objects. This only makes objects easier to change and maintain, considering its attributes and functions are all objects that can be interchanged in a modular way, but is still something unheard of for someone like me who can only boasts of an expansive understanding of the Java language.
There's an interesting point made in this podcasts, and that is that LISP was original conceived as a tool for AI developing. I can see how such a simple and maintainable language con serve such a purpose but I couldn't even begin to list why I think that would be harder than making a compiler in Java. Not that I'm demeriting LISP, but it just seems hard, everything seems so ambiguous and abstract, I would imagine that the AI science would contain at least a small quantity of explicitely and compulsorily concrete values instead of all these weird data structures.
I honestly hope that by the end of this course I understand most (if not all) of the rarities LISP has to offer.
No hay comentarios:
Publicar un comentario