3 ms·

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

by 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)

by johnfn 10y ago

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)