Post AcWrCACsS7pX3XDMEy by galdor@emacs.ch
(DIR) More posts by galdor@emacs.ch
(DIR) Post #AcWrCACsS7pX3XDMEy by galdor@emacs.ch
2023-12-06T09:49:24Z
0 likes, 0 repeats
I stop counting the number of time I've been stuck with an horrible workaround because a developer chose not to export a function or type from their Go package. #CommonLisp got it right, a language should never stop you from accessing everything.
(DIR) Post #AcWrsoXAuH5KI92txQ by hajovonta@mastodon.online
2023-12-06T09:57:06Z
0 likes, 0 repeats
@galdor I sometimes read this opinion from senior developers that "the language enforces this or that". I think it comes with large codebases where many people are forced to work together on the same code and they can't or don't bother with proper code review processes. Just want to offload this burden to "the language".This brings you to your life choice as well, namely, to write anything in Go. But I guess it's a result of a tradeoff.
(DIR) Post #AcWsIT9n0citWLLBtQ by galdor@emacs.ch
2023-12-06T10:01:45Z
0 likes, 0 repeats
@hajovonta Everything is a tradeoff :) And selling Go to companies for commercial development is a thousand time easier than even just using the word "Lisp" in a conversation (or even "Erlang").
(DIR) Post #AcWxPLW4JZqzcarOAS by eshel@emacs.ch
2023-12-06T10:59:00Z
0 likes, 0 repeats
@galdor I kinda agree, but note that the ability to fullyconceal some definitions opens the door for optimizations that youwouldn't get otherwise, and there's power in that.So should a language stop you from concealing stuff when you really want to?
(DIR) Post #AcWzapLtvQqzFYhsX2 by galdor@emacs.ch
2023-12-06T11:23:30Z
0 likes, 0 repeats
@eshel What kind of optimizations do you have in mind?
(DIR) Post #AcX0ZHPiiou9elJqq0 by eshel@emacs.ch
2023-12-06T11:34:26Z
0 likes, 0 repeats
@galdor Inlining of the concealed definitions, and subsequentspecializations. Of course you can do that and keep the non-inlineddefinition around, and expose that, but then you're left with a(often) redundantly increased memory footprint.
(DIR) Post #AcX1Zg11Lz2VuYWFzU by galdor@emacs.ch
2023-12-06T11:45:43Z
0 likes, 0 repeats
@eshel You actually inline functions for specific function calls; nothing is stopping compilers to include the function in the library.And yes, it uses memory, but nothing compared to the extra memory consumed to copy this function code at each inline called.And of course there's no real memory cost of exporting a type.It is as always about control, with developer feeling that they have to stop others to use specific constructs because they believe they know what's good for them (they do not).
(DIR) Post #AcX2ZFsAeSY6mjk6Ge by eshel@emacs.ch
2023-12-06T11:56:50Z
0 likes, 0 repeats
@galdor"yes, it uses memory, but nothing compared to the extra memoryconsumed to copy this function code at each inline called."Well, not necessarily, sometimes you have only a few relevant callsites, and you can specialize each of them so the memory footprint isactually reduced. But I agree with you that..."It is as always about control, with developer feeling that they haveto stop others to use specific constructs."So it's really a social problem, more than a technical one. My pointis basically that there's nothing wrong with a language allowing youto conceal stuff, since in some (admittedly niche) cases that's a goodthing to do. The problem is with people leveraging this mechanism ininappropriate circumstances.
(DIR) Post #AcXRyO23wv8WBXRx0y by aerique@genart.social
2023-12-06T16:41:29Z
0 likes, 0 repeats
@galdor Yes, most languages put the burden on the developer.
(DIR) Post #AcXSRK4DlqpIHkG0Rs by veer66@social.vivaldi.net
2023-12-06T16:46:43Z
0 likes, 0 repeats
@galdor I like ::, but I took so much time to learn about it.