Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Missing the point.

If you read just a little farther, you get that extra apparatus has a purpose that is opaque to beginners, that just adds confusion.



I'm responding to

> And so they would have accidentally re-introduced classes, only this time the existence of classes would have been implicit in the code, and their behaviour ad hoc defined, their invariants spread all over the source files, and with no language-level tooling or introspection to help the programmer. Classes would still exist, but as implicit patterns.

You don't need to do this with classes, my design is better than the class design because it's more flexible


Flexibility usually has a cost. It's not better or worse.


Correct! When the language provides apparatus to do the thing, everybody doing the thing is incentivized do it the same way, making libraries implicitly compatible. Cobbling things together yourself (which you can always do: these languages are Turing-complete) you are unlikely to do it compatibly with what anybody else does.

This might be why Lisp never developed an ecosystem. Everybody can make their own pile of macros to customize the language for their use, with no standard interfaces that can be composed.


So would this argument not apply to the use of Templates in C++? Everyone can design their own--what is to keep these from slopping all over the landscape?


> So would this argument not apply to the use of Templates in C++?

Yes, AFAICS arguably it would.

> Everyone can design their own--what is to keep these from slopping all over the landscape?

Who says there is anything to do that?


I was referring to

> you are unlikely to do it compatibly with what anybody else does


Yes, and I was implying there's nothing to make sure it's compatible.


Example: GNU Emacs comes bundled with 1.5 million lines of Lisp code. How was that possible, given that Emacs Lisp has macros?


You have maybe noticed that Emacs is a single program? (OK, two or three, historically.) Emacs Lisp code that doesn't integrate with the rest of Emacs just doesn't work.


What I have noticed is that GNU Emacs is an application development platform for various programs.

Example: Org mode. 133 k lines of Emacs Lisp code.

https://orgmode.org

Org mode then is also used by other tools.

Somehow these 'Lisp macros' seem to integrate, even though they are written in different times (GNU Emacs started in the mid 80s) by many different authors, for different programs on top of GNU Emacs.

That GNU Emacs is a program itself is not different from, say, CPython. That's also a program itself, used to run other code. GNU Emacs has 'packages' and an online archive for that. Developers publish libraries (which other use) and whole solutions, like Org mode.

That 'Lisp' itself doesn't have an 'eco system' is no surprise, since Lisp is not a single language, but a family of dialects, developed over the last almost 64 years - either similar ones like Autolisp and Emacs Lisp or different ones like Logo and Racket. Thus these dialects tend to have their own eco-systems. Like Java and C each have their own eco-systems.


I really don't care about Lisp.

The point is that if you are designing a language and want a lively ecosystem, you either build in features that establish conventions, or implement them in a Standard Library if the language is powerful enough to express them that way.

Failing to build common ground to enable libraries from different places to interact cleanly dooms your language to obscurity.


Not sure what that has to do with Lisp then, since macros establish conventions, but on a language level.

Example: the Common Lisp Object System was initially developed as new a library, based on two other earlier libraries. This was then standardized and it is the standard way to develop object-oriented software in CL.

The library has three API layers: an object-oriented layer, a functional layer and a syntactic layer. The syntactic layer is implemented with Macros. It provides for the developer a convenient way to specify the elements of an object-oriented program: classes, generic functions, methods, control structures, ... As a developer everyone prefers to use the syntactic level.

There are many libraries and applications using it. It's also extensible, so that other user can add new behaviour to the object-system itself.

That macros enable new language extensions also on a syntactic level is nothing special. To use macros from other developers is not more difficult than using a class graph, or similar.

There is a lot of 'fear' of user-level syntax extensions from people who have never developed with it. Understanding the implementation of macros themselves is an added burden, since many developers are not used to write&read code which is written on a meta-level of incremental code generation. But there are practices which can be learned and applied. Macros themselves can make the code much more readable, since it allows one to support a problem domain also on a syntax level and hides implementation details.


I disagree. It is maybe better for the author or you as a beginner, but not everyone. One needs data to support claims like that.


Again, you miss the point.

Identically the same person, at different times, is confused by what seems like pointless extra apparatus, and, later, embraces it as solving a problem they have come, after experience, to recognize.

"One needs data" is, in this context, nothing better than meaningless bluster.


You can make a general claim like that and sounds true. But I was referring to how your general claim fits to the specific situation.

Conversation is mean to have a deliver and receive end, both side can have problems. "you miss the point" kind of push all the responsibility to the listener. But why you have such a strong confidence about your expression?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: