5 ms·

This is one of the eternal debates in software engineering. Knowing that certain powerful features of programming languages can be used to create unmaintanable

This is one of the eternal debates in software engineering. Knowing that certain powerful features of programming languages can be used to create unmaintanable code, do we ban those features or do we try to harness them by using a disciplined approach to software design? Specifically with regard to meta programming, I think we have seen all that can happen several times over. If you have those features within the programming language they tend to get overused. If you don't have them within the programming language, they get tacked on in some inconsistent, half-assed way as soon as the need for frameworks, DSLs or sophisiticated configuration arises.

vikeri 8y ago
In Clojure macros are not overused IMO.Even though they are fully supported the community encourages you to only use it when it's absolutely necessary.
- serpix 8y ago
  And even then the consensus is to reconsider. And at the very last document a sample usage and an expanded form plus apology.
  - typon 8y ago
    And I totally believe it doesn't have to be this way. The way Racket does macros is a great example of how to do them well.
realusername 8y ago
> Knowing that certain powerful features of programming languages can be used to create unmaintanable code, do we ban those features or do we try to harness them by using a disciplined approach to software design? I don't have any example were the disciplined approached worked so I would agree with the first option. People overused every single bad feature, here it's Lisp but it's the same in Php, Perl, Javascript or Python.
oblio 8y ago
Well, everything I've read about this subject basically shows that ever since we stopped congregating in families and tribes, scaling people effectively trumps any kind of individual scaling. The Kingdom of Benin probably had some amazing individuals we'll never read about, but once the much more organized Brits came around, the stronger organization beat the other one.
- Ultimatt 8y ago
  Scaling individuals gets you output at the quality of the very best individuals. Scaling the people gets you the best the average of the people can deliver. The vast majority of useful and highly complex software at least in its initial formative stages is produced by one or very few individuals working. Later come the masses of me too I need this. There will always be the need for languages you can be super effective and productive in as an individual. Java is a great engineering language, but anyone who thinks their personal itch project is best served by that language, doesn't know anything other than Java.
  - oblio 8y ago
    Software advice from the unlikeliest of sources (Stalin): quantity has a quality all its own. The architects will be constrained by Java, but they can use it nonetheless. And instead of metaprogramming with Lisp they can metaprogram with humans. You'll need them anyway, as the application grows, and like this they get to know the code better, since they write it.
    - pasabagi 8y ago
      I think Stalin is paraphrasing Hegel, there.
      - oblio 8y ago
        Via Marx, it seems :)
- deleted 8y ago
  [deleted]
jcelerier 8y ago
> they get tacked on in some inconsistent, half-assed way as soon as the need for frameworks, DSLs or sophisiticated configuration arises. can confirm, if you can't metaprogram in the language, you will at some point write external code generators and such... Metaprogramming is just the most common programming "task", avoiding repetition, applied to itself.
- pjmlp 8y ago
  Yep, even Go with their bias against modern type systems ended up bolting "//go:generate" for exactly that purpose.
lmm 8y ago
> Knowing that certain powerful features of programming languages can be used to create unmaintanable code, do we ban those features or do we try to harness them by using a disciplined approach to software design? Discipline never works unless it's enforced. So the only hope is to figure out "less powerful" versions of those features that cover all their important use cases without permitting unmaintainable code. Fortunately, modern programming language design has gotten pretty good at that: 95% of the killer use cases you'd see as macro examples in Lisp advocacy 20 years ago are now ordinary, standard-ish programming language features. > If you have those features within the programming language they tend to get overused. If you don't have them within the programming language, they get tacked on in some inconsistent, half-assed way as soon as the need for frameworks, DSLs or sophisiticated configuration arises. That's a possible failure mode, but we've been pretty good at moving away from it IME. The best modern languages do manage to walk the fine line between a language that's too constrained to do anything in without some magic addon and a language that's unmaintainably flexible in the language proper.

vikeri 8y ago

In Clojure macros are not overused IMO.Even though they are fully supported the community encourages you to only use it when it's absolutely necessary.

serpix 8y ago
And even then the consensus is to reconsider. And at the very last document a sample usage and an expanded form plus apology.
- typon 8y ago
  And I totally believe it doesn't have to be this way. The way Racket does macros is a great example of how to do them well.

realusername 8y ago

> Knowing that certain powerful features of programming languages can be used to create unmaintanable code, do we ban those features or do we try to harness them by using a disciplined approach to software design? I don't have any example were the disciplined approached worked so I would agree with the first option. People overused every single bad feature, here it's Lisp but it's the same in Php, Perl, Javascript or Python.

oblio 8y ago

Well, everything I've read about this subject basically shows that ever since we stopped congregating in families and tribes, scaling people effectively trumps any kind of individual scaling. The Kingdom of Benin probably had some amazing individuals we'll never read about, but once the much more organized Brits came around, the stronger organization beat the other one.

Ultimatt 8y ago
Scaling individuals gets you output at the quality of the very best individuals. Scaling the people gets you the best the average of the people can deliver. The vast majority of useful and highly complex software at least in its initial formative stages is produced by one or very few individuals working. Later come the masses of me too I need this. There will always be the need for languages you can be super effective and productive in as an individual. Java is a great engineering language, but anyone who thinks their personal itch project is best served by that language, doesn't know anything other than Java.
- oblio 8y ago
  Software advice from the unlikeliest of sources (Stalin): quantity has a quality all its own. The architects will be constrained by Java, but they can use it nonetheless. And instead of metaprogramming with Lisp they can metaprogram with humans. You'll need them anyway, as the application grows, and like this they get to know the code better, since they write it.
  - pasabagi 8y ago
    I think Stalin is paraphrasing Hegel, there.
    - oblio 8y ago
      Via Marx, it seems :)
deleted 8y ago
[deleted]

jcelerier 8y ago

> they get tacked on in some inconsistent, half-assed way as soon as the need for frameworks, DSLs or sophisiticated configuration arises. can confirm, if you can't metaprogram in the language, you will at some point write external code generators and such... Metaprogramming is just the most common programming "task", avoiding repetition, applied to itself.

pjmlp 8y ago
Yep, even Go with their bias against modern type systems ended up bolting "//go:generate" for exactly that purpose.

lmm 8y ago

> Knowing that certain powerful features of programming languages can be used to create unmaintanable code, do we ban those features or do we try to harness them by using a disciplined approach to software design? Discipline never works unless it's enforced. So the only hope is to figure out "less powerful" versions of those features that cover all their important use cases without permitting unmaintainable code. Fortunately, modern programming language design has gotten pretty good at that: 95% of the killer use cases you'd see as macro examples in Lisp advocacy 20 years ago are now ordinary, standard-ish programming language features. > If you have those features within the programming language they tend to get overused. If you don't have them within the programming language, they get tacked on in some inconsistent, half-assed way as soon as the need for frameworks, DSLs or sophisiticated configuration arises. That's a possible failure mode, but we've been pretty good at moving away from it IME. The best modern languages do manage to walk the fine line between a language that's too constrained to do anything in without some magic addon and a language that's unmaintainably flexible in the language proper.