5 ms·

I have been trying to understand the problem with syntactic abstraction in other languages -- or creating your own languages to fit the problem. Is it a real i

by Xurinos 16y ago

I have been trying to understand the problem with syntactic abstraction in other languages -- or creating your own languages to fit the problem. Is it a real issue? or is the problem with it just same problem people have with any unfamiliar codebase where the developers made unclear or poor abstractions? To clarify what I mean, I have presented lisp ideas to fellow coworkers and met with resistance along two lines: (1) They want to understand what is really going on, and the abstraction can obscure that. This sounds to me like a general abstraction problem more than an issue with syntactic abstraction... and really, it seems like a problem with understanding how someone chose to abstract things. They want to look underneath the hood for answers. (2) They suggest that new developers will have a hard time understanding and adding to the system. But new developers for any project have to learn the local language anyway. It may look like C++, python, or whatever, but it the framework other developers developed always has its own learning curve. Surely syntactic abstraction is just another abstraction tool that can be used to help make those frameworks easier to dive into. There is always poor code and poor documentation; this is not an excuse not to declare functions or other pretty approaches. Why is it any scarier to use this tool than to use someone's library?

dman 16y ago
There is a small difference - syntax affects the read time comprehensibility of code in ways other abstractions dont. For eg in C++ an overridden "+" operator could be doing anything in the background and there would be no way for you to know by a casual read of the code. Lisp has macroexpand-l for this, but one needs to be dilligent enough to use it on new pieces of code.
- Xurinos 16y ago
  Since in C++ the + operator is actually a class method in C++, it sounds like all abstraction suffers the same potential problem of "no way for you to know by a casual read of the code". That is a good point on the macroexpand functions; I would hope that if syntactic abstraction was added to C++, there would be a similar way to view the resulting code (sounds like a great future gdb / MSVC debugger feature).
  - jpr 16y ago
    I have found that while I mostly understand C++ as a language and respect it for what it tries to accomplish, the development environments are absolutely atrocious in many ways, and I spend more time fighting them than writing code. This has made me conclude that even though I could in theory program in C++, it is waste of human resources to do so with the current generation of development tools.

by Xurinos 16y ago

dman 16y ago

There is a small difference - syntax affects the read time comprehensibility of code in ways other abstractions dont. For eg in C++ an overridden "+" operator could be doing anything in the background and there would be no way for you to know by a casual read of the code. Lisp has macroexpand-l for this, but one needs to be dilligent enough to use it on new pieces of code.

Xurinos 16y ago
Since in C++ the + operator is actually a class method in C++, it sounds like all abstraction suffers the same potential problem of "no way for you to know by a casual read of the code". That is a good point on the macroexpand functions; I would hope that if syntactic abstraction was added to C++, there would be a similar way to view the resulting code (sounds like a great future gdb / MSVC debugger feature).
- jpr 16y ago
  I have found that while I mostly understand C++ as a language and respect it for what it tries to accomplish, the development environments are absolutely atrocious in many ways, and I spend more time fighting them than writing code. This has made me conclude that even though I could in theory program in C++, it is waste of human resources to do so with the current generation of development tools.