Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)L

lysdexic

@ lysdexic @programming.dev

Posts
439
Comments
601
Joined
3 yr. ago

  • Musings on the C charter | Ruminations

    Jump
  • Removed

    Can a Programmer Be Jobless?

    Jump

  • I’m not saying this guy’s experience isn’t valid, just that there is something else going on here whether it’s a changing job market that hasn’t caught up with me yet or soft skills or that market or outdated skill set or what.

    The blogger described his career path as "After more than a decade of sitting behind a single company's desk, my CV looks bleak." That doesn't sound like someone who was mindful of their career path.

    I also don't think the blogger is completely honest or factual with regards to the job interview process. The blogger claims that "Nowadays, you have to pass through several layers of random and arbitrary screening in order to even get invited to the even more grueling in-person interviews." As someone who somewhat recently switched roles, my personal experience is not the same. The bulk of recruiting processes start with a phone screening to verify that you really exist and have basic social skills, but technical screenings follow right after. Some organizations do pride themselves in having close to a dozen interview rounds, but you are expected to prove your worth in each and every single interview round you're pulled into it.

    The truth of the matter is that as labor supply is increasing, you have to do more than show up in a meeting to get a job offer. Not having a degree is also a red herring because that's effectively irrelevant for the bulk of the development positions out there.

    There's however a critical factor that I feel everyone should have in mind: the bulk of IT services/consultancy recruiters out there might post job ads but they actually have zero positions to fill. The blogger briefly mention those without appearing to connect the dots when they mention "Mr X was very impressed with your skills, however, we don't have any opening for you right now". Odds are they really really do not have a opening, and they just forced you to go through tests and assessments just so that they could add another entry in their database.

  • Removed

    Can a Programmer Be Jobless?

    Jump

  • And that’s how software development became just another profession.

    I don't think that's a healthy way of framing things. Software development was always, from the very start, just another profession. What changed in the last decade or so was a) supply and demand in the job market, b) the quality of the pool of workers searching for jobs. Companies still look for developers, and most still pay handsomely well, but the hiring bar is currently met only by those who are far more experienced and/or paid attention to their career growth. You still see companies hiring people straight out of bootcamps, but they come out of the bootcamp pipeline with proper portfolios and they hit the ground running without requiring that much training or onboarding.

    In contrast, the blogger states that "After more than a decade of sitting behind a single company's desk, my CV looks bleak." A decade is a very long time to stay idle by without updating their skills, isn't it?

    I saw this phenomenon throughout the past decade in the hiring loops I was involved. In the demand peak I already saw a few developers with over a decade of experience interviewing for senior positions that started their interviews already defeated and broken, complaining that in their last roles they just went with the flow and never bothered to do anything relevant with their career. They claimed they could fit the role and do whatever needed to be done, but the truth of the matter is that that's true for each and every single developer called for a technical review. We needed to have some assurance that we were hiring the best candidate for the job, and these developers with a long experience of "sitting behind a single company's desk" gave us nothing to work with. So why would we hire them over those who could show off something?

  • Handling HTTP POST requests with node.js

    Jump

  • For those learning Nodejs, here is a tutorial on how to handle HTTP POST requests.

    I recommend you start by taking a look at frameworks such as Express.

    https://expressjs.com/en/starter/installing.html

    Express' "Getting started" guide showcases a cut-and-paste example of how to route POST requests in its section on basic routing.

    https://expressjs.com/en/starter/basic-routing.html

    Once you get that up and running, I recommend you onboard onto cross-origin resource sharing (CORS), which is used to protect against cross-site request forgery (CSRF) attacks. POST is considered an unsafe method by default, as it's typically used to cause side-effects on server data, and you might be forced to support ways to mitigate those attacks, such as supporting CSRF tokens.

  • Programming @programming.dev
    lysdexic @programming.dev

    Modern B-Tree Techniques (2011)

    doi.org /10.1561/1900000028

  • GitHub - goldbergyoni/nodebestpractices: The Node.js best practices list (December 2023)

    Jump

  • Don’t use js for a servers backend.

    What leads you to believe that?

  • Node.js @programming.dev
    lysdexic @programming.dev

    GitHub - goldbergyoni/nodebestpractices: The Node.js best practices list (December 2023)

    github.com /goldbergyoni/nodebestpractices
  • Node.js @programming.dev
    lysdexic @programming.dev

    The Most Popular Node.js Frameworks of 2023

    stackdiary.com /node-js-frameworks/

  • Boost 1.84.0 has been released

    Jump

  • Perhaps the biggest news of Boost 1.84 is the introduction of Boost.Redis, a Redis async client library built on top of Boost.Asio.

    Does anyone have any plans to start using Boost.Redis in their projects?

  • C++ @programming.dev
    lysdexic @programming.dev

    Boost 1.84.0 has been released

    www.boost.org /users/history/version_1_84_0.html
  • Functional Programming @programming.dev
    lysdexic @programming.dev

    Functional Classes (2023)

    blog.cleancoder.com /uncle-bob/2023/01/18/functional-classes.html

  • Does C# (or any other languages) have an official style guide like python has pep8?

    Jump

  • The C++ scope resolution operator is beautiful

    Jump

  • In Java, your objects start lowercase, so if you see uppercase, its a static call.

    Not really, that's just the way a specific coding style was specified. You're free to refactor all your projects to follow any other coding style if you really want to, and your programs will continue to work just fine.

  • Memory Safety is a Red Herring

    Jump

  • Nobody’s perfect and time has shown multiple time that you can’t trust human beings with memory safety.

    That's perfectly fine. That's not a problem caused UB, or involving UB.

    Again, UB is a red herring.

    It is however the language’s fault to allow UB in the first place.

    It really isn't. Again, mindlessly parroting this doesn't give any substance to this claim. Please try to think about it for a second. For starters, do you believe it would make any difference if the C or C++ standard defined how the language should handle dereferencing a null pointer? I mean, in some platforms NULL is a tombstone, but on specific platforms NULL actually points to a valid memory address. The standards purposely leave this as undefined. Why is that? Seriously, think about it for a second.

    Am I blaming those languages? Nah, it was a different time.

    It really isn't. It's a design choice that reflects the need to work with the widest possible range of platforms. The standards have already been updated with backwards-incompatible changes, but even the latest revisions purposely include UB.

    I repeat: I see people mindlessly parroting nonsense about UB when they clearly have no idea what they're talking about.

  • Memory Safety is a Red Herring

    Jump

  • I use C++ all the time, undefined behavior is not something I encounter ever. I run undefined behavior sanitizer often.

    From the looks of some of the posts showing up in this thread, I doubt the bulk of the commenters portraying UB as the root cause of any problem have any experience at all with C or C++. They are clearly resorting to unrealistic strawmen to pretend UB is something that it clearly is not. That just goes to show their technical background and the substance behind their claims. I really don't know how this helps advocating for Rust.

  • Memory Safety is a Red Herring

    Jump

  • Doesn’t change the overall quality of the article ?

    I'm sorry, but I'm afraid the article is quite good.

  • Memory Safety is a Red Herring

    Jump

  • It was really bad because the author in his 11y of writing Rust never once heard about the philosophy of Rust/Unsafe Rust.

    You're talking about Steve Klabnik, a guy known for being one of the authors of The Rust Programming Language and the guy who literally ran the @rustlang Twitter account.

  • Memory Safety is a Red Herring

    Jump

  • Ive never gotten to write rust professionally, but I have always kinda winder d if it was marketed wrong. My thought was always that it should be sold as “easy” though. Its easy to write code. It’s hard(er) to make mistakes.

    I agree, but I don't think the problem is marketing. The problem is how some elements of Rust's community desperately try to upsell the language beyond the value it actually can provide, and once that fails they fall back to toxic behavior and basically just mindlessly shitting on anything that's not Rust. It goes well beyond a cargo cult mentality, and it's sad that a fine technology is dragged through the mud by those who were expected to show its value.

  • Memory Safety is a Red Herring

    Jump

  • Dangling pointers, double frees and the like, mostly.

    Those are bugs you wrote in. UB is not the problem. Your code is the problem.

    Tell me you haven’t run into those and I’ll laugh in your face and call you a liar.

    I ran into bugs. Do you understand that UB is not the problem if you're pushing broken code? It's not the C++ standard that's messing up if you're writing in use-after-free bugs.

    The irony of your comment is that some implementations take advantage of UB to prevent programs from crashing and actually continue to work in some scenarios such as use-after-free and even dereferencing null pointers. But that's not caused by UB, is it? Those problems are caused by developers like you and me who didn't knew what they were doing and even failed to either pay attention to the errors flagged by compiler and static code analysis tools, or even failed to onboard one.

    I mean, think about it for a second. Let's say we have a magic wand that can update any C and C++ standard version of your choosing, and we specify that each and every single instance where behavior is left undefined is updated to specify that the program should automatically crash. Awesome, no more UB. What does this mean for your code? Is it now bug-free? Is it now working well after crashing all the time due to the code you added? What role did UB played in this mess?

    Do you understand this?

    I repeat: detractors just parrot undefined behavior as some kind of gotcha in ways I’m not even sure they fully understand.

  • Memory Safety is a Red Herring

    Jump

  • Some people also feel strongly about topics they are very familiar with 🙂. I have experienced my fair share of undefined behaviour in C++ and it has never been a pleasant experience.

    If you had half the experience you claim to have, you'd know that code that triggers UB is broken code by definition, and represents a bug that you introduced.

    It's not the language's fault that you added bugs to the code. UB is a red herring.

    Sure, sometimes use of undefined behaviour works (...)

    You missed the whole point of what I said.

    By definition, UB does not work. It does not work because by design there is no behavior that should be expected. By design it's up to the implementation to fill in the blanks, but as far as the language spec goes there is no behavior that should be expected.

    Thus, code with UB is broken code, and if your PR relies on UB then you messed up.

    Nevertheless, some implementations do use UB to add guardrails to typical problems. However, if you crash onto a guardrail, that does not mean you know how to drive. Do you get the point?

  • C++ Should Be C++

    Jump

  • Where he gives plenty of examples of UB resulting in the compiler optimizing away safety and introducing security vulnerabilities silently.

    That's the bit that those who parrot on abot UB get entirely wrong, and yet cling to it if it was something meaningful.

    Let's make this absolutely clear: any code you write that triggers UB is a a bug you introduced. Your complains about UB boil down to blaming the language for bugs you created because you didn't knew what you were doing.

    As you can configure compilers and static code analysis tools to flag UB as warnings or even errors, the discussion of using UB in your code is a discussion on incompetence. Complaining that a programming language purposely leaves out the specification of the behavior that broken code should have because you don't know what you're doing is the definition of a bad workman blaming his tools.

    If you paid attention to the article you're quoting, you'd notice that even the author makes it quite clear that programs with UB only "appear to work". That boils down to the definition of UB, and the reason why every single developer in the world who had any intro to C or C++ experience knows quite well that UB means broken code. Why is it hard for you to understand this?

  • Programming @programming.dev
    lysdexic @programming.dev

    10 Things Software Developers Should Learn about Learning

    cacm.acm.org /magazines/2024/1/278891-10-things-software-developers-should-learn-about-learning/fulltext

  • Memory Safety is a Red Herring

    Jump

  • Each implementation that exhibits different behavior doubles the amount of testing needed to ensure cross-platform correctness.

    Not really. The whole point of undefined behavior is that the standard intentionally leaves out any definition of behavior, or the program is already fundamentally broken.

    If you insist on unwittingly using code that relies on undefined behavior, you're the one mindlessly writing broken code. It's not the standard's fault that you're adding bugs.

    The irony is that compiler implementations also leverage undefined behavior to save you from yourself and prevent programs to crash when they stumble upon the mess you've done with the code.

  • Memory Safety is a Red Herring

    Jump

  • what is the usecase for going beyond maxint?

    There are many examples of applications that leverage integer overflow, either wrapping around or saturating values.

  • Memory Safety is a Red Herring

    Jump

  • What do you mean wrong “already”?

    This is one of the problems in these discussions about undefined behavior: some people feel very strongly about topics they are entirely unfamiliar with.

    According to the C++ standard, "undefined behavior may be expected when this document omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data." Some examples of undefined behavior still lead to the correct execution of a program, but even so the rule of thumb is to interpret all instances as wrong already.

  • C++ @programming.dev
    lysdexic @programming.dev

    Learn Modern C++

    learnmoderncpp.com