LOL not a "festering" issue, just a regrettable design decision clearly motivated by OCD ;)

I never, ever implied that JSON didn't need a parser, even in
Javascript.

Right, but the conversation as a whole hasn't made sense. People comparing Python serialization (with JSON as the definitive example, even though JSON came out of Javascript) to Java serialization. Even though there's no direct comparison I'm aware of. And so on.

LOL not a "festering" issue, just a regrettable design decision
clearly motivated by OCD ;)

I remain on the fence with regard to that topic. On one hand, as a dyed-in-the-wool C programmer (who will remain a C programmer, no matter how many Gotards tell me it's obsolete) I do like my semicolons. On the other hand, Python's use of indentation to define scope *does* force code to be that much more readable.

At this point, though, it's a moot point; Python is everywhere, and has withstood the test of time while other language fads have come and gone (I'm thankful that the Ruby fad has passed and I'm looking forward to Go disappearing).
A discussion of the merits of Python's indentation rules is about as productive as a discussion of whether GOTO (Basic) or GO TO (Fortran) is more appropriate.

I don't use GOTO statements anymore, because you can't spell GOTO without "GO", and Go is a stupid language.

Heh... 'the Ruby fad has passed'... while I'm dipping in it today.

C is not obscolete by any stretch of the imagination. It has become increasingly niche, perhaps, but it isn't obscolete. It is the only language capable of a certain efficiency-to-legibility ratio that programmers find appealing.

As for Python's penchant for indentation, it's still quite capable of obfuscated code if you put your mind to it (or hire folks who don't give a damn about legibility). Occasionally, I find its import mechanics confusing, cripplingly so in especially large projects if you aren't careful. Which our team wasn't back when I maintained a build system built in Python... *shudder*

It's certainly the preferred language of cyber security folks, though. It feels like anyone wanting to get serious about doing work in cybersecurity needs to learn Python or find themselves on the other side of the glass, looking in.

I'm still a strong fan of C++, though. And it feels like it's getting better with each new library folks add. But, I guess learning it is a bit of an investment.

I think it's interesting how Python's particular combination of features has resulted in a particular preferred programming style: "flat is better than nested" feels more important in Python than in other languages, in part because deeply nested variable scopes are easier to create and can cause so much trouble, but also in part because there are fewer visual cues about block scope. Why be strict about whitespace if it turns out that nesting is not preferred anyway?

But, I guess learning it is a bit of an investment.

well hello, captain obvious ;)

I'm a fan of making semicolons optional, as Haskell does (I think Python does too). However, I do concede that braces makes refactoring, and occasionally, navigating, code easier. When working on larger Python code bases, I miss having the ability to use % in vim to rapidly skip over a block.

I just realized that Intercal supports DRY. Because once you've finished some working code in Intercal, you aren't interested in writing it ever again.

Got a link? I don't see that at a glance, and Google gets confused by the search terms.

https://www.muppetlabs.com/~breadbox/intercal-man/

Yeah, I looked there. Don't see anything. Of course, this is INTERCAL we're talking about, so I guess I'm supposed to be confused.

OTOH, perhaps my joke isn't particularly good.

Yeah, I looked there. Don't see anything. Of course, this is INTERCAL

we're talking about, so I guess I'm supposed to be confused.

Ironic that ESR has participated in (probably several) programming language parodies, but he himself is now a Gotard.

I've never really looked Go, since it hasn't really come up as anything needful to getting anything done where I work... despite dealing with everything else it seems, from Java, Javascript, Ruby/Rails, C/C++, some assembly, Python, and probably some other stuff I can't remember right now.

Go never came up.

But I'll probably suddenly need to deal with it now that I've mentioned it.

I'm in SQL-hell.

I have this ridiculous SQL query I have to perform to get all the information I need, information that includes various aggregate sums of numbers depending upon sub-results of the full data set, etc.

It forms a kind of spreadsheet-like thing that has about 6 pivot layers deep of information. It's actually faster to perform a single query to get the information this way than to make multiple SQL calls to provide the 6 layers of joins and build the objects properly. One call, 6 pivot layers, then iterate over all the records building the layers.

But... ultimately... I don't want all the inner joins matching against the actual table, but a filtered view of it.

I have to find a way to specify this within the SQL query, and I'd prefer to not have to constantly type out the same condition clause 6 times. It feels like you ought to kinda make a temporary table and use that.

Disclaimer - I'm not an SQL expert. But I remember reading about something called a "view" not long ago; is it possible to maybe get the DBA to install a custom view to function as that filtered table perhaps?

I found a way.

I couldn't use a view, although I tried that. The view approach still had long times (for some reason), and required making three statements.. one to create the temporary view, one for the monster query that would use this view, and one to remove the view when I'm done. To ensure the view would disappear, I also had to ensure I established a new database connection, so when it went away the temporary view would go away... to avoid potential collusions if multiple calls were made to this page simultaneously.

Still, at 8 minutes, I didn't think the query went quickly enough for my needs.

So, after some careful reading, I saw the PostgreSQL folks recommended using "Common Table Expressions", which "can be thought of as defining temporary tables that exist just for one query."

WITH [tmp_table_name] AS (SELECT * FROM [actual_table] WHERE [where clause]) [your monster SELECT statement using tmp_table_name instead of actual_table];

That statement took a little over 12 seconds.

OOH, I had never heard of these before. Will Google for them. Thanks!

We've done a lot of Common Table Expressions to make it faster.. Views are indices.. And sometimes it's useful to keep the view permanently instead of waiting for it to rebuild on the fly all the time. Slows your update processing some, but can be handy.

I hearken back to the old tried and true method.

Dump it all to a flat file, sort and rampage through the darned thing.

Heh... the funny bit there is that I'm attempting to get a lot of data into a 'flat file' format, because it's easier to work with that way.

But the data is spread out in a billion tables with a million relationships (something rivalling most soap operas) that don't always make the best sense in the world. I have to seriously refactor this application. We built it in a hurry, and we didn't know what we were doing, or where we were ultimately going to go with it.

We have a better idea now, so I'd like to refactor it while that can still happen relatively painlessly.