7 ms·

The highlights include a game of tic-tac-toe solely in several calls to printf(fmt, arg), where fmt and arg are carefully chosen. This made me reflect on wheth

by lldbg 6y ago

The highlights include a game of tic-tac-toe solely in several calls to printf(fmt, arg), where fmt and arg are carefully chosen. This made me reflect on whether good language design should limit expressiveness of code?

nemo1618 6y ago
My latest PL idea, inspired by Rust's "unsafe {}" blocks is "expressive {}" blocks. The "base language" would be boring, pedestrian, optimizing for zero surprises. But inside an expressive{} block, you could have macros, operator overloading, DSLs, first-class continuations, you name it.
- owl57 6y ago
  dragons {}
- bidirectional 6y ago
  I had a similar idea upon seeing the power of incredibly terse languages like k and q (both still used in a lot of investment banks). The core language would be boring and imperative, for plumbing, but you'd also be able to write and evaluate array language expressions as a first class construct.
saagarjha 6y ago
Accidental Turing completeness isn't necessarily a problem in a Turing complete language ;)
- schoen 6y ago
  The author of this program also wrote a paper about the technique it uses https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-carlini.pdf https://www.usenix.org/system/files/conference/usenixsecurit... describing it as a way of circumventing security measures that try to ensure that a particular control flow is followed in a compiled binary. In that case the security goal could be seen as forcing the compiled program to behave in a way close to what a human writer (or reader) would expect, while this method gets around that. So in that way, it could still be a problem, because the programmer appeared to write specialized program X but it can potentially be induced to behave like unrelated program Y at run time.
- IQunder130 6y ago
  It is a problem when the language is being used to get anything done in the real world.
raverbashing 6y ago
> This made me reflect on whether good language design should limit expressiveness of code? Yes, I think so. "Smart" code is smart for 5 min, after that it becomes a liability
- woofie11 6y ago
  The former doesn't follow from the latter. For tools I use and places I want to work: * Programming languages should be general. * Programmers should be competent and disciplined enough not to misuse that generality. I absolutely hate programming in languages like Java, designed for idiot programmers. I understand their place -- there are a lot of incompetent programmers, and we need to constrain them, and a lot of places with boring IT problems who won't be able to hire competent people -- but it's not something I'd ever want to touch. That sort of workplace and that sort of language would make me miserable.
  - qayxc 6y ago
    To quote a man I consider to be both, very intelligent and wise: > Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
    - woofie11 6y ago
      I don't consider that man particularly wise. Clever has many different axes. Compare debugging something like git or hg (clever, simple data structure) to cvs or svn (non-clever, standard data structure). Systems like git and hg don't just do more; they're also far more debuggable thanks to clever. That's not an IOCCC type of cleverness, but a deep, deep clever. Likewise, consider general-purpose data stores (such as a KVS or an RDBMS) compared to a one-off data structures mapping directly to your data. The design of the original RDBMS was hyper-clever. A wise man knows when to be clever and when not to be clever. I don't know of any programming language designer who can make that determination for me; it's too domain-specific. If you can rely on programmers to not be clever for inane reasons, you can allow them to be clever for architecturally-critical reasons.
bawolff 6y ago
%n has caused many a security vulnerability.
Kalium 6y ago
> This made me reflect on whether good language design should limit expressiveness of code? There's a magic to a sonnet that isn't found in blank verse. Limitations can do a lot to improve writing.
mightybyte 6y ago
Here's a nice talk that goes into this dichotomy a bit. https://www.youtube.com/watch?v=GqmsQeSzMdw https://www.youtube.com/watch?v=GqmsQeSzMdw

by lldbg 6y ago

nemo1618 6y ago

My latest PL idea, inspired by Rust's "unsafe {}" blocks is "expressive {}" blocks. The "base language" would be boring, pedestrian, optimizing for zero surprises. But inside an expressive{} block, you could have macros, operator overloading, DSLs, first-class continuations, you name it.

owl57 6y ago
dragons {}
bidirectional 6y ago
I had a similar idea upon seeing the power of incredibly terse languages like k and q (both still used in a lot of investment banks). The core language would be boring and imperative, for plumbing, but you'd also be able to write and evaluate array language expressions as a first class construct.

saagarjha 6y ago

Accidental Turing completeness isn't necessarily a problem in a Turing complete language ;)

schoen 6y ago
The author of this program also wrote a paper about the technique it uses https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-carlini.pdf https://www.usenix.org/system/files/conference/usenixsecurit... describing it as a way of circumventing security measures that try to ensure that a particular control flow is followed in a compiled binary. In that case the security goal could be seen as forcing the compiled program to behave in a way close to what a human writer (or reader) would expect, while this method gets around that. So in that way, it could still be a problem, because the programmer appeared to write specialized program X but it can potentially be induced to behave like unrelated program Y at run time.
IQunder130 6y ago
It is a problem when the language is being used to get anything done in the real world.

raverbashing 6y ago

> This made me reflect on whether good language design should limit expressiveness of code? Yes, I think so. "Smart" code is smart for 5 min, after that it becomes a liability

woofie11 6y ago
The former doesn't follow from the latter. For tools I use and places I want to work: * Programming languages should be general. * Programmers should be competent and disciplined enough not to misuse that generality. I absolutely hate programming in languages like Java, designed for idiot programmers. I understand their place -- there are a lot of incompetent programmers, and we need to constrain them, and a lot of places with boring IT problems who won't be able to hire competent people -- but it's not something I'd ever want to touch. That sort of workplace and that sort of language would make me miserable.
- qayxc 6y ago
  To quote a man I consider to be both, very intelligent and wise: > Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
  - woofie11 6y ago
    I don't consider that man particularly wise. Clever has many different axes. Compare debugging something like git or hg (clever, simple data structure) to cvs or svn (non-clever, standard data structure). Systems like git and hg don't just do more; they're also far more debuggable thanks to clever. That's not an IOCCC type of cleverness, but a deep, deep clever. Likewise, consider general-purpose data stores (such as a KVS or an RDBMS) compared to a one-off data structures mapping directly to your data. The design of the original RDBMS was hyper-clever. A wise man knows when to be clever and when not to be clever. I don't know of any programming language designer who can make that determination for me; it's too domain-specific. If you can rely on programmers to not be clever for inane reasons, you can allow them to be clever for architecturally-critical reasons.

bawolff 6y ago

%n has caused many a security vulnerability.

Kalium 6y ago

> This made me reflect on whether good language design should limit expressiveness of code? There's a magic to a sonnet that isn't found in blank verse. Limitations can do a lot to improve writing.

mightybyte 6y ago

Here's a nice talk that goes into this dichotomy a bit. https://www.youtube.com/watch?v=GqmsQeSzMdw https://www.youtube.com/watch?v=GqmsQeSzMdw