|
this mostly seems to reflect the (extremely bad) decision to interpret unreserved barewords as strings. my favourite consequence of this is code:
|
# ? May 25, 2020 19:16 |
|
|
# ? May 16, 2024 17:02 |
|
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 |
|
MrMoo posted:Taken from Perl which also has the inverse: Ruby also took unless code:
e: "modern Perl" is Ruby
|
# ? May 25, 2020 20:25 |
|
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 |
|
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 |
|
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 |
|
more falafel please posted:To be fair, that's what we say in C++-land too. Modern C++ is much better than earlier versions but I'd be very suspicious of anyone who says it's all OK now.
|
# ? May 25, 2020 22:34 |
|
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 |
|
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 |
|
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 |
|
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. Perl 6 got renamed to Raku last year so you can still use it and technically not be using Perl
|
# ? May 25, 2020 23:22 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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. 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 |
|
Any sort of mixable epochs are a no go, unless they are glorified -Werror.
|
# ? May 26, 2020 09:30 |
|
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 |
|
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 |
|
"garbage collection hobbles new languages" is one heck of a take.
|
# ? May 26, 2020 15:03 |
|
If you are tackling C++'s niche, it is extremely correct tho.
|
# ? May 26, 2020 15:14 |
|
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 |
|
Yes, GC for C++ or similar explicitly lower level languages is generally a mistake, I understand.
|
# ? May 26, 2020 15:59 |
|
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 |
|
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 |
|
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 |
|
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. 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. 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 |
|
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 |
|
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 |
|
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 |
|
Haskell would have language lawyers if it were more popular.
|
# ? May 26, 2020 19:13 |
|
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 |
|
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 |
|
https://twitter.com/raganwald/status/1265309365646643201
|
# ? May 26, 2020 22:26 |
|
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. I thought the 2d graphics thing was a joke 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 |
|
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 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
|
# ? May 26, 2020 22:56 |
|
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. What does it do?
|
# ? May 26, 2020 22:57 |
|
|
# ? May 16, 2024 17:02 |
|
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 |