|
eschaton posted:code is read far more than it’s written so it’s good and proper to be as verbose and explicit as possible, with a minimum of memorization required on the part of the reader I like short names precisely because it is easier when reading the code (when you can remember what the names mean). I think my brain ends up doing more symbol/image recognition and less conscious reading when processing terse code. For various other reasons I don't like going all the way to APL (mostly because you cannot add abstractions to APL without losing this advantage), but consistent terseness can made code read much more like a precise formula than some lumbering essay. Edit: but let me repeat this is mostly for frequently used building block functions and such. I'm fine with giving long and clumsy names to exotic functions that are almost never called. Perl for example gets this completely backwards by having single-symbol global variables that change subtle things about the language and runtime system.
|
#
?
Jul 8, 2020 11:59
|
|
|
|
| # ? Jun 1, 2024 22:58 |
|
|
fart simpson posted:i think this is what rust does? yes rust uses i32, f64, etc those are too terse to be readable though, they should be ThirtyTwoBitTwosComplementSignedInteger and InstituteOfElectricalAndElectronicsEngineersDoublePrecisionFloatingPoint instead
|
|
#
?
Jul 8, 2020 13:38
|
|
|
i actually like most of modern javascript's syntax but i absolutely hate the naming of standard global objects stringify? globalThis? array push and pop instead of add/remove? no thanks
|
|
#
?
Jul 8, 2020 14:29
|
|
|
the push/pop thing is because js is actually heavily influenced by perl. see also use strict
|
|
#
?
Jul 8, 2020 14:31
|
|
|
RPATDO_LAMD posted:there are so many std library types that are as short as possible at the expense of readability rust used to have a rule where no keyword or std type should have a name longer than 5 letters, so you had ret for return and loop instead of continue (and even sillier stuff like iface instead of trait). they got rid of that ages ago but it still lingers in places the whole String/str split is one of many things about rust that hasn't really hindered me in large projects but it makes whiteboard-tier toy programs more annoying than they should be
|
|
#
?
Jul 8, 2020 14:38
|
|
|
long names suck tbh
|
|
#
?
Jul 8, 2020 15:10
|
|
|
Bloody posted:long names suck tbh yeah sometimes, but then, well, let me quote from the code I'm rewriting right now: e: actually in retrospect copyright compliance etc, etc, let's just say there's a lot of two- and three-letter non-local variables which is to say, I'd rather deal with an extra word in a symbol than try to figure out what nhr, ndr and ndx are (and no it's not "number", it's new header row, new dictionary row and new dictionary row x offset) and what the compounded ternary does with them Private Speech fucked around with this message at 16:17 on Jul 8, 2020 |
|
#
?
Jul 8, 2020 15:46
|
|
|
code:
|
|
#
?
Jul 8, 2020 17:00
|
|
|
it's not enjoyable having to check docs constantly to see what names mean. if you memorize them, that works. if a longer name adds hints, that works too if long names offend your column limit or whatever, you might consider adapting your style and editor for the code at hand! weird!
|
|
#
?
Jul 8, 2020 17:45
|
|
|
oh, yeah, docs could use some of those I do have doxygen set up but I don't really have time for it right now
|
|
#
?
Jul 8, 2020 17:50
|
|
|
tinaun posted:rust used to have a rule where no keyword or std type should have a name longer than 5 letters, so you had ret for return and loop instead of continue (and even sillier stuff like iface instead of trait). they got rid of that ages ago but it still lingers in places They also has "cont" instead of "continue" until someone pointed out they were uncomfortable saying that our loud, or something.
|
|
#
?
Jul 8, 2020 18:01
|
|
|
fart simpson posted:yeah and i hate when people use the + operator instead of the add function quote:+ aNumber
|
|
#
?
Jul 8, 2020 20:18
|
|
|
smalltalk has operators but no concept of precedence so x * x + y * y actually computes ((x * x) + y) * y eschaton and a bunch of other lisp idiots will fervently defend this, of course like check out this scintillating conversation between programming's greatest lights
|
|
#
?
Jul 8, 2020 20:36
|
|
|
actually it's basically fine in a language like lisp or forth where you can't write things in infix style to begin with so there's no confusion. i mean i don't like it, i find that the infix syntax promotes much more readable code (although of course you can abuse it to make code that's completely unapproachable by novices), but it's not actively problematic smalltalk's choice is an attractive nuisance: it lets you write things that look right and have a standard interpretation and then gives them a non-standard interpretation that breaks them. this is unavoidable in languages with infix, which is why they all have precedence except for a few exceptions written by idiots
|
|
#
?
Jul 8, 2020 20:46
|
|
|
I would have agreed with you in the past but then I did some q and having line order precedence is actually pretty nice
|
|
#
?
Jul 8, 2020 20:46
|
|
|
repiv posted:yes rust uses i32, f64, etc c also has this, although not for floats for reasons
|
|
#
?
Jul 8, 2020 21:24
|
|
|
I wouldn't have minded if RPN arithmetic became the standard for programming languages and persisted through inertia but that's not the world we ended up in today. There's a case to be made for matching scientific and engineering notation conventions with hundreds of years of history behind them, sure, but if you go too far down that tradition rabbit hole you end up with crap like 4GLs and SQL.
|
|
#
?
Jul 8, 2020 21:38
|
|
|
it is one of those things you learn in no time, so it is kind of whatever. otoh ruby just added operator precedence to smalltalk and it worked out just fine (in that regard at least).
|
|
#
?
Jul 8, 2020 22:08
|
|
|
there is basically no good reason not to do precedence if you're doing infix operators, it is dead simple to implement and it means you interpret simple expressions the way people expect them to be interpreted instead of leaving a weird gotcha for when someone finally uses a numeric formula for the first time the problem i see is that languages often do precedence and then think they have to have precedence relationships for everything. if there isn't an obvious ordering between two operators, it's okay to leave them unordered and make using them in adjacent positions an error
|
|
#
?
Jul 8, 2020 22:15
|
|
|
NihilCredo posted:you might like https://verbalexpressions.github.io/ thanks, this is kinda great!
|
|
#
?
Jul 8, 2020 22:21
|
|
|
rjmccall posted:there is basically no good reason not to do precedence if you're doing infix operators, it is dead simple to implement and it means you interpret simple expressions the way people expect them to be interpreted instead of leaving a weird gotcha for when someone finally uses a numeric formula for the first time i was going to ask this. are there any languages that accept traditional notation but refuse to mix it with non-traditional operators? like you can use regular arithmetic operators with "normal" bimdas precedence but it just refuses to allow bit shifting or pre/post increment or any custom operators in the same expression
|
|
#
?
Jul 8, 2020 22:22
|
|
|
i don't know any. swift's precedence system is capable of expressing that, and new operators by default don't associate with anything (including themselves) except for parsing tighter than assignment. but when we added that whole system, we just took the existing numeric operator precedences and preserved their effect in the new system, which was really a missed opportunity. we did fix some of c's precedences but overall too many things still have precedence relationships, they're just better precedence relationships
|
|
#
?
Jul 8, 2020 22:40
|
|
|
psiox posted:thanks, this is kinda great! actually it’s worthless trash. the reason regexes can become unreadable is nothing to do with syntax so changing the syntax is only going to be a negative: it won’t make things any better so you’re just using something nonstandard for no good reason. know what makes code hard to read? doing that.
|
|
#
?
Jul 9, 2020 00:04
|
|
|
just use a parser generator if you need parsing code to be readable imo
|
|
#
?
Jul 9, 2020 00:10
|
|
|
pokeyman posted:if long names offend your column limit or whatever, you might consider adapting your style and editor for the code at hand! weird! and also for the 80s, when UIs that supported scrolling became commonplace 80-column limits are bullshit and I say this as a person who has many character terminals and even a teletype
|
|
#
?
Jul 9, 2020 06:23
|
|
|
Destroyenator posted:i actually went to check the smalltalk docs to see if they had something fun but apparently you can pass a message called + classical Smalltalk does indeed have a small number of single-character one-argument method names, representing the most common arithmetic operations; some modern Smalltalks add a small number of multi-character method names sans colon too, typically those from C this may have actually been a mistake that’s led to bugs, since it does not have mathematical operator precedence: code:and of course the Smalltalk dialects that have added the C operators also just evaluate left-to-right, because they’re Smalltalk other than pretty much this single wart, the Smalltalk grammar is extremely simple, to a similar degree as Lisp, and it’s very nice to construct a system within
|
|
#
?
Jul 9, 2020 06:31
|
|
|
rjmccall posted:smalltalk has operators but no concept of precedence so x * x + y * y actually computes ((x * x) + y) * y actually I wouldn’t defend Smalltalk on this front, I think it misleads people and add: might have been better Lisp doesn’t have the same degree of ambiguity, though it has its own kind what with selective evaluation in special forms and the ability to create new ones with macro
|
|
#
?
Jul 9, 2020 07:21
|
|
|
people are talking about more seriously bringing rust into the Linux kernel. there's going to be so much graybeard whining
|
|
#
?
Jul 11, 2020 21:11
|
|
|
why?
|
|
#
?
Jul 11, 2020 21:19
|
|
|
animist posted:people are talking about more seriously bringing rust into the Linux kernel. there's going to be so much graybeard whining i'll believe it when "people" includes linus torvalds
|
|
#
?
Jul 11, 2020 21:20
|
|
|
Linus seems down with it, or at least resigned to it. https://lkml.org/lkml/2020/7/10/1261 https://thenewstack.io/linus-torvalds-on-diversity-longevity-rust-and-arm-chips/
|
|
#
?
Jul 11, 2020 21:36
|
|
|
They say a picture is worth a thousand words.
|
|
#
?
Jul 11, 2020 21:53
|
|
|
they will whine with or without rust
|
|
#
?
Jul 11, 2020 22:01
|
|
|
I'll be interested to see what bright line makes C++ unacceptable but Rust acceptable. C has seen a great many  REVOLUTIONARY NEW PARADIGM languages come and go over the years. You would probably need 1TB of RAM and some very high single-threaded performance indeed to compile a hypothetical Rust-ified Linux kernel in any reasonable amount of time, which is certainly not a point in favor of its adoption.
Sapozhnik fucked around with this message at 00:15 on Jul 12, 2020 |
|
#
?
Jul 12, 2020 00:13
|
|
|
i guess c++ is the best things can ever get
|
|
#
?
Jul 12, 2020 00:22
|
|
|
Sapozhnik posted:C has seen a great many fwiw this is the justification a prev workplace gave for using a Delphi from 1999 and INTERBASE in 2015, and I think also for not using version control
|
|
#
?
Jul 12, 2020 00:23
|
|
|
Vanadium posted:fwiw this is the justification a prev workplace gave for using a Delphi from 1999 and INTERBASE in 2015, and I think also for not using version control eh, could be worse, they could be using perforce
|
|
#
?
Jul 12, 2020 07:48
|
|
|
Vanadium posted:fwiw this is the justification a prev workplace gave for using a Delphi from 1999 and INTERBASE in 2015, which, if it did the thing it what supposed to and let people clock out at four, is a fine argument. Vanadium posted:and I think also for not using version control which is not.
|
|
#
?
Jul 12, 2020 10:35
|
|
|
Sapozhnik posted:I'll be interested to see what bright line makes C++ unacceptable but Rust acceptable. by the time you stripped everything not suitable for a kernel environment out of c++, you'd basically just be left with c with basic classes, and even then there would be restrictions (e.g. no allocating in constructors)
|
|
#
?
Jul 12, 2020 15:49
|
|
|
|
| # ? Jun 1, 2024 22:58 |
|
|
I mean you *can* write a kernel in Java or whatever it's just a terrible idea
|
|
#
?
Jul 12, 2020 16:04
|
|