Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Cacodemon345

What do you think of the C-family programming languages?

Recommended Posts

32 minutes ago, Maes said:

Well, "real programmers" in the above sense are much like a capricious but talented ace pilot or football player. Their talent is what allows them to "get the job done" (and more often than not, they do get it done, especially if it's something none else would touch with a 30-foot cattle prod) but also it means that they won't always be good team players or work well within strict procedure or company protocol. It's not even about using esoteric programming languages or refusing to use GUIs, but more about thinking outside the box and/or having a passionate perseverance.

 

They do have their uses, but employing them in a manner that will restrain their talent/unique skills is a management error. There are many "run of the mill" or "suit" programmers if one just wants compliance and adherence. Real programmers are best reserved for those special tasks none else will tackle.

 

Sorry, but no. Anybody working on some larger infrastructure needs to be a team player. Those people are not. They have their own way of doing things, often do not listen to feedback and ultimately tend to create a larger problem than what they are supposed to solve - especially when they leave and nobody can follow their unique way of problem solving.

Like I said, I had my run-ins with them, that's virtually impossible to avoid if you work in the field for almost 30 years, and while they tend to think out of the box, it usually also means that their solutions are outside the box as well and cause long term problems, and it far too often happened that their code needed to be thrown away because it was too specialized and/or too weird for others to continue their work.

 

15 minutes ago, Jon said:

I hate both "real programmer" and "real computer"

 

I did not mean it in a derogatory way. There's a vast difference between an actual computer that is being designed to run arbitrary programs or a device that needs some programming to work. In particular, the way they need to be programmed does not have much in common because the resources they provide are very, very different.

 

Share this post


Link to post
2 hours ago, Maes said:

Sigh, the more time passes the less new programmers "get" the good old fashioned humor of the Jargon File and the sheer epicness of The Story Of Mel.

This kind of Real Programmers jokes are kinda like Chuck Norris jokes: they were funny originally, but after a while they're now just kinda tired and boring.

 

Yes, in the pioneer era of programming, where every single bit of memory was a cruelly limited resource and it one hour of computation times (factoring in the time to replace any vacuum tube that blew up during the operation) to process an addition, extreme optimizations that were entirely hardware-dependent made sense.

 

But that situation is now obsolete and actual real programming skills are elsewhere. We're no longer fighting to shave off ten bytes from a primitive Breakout game, we're now trying to avoid jank in blockbusters done by massive teams of hundreds if not thousands of people. The complexity of programs has increased so much that the mark of a good programmer has become the ability to write clear, legible code that is easy to maintain and integrate in a large collaborative codebase. No one will care if that costs 20% more memory use because by the time the program finishes development the size of the memory in the baseline platform will have increased by +100% anyway.

Share this post


Link to post
2 minutes ago, Graf Zahl said:

Like I said, I had my run-ins with them, that's virtually impossible to avoid if you work in the field for almost 30 years, and while they tend to think out of the box, it usually also means that their solutions are outside the box as well and cause long term problems, and it far too often happened that their code needed to be thrown away because it was too specialized and/or too weird for others to continue their work.

As I said, they are best used for those problems that nobody else within the orgnization will touch -or even be able to solve at all- with "normal" coding or not. Even if doing so means that the only solution is idiosyncratic code, that only a "real programmer" can produce. Expecting something else is, as I said, a management/human resource allocation error.

Share this post


Link to post

I disagree. If you give such employees a free pass you won't get a solution. Even if "nobody else" wants to take the task, you still make sure that these people won't go off the rails, you still make sure they work within the established framework and you certainly make sure that they are supervised and their work gets reviewed. And most importantly, you make sure that in case of an emergency someone can stand in for them! If they refuse to work in such a system, don't hire them. Everything else would really be a management error. Otherwise you get a loose cannon on the job which may go off at any moment. Otherwise you become totally dependent on this person and that'd be the worst outcome ever.

Share this post


Link to post
4 minutes ago, Graf Zahl said:

Otherwise you become totally dependent on this person and that'd be the worst outcome ever.

 

Some call this "job security", and some systems/languages are so inherently quirky that anyone who can work with them to any degree of competence/effectiveness would qualify as a "real programmer" in the pejorative sense you ascribe to it, simply by doing their job in no extraordinary or out-of-whack fashion.

 

Of course then you could argue that the real weakness here is the dependence on systems that require hiring such people....and I wouldn't disagree, but sometimes it cannot be helped.

Share this post


Link to post
28 minutes ago, Gez said:

This kind of Real Programmers jokes are kinda like Chuck Norris jokes: they were funny originally, but after a while they're now just kinda tired and boring.

 

Agreed, but if you hang out in the right places you still find these types that

- do not use a debugger "because printf is good enough"

- refuse to use modern languages because they "no longer control the code being generated."

- proudly proclaim that they made the most inconsequential function in a large code base 200% faster.

- start optimizing code in the design phase, long before they know whether it is beneficial or not.

 

The cliché is surely boring and tired and it's hard to find people that match every criteria, but each one of these issues can still be found in actual people, and funny enough, these people are often precisely the kind that consider themselves the "real programmers" while the rest is just spoiled by all the modern advances.

 

There's a reason after all why these jokes still persist.

 

 

28 minutes ago, Gez said:

Yes, in the pioneer era of programming, where every single bit of memory was a cruelly limited resource and it one hour of computation times (factoring in the time to replace any vacuum tube that blew up during the operation) to process an addition, extreme optimizations that were entirely hardware-dependent made sense.

 

Some of this even made sense on the 80's home computers, but here we clearly can see who learned and grew up and who stuck to the methods initially learned.

 

 

28 minutes ago, Gez said:

But that situation is now obsolete and actual real programming skills are elsewhere. We're no longer fighting to shave off ten bytes from a primitive Breakout game, we're now trying to avoid jank in blockbusters done by massive teams of hundreds if not thousands of people. The complexity of programs has increased so much that the mark of a good programmer has become the ability to write clear, legible code that is easy to maintain and integrate in a large collaborative codebase. No one will care if that costs 20% more memory use because by the time the program finishes development the size of the memory in the baseline platform will have increased by +100% anyway.

 

Agreed on all accounts. Of course for an old-school programmer that means relearning their trade constantly, and we all know that there's people - even very intelligent people - out there that have difficulties doing that.

 

5 minutes ago, Maes said:

Of course then you could argue that the real weakness here is the dependence on systems that require hiring such people....and I wouldn't disagree, but sometimes it cannot be helped.

 

If someone manages to get themselves into such a corner, they don't deserve any better. But that still doesn't excuse them if they do not set up procedures that prevent  these developers from "securing" their jobs through bad code.

 

 

Share this post


Link to post
21 minutes ago, Graf Zahl said:

 

Agreed, but if you hang out in the right places you still find these types that

- do not use a debugger "because printf is good enough"

 

Hmm...sometimes there's no alternative to printf (or worse, files) because of the platform's design, but I digress. As much as one could argue "such platforms should not exist"/"whoever uses them gets what they deserve", they do exist and they do put bread on the table for someone, somewhere, so...

 

Thinking about it, we should be thankful even for printf as a last resort. Below that, I can only imagine printing to a RS232 terminal, which is still a HUUUUGE luxury over e.g. toggling bits in an accessible bus/port, beeping or flashing an LED ;-)

Share this post


Link to post
12 minutes ago, Maes said:

 

Hmm...sometimes there's no alternative to printf (or worse, files) because of the platform's design, but I digress. As much as one could argue "such platforms should not exist"/"whoever uses them gets what they deserve", they do exist and they do put bread on the table for someone, somewhere, so...

  

 

There's a major difference between using printf because of no other choice or deliberate forfeiting the available tools because they are too "wussy". I had to do printf debugging myself but only as a last resort in most cases.

Share this post


Link to post

I find printf invaluable for analyzing program flow - like if I need to figure out what a set of nested for loops is doing, or figuring out what some confusing twisted maze of function calls is doing.

 

That said, I'm all about those debuggers, breakpoints, and stack traces.  They're simply too useful to ignore.  But let me tell you, once you go ASan, you'll never go back...

 

Spoiler

=================================================================
==33659==ERROR: AddressSanitizer: heap-use-after-free on address 0x607000069a74 at pc 0x5603b1b67dc6 bp 0x7ffd4837b980 sp 0x7ffd4837b970
READ of size 2 at 0x607000069a74 thread T0
    #0 0x5603b1b67dc5 in IWindowSurface::getHeight() const ../client/sdl/i_video.h:342
    #1 0x5603b1b67dc5 in I_IsWideResolution(IWindowSurface const*) ../client/sdl/i_video.cpp:976
    #2 0x5603b1d8b0e7 in CheckWideModeAdjustment ../client/src/v_video.cpp:256
    #3 0x5603b1d8b0e7 in cvarfunc_sv_allowwidescreen(cvar_t&) ../client/src/v_video.cpp:268
    #4 0x5603b1d9c486 in cvar_t::Callback() ../common/c_cvars.h:103
    #5 0x5603b1d9c486 in cvar_t::ForceSet(char const*) ../common/c_cvars.cpp:203
    #6 0x5603b1d9c7a3 in cvar_t::Set(char const*) ../common/c_cvars.cpp:225
    #7 0x5603b1d9d16e in cvar_t::UnlatchCVars() ../common/c_cvars.cpp:518
    #8 0x5603b1d9f9e1 in cvar_t::C_RestoreCVars() ../common/c_cvars.cpp:483
    #9 0x5603b1be54bf in CL_QuitNetGame() ../client/src/cl_main.cpp:439
    #10 0x5603b1b5eb4f in I_Quit() ../client/sdl/i_system.cpp:678
    #11 0x5603b1b25ac0 in call_terms() ../client/sdl/i_main.cpp:93
    #12 0x5603b1bdd290 in CL_QuitCommand() ../client/src/cl_main.cpp:1104
    #13 0x5603b1c06a97 in Cmd_quit::Run(unsigned int) (/home/alexmax/Documents/Workspace/odamex/build/client/odamex+0x274a97)
    #14 0x5603b1da90ab in C_DoCommand(char const*, unsigned int) ../common/c_dispatch.cpp:276
    #15 0x5603b1da9cc7 in AddCommandString(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int) ../common/c_dispatch.cpp:400
    #16 0x5603b1b45d5d in ISDL20Window::getEvents() ../client/sdl/i_sdlvideo.cpp:1313
    #17 0x5603b1b462f4 in ISDL20Window::startRefresh() ../client/sdl/i_sdlvideo.cpp:1390
    #18 0x5603b1b67e5d in I_BeginUpdate() ../client/sdl/i_video.cpp:1107
    #19 0x5603b1c4820b in D_Display() ../client/src/d_main.cpp:230
    #20 0x5603b1bdd281 in CL_DisplayTics() ../client/src/cl_main.cpp:690
    #21 0x5603b1de7828 in CappedTaskScheduler::run() ../common/d_main.cpp:1007
    #22 0x5603b1dd7b22 in D_RunTics(void (*)(), void (*)()) ../common/d_main.cpp:1117
    #23 0x5603b1c493bf in D_DoomLoop() ../client/src/d_main.cpp:348
    #24 0x5603b1c4ac04 in D_DoomMain() ../client/src/d_main.cpp:972
    #25 0x5603b1b26a46 in main ../client/sdl/i_main.cpp:245
    #26 0x7fb5b73150b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    #27 0x5603b1b050ed in _start (/home/alexmax/Documents/Workspace/odamex/build/client/odamex+0x1730ed)

0x607000069a74 is located 68 bytes inside of 80-byte region [0x607000069a30,0x607000069a80)
freed by thread T0 here:
    #0 0x7fb5b7c4f8df in operator delete(void*) (/lib/x86_64-linux-gnu/libasan.so.5+0x1108df)
    #1 0x5603b1b3f85c in ISDL20TextureWindowSurfaceManager::~ISDL20TextureWindowSurfaceManager() ../client/sdl/i_sdlvideo.cpp:1059
    #2 0x5603b1b3f916 in ISDL20TextureWindowSurfaceManager::~ISDL20TextureWindowSurfaceManager() ../client/sdl/i_sdlvideo.cpp:1065
    #3 0x5603b1b3ffca in ISDL20Window::~ISDL20Window() ../client/sdl/i_sdlvideo.cpp:1198
    #4 0x5603b1b4008e in ISDL20Window::~ISDL20Window() ../client/sdl/i_sdlvideo.cpp:1202
    #5 0x5603b1b40202 in ISDL20VideoSubsystem::~ISDL20VideoSubsystem() ../client/sdl/i_sdlvideo.cpp:1750
    #6 0x5603b1b40296 in ISDL20VideoSubsystem::~ISDL20VideoSubsystem() ../client/sdl/i_sdlvideo.cpp:1754
    #7 0x5603b1b67bbf in I_ShutdownHardware() ../client/sdl/i_video.cpp:736
    #8 0x5603b1b25ac0 in call_terms() ../client/sdl/i_main.cpp:93
    #9 0x5603b1bdd290 in CL_QuitCommand() ../client/src/cl_main.cpp:1104
    #10 0x5603b1c06a97 in Cmd_quit::Run(unsigned int) (/home/alexmax/Documents/Workspace/odamex/build/client/odamex+0x274a97)
    #11 0x5603b1da90ab in C_DoCommand(char const*, unsigned int) ../common/c_dispatch.cpp:276
    #12 0x5603b1da9cc7 in AddCommandString(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int) ../common/c_dispatch.cpp:400
    #13 0x5603b1b45d5d in ISDL20Window::getEvents() ../client/sdl/i_sdlvideo.cpp:1313
    #14 0x5603b1b462f4 in ISDL20Window::startRefresh() ../client/sdl/i_sdlvideo.cpp:1390
    #15 0x5603b1b67e5d in I_BeginUpdate() ../client/sdl/i_video.cpp:1107
    #16 0x5603b1c4820b in D_Display() ../client/src/d_main.cpp:230
    #17 0x5603b1bdd281 in CL_DisplayTics() ../client/src/cl_main.cpp:690
    #18 0x5603b1de7828 in CappedTaskScheduler::run() ../common/d_main.cpp:1007
    #19 0x5603b1dd7b22 in D_RunTics(void (*)(), void (*)()) ../common/d_main.cpp:1117
    #20 0x5603b1c493bf in D_DoomLoop() ../client/src/d_main.cpp:348
    #21 0x5603b1c4ac04 in D_DoomMain() ../client/src/d_main.cpp:972
    #22 0x5603b1b26a46 in main ../client/sdl/i_main.cpp:245
    #23 0x7fb5b73150b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

previously allocated by thread T0 here:
    #0 0x7fb5b7c4e947 in operator new(unsigned long) (/lib/x86_64-linux-gnu/libasan.so.5+0x10f947)
    #1 0x5603b1b4115a in ISDL20TextureWindowSurfaceManager::ISDL20TextureWindowSurfaceManager(unsigned short, unsigned short, PixelFormat const*, ISDL20Window*, bool, char const*) ../client/sdl/i_sdlvideo.cpp:1045
    #2 0x5603b1b42c01 in ISDL20Window::setMode(IVideoMode const&) ../client/sdl/i_sdlvideo.cpp:1655
    #3 0x5603b1b6b940 in I_SetVideoMode(IVideoMode const&) ../client/sdl/i_video.cpp:603
    #4 0x5603b1d8dc95 in V_DoSetResolution ../client/src/v_video.cpp:480
    #5 0x5603b1d8e0a0 in V_Init() ../client/src/v_video.cpp:539
    #6 0x5603b1c49081 in D_Init() ../client/src/d_main.cpp:590
    #7 0x5603b1c49f39 in D_DoomMain() ../client/src/d_main.cpp:769
    #8 0x5603b1b26a46 in main ../client/sdl/i_main.cpp:245
    #9 0x7fb5b73150b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

SUMMARY: AddressSanitizer: heap-use-after-free ../client/sdl/i_video.h:342 in IWindowSurface::getHeight() const
Shadow bytes around the buggy address:
  0x0c0e800052f0: fa fa fd fd fd fd fd fd fd fd fd fa fa fa fa fa
  0x0c0e80005300: fd fd fd fd fd fd fd fd fd fa fa fa fa fa fd fd
  0x0c0e80005310: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd fd
  0x0c0e80005320: fd fd fd fd fd fa fa fa fa fa fd fd fd fd fd fd
  0x0c0e80005330: fd fd fd fd fa fa fa fa fd fd fd fd fd fd fd fd
=>0x0c0e80005340: fd fa fa fa fa fa fd fd fd fd fd fd fd fd[fd]fd
  0x0c0e80005350: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fa fa
  0x0c0e80005360: fa fa fd fd fd fd fd fd fd fd fd fd fa fa fa fa
  0x0c0e80005370: fd fd fd fd fd fd fd fd fd fa fa fa fa fa fd fd
  0x0c0e80005380: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd fd
  0x0c0e80005390: fd fd fd fd fd fa fa fa fa fa fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==33659==ABORTING

 

 

If this doesn't knock your socks off, you probably were wearing sandals.  I think Visual C++ can do some of this with the debug heap, but I can personally attest that ASan has caught loads of bugs that the debug heap never found.  I think Valgrind could do some of this too, but my memory is that it was tricky to set up and much slower.

 

This level of verbosity has turned many occasional crashes and wild goose chases into "Oh, that's what's happening.  Fixed."   It has saved me countless hours and countless dozens of strands of hair on my head.  Debuggers aren't modern tooling by 2020's standards.  Stuff like this is.

Edited by AlexMax

Share this post


Link to post

I rarely need to use tools like address sanitizers as they typically only come into play for C code or when the code never gave any proper ownership to allocated data. In quality C++ codebases such stuff is handled automatically by unique_ptr and shared_ptr in 99% of all cases.

 

That's not to say that the tool isn't incredibly useful whenever that situation arise, but still, I'd say I need to set a breakpoint 1000 times more often than track down a memory misuse like that. In fact, I can't remember the last time I had to debug a use-after-free bug. Even buffer overruns are very rare the way I code things in 2020 - haven't had one yet this year.

Share this post


Link to post
1 hour ago, dpJudas said:

I rarely need to use tools like address sanitizers as they typically only come into play for C code or when the code never gave any proper ownership to allocated data. In quality C++ codebases such stuff is handled automatically by unique_ptr and shared_ptr in 99% of all cases. 

 

The whole reason I started getting serious with ASan was because of this talk, and even after that it took me a few personal instances of "Holy cow that would've taken me forever to track down" before I was a believer.  Facebook is certainly not stuck in in ancient C++ land, and most of the listed bugs have nothing to do with the usual suspects of C cruft, but instead are ways that idiomatic C++ can be used carelessly.

 

I suppose that I am fortunate to be in the position where I can always afford the spare CPU cycles to compile with it always turned on, so I'm never in the mindset of it being a tool to track down a specific bug, but instead an additional set of guardrails that I don't have to think about until I slide into them by accident and I think "Whew, glad I had that turned on".

Share this post


Link to post
6 hours ago, AlexMax said:

I find printf invaluable for analyzing program flow - like if I need to figure out what a set of nested for loops is doing, or figuring out what some confusing twisted maze of function calls is doing.

I completely agree with this. printf was invaluable for EFI low level debugging; I used it for UEFI Doom. I would need to look for a PC that allows UEFI debugging if printf wasn't available.

Share this post


Link to post
5 hours ago, dpJudas said:

I rarely need to use tools like address sanitizers as they typically only come into play for C code or when the code never gave any proper ownership to allocated data. In quality C++ codebases such stuff is handled automatically by unique_ptr and shared_ptr in 99% of all cases.

  

That's not to say that the tool isn't incredibly useful whenever that situation arise, but still, I'd say I need to set a breakpoint 1000 times more often than track down a memory misuse like that. In fact, I can't remember the last time I had to debug a use-after-free bug. Even buffer overruns are very rare the way I code things in 2020 - haven't had one yet this year.

 

Same here. With C++ I rarely run into such situations outside of old code. However, at work I have to use Objective-C on iOS and the amount of memory corruption being caused by ObjC's broken memory management is magnitudes worse.

It is quite frequent that the system believes that a certain piece of memory is not needed anymore, freeing it behind my back and then later - boom! I always found garbage collection to be sub-optimal but a system like this that gives the programmer no control whatsoever and has its own rules about ownership is the worst of both worlds.

Share this post


Link to post
2 hours ago, luckyjack said:

With SSL certificate your users will recognize that your site is safe

Uh what?

 

Phishing sites in the past got actual SSL certificates.

Share this post


Link to post
5 minutes ago, Cacodemon345 said:

Uh what?

 

Phishing sites in the past got actual SSL certificates.


That's one extreme. The other is sites whose administrators refuse to adopt SSL encryption because "It still gets hacked in the end, so why bother".

Share this post


Link to post

I’d not buy them in this day and age and just use let’s encrypt instead. 

Share this post


Link to post

I'm more confused about what this is doing in a c++ thread... actually going through the user's history it would appear this is nothing more than a spambot. Oops. I've taken to reporting these when I come across them, there's been a bunch over the years, but I overlooked this one.

 

ed: bot is probably a stretch, I'm assuming they're actual paid spammers or something given that their behavior isn't 100% robotic (ie dropping songs in the music thread and so on), but it's spam nonetheless.

Share this post


Link to post
7 minutes ago, SaladBadger said:

I'm more confused about what this is doing in a c++ thread... actually going through the user's history it would appear this is nothing more than a spambot. Oops. I've taken to reporting these when I come across them, there's been a bunch over the years, but I overlooked this one.

 

ed: bot is probably a stretch, I'm assuming they're actual paid spammers or something given that their behavior isn't 100% robotic (ie dropping songs in the music thread and so on), but it's spam nonetheless.

 

Yet another derail, but I always wondered if dropping random sales pitches in the middle of random threads on the internet (even if you try to at least be relevant to the subject) is a viable marketing strategy, aka does it bring more customers/sales in the end. To me, it always appeared a desperate move, like someone suckered in an MLM scheme or "work from home" scam would do. For one, if not done automatically, it should take a lot of someone's time, keeping accounts in different forums etc. and I even bet that the spammers actually paid someone to be given access to some form of "spammer training" or "platform". In other words, someone must be making money out of all of this, just not the spammers themselves. Just my 2c....

Share this post


Link to post

I used Go for a few years and I really enjoyed it. I’d still use it on personal projects that called for a compiled language, at least to start. I just got a new job where I’ll be using Objective-C++ (yes, both Objective-C and C++). I have to brush up on it. I really have a soft spot for Go but feel like working in “old school” languages professionally was always a blind spot.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×