Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

Jeb Bush 2012: Apr 4, 2007; A mathematician, like a painter or poet, is a maker of patterns. If his patterns are more permanent than theirs, it is because they are made with ideas.

ultrafilter posted:

Random paint splatters are valid Perl.

this mostly seems to reflect the (extremely bad) decision to interpret unreserved barewords as strings. my favourite consequence of this is

code:

#!/usr/bin/perl

if (false) {
  print "perl bad\n";
}

to be fair this doesn't happen if you follow best practice by using the strict pragma, but it's mad that it's the default behaviour

# ? May 25, 2020 19:16

Adbot: ADBOT LOVES YOU

# ? May 16, 2024 19:48

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

I've been hearing for what seems like decades from perl and php apologists about how "modern perl/php is all a-ok you just have to do x, y, and z".

# ? May 25, 2020 19:56

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

MrMoo posted:

Taken from Perl which also has the inverse:
code:
something unless $flag

Ruby also took unless

code:


unless it.poop?
  it.touch
end

e: "modern Perl" is Ruby

# ? May 25, 2020 20:25

Impotence: Nov 8, 2010; Lipstick Apathy

Thermopyle posted:

I've been hearing for what seems like decades from perl and php apologists about how "modern perl/php is all a-ok you just have to do x, y, and z".

modern php is fine you don't have to do anything special

# ? May 25, 2020 20:28

more falafel please: Feb 26, 2005; forums poster

Thermopyle posted:

I've been hearing for what seems like decades from perl and php apologists about how "modern perl/php is all a-ok you just have to do x, y, and z".

To be fair, that's what we say in C++-land too.

# ? May 25, 2020 22:26

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

At some point they might be right. Maybe that point has come and gone, I dunno. I gave up caring after hearing the lies one time too many.

# ? May 25, 2020 22:32

ultrafilter: Aug 23, 2007; It's okay if you have any questions.

Thermopyle posted:

I've been hearing for what seems like decades from perl and php apologists about how "modern perl/php is all a-ok you just have to do x, y, and z".

So how exactly is �modern Perl is fine, you just have to put use strict; at the top of your script� any different from �modern JavaScript is fine, you just have to put �use strict� at the top of your script�?

# ? May 25, 2020 22:44

MadFriarAvelyn: Sep 25, 2007

At a prior employer of mine, we used Perl as our primary language of choice for our server-side code. I was a junior dev on a team that was tasked with bringing a modern architecture and a brand new UI to our main application. Some of that infrastructure work included the use of a module, Moose, which would allow us to more easily write class-like modules akin to how you'd see them in, say, .Net, with property accessors and everything.

However, Moose generated all of these convenience methods at run time, the first time a module was loaded. After a few months of banging our heads at this effort, we finally shipped a bunch of our code to production. The end result was our IT staff banging down our doors asking what the hell we did to make server startup go from a several second affair to several minutes. Turns out our production servers force loaded all of the Perl modules in our codebase on server start-up, which meant Moose had to generate all of the convenience methods and etc required by the tons of tiny little Moose modules we had written, but weren't actually used anywhere by our users yet. Oops.

Our actual Perl Monk on staff wrote a replacement module to give us the same functionality, with quicker performance, but it was bad for a while.

This was almost a decade ago, supposedly there was a whole new version of Perl released between now and then that does all of the above better, but honestly I'd prefer to just never have to use Perl ever again.

# ? May 25, 2020 23:06

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Soricidus posted:

So how exactly is �modern Perl is fine, you just have to put use strict; at the top of your script� any different from �modern JavaScript is fine, you just have to put �use strict� at the top of your script�?

The length of time people have been claiming do something to make it fine and thus the number of times I've been lied to.

# ? May 25, 2020 23:21

susan b buffering: Nov 14, 2016

MadFriarAvelyn posted:

At a prior employer of mine, we used Perl as our primary language of choice for our server-side code. I was a junior dev on a team that was tasked with bringing a modern architecture and a brand new UI to our main application. Some of that infrastructure work included the use of a module, Moose, which would allow us to more easily write class-like modules akin to how you'd see them in, say, .Net, with property accessors and everything.

However, Moose generated all of these convenience methods at run time, the first time a module was loaded. After a few months of banging our heads at this effort, we finally shipped a bunch of our code to production. The end result was our IT staff banging down our doors asking what the hell we did to make server startup go from a several second affair to several minutes. Turns out our production servers force loaded all of the Perl modules in our codebase on server start-up, which meant Moose had to generate all of the convenience methods and etc required by the tons of tiny little Moose modules we had written, but weren't actually used anywhere by our users yet. Oops.

Our actual Perl Monk on staff wrote a replacement module to give us the same functionality, with quicker performance, but it was bad for a while.

This was almost a decade ago, supposedly there was a whole new version of Perl released between now and then that does all of the above better, but honestly I'd prefer to just never have to use Perl ever again.

Perl 6 got renamed to Raku last year so you can still use it and technically not be using Perl :v:

# ? May 25, 2020 23:22

Nth Doctor: Sep 7, 2010; Darkrai used Dream Eater!
It's super effective!

MadFriarAvelyn posted:

Our actual Perl Monk on staff wrote a replacement module to give us the same functionality, with quicker performance, but it was bad for a while.

Timtowtdi exemplified.

# ? May 25, 2020 23:33

QuarkJets: Sep 8, 2008

ultrafilter posted:

Modern C++ is much better than earlier versions but I'd be very suspicious of anyone who says it's all OK now.

Only because no language is really "all OK", right?

Modern C++ has a lot of good stuff in it but obviously putting more safety features and a fancy scope on a rifle won't save someone who's determined to shoot themselves.

# ? May 26, 2020 00:55

Doom Mathematic: Sep 2, 2008

QuarkJets posted:

Only because no language is really "all OK", right?

This is it. I'm more inclined to judge a programming language by the quality/linting/best practice tools surrounding it these days than by how it works out of the box. I'm less interested in seeing the most horrific possible code than in the most horrific possible code with all of the warnings cranked up to maximum. And also whether the culture around the language encourages those tools to be used as standard practice.

# ? May 26, 2020 01:08

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Doom Mathematic posted:

This is it. I'm more inclined to judge a programming language by the quality/linting/best practice tools surrounding it these days than by how it works out of the box. I'm less interested in seeing the most horrific possible code than in the most horrific possible code with all of the warnings cranked up to maximum. And also whether the culture around the language encourages those tools to be used as standard practice.

Yeah, I think this is right.

As I've gotten older and more experienced I've given up all sorts of coding preferences and just want everyone to use The One True linter/formatter/thingamajig.

Lately I've been working on a 50kloc code base with 3 other devs. So not real big but big enough. It's all in Python and all with type annotations. the CI runs mypy (type checker) and black (formatter) and it's just really nice. Years ago I would've been mad because I couldn't use my preferred way for formatting whatever, but nowadays I just want consistency with fine defaults.

# ? May 26, 2020 01:43

Xarn: Jun 26, 2015

Nah, C++ is still bad. For every step forward it takes half a step back thanks to increasing complexity, unforeseen interactions between features and sometimes plain idiotic design.

I would never return to writing C++98 tho.

# ? May 26, 2020 07:22

Impotence: Nov 8, 2010; Lipstick Apathy

Xarn posted:

Nah, C++ is still bad. For every step forward it takes half a step back thanks to increasing complexity, unforeseen interactions between features and sometimes plain idiotic design.

I'm just happy the auto keyword exists

# ? May 26, 2020 08:30

Sagacity: May 2, 2003; Hopefully my epitaph will be funnier than my custom title.

Xarn posted:

Nah, C++ is still bad. For every step forward it takes half a step back thanks to increasing complexity, unforeseen interactions between features and sometimes plain idiotic design.

I would never return to writing C++98 tho.

Agreed. I would love it if C++ can take an 'edition' approach to get rid of a whole bunch of legacy, but at that point it will be such a completely different language I'm not sure it's worth the bother.

OTOH it will take them at least 15 years of bikeshedding to decide what the edition's going to look like (and whether its new stdlib should include 2d graphics, probably), so this point is moot anyway.

# ? May 26, 2020 09:27

Xarn: Jun 26, 2015

Any sort of mixable epochs are a no go, unless they are glorified -Werror.

# ? May 26, 2020 09:30

Sagacity: May 2, 2003; Hopefully my epitaph will be funnier than my custom title.

And if they're not mixable, they're not solving the fundamental issues that make C++ so complex. Oh well.

# ? May 26, 2020 09:31

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Sagacity posted:

And if they're not mixable, they're not solving the fundamental issues that make C++ so complex. Oh well.

c++ will always be slow to build and insane to compile, because c++ cannot be parsed in LR(1) (https://stackoverflow.com/questions/243383/why-cant-c-be-parsed-with-a-lr1-parser.) a fundamental pillar of the language, template meta-programming, is actually ridiculously difficult to do correctly, and you'll have nonsense like visual studio faking support for stuff like variadic templates for decades after such a feature comes out in the standard. there are core problems with the language that can never be fixed, but unfortunately everyone smart enough to say "this is bullshit, let's try something else" will invariably have read some trendy paper about some fancy cs technique (e.g. garbage collection) and end up hobbling whatever new language comes out by trying to be too smart.

# ? May 26, 2020 14:42

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

"garbage collection hobbles new languages" is one heck of a take.

# ? May 26, 2020 15:03

Xarn: Jun 26, 2015

If you are tackling C++'s niche, it is extremely correct tho.

# ? May 26, 2020 15:14

more falafel please: Feb 26, 2005; forums poster

Volmarias posted:

"garbage collection hobbles new languages" is one heck of a take.

A "systems programming" language with mandatory GC is worthless from the jump

# ? May 26, 2020 15:28

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

Yes, GC for C++ or similar explicitly lower level languages is generally a mistake, I understand.

# ? May 26, 2020 15:59

Jeb Bush 2012: Apr 4, 2007; A mathematician, like a painter or poet, is a maker of patterns. If his patterns are more permanent than theirs, it is because they are made with ideas.

sure but referring to it as "some fancy cs technique" is still pretty funny

kids these days, with their garbage collection and their compilers and their visual editors

# ? May 26, 2020 16:02

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

ngl if they finally get rid of SFINAE in a new C++ version then i will upgrade. pretty much everything else has been a downgrade tho

# ? May 26, 2020 16:16

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Bruegels Fuckbooks posted:

c++ will always be slow to build and insane to compile, because c++ cannot be parsed in LR(1) (https://stackoverflow.com/questions/243383/why-cant-c-be-parsed-with-a-lr1-parser.)

c also can't be parsed in LR(1). most programming languages are context-dependent. c is perfectly fast to compile, though. parsing theory doesn't have too much bearing on compile speed.

the c++ compilation model is basically at war with the language. because of how the language is designed wrt. templates, pretty much all of the real work in every TU is duplicated. the same exact code for std::string and std::vector is compiled into every .cpp, separately, again, and the linker has to throw out 99% of it.

the fix for this was supposed to be "modules", a feature which will never work.

Bruegels Fuckbooks posted:

a fundamental pillar of the language, template meta-programming, is actually ridiculously difficult to do correctly, and you'll have nonsense like visual studio faking support for stuff like variadic templates for decades after such a feature comes out in the standard. there are core problems with the language that can never be fixed

the ISO process for improving c++ is broken, and self-selects for people with way too much time, and excludes domain experts. the new c++ random system was broken from day 1, lots of people pointed it out, but because nobody cba'd to submit a competing paper, it never got a formal rebuttal, and was included.

similarly, 2D graphics was a piece of junk written by non-domain experts, and was worked on for over 6 years (?). i found a bunch of extremely stupid mistakes through a basic read of the spec, and it's only because my former employer has a full-time C++ liason that any of my feedback made it to the room.

take a look at the story of std::embed if you want another example of how this works. the process self-selects for people with too much free time.

# ? May 26, 2020 16:25

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Suspicious Dish posted:

c also can't be parsed in LR(1). most programming languages are context-dependent. c is perfectly fast to compile, though. parsing theory doesn't have too much bearing on compile speed.

C isn't LR(1) but it wouldn't take that much to fix it. Most languages can be parsed in a set number of passes (excepting C++.) That said the LR(k) stuff is just the canary in the coal mine rather than a fundamental problem.

quote:

the ISO process for improving c++ is broken, and self-selects for people with way too much time, and excludes domain experts. the new c++ random system was broken from day 1, lots of people pointed it out, but because nobody cba'd to submit a competing paper, it never got a formal rebuttal, and was included.

Yeah, that's the other thing about C++. You try to do some mundane task such as "write a string to the screen" or "generate a random number" and to do it correctly requires slogging through literally decades of history and there might not even be a consensus answer. I definitely have days when I develop in the language where I feel like I'm just feeding the technology and reading about a bunch of bullshit that doesn't matter - every so often, I'll just encounter some aspect that requires a lot of reading to even get the background to understand how to approach the problem. It's so much worse mentoring other people in the language because doing a lot of reading and retaining bullshit that doesn't matter is something of my specialty, and it's painful to be like "oh, you need to rewrite this because you didn't understand bstr_t and so this code you wrote is going to crash your application ten minutes after the code runs because windows has a cache for bstr but since bstr_t is a smart pointer it's being de-allocated here but the operating system level cache is keeping the string alive until it gets evicted from the os level cache - always have oanocache environment variable enabled so the windows bstr cache doesn't cover for this problem" or some bullshit every single day.

But then you develop in C#, and the initial bring-up is great and everything is fine and you write all this good, easy looking code real fast - oh wait gc pauses and people care about that now even though it's supposed to be a web-app. gently caress, what do you do? Reduce new calls to new()? Don't make garbage? Turn off garbage collector oh wait the application uses 150mb of memory a second, that poo poo isn't going to fly? What do you do? (lol C++ / CLI)

# ? May 26, 2020 16:54

Beef: Jul 26, 2004

The GC proposals for C++ I've seen are all separate opt-in heaps, never the entire language. Yeah Java, C# and golang have GC for everything, and the languages have been built around that. No, that is not the only way you can put a GC in your language.

There are a bunch of problems and domains where a GC-managed heap is absolutely the best way to manage that memory, and C++ currently has no way to address those.

Relevant Herb Sutter cppcon presentation: https://www.youtube.com/watch?v=JfmTagWcqoE

edit: "You know what happens if you talk to C++ programmers about garbage collection?" https://www.youtube.com/watch?v=JfmTagWcqoE&t=5600s

Beef fucked around with this message at 18:17 on May 26, 2020

# ? May 26, 2020 18:09

Falcorum: Oct 21, 2010

Biowarfare posted:

I'm just happy the auto keyword exists

It's great because it lets me point out to people in code reviews that it doesn't do what they think it does.

const auto& on the other hand is pretty solid

# ? May 26, 2020 18:13

Athas: Aug 6, 2007; fuck that joker

How many language communities have the notion of a "language lawyer" the way C++ (and partially C) does? It's kind of ridiculous that a language can be complex enough that you can have detailed arguments about how it actually works (or is supposed to work). Even supposedly complex academic languages like Haskell or Idris don't have discussions at that level (except when designing new language extensions, where I guess it's fair).

# ? May 26, 2020 19:09

ultrafilter: Aug 23, 2007; It's okay if you have any questions.

Haskell would have language lawyers if it were more popular.

# ? May 26, 2020 19:13

Ralith: Jan 12, 2011; I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

Athas posted:

How many language communities have the notion of a "language lawyer" the way C++ (and partially C) does? It's kind of ridiculous that a language can be complex enough that you can have detailed arguments about how it actually works (or is supposed to work). Even supposedly complex academic languages like Haskell or Idris don't have discussions at that level (except when designing new language extensions, where I guess it's fair).

I think a lot of this is due to how pervasive UB hazards make your relationship with the compiler more adversarial than cooperative: if you get some subtle detail wrong, it will probably do something horrible rather than just telling you. Modern languages don't have so much trouble with that.

# ? May 26, 2020 19:30

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Requiring arbitrary lookahead in a handful of places is not why parsing C++ is slow. It's almost entirely the preprocessor � the vast amount of redundant information brought in by included files, the statefulness of tokenization, and the pervasive need to handle macros � assisted by the lookup rules and the general complexity of the language. And then you add the hilarious amount of wasted work implied by templates under the traditional compilation model.

# ? May 26, 2020 21:27

iospace: Jan 19, 2038

https://twitter.com/raganwald/status/1265309365646643201

# ? May 26, 2020 22:26

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Suspicious Dish posted:

the ISO process for improving c++ is broken, and self-selects for people with way too much time, and excludes domain experts. the new c++ random system was broken from day 1, lots of people pointed it out, but because nobody cba'd to submit a competing paper, it never got a formal rebuttal, and was included.

similarly, 2D graphics was a piece of junk written by non-domain experts, and was worked on for over 6 years (?). i found a bunch of extremely stupid mistakes through a basic read of the spec, and it's only because my former employer has a full-time C++ liason that any of my feedback made it to the room.

take a look at the story of std::embed if you want another example of how this works. the process self-selects for people with too much free time.

I thought the 2d graphics thing was a joke :cripes:

Guessing it still is, just baked into stdlib now

Bruegels Fuckbooks posted:

oh wait gc pauses and people care about that now even though it's supposed to be a web-app

Who are these people? I want to know so I can avoid them.

# ? May 26, 2020 22:34

Xarn: Jun 26, 2015

Munkeymon posted:

I thought the 2d graphics thing was a joke

It, just like web_view, is completely earnest.

Part of the problem of the committee model is that you can't really stop someone from sending new revisions of papers :v:

rjmccall posted:

Requiring arbitrary lookahead in a handful of places is not why parsing C++ is slow. It's almost entirely the preprocessor � the vast amount of redundant information brought in by included files, the statefulness of tokenization, and the pervasive need to handle macros � assisted by the lookup rules and the general complexity of the language. And then you add the hilarious amount of wasted work implied by templates under the traditional compilation model.

And then we also make things like move/forward actual functions, because we wanted more template instantions and overload set resolutions :suicide:

# ? May 26, 2020 22:56

QuarkJets: Sep 8, 2008

Falcorum posted:

It's great because it lets me point out to people in code reviews that it doesn't do what they think it does.

const auto& on the other hand is pretty solid

What does it do?

# ? May 26, 2020 22:57

Adbot: ADBOT LOVES YOU

# ? May 16, 2024 19:48

Xarn: Jun 26, 2015

Xarn posted:

And then we also make things like move/forward actual functions, because we wanted more template instantions and overload set resolutions

Or you find out that significant amount of your compile times is caused by instantiating unique_ptr couple of times in ~every TU.

# ? May 26, 2020 22:58

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »