• million@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    2 years ago

    Refactoring is something that should be constantly done in a code base, for every story. As soon as people get scared about changing things the codebase is on the road to being legacy.

    • NoXzema@lemmynsfw.com
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 years ago

      Been with a lot of codebases that had no unit tests at all and everyone was afraid to change anything because the QA process could take weeks to months.

      The result is you have a codebase that ages like milk.

  • fubo@lemmy.world
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    2 years ago

    Until you know a few very different languages, you don’t know what a good language is, so just relax on having opinions about which languages are better. You don’t need those opinions. They just get in your way.

    Don’t even worry about what your first language is. The CS snobs used to say BASIC causes brain damage and that us '80s microcomputer kids were permanently ruined … but that was wrong. JavaScript is fine, C# is fine … as long as you don’t stop there.

    (One of my first programming languages after BASIC was ZZT-OOP, the scripting language for Tim Sweeney’s first published game, back when Epic Games was called Potomac Computer Systems. It doesn’t have numbers. If you want to count something, you can move objects around on the game board to count it. If ZZT-OOP doesn’t cause brain damage, no language will.)


    Please don’t say the new language you’re being asked to learn is “unintuitive”. That’s just a rude word for “not yet familiar to me”. So what if the first language you used required curly braces, and the next one you learn doesn’t? So what if type inference means that you don’t have to write int on your ints? You’ll get used to it.

    You learned how to use curly braces, and you’ll learn how to use something else too. You’re smart. You can cope with indentation rules or significant capitalization or funny punctuation. The idea that some features are “unintuitive” rather than merely temporarily unfamiliar is just getting in your way.

    • Walnut356@programming.dev
      link
      fedilink
      arrow-up
      0
      arrow-down
      1
      ·
      2 years ago

      Please don’t say the new language you’re being asked to learn is “unintuitive”. That’s just a rude word for “not yet familiar to me”…The idea that some features are “unintuitive” rather than merely temporarily unfamiliar is just getting in your way.

      Well i mean… that’s kinda what “unintuitive” means. Intuitive, i.e. natural/obvious/without effort. Having to gain familiarity sorta literally means it’s not that, thus unintuitive.

      I dont disagree with your sentiment, but these people are using the correct term. For example, python len(object) instead of obj.len() trips me up to this day because 99% of the time i think [thing] -> [action], and most language constructs encourage that. If I still regularly type an object name, and then have to scroll the cursor back over and type “len(”, i cant possibly be using my intuition. It’s not the language’s “fault” - because it’s not really “wrong” - but it is unintuitive.

  • words_number@programming.dev
    link
    fedilink
    arrow-up
    2
    ·
    2 years ago

    JS is horse shit. Instead of trying to improve it or using that high level scripting language as a compilation target (wtf?!), we should deprecate it entirely and put all efforts into web assembly.

  • Buttons@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 years ago

    Shorter code is almost always better.

    Should you use a class? Should you use a Factory pattern or some other pattern? Should you reorganize your code? Whichever results in the least code is probably best.

    A nice thing about code length is it’s objective. We can argue all day about which design pattern makes more sense, but we can agree on which of two implementations is shorter.

    It takes a damn good abstraction to beat having shorter code.

    • TanakaAsuka@sh.itjust.works
      link
      fedilink
      arrow-up
      1
      ·
      2 years ago

      I mostly agree with this but more than shorter code I value readability, I would rather take 3 lines to be clear to any developer than use some obscure or easy to misunderstand structure to write it in 1.

  • enemenemu@lemm.ee
    link
    fedilink
    arrow-up
    1
    ·
    9 months ago

    Don’t be afraid to drop a tool although you’ve spent years mastering it if there is something new that is much more efficient. Some day you have to switch anyway.

  • OADINC@feddit.nl
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    2 years ago

    This is the only way;

    if (condition) {
        code
    }
    

    Not

    if (condition)
    {
        code
    }
    

    Also because of my dyslexia I prefer variable & function names like this; ‘File_Acces’ I find it easier to read than ‘fileAcces’

  • Kushan@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 years ago

    That the entire industry is cyclical and the current trends are yesterday’s anarcisms. Oop Vs functional, separating concerns Vs vertical slices, there’s examples all over the place.

    All of this has happened before and all of this will happen again.

  • lefixxx@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 years ago

    I like 1-index because its what I learned first, and you like 0-index because that’s what you learned first

  • escapesamsara@discuss.online
    link
    fedilink
    arrow-up
    1
    ·
    2 years ago

    Python is legitimately the best language by far for the vast majority of non-performance critical tasks, and most tasks that need to be developed for are not performance critical.

  • Masterkraft0r@discuss.tchncs.de
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    2 years ago

    As an embedded firmware guy for 10ish years:

    C can die in a fire. It’s “simplicity” hides the emergent complexity by using it as it has nearly no compile time checks for anything and nearly no potential for sensible abstraction. It’s like walking on an infinite tight rope in fog while an earth quake is happening.

    For completely different reasons: The same is true for C++ but to a far lesser extent.

  • gpopides@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    2 years ago

    Not everything should be beginner friendly. Trying to nerf things because they are not beginner friendly should not be how tools/patterns of languages are designed.

    Its ok to have more advanced topic that require more knowledge and that people don’t understand from the first moment they see them.

  • argv_minus_one@beehaw.org
    link
    fedilink
    arrow-up
    1
    ·
    2 years ago

    Dynamic typing is insane. You have to keep track of the type of absolutely everything, in your head. It’s like the assembly of type systems, except it makes your program slower instead of faster.

    • Cratermaker@discuss.tchncs.de
      link
      fedilink
      arrow-up
      1
      ·
      2 years ago

      Nothing like trying to make sense of code you come across and all the function parameters have unhelpful names, are not primitive types, and have no type information whatsoever. Then you get to crawl through the entire thing to make sense of it.