|
Treating enums as integral values means some rear end in a top hat is going to do cutesy integer arithmetic on it or that you'll have to consider cases where you get an integral value that doesn't map to the assigned enum integral values. Treating bools as integral values means you'll accidentally coerce numerical values into a bool and vice versa and cause a bunch of cool bugs and make reading code harder. People will also constantly forget that negative integral values exist and what they should coerce to.
|
# ? Oct 23, 2015 06:21 |
|
|
# ? May 27, 2024 02:44 |
|
TheresaJayne posted:i can't stand emacs, pre:When I log into my Xenix system with my 110 baud teletype, both vi *and* Emacs are just too drat slow. They print useless messages like, 'C-h for help' and '"foo" File is read only'. So I use the editor that doesn't waste my VALUABLE time. Ed, man! !man ed ED(1) UNIX Programmer's Manual ED(1) NAME ed - text editor SYNOPSIS ed [ - ] [ -x ] [ name ] DESCRIPTION Ed is the standard text editor. --- Computer Scientists love ed, not just because it comes first alphabetically, but because it's the standard. Everyone else loves ed because it's ED! "Ed is the standard text editor." And ed doesn't waste space on my Timex Sinclair. Just look: -rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed -rwxr-xr-t 4 root 1310720 Jan 1 1970 /usr/ucb/vi -rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs Of course, on the system *I* administrate, vi is symlinked to ed. Emacs has been replaced by a shell script which 1) Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk quota by 100K; and 3) RUNS ED!!!!!! "Ed is the standard text editor." Let's look at a typical novice's session with the mighty ed: golem> ed ? help ? ? ? quit ? exit ? bye ? hello? ? eat flaming death ? ^C ? ^C ? ^D ? --- Note the consistent user interface and error reportage. Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity. "Ed is the standard text editor." Ed, the greatest WYGIWYG editor of all. ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN SHINE AND THE BIRDS SING AND THE GRASS GREEN!! When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!! TEXT EDITOR. When IBM, in its ever-present omnipotence, needed to base their "edlin" on a UNIX standard, did they mimic vi? No. Emacs? Surely you jest. They chose the most karmic editor of all. The standard. Ed is for those who can *remember* what they are working on. If you are an idiot, you should use Emacs. If you are an Emacs, you should not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!! ?
|
# ? Oct 23, 2015 06:28 |
|
comedyblissoption posted:Treating enums as integral values means some rear end in a top hat is going to do cutesy integer arithmetic on it or that you'll have to consider cases where you get an integral value that doesn't map to the assigned enum integral values. Or worse, you could be working with someone who thinks flag enums are really cool and not an abomination
|
# ? Oct 23, 2015 08:18 |
|
ok, i'll bite: what's wrong with flag enums?
|
# ? Oct 23, 2015 09:06 |
|
Harik posted:A few different horrors at work - first, the meticulous comment documentation for a magic hex number instead of spending that time turning it into #defines Why would you turn it into a #define rather than a const variable?
|
# ? Oct 23, 2015 09:36 |
|
Suspicious Dish posted:ok, i'll bite: what's wrong with flag enums? If you're not at the optimisation level where you care about saving bits - you aren't, especially if we're talking about c# - then a struct of bools is better and safer in every single way. It explicitly states its nature and its functioning, it's impossible to define it or operate on it in a broken way, its usage is far more readable, and it's trivial to extend it when necessary (for example, if one of the flags needs to allow for a third value). Flag enums are a clever efficiency hack, which are the three most damning words I know to describe a programming construct.
|
# ? Oct 23, 2015 12:51 |
|
Hammerite posted:Why would you turn it into a #define rather than a const variable? In C, const means read-only but not constant - it could be modeling a value in memory which does change, so subsequent reads could return different values. You just can't write to it. Since it's just a variable you still get all the normal variable things like storage allocation. #define is the way to form constant literal values. e: unless you want to use C enums but since we're at the moment arguing about how int-enums are literally Satan it seems in poor taste csammis fucked around with this message at 13:39 on Oct 23, 2015 |
# ? Oct 23, 2015 13:36 |
|
If you ever use C# in something like a manufacturing fixture configuring a device EEPROMs, or reading various wire formats, and so on you will find it's often more sensible to work with data in situ packed however the guy on the "other end of the line" packed it rather than unpacking/serializing it, working on it and then repacking/deserializing it. In these cases boolean flags packed into integer types and bitfields and whatnot are something you just have to deal with, and enums are C#'s cleanest way to deal with them. (If you decide to serialize/deserialize it doesn't get around this problem, of course, it just means you get to do it twice instead of once).
|
# ? Oct 23, 2015 13:56 |
|
Suspicious Dish posted:ok, i'll bite: what's wrong with flag enums?
|
# ? Oct 23, 2015 14:12 |
|
Building flags out of something with unknown width makes me uncomfortable too, for some reason.
|
# ? Oct 23, 2015 14:51 |
|
Blotto Skorzany posted:If you ever use C# in something like a manufacturing fixture configuring a device EEPROMs, or reading various wire formats, and so on you will find it's often more sensible to work with data in situ packed however the guy on the "other end of the line" packed it rather than unpacking/serializing it, working on it and then repacking/deserializing it. In these cases boolean flags packed into integer types and bitfields and whatnot are something you just have to deal with, and enums are C#'s cleanest way to deal with them. (If you decide to serialize/deserialize it doesn't get around this problem, of course, it just means you get to do it twice instead of once). Enumerations for extracting bits are not any cleaner than the above and give you essentially nothing. The only thing C-like enumerations buy you is being able to leverage familiarity with C-isms. Restricting enumerations to not be any arbitrary integer is a much more useful property than familiarity with C-idioms. Hell, it could even make the act of extracting bits into enums safer, because now the enums are guaranteed to make sense instead of be allowed to be any arbitrary integer. comedyblissoption fucked around with this message at 15:19 on Oct 23, 2015 |
# ? Oct 23, 2015 15:15 |
|
The library would probably do things like let you give it a map between enums and integral constants. The one disadvantage of this approach is the language designers will probably not guarantee the correctness of your map statically and the library author will dynamically verify the correctness of your map. This allows you to have C-like bitfields while preserving the sanity of what enumerations really should be. It could be argued that enumerations really want to be sum types and what we really need is algebraic data types, though.
|
# ? Oct 23, 2015 15:24 |
|
comedyblissoption posted:In a sanelang this should be represented by operations on bitfields and defined integral constants, because this is literally what the data and operations are. Someone could probably write a standard library API for this specific purpose.
|
# ? Oct 23, 2015 15:48 |
|
Dessert Rose posted:so, on april fools, emacs users can actually use emacs? That should have been == I typed it from memory. I couldn't remember if I did "!= ||" or "== &&" and I conflated the two. Marta Velasquez fucked around with this message at 16:57 on Oct 23, 2015 |
# ? Oct 23, 2015 16:55 |
|
NihilCredo posted:If you're not at the optimisation level where you care about saving bits - you aren't, especially if we're talking about c# - then a struct of bools is better and safer in every single way. It explicitly states its nature and its functioning, it's impossible to define it or operate on it in a broken way, its usage is far more readable, and it's trivial to extend it when necessary (for example, if one of the flags needs to allow for a third value). I mostly write C code, where the alternative is: C++ code:
C++ code:
|
# ? Oct 23, 2015 17:23 |
|
I like gedit.
|
# ? Oct 23, 2015 17:24 |
|
Also, you would probably hate me for writing code that looks like this in java script:JavaScript code:
|
# ? Oct 23, 2015 17:29 |
|
LeftistMuslimObama posted:When you get right down to it, no matter how you represent it it's going to have some consistent integer value underneath, even if you go to pains for it to be inaccessible. Even ruby gets this right (they are not integers at any point): "The global value true is the only instance of class TrueClass and represents a logically true value in boolean expressions. The class provides operators allowing true to be used in logical expressions."
|
# ? Oct 23, 2015 17:41 |
|
Suspicious Dish posted:I mostly write C code, where the alternative is: c99 supremacy? C++ code:
|
# ? Oct 23, 2015 18:03 |
|
I thought you had to do: thing(foo, bar, (struct options) { ... }); I didn't think it worked without the cast there, because the compound literal syntax includes the cast. Maybe it's a gcc extension?
|
# ? Oct 23, 2015 18:09 |
|
I'm doing a code review on some SQL statements and there were some legacy statements that had a static final constant named COMMA instead of just ", " and it is ugly as gently caress to read. I'm glad this programmer refactored them while he was in there.
|
# ? Oct 23, 2015 18:25 |
|
Suspicious Dish posted:I didn't think it worked without the cast there, because the compound literal syntax includes the cast. Maybe it's a gcc extension?
|
# ? Oct 23, 2015 18:36 |
|
so there was some legacy code written in 2004 when everyone thought that a string deserved to be a static constant. the company's dynamic sql building code used to be a nightmare. each word had its own string and that was chained together with a ton of string concatenation. no prepared statements, just plain text and apostrophes.
lord of the files fucked around with this message at 18:54 on Oct 23, 2015 |
# ? Oct 23, 2015 18:46 |
|
Using bit-fields instead of flag masks is conceptually nicer and definitely gives you prettier code, but (1) they don't always perform as well for subtle reasons, even on modern compilers, and (2) please please please do not use them as part of a binary serialization format.
|
# ? Oct 23, 2015 19:05 |
|
I recently was looking through a debug dump of the onboard nonvolatile memory of a product that I worked on a couple of years ago. When I picked the format for it, I mostly picked constants for uninitialized fields that would stand out in a hex dump: And that's all well and good. However, this was a very frustrating project to work on for a number of reasons, and at one point I really doubted whether people were even reading the specs for various subsystems that I was sending them and asking them to review and check for errors. So when I got to the end of the hex dump, I was reminded of one of the ways I checked whether anybody bothered to read things: It brought warmth to my heart. I am the horror.
|
# ? Oct 23, 2015 19:17 |
|
Blotto Skorzany posted:I recently was looking through a debug dump of the onboard nonvolatile memory of a product that I worked on a couple of years ago. When I picked the format for it, I mostly picked constants for uninitialized fields that would stand out in a hex dump: Why are all the fives circled?
|
# ? Oct 23, 2015 19:20 |
|
As usual for enum-related things, Java gets it more right than most mainstream languages: an EnumSet is strongly typed and behaves like a set, not an integer, but internally it can use bit flags to keep things efficient too.
|
# ? Oct 23, 2015 19:23 |
|
sarehu posted:Why are all the fives circled? Hexplorer's default font
|
# ? Oct 23, 2015 19:35 |
Managers are going to be piloting a new bit of software called HP Agile Manager as a potential replacement for JIRA. Anyone have insight into whether this will be good/bad/horrible for all involved?
|
|
# ? Oct 23, 2015 20:46 |
|
It's from HP and has Agile in the same, so pretty safe to assume it's horrible.
|
# ? Oct 23, 2015 20:47 |
Plorkyeran posted:It's from HP and has Agile in the same, so pretty safe to assume it's horrible. That was my first thought I fear that people here are secretly, unironically using the term "agilefall" in planning meetings
|
|
# ? Oct 23, 2015 21:03 |
|
ChickenWing posted:That was my first thought wagile
|
# ? Oct 24, 2015 00:56 |
|
ChickenWing posted:Managers are going to be piloting a new bit of software called HP Agile Manager as a potential replacement for JIRA. Anyone have insight into whether this will be good/bad/horrible for all involved? It's actual triple word score because of "manager" which is about as descriptive as "program" in terms of telling what something does. HP is like the least "Agile" company in the history of the world - it is a really big offender in the "writing software that no one in their right mind would buy" category of enterprise software (e.g. QTP.) Having HP write agile tools is like inviting Hitler to be a rabbi at a bar mitsvah.
|
# ? Oct 24, 2015 13:59 |
|
Bruegels Fuckbooks posted:which is about as descriptive as "program" in terms of telling what something does. Um, it's a spell that appeases the machine spirits? I thought we were all programmers here.
|
# ? Oct 24, 2015 17:28 |
|
Munkeymon posted:Basically I'm wondering what we'd have to deal with if the entire computing revolution came from the Arabic-speaking world. I'm guessing there'd be an ASCII-alike where some character range was supposed to print one way and some the other and software was just expected to deal with it. Oh and since this is an alternate reality where IBM is based in Qatar, everyone has to deal with this encoding as the foundation of Unicode, including the implicit direction changes. Also porn filters have become strong AI. This reminds me of a real life standards horror - ASMO 449 (thankfully superseded by ASMO 449+). Somebody had the genius idea of trying to fit both Arabic and Latin characters into a 7-bit encoding, in such a way that the arabic characters superimpose over the ASCII latin character space. The general idea is that by default a text string is displayed as arabic, with the exception of sequences delimited by '[' and '}' which would be interpreted as latin. I had the pleasure of being introduced to this when visiting a potential customer in Egypt back in the early 2000s. The system comprised several million lines of code, and gigabytes worth of pre-existing database data. They wanted to modernize, which meant converting it all to ASMO 708 at the very least. Unfortunately a lot of the meta-characters were broken over multiple strings (both in the code and in the database), so there was no viable means of automating the conversion.
|
# ? Oct 25, 2015 12:46 |
|
No indentation has been lost in the following code block:code:
|
# ? Oct 26, 2015 10:50 |
|
porkfactor posted:This reminds me of a real life standards horror - ASMO 449 (thankfully superseded by ASMO 449+). Somebody had the genius idea of trying to fit both Arabic and Latin characters into a 7-bit encoding, in such a way that the arabic characters superimpose over the ASCII latin character space. The general idea is that by default a text string is displayed as arabic, with the exception of sequences delimited by '[' and '}' which would be interpreted as latin. Yeah, that's what I'm talking about
|
# ? Oct 26, 2015 15:23 |
|
My program is using a persistent ActiveMQ JMS queue: 1. Item (a batch job) is enqueued in ActiveMQ 2. ActiveMQ saves the item to disk 3. Eventually we take the item out of the queue and process it, using a JMS transaction (so the item is flagged so that nobody else can take it from the queue, but it's still on disk) 4. If nothing goes wrong then we commit the JMS transaction and delete the item from the queue/disk, if the server crashes in the meantime then the item will still be on the queue when the server restarts My co-worker wants to "optimize" this 1. Item is enqueued in ActiveMQ using a JMS transaction; we don't commit this transaction 2. Eventually we take the item out of the queue and process it using the same JMS transaction that we used to enqueue the item 3. If nothing goes wrong then we commit the JMS transaction which doesn't make any changes to the queue, if the server crashes in the meantime then the item is gone forever because we never committed the transaction that sends the item to ActiveMQ This way everything runs faster because we're not doing disk IO! He insists that this will still behave like a persistent queue (I'm trying to convince him that this is wrong) - I'm not sure how we can have a persistent queue without doing disk IO, but there you go.
|
# ? Oct 26, 2015 15:35 |
|
It's ActiveMQ I don't think performance is high on your priority list already?
|
# ? Oct 26, 2015 16:18 |
|
|
# ? May 27, 2024 02:44 |
|
Nope, queueing accounts for a piddly fraction of execution time - the whole point of using a JMS queue is for persistence / fault tolerance, otherwise I'd be using a ConcurrentLinkedQueue.
|
# ? Oct 26, 2015 16:20 |