5 ms·

Sorry, but I have a hard time believing the common trope that something silly like more language complexity will significantly help keeping the complexity of th

Sorry, but I have a hard time believing the common trope that something silly like more language complexity will significantly help keeping the complexity of the code down. Personally, I believe it is often the opposite. So you can't abstract over data types in C? I often do. Some random thing I often do: void linear_allocate(Linear_Allocator *alloc, size_t size, size_t align, size_t count); #define linear_allocate_type(alloc, type, count) ((type *) (linear_allocate((alloc), sizeof (type), alignof (type), (count)))) (Anybody objecting they don't like macros and this is not a real abstraction: You are all fools. To a certain point, that is - before you possibly start being right. But don't underestimate how far this can go, and how long this can be a superior solution over alternatives.) You know something that is very hard to abstract over? Programming language FEATURES! Anybody, please show me the ways of doing computation over all the data that was encoded as fancy programming language syntax. This requires even more language features to get this data back from the compiler in some weird form... if possible at all.

zbentley 4y ago
> Anybody, please show me the ways of doing computation over all the data that was encoded as fancy programming language syntax. This requires even more language features to get this data back from the compiler in some weird form... if possible at all. Happily! https://lisp-lang.org/ https://lisp-lang.org/
- jstimpfle 4y ago
  So you show me (or do not show me, instead you just link a website) your ways of retrieving the data encoded by fancy syntax, using a language that has literally almost no syntax at all?
  - zbentley 4y ago
    Exactly! The extremely simple syntax of a lisp is what enables similarly extreme syntactic consistency. That consistency, in turn, is what enables lisps' uniquely powerful treatment of code as data, so that programmers can access and transform what would be represented in other languages as "syntactic constructs" and "data values" in a uniform (and, in my opinion, quite nice and expressive) way. At risk of stereotyping myself, if you like this kind of thing, check out SICP. It is a really good dive into exactly how far you can go with this kind of tool, and also has applicability across the engineering discipline (not just for lisp folks).
    - jstimpfle 4y ago
      I've read through most of SICP, but I never found what's so great about it. Maybe it is that you can apply this argument to any other language as well: Represent your theoretical model as data structures that you control, instead of giving up control to the compiler. Representing code as data is not very interesting IMO. Code is code, data is data. Granted both are stored in RAM, but they are very different beasts considering how they flow through the machine. Almost any language allows to parameterize over functions (e.g. function pointers), but there is no need to make closures a first class citizen. After all, closures are a brutal abstraction, isolating any context from the caller. When overdone this ends up in a terrible mess where you don't know what's happening anymore (otherwise known as callback hell). Conclusion, use this only as a last resort.

zbentley 4y ago

> Anybody, please show me the ways of doing computation over all the data that was encoded as fancy programming language syntax. This requires even more language features to get this data back from the compiler in some weird form... if possible at all. Happily! https://lisp-lang.org/ https://lisp-lang.org/

jstimpfle 4y ago
So you show me (or do not show me, instead you just link a website) your ways of retrieving the data encoded by fancy syntax, using a language that has literally almost no syntax at all?
- zbentley 4y ago
  Exactly! The extremely simple syntax of a lisp is what enables similarly extreme syntactic consistency. That consistency, in turn, is what enables lisps' uniquely powerful treatment of code as data, so that programmers can access and transform what would be represented in other languages as "syntactic constructs" and "data values" in a uniform (and, in my opinion, quite nice and expressive) way. At risk of stereotyping myself, if you like this kind of thing, check out SICP. It is a really good dive into exactly how far you can go with this kind of tool, and also has applicability across the engineering discipline (not just for lisp folks).
  - jstimpfle 4y ago
    I've read through most of SICP, but I never found what's so great about it. Maybe it is that you can apply this argument to any other language as well: Represent your theoretical model as data structures that you control, instead of giving up control to the compiler. Representing code as data is not very interesting IMO. Code is code, data is data. Granted both are stored in RAM, but they are very different beasts considering how they flow through the machine. Almost any language allows to parameterize over functions (e.g. function pointers), but there is no need to make closures a first class citizen. After all, closures are a brutal abstraction, isolating any context from the caller. When overdone this ends up in a terrible mess where you don't know what's happening anymore (otherwise known as callback hell). Conclusion, use this only as a last resort.