4 ms·

1000 lines of code is considered small. But check this out http://kparc.com/edit.k http://kparc.com/edit.k Under 50 lines for a text editor written in K by th

1000 lines of code is considered small. But check this out http://kparc.com/edit.k http://kparc.com/edit.k Under 50 lines for a text editor written in K by the language's author. Way beyond my present understanding, but the promise of very small, powerful code is incredibly attractive.

johnfn 10y ago
Just to be that guy. Yeah, it's cool that the language author built a text editor in under 50 lines, and there's a sort of geeky hacky appeal to trying to cram as much functionality as possible into as small a space as possible. But what does it actually mean in terms of programming? How maintainable is "small code"? How readable is it? (Well, you answered that question already.) How hackable is it? It's a curiosity, and a really fun one! But it's not practical.
- aethertron 10y ago
  Fine questions. But super-compact code could be very practical/readable/hackable, as long as there's the prerequisite knowledge. Fewer symbols means less complexity to parse. This works, provided that those symbols map to powerful operators that can be really understood and effectively combined to produce the desired outcome. And there's no need to scroll: perceive everything in one glance!
- de_Selby 10y ago
  > But what does it actually mean in terms of programming? Without trying to be too trite, what does this question mean in terms of English? > How maintainable is "small code"? Once you get the hang of it it's as maintainable as any other code base > How readable is it? (Well, you answered that question already.) There is a learning curve, but the code is actually reasonably readable. It takes time to get used to many operations occurring in one line but there are benefits (eg you can see everything that the CTRL-Z function for undo does at a glance). > How hackable is it? Again, I'm not sure what you're asking here. The editor is very bare bones so isn't a great example of production code. In a real system generally people are a bit more verbose.
- mhd 10y ago
  I wouldn't say the code is really that small in its language context, which is why comparing code by lines is inherently fallacious. It's just that a large percentage of languages are quite similar in how they're structured. Since Pascal and at least until Java/C#, most mainstream languages ended up roughly doing "one thing" per line. Quite often one function call or simple mathematical operation. Then each function or block of a larger one does one larger thing. And so forth. Code and/or languages that break that paradigm are often confusing to "switchers" and thus often abandoned or maligned way too early. But most often, they're just scanned differently. Assembly would be the opposite end. It basically takes "do one thing per line" to the extreme. But quite often, experienced asm programmers scan the program by blocks, as some patterns are quite common or you find some constant/string to attach your focus to, then continue from there into the details. Forth programmers obviously read slightly differently, due to the high level of decomposition and the stack based nature (fewer parameters). Lisp looks a bit weirder at the first glance, but I wouldn't even say that it's read all that differently from the Algol family, if written imperatively enough. Functional code, in almost any language, often has to be read differently, as a lot of things can happen in one line. APL and some DSLs (regular expressions for example) are the opposite end of the spectrum. But line length would be the wrong axis to judge things, the amount of operations isn't necessarily that much smaller. Data exchange (arrays vs. stacks vs. function parameters) is the bigger change, as is symbolic density (APL symbols vs J shorthand vs. function names vs. HiHowYouDoingIAmAnAbstractJavaBeansFactoryConsumerImplementationNiceToMeetYou)
vidarh 10y ago
It is, but the little I've seen of K implies that it's small size comes from a combination of two things: 1) A standard library / set of operators that are a very good fit for the typical domains it works on. 2) Minimizing symbol length. E.g. I translated one example I saw into Ruby, and ended up with something of similar length once I 1) implemented equivalent methods, 2) dispensed with all idioms for how to write Ruby and went for single character variable names and method names etc. In other words, there's nothing particularly "magic" there. K code gets to where it is largely by because its author and users are willing to violate every convention from other languages in terms of how to write and structure code in pursuit of a philosophy that is fundamentally different in terms of e.g. focusing more on code size. That could be a good thing, but I'm not convinced that the extremely sparse code is worth the (to me at least) extreme lack in readability. Code golf can be fun in any language, but it seems few of us have gone back to writing other code and decided it's worth aiming for code that small. In fact, I've more than once rewritten code to be longer because it made it easier to read. That said, there are good parts in terms of language constructs etc. that'd be worth learning from. If only it wasn't so incredibly annoying to decipher the code (yes, I'm sure it gets faster when you get used to it).
- jdc0589 10y ago
  > extreme lack in readability. understatement of the year.

johnfn 10y ago

Just to be that guy. Yeah, it's cool that the language author built a text editor in under 50 lines, and there's a sort of geeky hacky appeal to trying to cram as much functionality as possible into as small a space as possible. But what does it actually mean in terms of programming? How maintainable is "small code"? How readable is it? (Well, you answered that question already.) How hackable is it? It's a curiosity, and a really fun one! But it's not practical.

aethertron 10y ago
Fine questions. But super-compact code could be very practical/readable/hackable, as long as there's the prerequisite knowledge. Fewer symbols means less complexity to parse. This works, provided that those symbols map to powerful operators that can be really understood and effectively combined to produce the desired outcome. And there's no need to scroll: perceive everything in one glance!
de_Selby 10y ago
> But what does it actually mean in terms of programming? Without trying to be too trite, what does this question mean in terms of English? > How maintainable is "small code"? Once you get the hang of it it's as maintainable as any other code base > How readable is it? (Well, you answered that question already.) There is a learning curve, but the code is actually reasonably readable. It takes time to get used to many operations occurring in one line but there are benefits (eg you can see everything that the CTRL-Z function for undo does at a glance). > How hackable is it? Again, I'm not sure what you're asking here. The editor is very bare bones so isn't a great example of production code. In a real system generally people are a bit more verbose.
mhd 10y ago
I wouldn't say the code is really that small in its language context, which is why comparing code by lines is inherently fallacious. It's just that a large percentage of languages are quite similar in how they're structured. Since Pascal and at least until Java/C#, most mainstream languages ended up roughly doing "one thing" per line. Quite often one function call or simple mathematical operation. Then each function or block of a larger one does one larger thing. And so forth. Code and/or languages that break that paradigm are often confusing to "switchers" and thus often abandoned or maligned way too early. But most often, they're just scanned differently. Assembly would be the opposite end. It basically takes "do one thing per line" to the extreme. But quite often, experienced asm programmers scan the program by blocks, as some patterns are quite common or you find some constant/string to attach your focus to, then continue from there into the details. Forth programmers obviously read slightly differently, due to the high level of decomposition and the stack based nature (fewer parameters). Lisp looks a bit weirder at the first glance, but I wouldn't even say that it's read all that differently from the Algol family, if written imperatively enough. Functional code, in almost any language, often has to be read differently, as a lot of things can happen in one line. APL and some DSLs (regular expressions for example) are the opposite end of the spectrum. But line length would be the wrong axis to judge things, the amount of operations isn't necessarily that much smaller. Data exchange (arrays vs. stacks vs. function parameters) is the bigger change, as is symbolic density (APL symbols vs J shorthand vs. function names vs. HiHowYouDoingIAmAnAbstractJavaBeansFactoryConsumerImplementationNiceToMeetYou)

vidarh 10y ago

It is, but the little I've seen of K implies that it's small size comes from a combination of two things: 1) A standard library / set of operators that are a very good fit for the typical domains it works on. 2) Minimizing symbol length. E.g. I translated one example I saw into Ruby, and ended up with something of similar length once I 1) implemented equivalent methods, 2) dispensed with all idioms for how to write Ruby and went for single character variable names and method names etc. In other words, there's nothing particularly "magic" there. K code gets to where it is largely by because its author and users are willing to violate every convention from other languages in terms of how to write and structure code in pursuit of a philosophy that is fundamentally different in terms of e.g. focusing more on code size. That could be a good thing, but I'm not convinced that the extremely sparse code is worth the (to me at least) extreme lack in readability. Code golf can be fun in any language, but it seems few of us have gone back to writing other code and decided it's worth aiming for code that small. In fact, I've more than once rewritten code to be longer because it made it easier to read. That said, there are good parts in terms of language constructs etc. that'd be worth learning from. If only it wasn't so incredibly annoying to decipher the code (yes, I'm sure it gets faster when you get used to it).

jdc0589 10y ago
> extreme lack in readability. understatement of the year.