*If you could ban something from the field of programming forever, what would it be? 👀

*Pls. don't ban me thx c:

  • 12
    White background in IDE and editors
  • 10
  • 16
  • 0
    Anything that was the brainchild of Steve Sanderson.
  • 7
  • 8
    Exploitative licensing models
  • 6
    Leonnard Poettering.
    His entire existence, gone.
  • 8
    Javascript, hell just ban Java too.
    PS. Webassembly and Kotlin still exist, so nobody should be too sad.
  • 5
    I would go for PHP. It makes me cry
  • 6
  • 2
    Toss up between Lennart Poettering and emotions.

    I'd normally say stupidity, but some very smart people base their decisions on emotion, and therefore still make poor choices. Then again, banning emotion would result in stupid people still being able to make stupid decisions.

    So let's just ban Poettering.

    Then again we could also ban corruption... that's probably the best choice. but Poettering isn't corrupt. 🤦‍♀️

    Can I ban two things?
  • 13
    Not literally directly related but; fucking trackers and non-privacy-respecting analytics.
  • 3
    @linuxxx We could generalize and include most of these.

    Ban anything against the user's best interest / anything harmful to the user.

    That would include spying, malware, removal of user control, misleading tricks, Lennart Poettering, adware, selling of data, manipulation, ....
  • 1
  • 2
    Today I would ban Edge. Fucking pissed at Edge.
  • 3
    @Root You would ban the lion share of Microsoft and Google business models. Thank you. I will vote for you. You should run for office. Don't care what, just run.
  • 1
    NULL pointers - or maybe all manual memory management.

    So many bugs and problems gone.
  • 0
    @Root You're saying to ban all software that's either non-free or needlessly headache-inducing.
  • 5
    @phorkyas Nah man. Don't ban efficient code.
  • 2
    Ignorant fucktards.

    - this is my code. what have you done?
    - I don't Inderstand this. It's bad. leave it like it is.
    - Yeah. This is concerning in many ways, but we don't have time. Just ignore it.
    - I don't think we should bother about working in teams - everyone should focus on his own project and work the way they like it.

    - many many many many many more examples come to mind -

    What a joy working could be.
  • 2
    Programming language vs. programming language / spats.

    I'd rather just get to solving the problem at hand.
  • 0
    @kescherRant It's 2020, garbage collection is around for 61 years,.. but you still want to bash the JVM, Go or Rust for being slow or ineffecient for not going down to the unsafe raw pointers?
  • 1
    Religious, idealogical wars - zealots.
  • 6
    @phorkyas there are environments where manual memory management is the only way to go, such as embedded devices - especially mission-critical ones, like satellites.
  • 6

    "unsafe raw pointers"

    This idea of safety is an ideologue argument against knowing what the fuck you are doing.
  • 4
    @phorkyas I use both kinds of memory management, depending on the use case. Removing either would be braindead as fuck.

    Take away the convenient garbage collection in many modern languages, and suddenly people can't fucking code anymore.
    Take away the """unsafe""" (yeah it's only unsafe if you have no clue what you're doing) raw pointers and manual allocation and freeing, and you can may no longer have code running on low-power devices at all (such as your goddamn SIM card!)

    These things are not being done without a good reason.
    Also, very optimized code must be written with manual memory management, or it'll suffer.
  • 5
    @phorkyas "unsafe"? Go back to basics and learn some freaking C.
  • 2

    Nowadays (with the introduction of v3) it serves no purpose than to bully and act elitist.

    No, it doesn't serve the idea of freedom, because freedom includes the ability to do what you want with your own creations; Something GPLv3 actively inhibits.
  • 0
    @kescherRant @root Well it's just that manual memory management accounts for 70% of security bugs (sauce: https://zdnet.com/article/...) - but maybe you are better than the Chrome engineers who also shoot some serious fuzzing at their code, or are more ingenious than djb whose qmail got exploited finally.

    Of course there has to be some low level language close to the metal. But why has it to be C? Why not Rust, Lisp or JS (just kiddin)? Because that's the way we have been doing it for years and all the friggin' toolchains are now build like it and depend on it, because it "just works"? Am I not allowed to dream of another type of computing, isn't it supposed to be universal, independent of the physical device and language you use?
  • 2
    @phorkyas GCs, like all layers of abstraction, are incredibly inefficient. They're also slow and wasteful. If you want speed and resource efficiency, look elsewhere. As with all things, if you want it done right, do it yourself.

    Now, if you're building something as sprawling and complicated as Chromium, a GC will absolutely save you many headaches. However, I can guarantee that you are not. Hiding behind this idea so you don't have to learn memory management is childish and will only hinder you.
  • 2
    @phorkyas Yes, it accounts for 70% of security bugs.
    If you make a mistake, it opens security holes.

    However, if this was the approach taken by the Linux kernel, nobody would use the Linux kernel, because it would be too fucking slow.

    Besides, I've mentioned that both approaches have their uses. I am fully aware of the pitfalls of both approaches.
  • 2
    @phorkyas Also, you are allowed to dream about this stuff being universal, but it can't happen, due to the inherent differences in architecture that would first have to be abstracted away, causing performance slowdowns on already slow devices.
  • 1

    >As with all things, if you want it done right, do it yourself.

    Like crypto ;-)

    @kescherRant: As much as I like Linus and his stance that all the implementation details matter, I think it's just wrong to see C++, OOP or abstraction in general as opposing performance. Having a type system with which you can express invariants may not only make it easier for the developer to reason about the code, but even allow compiler optimization (remember Carmack the const-Nazi) - E.g. here Apple claims that moving from C to a subset of C++ they could make their drivers 75% smaller: https://developer.apple.com/library...

    I know C is still the king of kernels, and Symbian and BeOS died, but I have already wasted too much life time hunting other's poeple C-string off by one errors, especially if it's causing a kernel panic in production code it's no fun anymore.
  • 1
    @phorkyas I agree, certain abstractions are helpful.
    But C++ still has no real GC.
  • 1
    People using languages like python or JS for embedded development
  • 1
    @PlatinumFire GPL is basically a communists idea of freedom
Add Comment