Comments by "Edward Cullen" (@edwardcullen1739) on "ThePrimeTime" channel.

  1. ​ @louisf2506  Completely agree. 90% of development is understanding the problem. Using a fast prototyping language, like Python makes a lot of sense in this context. This is precisely the mentality recommended by the creator of Python.
    133
  2. Imposter Syndrome is a complex state of being. It only impacts highly conscientious people. It is a mix between anxiety and caring about performing at the right level. Imposter syndrome is as much a product of the work environment as it is of individual psychological characteristics. 70% of top performers have experienced imposter syndrome at some point.
    90
  3. This is the problem with weak leadership.
    58
  4. Yep. Still struggle to comprehend how people can't see past programming language as the problem when it comes to large projects. 🤷‍♂️ The problem of scale is the problem of scale, not programming language.
    51
  5. Which is kinda missing the whole point. The point of "write maintainable code" is to get devs to think beyond "it compiles" mentality. (Edit: typo)
    27
  6. ​ @InterpretingYou  Sanity? Nah, you have to have belief that things can be different to first. Ed has no belief. Ed knows that this is the way things are, always have been and always will be.
    25
  7. The whole JavaScript ecosystem is insane. Every project I've worked on seems to download the entire Internet. There was even one library that needed Python to build it. 🤦‍♂️🤦‍♂️🤦‍♂️
    24
  8. Concur. "Micro ORM"s, like Dapper, that automate the Object-ification of query results are where the usefulness of ORMs start and finish.
    23
  9. Agreed. The author doesn't really understand the distinction between the System Call Interface and the C wrapper library that most people interact with. He does not understand that all C implementations are exactly that and they have freedom to do their own thing. This is not a failure of C or even other languages, it is the nature of the beast and he is simply unaware that people "don't bother" writing their own SysCall wrappers - they just reuse glibc or whatever. The Linux System Call Interface is fixed and Linus does a LOT to ensure it never breaks (the rants he has about this 😅...) There is nothing to stop Rust from implementing a SysCall wrapper library that bypasses glibc. They just haven't done the work.
    20
  10. Usually, the person writing the code will be better than the person who will have to maintain the code. True skill is the ability to take complex ideas and express them as simply as possible. A mid-tier fresh graduate should be able to read and comprend your code. The issue is when you have "god tier" devs who write code that's beyond all human comprehension. It's part of the idea that developer responsibility extends beyond "I checked it in and it passed the compile check".
    17
  11. "How not to handle getting laid-off Millennial/Gen Z edition."
    12
  12. This is why engineers constantly complain about "managers". Managers fear anything they do not understand.
    10
  13. Totally. I mean, Dilbert didn't: 1. Come out of nowhere 2. become popular because it had not relation to people's experiences. 🤷‍♂️
    10
  14. You just described "requirements discovery"...
    9
  15. This author could have saved us all some time by saying "Good engineering is hard, time consuming and expensive." Overall he contradicts himself. He says "DevOps bad", but then says you need people with skills in both areas. 👍🤦‍♂️ Here's the "secret" of DevOps: it's just good Systems Engineering. We just call it DevOps for the benefit of management types who don't know DNS from a runaway chain reaction. So much of what he complains about, is a sign that there are architectural issues or that the system has outgrown the staffing levels. Also, his advocating for "engineers should be able to do whatever the hell they like" is about the most retarded thing I've heard in a loooong time. Holy sweet Jesus! Have you ever had to support a heterogeneous environment? Ever had to take one over? Yes, you need to be using the most appropriate tools for a job, but what tools you have must be used consistently, so that others can unpick your mess when you leave. Does this mean that larger organisations become more stiltified? YES, OF COURSE IT DOES, because that's the fucking DEFINITION of a "big business". Frankly, this guy comes across as "just" a programmer (not least of all because of his "hobbyist" comment!!!), who doesn't like doing serious engineering. I'm a serious professional, fuck-you-very-much. I'm not a "hobbyist". This shit is HARD and made harder by tools like this that refuse to accept that engineering is about compromise. Further, devs who have "no interest in the platform" are, by definition, amateurs; F1 drivers know almost as much about the cars as the people that designed and built them. This is the attitude that software engineers need to have about platform.
    8
  16. But useless... 😂
    8
  17. ​ @phillipsusi1791  You're suffering the same lack of understanding that the author of the article does. Whatever standard library has will provide all the same kinds of functionality as glibc, except it relies on glibc to handle syscalls. There is nothing stopping the Rust maintainers from implementing their own SysCall wrappers. Easier on Linux/Unix, not so easy on Windows... But if Rust really is "the future", Microsoft will start to implement a native Rust interface anyway... As to the question of "unstable SysCall interface"... This is answered by Linus MANY "do not break userland" rants; if this is an issue, use a better-managed OS/kernel.
    8
  18. ​ @TehKarmalizer  Yeah, I need to use C++ for it's power, but desperately want to be using C for its simplicity. I was a pretty competent C++98 programmer, but life has prevented me from keeping-up with C++ and it's a completely different language now and I basically need to start from scratch. 🤷‍♂️🤦‍♂️
    7
  19.  @sqeaky8190  Here's a thought: If it can (only) "pass" or "fail", it's a test. Otherwise, it's an evaluation. If it's a test - binary - then computers can do that. If computers can do it, they can probably do it better (cheaper) than a human. If it's cheaper for a computer, then it should be done by a computer. If your requirements are expressed correctly, they should be translatable to binary checks (does it do this?), which means they are testable. If it's testable, then is should be done by a computer - automated. Cucumber is a means of automating testing to requirements. Cucumber didn't "co-opt" BDD, it is a necessary and logical conclusion of BDD. If Cucumber is bad, write a better tool, but don't dismiss the technique underlying it. (I'm on the fence with Cucumber as a tool; haven't spent enough time exploring alternatives)
    7
  20.  @phillipsusi1791  Right, the article doesn't mention syscalls, because the author doesn't know what a syscall is. Because he doesn't know what a syscall is, in HIS MIND the only way to do certain things is to use C. This belief is what underpins the title "C is not a Language". I AM NOT ALONE IN DRAWING THIS CONCLUSION! The OP of this thread and many others have had this same insight. The original author also has some difficulties around appreciating the flexibility implementors have when it comes to the C language - where he's complaining about the variation in ABI between clang and GCC/glibc. Indeed, the original author betrays a lack of understanding of what an ABI even is! Application Binary Interference is not System Call Interface; he does not appreciate that incompatible ABIs between clang and GCC are normal as each C implementation defines their own ecosystem, in the same way a Java library and a python .pyc are different. Would it be better if GCC and clang had mutually compatible ABIs? Probably, but there is no requirement, because that's not how C works - because C IS a language, NOT a comprehensive ABI specification!!!
    7
  21.  @Helvanic  That's flat wrong. The purpose is to ensure your code does what you intend it to - no more, no less.
    6
  22.  @samjohns8381  Design is not requirements. Maybe TDD has evolved since Beck wrote his book? 🤔 The origins and evolution of a technique are not the issue at hand, the applicability to now is. That said, the corpus of software engineering between the late 90s until the mid 2010s was heavily focused on optimising requirements elicitation, as this was seen as the greatest challenge in practical software delivery. What you are describing is "how do I deal with a customer who doesn't know what they want?" which is both within the requirements elicitation space and Beck's key interests as an author. I say again: separate the what your code is trying to achieve from how you are going to achieve it. By definition what is a requirement, how is design. If you have the what, then your tests should remain consistent (you ARE testing at the interface, right???), which means you're then free to change the how any way you want. API design is basically a solved problem, so major revisions shouldn't be necessary, if you've put the effort in up front. But designing your APIs right means understanding the problem, which implies having clear requirements... Which returns us to the beginning.
    6
  23. ​ @amafi_poe  or you just don't care, because you've made hundreds of millions 🤷‍♂️
    6
  24. "Makes refactoring easier." Not when you have real-world amounts of data. For toy databases, sure, but "refactoring" database tables for serious applications is no joke and ORMs are more of a hindrance than a help. Something like Dapper is good, for eliminating the tedium of Object-ifying query results, but direct table access and ORM-generated queries are simply the route to a long-term maintenance nightmare.
    6
  25. ​ @braincruser  This isn't extortion, it's enforcing their legal rights under trademark law. You need to do a basic course on trademark law?
    6
  26. The C shift op is defined as 0-fill. IIRC, x86 supports all flavours of shifting - 0-fill, 1-fill and rotate. I even have a vague recollection of some really funky ones (it's been 20 years, okay? 😂), but I could just be misremembering.
    5
  27. This is not true. The author does not understand the distinction between the System Call Interface and the glibc wrapper. There is no reason preventing Rust from implementing its own wrapper around system calls on each platform. There were many, many misunderstandings that boil down to "Yes, this shit is hard. If you want to do it properly, you need to do the work."
    5
  28. ​ @phillipsusi1791  Correct answer. This is exactly where people fall down; they think if the language definition in terms of the implementation they're used to. There is nothing stopping an implementation where sizeof(...) char == short == int == long.
    5
  29. The only value of code coverage is during development: if your code coverage has dropped (significantly), you have definitely missed something.
    5
  30.  @buc991  Because JS isn't a programming language. More to the point, JS programmers do not take responsibility for the shit they use. The ecosystem for other languages are not nearly as bad. The fact that "no one uses NPM anymore", because they all use something else that tries to manage the dependency hell, says it all.
    4
  31. This is as true as it is false. There's many reasons for this, least of which is that libraries are badly written or only supported on one platform.
    4
  32.  @neociber24  Humour lost in translation, I think... Maintainability goes far deeper than simple styling issues.
    3
  33. Embrace the low-level nature. Understand everything, from the hardware, through operating system and programming. This is how you will survive against AI.
    3
  34. Agreed. SQL desperately needs replacing with better RDBMS language that implements the 40 years of experience we have with DBs...
    3
  35. Just because he's "wrong," doesn't mean he's a bad person... There are a LOT of things that he's right about, not necessarily clean code though...
    3
  36. ​ @siniarskimar  LOL, yeah, same. Because that's how most people react when they have to use it. 😂
    3
  37.  @sk-sm9sh  Amen! Couldn't agree more!
    3
  38. ​ @TomNook.  Yeah, I've never been able to use my preferred style (which is objectively better, obviously 😉) because someone else has already defined a style I need to adhere to.
    2
  39.  @HirokuDev  Thanks. Exactly. I was clearly very angry when I wrote this. 🫣😂 I am passionate about my job; no apologies offered. 🤷‍♂️
    2
  40. Or... Just don't pass to the shell?!?!? Maybe I'm old or something, but I don't understand why people are still doing this. I avoid it like the plague, even porting logic from 3rd-party batch files into a proper language, simply because it's a saver in the end.
    2
  41. My experience is that most ORMs are dumb as a brick and about as useful when it comes to real-world software. I have direct knowledge of one well-known piece of software that had to engage in a complete rewite of their DB layer because the ORM became a performance bottleneck. This is worse than it sounds, because you have to mix the ORM code with hand-written stuff, so it becomes an absolute nightmare to maintain. Fun, if you're deeply into SQL/are a complete masochist. But for normal people, not so much...
    2
  42.  @ComputersAndLife  Sorry, you don't know what you're talking about. There's a lot of research on Imposter Syndrome and it is generally pretty well understood. When I'm talking about "environment", I mean the attitude of the people around you and whether they are supportive and whether you're getting appropriate performance feedback. Being around other high performers is more likely to be good for a sufferer, because you're more likely to encounter someone who is also suffering or has in the past and can provide guidance and support on overcoming.
    2
  43. Holy crap, loves Ruby and JS??? Ruby is okay, I guess, apart from aiming to be a "cleaned-up Perl", which is a dubious objective at best and JS? JS isn't a programming language.
    2
  44. I don't understand this CVE. It is NEVER safe to pass "untrusted" arguments to a shell. Regardless of the issues with Rust's implementation, if you're passing unsanitised user input, you've already failed.
    2
  45.  @timseguine2  Ah, I get you. What I'm trying to let people know is that "passing user-provided input to a shell" is a well-known vulnerability, with a long and shameful history. Remember the Bash CGI-bin crisis a few years ago? It doesn't matter whether it's Unix or Windows or how the OS parses the arguments - the only safe way to invoke a sub-process shell is to thoroughly vet any user input before passing it. The sub-process shell is the gun. Any parsing done by Rust or C runtime is only a trigger guard, not a safety. A .bat file is interpreted by the shell, as a .sh file would be (though, the precise method for doing so is different, which is where this issue arrises).
    2
  46. ​ @Acorn_Anomaly  "Yes, you honour, we made repeated efforts to engage WP Engine in constructive dialogue and contract negotiations to resolve the Trademark dispute and made repeated public statements to that effect, but they failed to engage with the legal copyright and trademark holder, so, here we are." I think you do not appreciate how legal process works. 🤷‍♂️
    2
  47. ​ @nerdycatgamer  Yeah, the way they teach in schools/universities is really bad (I went to a top university...) They emphasise developing the coding skills, so people get conditioned into thinking that "everything else" isn't as important. Experience teaches that this is completely backwards.
    2
  48.  @an0nsaiko890  The original article author implies that he believes that the only way to access syscalls is via C functions. The OP of this thread and I both drew this same conclusion. And both myself and the OP of this thread have implied the same - that if the original author understood how syscalls worked, he would not have written the article in the same way. It seems like people have jumped into the conversation half-way through, completely ignored the context of this thread, completely ignored my previous posts and are now ascribing the same lack of knowledge/understanding of the original author to me, which is absurd.
    2
  49.  @andreipangi  Opinions can be objectively wrong. You can have the opinion that Pi is 3, which would be wrong. This is another example. Again, it's not the C language that is the "protocol", it's the C function call interface and the syscall interface. As this varies by OS and C implementation, your assertion that other languages/runtimes would be "wrong" to implement their own syscall interface(s) is simply a demonstration of your lack of understanding of the subject. Your assertion that it would "add a lot of bugs" is the silliest argument - all software is buggy, therefore, never write anything new, because it will have bugs. 🤦‍♂️ Breaking assumptions is precisely the point - people want to be able to write "pure Rust", rather than having to "switch to C". Inter-code communication is precisely the issue and the desire to not have to do it. Again, this is all showing confusion about the topic and a general lack of understanding of what the real problems are. C is a language specification that gives broad latitude to implementors to make their own decisions, based on their needs and the needs of the OS and hardware they're running on. Failing to understand the distinction between the C language specification, a particular C implementation and the OS syscall interface (which can be accessed directly using assembly language), is the problem the OP has.
    2
  50. This is a perfect example of a broken organisation. The quick fix should have been committed immediately with the deeper changes being better planned. Yes, it might languish at the end of the now 4-month-long queue, but but that's a wider problem of how they deal with technical debt.
    2