mleku on Nostr: functional languages achieve much of this at the expense of massive amounts of memory ...
functional languages achieve much of this at the expense of massive amounts of memory copying, and if you add concurrency to the features, because there is good reasons to, you wind up with a problem that most of the time you should be using pointers and mutexes
and this doubly applies to the compiler itself, as with most languages, the compiler is written in the language itself, via a "bootstrap" method, i have seen haskell compilations OOM kill almost as often as i've seen badly written C++
compilation requires the use of massive tree structures and this combined with a pass by value policy leads to a LOT of garbage
and no, being a good programmer is only part of the story... if we were talking about carpentry, would you agree that frilly decorative crochet pieces around the tools are going to not impede with the work at hand?
that's how i see most of the languages...
i read python, so much repetition, such a poor visual impact of the general pattern of syntax
java, so many ridiculously long names and multi-hop paths due to the OOP... and C++ and javascript both also suffer from this extremely noisy visual aspect
in Go, you can often spot a bug just by that first momentary glance by the shape of the code
it is often tempting to forget to obey one of the first laws of go: fail fast - handle the error case before you handle success, and it always bites you on the arse, and this is an example of something that can be recognised instantly at a glance by the underscore where the programmer is pretending teh error case does not matter
it almost always matters, except in a few rare cases like running out of entropy
and yes, there is several critical parts of the Go standard library that push noisy, stuttering things on you like the context library, which is used to enable clean shutdown and timeouts of threads... not saying it's perfect, just that if you follow the rules in your code you less often have to go back and debug later on when things start going wrong
Published at
2024-04-03 13:05:22Event JSON
{
"id": "868fdffcb00797e56c268bccfd73388c98875c28412f2a60b9bd497ce7c48a87",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1712149522,
"kind": 1,
"tags": [
[
"e",
"92c370b9225a5ae09e830ced6784703a5927c57a8e28a5b3ca15c13fc70b7316",
"wss://nostr.oxtr.dev/",
"root"
],
[
"e",
"2e2d00d1868555d8c6fa594b307616068d3ac45d395c9720eebff3998ea4943e",
"wss://nostr.oxtr.dev/",
"reply"
],
[
"p",
"f72e682e90cea98c66f57f69546d6350836cde78f5b8a0262767aaf6c51af867",
"",
"mention"
]
],
"content": "functional languages achieve much of this at the expense of massive amounts of memory copying, and if you add concurrency to the features, because there is good reasons to, you wind up with a problem that most of the time you should be using pointers and mutexes\n\nand this doubly applies to the compiler itself, as with most languages, the compiler is written in the language itself, via a \"bootstrap\" method, i have seen haskell compilations OOM kill almost as often as i've seen badly written C++\n\ncompilation requires the use of massive tree structures and this combined with a pass by value policy leads to a LOT of garbage\n\nand no, being a good programmer is only part of the story... if we were talking about carpentry, would you agree that frilly decorative crochet pieces around the tools are going to not impede with the work at hand?\n\nthat's how i see most of the languages... \n\ni read python, so much repetition, such a poor visual impact of the general pattern of syntax\n\njava, so many ridiculously long names and multi-hop paths due to the OOP... and C++ and javascript both also suffer from this extremely noisy visual aspect\n\nin Go, you can often spot a bug just by that first momentary glance by the shape of the code\n\nit is often tempting to forget to obey one of the first laws of go: fail fast - handle the error case before you handle success, and it always bites you on the arse, and this is an example of something that can be recognised instantly at a glance by the underscore where the programmer is pretending teh error case does not matter\n\nit almost always matters, except in a few rare cases like running out of entropy\n\nand yes, there is several critical parts of the Go standard library that push noisy, stuttering things on you like the context library, which is used to enable clean shutdown and timeouts of threads... not saying it's perfect, just that if you follow the rules in your code you less often have to go back and debug later on when things start going wrong",
"sig": "e6ee692c981244765988c822fd1a7779add63c59b9a03562c02d2a79db3b3a644834b092db9b6f660023bcfd8ccf4e6802b08f383f2710a9e54cb1032f9c9461"
}