4 ms·

> The maximum semantic size of a function that's still easy to read is much larger. This seems like a really weird thing to optimise for - would you mind sayin

> The maximum semantic size of a function that's still easy to read is much larger. This seems like a really weird thing to optimise for - would you mind saying more? I've never found myself thinking "man, I wish my function could _do more_". > This syntax is very readable. Objectively, by any measure, this isn't true.

dang 9y ago
Not by the measure which matters most: the programmers using it. Readability is relative. It's a category error to speak of it without saying who the reader is. Is Sanskrit readable?
- sammoorhouse 9y ago
  > the programmers using it Completely disagree, and I think the people spending the 2010's clearing up screeds of idiomatic perl 5 would side with me :)
  - goatlover 9y ago
    Are these idiomatic perl 5 programmers, or programmers converting it to their language of choice? And if the second, would it have been any easier going from Lisp or Haskell to Python, Go or whatever? Point being that translating from unfamiliar syntax to familiar is always a challenge.
RodgerTheGreat 9y ago
I use k3 at work every day. It's perfectly readable to me. Every summer we spend about a week training interns with K, and they proceed to read, modify and write real production code with it during their tenure. Interns come from a mix of backgrounds- computer science, various engineering degrees, etc. This seems compelling evidence that K is learnable. If you find K unreadable, consider spending a week or two seriously working with it. You might be surprised how you feel afterwards.
- sammoorhouse 9y ago
  > I use k3 at work every day. It's perfectly readable to me. Right, but the one follows from the other. I'm passingly familiar with K, Q, and a+. I've worked with Borror and I kind of own an a+ compiler. I think if you define "readable" to mean "you can learn it with two weeks intensive tuition" the fine, yeah, it's readable. But to me, lightning-fast speed doesn't make up for terse-to-the-point-of-dumb syntax. +/&~&/(!1000)!/:3 5 Reads like a cruel joke to me. It's unreadable and it breaks everything we know about writing good software, and to pretend otherwise kinda comes across as macho BS. Sorry. I don't know why developers in Whitney's programming languages all have this kind of snow-blindness to the clear failings of the language. I don't know why number of characters of code is the thing we're optimising for in 2018. It's not like you're firing bytes over a 56k modem.
  - kthielen 9y ago
    Hi Sam, good to run into you here! :D
  - goatlover 9y ago
    Regex is the similarly terse, and many popular languages make use of it. Do you replace regex syntax with much more verbose function calls? Also, several posts above mention how the interpreter fits inside the CPU L1 cache for maximum performance. I'm guessing the terse syntax helps keep it small enough.
    - tytytytytytytyt 9y ago
      > Do you replace regex syntax with much more verbose function calls? No, but I also don't find myself wishing the entire project read like regex does. "If only our entire suite of enterprise software was made up of regexes..."
    - kthielen 9y ago
      You know what's faster than having an interpreter for your program that fits entirely in L1 cache? Not having the interpreter at all.
icen 9y ago
There's a maximum amount of stuff a single function/code unit can do before becoming unreadable. When writing code, there's a tension between the semantic size of the implementation, and the semantic size of the constituent parts of the problem: very few problems are broken down into clean chunks of code. Quite often, when trying to subjugate the problem to the language, you end up with lots of 'features' of the modular parts: lots of parameters, parameters being complex non-data objects, and so forth. Breaking stuff down costs, as well - you have to make it clear how something is going to be used. You might write a helper function for one bit in particular, and then rely on additional levels of abstraction to make it clear how this function should be used. Instead, if you can allow your functions to become semantically larger, you don't need to explain and protect your modularisation. Helper functions with one use are inlined (it's very common that these things have names longer than their definition). Instead of a large tower of abstraction, you just have two levels: the level of the data, and the level of the problem. Your entire program is written as functions, each of which does something in the problem domain, and for each, each definition is immediately clear about what it is doing with the data. There was an article here, a while ago, called 'smaller code, better code', and with accompanying comments, that explain this better than I can.
- sammoorhouse 9y ago
  Thanks for taking the time, it's interesting to see another perspective.

dang 9y ago

Not by the measure which matters most: the programmers using it. Readability is relative. It's a category error to speak of it without saying who the reader is. Is Sanskrit readable?

sammoorhouse 9y ago
> the programmers using it Completely disagree, and I think the people spending the 2010's clearing up screeds of idiomatic perl 5 would side with me :)
- goatlover 9y ago
  Are these idiomatic perl 5 programmers, or programmers converting it to their language of choice? And if the second, would it have been any easier going from Lisp or Haskell to Python, Go or whatever? Point being that translating from unfamiliar syntax to familiar is always a challenge.

RodgerTheGreat 9y ago

I use k3 at work every day. It's perfectly readable to me. Every summer we spend about a week training interns with K, and they proceed to read, modify and write real production code with it during their tenure. Interns come from a mix of backgrounds- computer science, various engineering degrees, etc. This seems compelling evidence that K is learnable. If you find K unreadable, consider spending a week or two seriously working with it. You might be surprised how you feel afterwards.

sammoorhouse 9y ago
> I use k3 at work every day. It's perfectly readable to me. Right, but the one follows from the other. I'm passingly familiar with K, Q, and a+. I've worked with Borror and I kind of own an a+ compiler. I think if you define "readable" to mean "you can learn it with two weeks intensive tuition" the fine, yeah, it's readable. But to me, lightning-fast speed doesn't make up for terse-to-the-point-of-dumb syntax. +/&~&/(!1000)!/:3 5 Reads like a cruel joke to me. It's unreadable and it breaks everything we know about writing good software, and to pretend otherwise kinda comes across as macho BS. Sorry. I don't know why developers in Whitney's programming languages all have this kind of snow-blindness to the clear failings of the language. I don't know why number of characters of code is the thing we're optimising for in 2018. It's not like you're firing bytes over a 56k modem.
- kthielen 9y ago
  Hi Sam, good to run into you here! :D
- goatlover 9y ago
  Regex is the similarly terse, and many popular languages make use of it. Do you replace regex syntax with much more verbose function calls? Also, several posts above mention how the interpreter fits inside the CPU L1 cache for maximum performance. I'm guessing the terse syntax helps keep it small enough.
  - tytytytytytytyt 9y ago
    > Do you replace regex syntax with much more verbose function calls? No, but I also don't find myself wishing the entire project read like regex does. "If only our entire suite of enterprise software was made up of regexes..."
  - kthielen 9y ago
    You know what's faster than having an interpreter for your program that fits entirely in L1 cache? Not having the interpreter at all.

icen 9y ago

There's a maximum amount of stuff a single function/code unit can do before becoming unreadable. When writing code, there's a tension between the semantic size of the implementation, and the semantic size of the constituent parts of the problem: very few problems are broken down into clean chunks of code. Quite often, when trying to subjugate the problem to the language, you end up with lots of 'features' of the modular parts: lots of parameters, parameters being complex non-data objects, and so forth. Breaking stuff down costs, as well - you have to make it clear how something is going to be used. You might write a helper function for one bit in particular, and then rely on additional levels of abstraction to make it clear how this function should be used. Instead, if you can allow your functions to become semantically larger, you don't need to explain and protect your modularisation. Helper functions with one use are inlined (it's very common that these things have names longer than their definition). Instead of a large tower of abstraction, you just have two levels: the level of the data, and the level of the problem. Your entire program is written as functions, each of which does something in the problem domain, and for each, each definition is immediately clear about what it is doing with the data. There was an article here, a while ago, called 'smaller code, better code', and with accompanying comments, that explain this better than I can.

sammoorhouse 9y ago
Thanks for taking the time, it's interesting to see another perspective.