npub1fzx00c36ny4whyuhg4ykx6987wxp885fmwmc784n27qcu6pavwzs3wt6h3 (npub1fzx…t6h3) npub1jz4fkl2yy7ar6n7lxg8ahd6ydps2pwrxngsj0y8yueqv3n3rv77s7rd2ua (npub1jz4…d2ua) npub1fdcpfzaqf28emyhg7rw7wtfmy6xeqcvt5wezr6j7saeskx6zm47sqr82j5 (npub1fdc…82j5) To be honest, I'm sceptical about defining "superiority" on the set of isomorphic code representations of reasonable code.
Of course, there's the space of bad code, e.g. long hard-to-understand poorly-documented (take any) functions, spagetti code, WET, unreadable constructs such as nested ternaries, etc., etc... And better programmers sample that space less, but it's substantial, even in more minimal languages.
I.e. I doubt you can write "better" code, you can write the code that is less bad perhaps.
Conversely, I'm in love with #elisp, so I know I can write the same iteration construct with mapcar & co, cl-loop, threading macros, seq-*, dash functions, dolist, cl-do, cl-reduce & the rest of cl-*, hmm, what else... And I don't feel like I've grown much because of that 🙂
By the way, it's kinda the same with the aforementioned darkness.js, with its counless _.chain(libraries) besides the built-in loop expressions, .map / .reduce / whatever, .forEach... A Scheme with C syntax indeed.
And next to the above, there's the space of memory/compute inefficient code... From my work with students, I often find it harder to explain that this code is O(n!) while it should be O(n^2).
Besides, there are principles of single responsibility, separation of concerns, which are mostly language-independent. And architectural decisions.
...maybe I'll change something in this stream of consciousness if I manage to work in the field for the next 20 years 🤷
Pavel Korytov :emacs: /
npub15m…vgltv
2023-08-10 14:24:33
in reply to nevent1q…jf4l
Author Public Key
npub15m0adkmh73j4wymedyqpd4wduylevlpg3peqj2s8lgh64pdp2ndscvgltvPublished at
2023-08-10 14:24:33Event JSON
{
"id": "447ad53ce92c0c9a74fce94668c920eb17b5cf41ffda3dfe0789f7c9ee2e5584",
"pubkey": "a6dfd6db77f465571379690016d5cde13f967c288872092a07fa2faa85a154db",
"created_at": 1691677473,
"kind": 1,
"tags": [
[
"p",
"488cf7e23a992aeb939745496368a7f38c139e89dbb78f1eb357818e683d6385",
"wss://relay.mostr.pub"
],
[
"p",
"90aa9b7d4427ba3d4fdf320fdbb7446860a0b8669a212790e4e640c8ce2367bd",
"wss://relay.mostr.pub"
],
[
"p",
"4b70148ba04a8f9d92e8f0dde72d3b268d90618ba3b221ea5e87730b1b42dd7d",
"wss://relay.mostr.pub"
],
[
"p",
"584b9282fbc3d56bde321066766c0ebca3c5508e8d1596a8c7f0a15ca830571c",
"wss://relay.mostr.pub"
],
[
"p",
"f320bdda416aa99f2ae0949dca56c3bf58a9815c9de7ba950ad1fa568da2b816",
"wss://relay.mostr.pub"
],
[
"p",
"412c4375e9a64ba0e7f9cc6016b0d7caca37f73623e8d4fcbd0cbbfab89b8d74",
"wss://relay.mostr.pub"
],
[
"e",
"4f1f7be595bc78a430d770f3210359b4487b17e922a608a21d0b373dac320277",
"wss://relay.mostr.pub",
"reply"
],
[
"t",
"elisp"
],
[
"proxy",
"https://emacs.ch/users/sqrtminusone/statuses/110865774926397158",
"activitypub"
]
],
"content": "nostr:npub1fzx00c36ny4whyuhg4ykx6987wxp885fmwmc784n27qcu6pavwzs3wt6h3 nostr:npub1jz4fkl2yy7ar6n7lxg8ahd6ydps2pwrxngsj0y8yueqv3n3rv77s7rd2ua nostr:npub1fdcpfzaqf28emyhg7rw7wtfmy6xeqcvt5wezr6j7saeskx6zm47sqr82j5 To be honest, I'm sceptical about defining \"superiority\" on the set of isomorphic code representations of reasonable code.\n\nOf course, there's the space of bad code, e.g. long hard-to-understand poorly-documented (take any) functions, spagetti code, WET, unreadable constructs such as nested ternaries, etc., etc... And better programmers sample that space less, but it's substantial, even in more minimal languages.\n\nI.e. I doubt you can write \"better\" code, you can write the code that is less bad perhaps.\n\nConversely, I'm in love with #elisp, so I know I can write the same iteration construct with mapcar \u0026 co, cl-loop, threading macros, seq-*, dash functions, dolist, cl-do, cl-reduce \u0026 the rest of cl-*, hmm, what else... And I don't feel like I've grown much because of that 🙂\n\nBy the way, it's kinda the same with the aforementioned darkness.js, with its counless _.chain(libraries) besides the built-in loop expressions, .map / .reduce / whatever, .forEach... A Scheme with C syntax indeed.\n\nAnd next to the above, there's the space of memory/compute inefficient code... From my work with students, I often find it harder to explain that this code is O(n!) while it should be O(n^2).\n\nBesides, there are principles of single responsibility, separation of concerns, which are mostly language-independent. And architectural decisions.\n\n...maybe I'll change something in this stream of consciousness if I manage to work in the field for the next 20 years 🤷",
"sig": "682c43dc8f2774f82087626d2f40a3e4904437dbdc412927867a16c349a41fe58b7123b9bb64c1b7bc9ed94bf9f3e03d7f0a9df132f73b77ba152c50b6d0a6c6"
}