4 ms·

A programmable programming language is one where you can alter the fundamental building blocks of the programming language to make it perfect for you. Unfortun

A programmable programming language is one where you can alter the fundamental building blocks of the programming language to make it perfect for you. Unfortunately, once you have more than 1 programmer involved in the project, you end up with slightly different versions the same concepts.

foreigner 4y ago
This was my experience with Ruby. The language makes it easy to create DSLs, so lots of libraries are implemented that way. To work on a large project you actually need to learn dozens of different languages. No thanks.
- brainbag 4y ago
  This used to be the case, but once Ruby stopped being the hot language, the examples of "just because you can doesn't mean you should" went to JS. Rake and RSpec format are the only two DSLs that get any major use anymore, and most other spec tools in other languages use similar describe/it DSLs to RSpec.
- giraffe_lady 4y ago
  Over the last couple years a way I've come to view software is that a sufficiently complex library, class, api, or even just file IS a DSL. I don't see a useful clear line between "code" and "dsl" in the end, certainly not one based on whether you still use strictly the syntax of the base language. I don't necessarily like learning a bunch of DSLs either, but I'm not sure the ruby situation is that different from what is always the case, just more honest about it. I've been trying to pay attention to the problems I solve and noticing early when they benefit from being explicitly defined as a little language and it's been quite successful in a few cases. It reminds me of something a mentor pointed out early in my career that has remained a valuable insight: a whole lot of real world logic is implemented with state machines, but the only reliable and maintainable ones are where the author knew that from the beginning. Often we're using a known pattern to solve a problem without recognizing and naming it, so missing opportunities to apply hard-won knowledge and tools from elsewhere.
  - lispm 4y ago
    > Over the last couple years a way I've come to view software is that a sufficiently complex library, class, api, or even just file IS a DSL. Yes. A macro gives a certain programming feature a name and a syntax. But with a function we also need to give it a name and we need to define the arguments. In the case of function arguments, we also need to know what the input and output of those function needs to be. For example in Lisp there is a macro WITH-OPEN-FILE, which opens a file, executes code using the input stream and then closes the file. It also ensures that the file is also closed in case of an error. (with-open-file (stream filename) (read stream)) We now may have two other ways to deal with that often needed functionality: write the code or use a function which does the same (here in this example this is possible, but often a macro does something which a function can't). First we write the code. We may pull this from a snippet library. We have to remember what the primitives are and what they do. (let (stream return-value) (unwind-protect (setf return-value (progn (setf stream (open filename)) (read stream))) (close stream) return-value)) Or we write a function. This gets a name CALL-WITH-OPEN-FILE, a list of arguments and in case of the function it needs to now what the input and outputs are: a stream is the input and the result is arbitrary, but will be returned by CALL-WITH-OPEN-FILE. (call-with-open-file filename (lambda (stream) (read stream))) For the macro we need to know: * the name of the macro * the syntax of the macro: with-open-file (<symbol, non-evaluated> <filename, evaluated>) form* * what the generated code is supposed to do For the function we need to know: * the name of the function * the list of arguments and their order * the types and semantics of the arguments: a filename and a function which takes a stream * what the function is supposed to do The effect is basically the same: both ways are essential leading to a DSL, where the language operators and their usage has to be learned.
reikonomusha 4y ago
This is a fallacy* that is often repeated. It's like saying that nobody can work together on a Python project because everybody will create their own incompatible pet decorators. Any reasonably run project will have standards and code review. I have not, once, in my decade+ career writing Common Lisp professionally, run into a single instance where my peer programmers on a project have painted one another into silly corners due to unfettered use of macros of any ilk. It doesn't happen, because (1) code comes from some manner of requirements and (2) PRs are reviewed. Macros that don't make solutions easier to read and write for the team, not just a programmer are patently rejected. * I feel this fallacy and others frequently come from people who hear about a relatively obscure feature or superpower of a language and—having never used it—then try to imagine pessimistic or pathological uses of said feature. Unfortunately, the speculation is usually flat-out wrong, and not even adjacent to some truth.
- agumonkey 4y ago
  I had a tiny habit of making cryptic names and structures that only I would perceive as good. But even then, with time I balanced things out.. I understand the value of other's perspective. And most books talk about it right away. People seeking advanced PLT features are not in it for foolish tricks.
- pixelrevision 4y ago
  A lot of us get burnt by inheriting older codebases where we have to work with code by a dev(s) who’s no longer there who got over enthusiastic with a powerful feature. What’s funny is you can usually trace that code back to a language adding some new improvement and it taking some time before people figured it out. Lisp seems to kind of avoid all that by just making everything available and not having a lot of language changes.
- pronlover723 4y ago
  It's good to hear your experience is positive My guess would be that people that come from C++, where meta programming is insanely complex and hard to follow, would guess that a language that encourages meta programming would often lead to complex and hard to follow solutions. A DSL that looks simple on usage but then looking into how it works is 10 nested complex compile time macros.

foreigner 4y ago

This was my experience with Ruby. The language makes it easy to create DSLs, so lots of libraries are implemented that way. To work on a large project you actually need to learn dozens of different languages. No thanks.

brainbag 4y ago
This used to be the case, but once Ruby stopped being the hot language, the examples of "just because you can doesn't mean you should" went to JS. Rake and RSpec format are the only two DSLs that get any major use anymore, and most other spec tools in other languages use similar describe/it DSLs to RSpec.
giraffe_lady 4y ago
Over the last couple years a way I've come to view software is that a sufficiently complex library, class, api, or even just file IS a DSL. I don't see a useful clear line between "code" and "dsl" in the end, certainly not one based on whether you still use strictly the syntax of the base language. I don't necessarily like learning a bunch of DSLs either, but I'm not sure the ruby situation is that different from what is always the case, just more honest about it. I've been trying to pay attention to the problems I solve and noticing early when they benefit from being explicitly defined as a little language and it's been quite successful in a few cases. It reminds me of something a mentor pointed out early in my career that has remained a valuable insight: a whole lot of real world logic is implemented with state machines, but the only reliable and maintainable ones are where the author knew that from the beginning. Often we're using a known pattern to solve a problem without recognizing and naming it, so missing opportunities to apply hard-won knowledge and tools from elsewhere.
- lispm 4y ago
  > Over the last couple years a way I've come to view software is that a sufficiently complex library, class, api, or even just file IS a DSL. Yes. A macro gives a certain programming feature a name and a syntax. But with a function we also need to give it a name and we need to define the arguments. In the case of function arguments, we also need to know what the input and output of those function needs to be. For example in Lisp there is a macro WITH-OPEN-FILE, which opens a file, executes code using the input stream and then closes the file. It also ensures that the file is also closed in case of an error. (with-open-file (stream filename) (read stream)) We now may have two other ways to deal with that often needed functionality: write the code or use a function which does the same (here in this example this is possible, but often a macro does something which a function can't). First we write the code. We may pull this from a snippet library. We have to remember what the primitives are and what they do. (let (stream return-value) (unwind-protect (setf return-value (progn (setf stream (open filename)) (read stream))) (close stream) return-value)) Or we write a function. This gets a name CALL-WITH-OPEN-FILE, a list of arguments and in case of the function it needs to now what the input and outputs are: a stream is the input and the result is arbitrary, but will be returned by CALL-WITH-OPEN-FILE. (call-with-open-file filename (lambda (stream) (read stream))) For the macro we need to know: * the name of the macro * the syntax of the macro: with-open-file (<symbol, non-evaluated> <filename, evaluated>) form* * what the generated code is supposed to do For the function we need to know: * the name of the function * the list of arguments and their order * the types and semantics of the arguments: a filename and a function which takes a stream * what the function is supposed to do The effect is basically the same: both ways are essential leading to a DSL, where the language operators and their usage has to be learned.

reikonomusha 4y ago

This is a fallacy* that is often repeated. It's like saying that nobody can work together on a Python project because everybody will create their own incompatible pet decorators. Any reasonably run project will have standards and code review. I have not, once, in my decade+ career writing Common Lisp professionally, run into a single instance where my peer programmers on a project have painted one another into silly corners due to unfettered use of macros of any ilk. It doesn't happen, because (1) code comes from some manner of requirements and (2) PRs are reviewed. Macros that don't make solutions easier to read and write for the team, not just a programmer are patently rejected. * I feel this fallacy and others frequently come from people who hear about a relatively obscure feature or superpower of a language and—having never used it—then try to imagine pessimistic or pathological uses of said feature. Unfortunately, the speculation is usually flat-out wrong, and not even adjacent to some truth.

agumonkey 4y ago
I had a tiny habit of making cryptic names and structures that only I would perceive as good. But even then, with time I balanced things out.. I understand the value of other's perspective. And most books talk about it right away. People seeking advanced PLT features are not in it for foolish tricks.
pixelrevision 4y ago
A lot of us get burnt by inheriting older codebases where we have to work with code by a dev(s) who’s no longer there who got over enthusiastic with a powerful feature. What’s funny is you can usually trace that code back to a language adding some new improvement and it taking some time before people figured it out. Lisp seems to kind of avoid all that by just making everything available and not having a lot of language changes.
pronlover723 4y ago
It's good to hear your experience is positive My guess would be that people that come from C++, where meta programming is insanely complex and hard to follow, would guess that a language that encourages meta programming would often lead to complex and hard to follow solutions. A DSL that looks simple on usage but then looking into how it works is 10 nested complex compile time macros.