• 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.

    •  Olissipo   ( @Olissipo@programming.dev ) 
      link
      fedilink
      English
      1
      edit-2
      1 year ago

      I like it in modern PHP, it’s balanced. As strict or as loose as you need in each context.

      Typed function parameters, function returns and object properties.

      But otherwise I can make a DateTime object become a string and vice-versa, for example.

      • What happens when you coerce a string to a date-and-time but it’s not valid?

        Where I’m from (Rust), error handling is very strict and very explicit, and that’s how it should be. It forces you to properly handle everything that can potentially go wrong, instead of just crashing and looking like a fool.

        • My point is, you won’t ever try. You’d only use “weak” variables inside the function you’re working on.

          It’s explicit when you absolutely need it to be, when the function is being called and you need to know what arguments to pass and what it’ll return

            • When you say user, you mean a user of a function? In that case PHP would throw a TypeError, and presumably only happens when developing/testing.

              If you mean in production, like when submitting a form, an Exception may be thrown. In which case you catch it and return some error message to the user saying the date string is invalid.

              • By “user” I mean the person who is using the application.

                Using exceptions for handling unexceptional errors (like invalid user input) is a footgun. You don’t know when one might be raised, nor what type it will have, so you can easily forget to catch it and handle it properly, and then your app crashes.

                • you can easily forget to catch it and handle it properly

                  Even if I coded the form by hand and that happened, it’s on me, not on the programming language.

                  But I don’t, I use a framework which handles all that boilerplate validation for me.

  • If you don’t add comments, even rudimentary ones, or you don’t use a naming convention that accurately describes the variables or the functions, you’re a bad programmer. It doesn’t matter if you know what it does now, just wait until you need to know what it does in 6 months and you have to stop what you’re doing an decipher it.

  • My take is that no matter which language you are using, and no matter the field you work in, you will always have something to learn.

    After 4 years of professional development, I rated my knowledge of C++ at 7/10. After 8 years, I rated it 4/10. After 15 years, I can confidently say 6.5/10.

  •  Vince   ( @Vince@feddit.de ) 
    link
    fedilink
    51
    edit-2
    1 year ago

    Not sure if these are hot takes:

    • Difficult to test == poorly designed
    • Code review is overrated and often poorly executed, most things should be checked automatically (review should still be done though)
    • Which programming language doesn’t matter (within reason), while amount of programming languages matters a lot
    • I agree with your first point, but pretty strongly disagree with the other two. Code review is critical. Devs should be discussing changes and design choices. One Dev can not be all things all the time and other people have experience you do not or can remind you of things you forgot. Programming language absolutely matters when you’re not the only dev on the team.

      • Nice, so they are hot takes :D

        If the design of a code change is bad, noticing that in the PR stage is not desirable. It should be discussed before someone actually went ahead and implemented it. It can also happen if people misunderstand the architecture, but again, that should be cleared up before actually implementing a change. Code style should be enforced automatically, as should test coverage and performance. Code review is also pretty bad at finding bugs from my experience. That imo leaves very few things where code review is useful that are not nitpicking.

        As for programming languages, the amount does matter for individuals and for teams/organisations. A developer who can only use a single language is not very good, and using a many different languages within the same team is not good either.

    • Code review is overrated and often poorly executed, most things should be checked automatically (review should still be done though)

      I think part of this is caused by the fact that a lot of people are bad at code reviews so they focus on things that a linter could have told you. Being able to read code isn’t necessarily the same skill as being able to write it – as evidenced by the knee jerk reaction to throw out any coffee we didn’t write ourselves.

      I still create code reviews when I’m working on a project alone because it gives me a different perspective on the changes I’ve made.

      • It’s not that most people are bad at it, they are just out of context.

        Like, I am completely swamped with a completely different business area of the code, besides checking for obviously dumb things, what can I really tell about a diff to a very separate part of the code which I may have never worked on before, with business requirements I don’t understand as I was not part of the 10 meetings that happened between the dev of the given ticket and BAs?

      • But does it have to be? I haven’t touched non-web GUIs since 15 years, so my perspective on this is limited. And web frontend is not what I would call a well designed system for it’s current purpose.

    • I’ve been wanting to make my applications easier to test. The issue is, I don’t know what to test. Often my issues are so trivial I notice them immediately.

      What are some examples of common things in, let’s say a web server, that could be unit tested?

      • Good questions, I could probably write a lot, but I’ll try to keep it short. I usually apply TDD and there are different schools of thought within it about how to structure the development process. But no matter how exactly you do it, if you focus on writing the tests while writing your code, you won’t end up with an application that you then have to figure out how to test.

        what to test

        Well, what is the application supposed do? That is what you test, the behaviour of the application.

        So in a codebase without any tests, the first thing you should write a test for is the happy path. That will probably not be a unit test. So for the web server example, set it up in a test with a file, start it and check if it serves that file.

        Then you can add tests for all the error cases and for additional functionality. You can write unit tests for individual components. The ideal places to test are interfaces with clear boundaries. Ideally you should not have to look at the code of a method to be able to write a test for it. In reality that’s not always so easy, especially in existing code bases, but if you have to set up more than one mock, it tends to lead to brittle tests.

        Every time you encounter a bug/issue, reproduce it in a test first. And do measure code coverage, but don’t make it a target, just check for places that are lacking.

  • SPAs are mostly garbage, and the internet has been irreparably damaged by lazy devs chasing trends just to building simple sites with overly complicated fe frameworks.

    90% of the internet actually should just be rendered server side with a bit of js for interactivity. JQuery was fine at the time, Javascript is better now and Alpinejs is actually awesome. Nowadays, REST w/HTMX and HATEOAS is the most productive, painless and enjoyable web development can get. Minimal dependencies, tiny file sizes, fast and simple.

    Unless your web site needs to work offline (it probably doesn’t), or it has to manage client state for dozen/hundreds of data points (e.g. Google Maps), you don’t need a SPA. If your site only needs to track minimal state, just use a good SSR web framework (Rails, asp.net, Django, whatever).

    • I do a lot of PHP, so naturally my small projects are PHP. I use a framework called Laravel, and while it is possible to use SPAs or other kinds of shit, I usually choose pure SS rendering with a little bit of VueJS to make some parts reactive. Other than that, it is usually, just pure HTML forms for submitting data. And it works really well.

      Yeah yeah, they push the Livewire shit, which I absolutely hate and think is a bad idea, but nobody is forcing me, so that’s nice.

        • I’m thinking more along the line of ubiquitous offline first PWAs. Imagine google doc running offline in a browser and being able to edit local docs directly. I guess secure file system access is one of the major road blocks, though I’m not sure of the challenges associated with coming up with a standard for this.

      • Counter hot take, I do actually like Blazor but it has limitations due to how immature web assembly still is. It also does not solve the problem of being a big complex platform that isn’t needed for small simple apps. Of the half dozen projects I’ve written in Blazor, I’d personally re-write 3 or so in just Razor Pages with Htmx.

    • Python is only good for short programs

      Was Python designed with enterprise applications in mind?

      It sounds like some developers have a Python hammer and they can only envision using that hammer to drive any kind of nail, no matter how poorly.

      •  witx   ( @witx@lemmy.sdf.org ) 
        link
        fedilink
        6
        edit-2
        1 year ago

        I mean, it’s still a very nice language. I can see someone, marveled by that, would endeavor to make bigger things with it. I just don’t feel it scales that well.

          • packaging woes

            My own hot take is that I hear this criticism of Python a lot, but have never had anyone actually back it up when I ask for more details. And I will be very surprised to hear that it’s a worse situation than Java/TypeScript’s.

            • We used to have a Python guy at my work. For a lot of LITTLE ETL stuff he created Python projects. In two projects I’ve had to fix up now, he used different tooling. Both those toolings have failed me (Poetry, Conda). I ended up using our CI/CD pipeline code to run my local stuff, because I could not get those things to work.

              For comparison, it took me roughly zero seconds to start working on an old Go project.

              Python was built in an era where space was expensive and it was only used for small, universal scripts. In that context, having all packages be “system-wide” made sense. All the virtual env shenanigans won’t ever fix that.

              • In that context, having all packages be “system-wide” made sense. All the virtual env shenanigans won’t ever fix that.

                Sorry, but you’ll need to explain this a little bit more to me. That’s precisely what virtual env shenanigans do - make it so that your environment isn’t referencing the system-wide packages. I can totally see that it’s a problem if your virtual env tooling fails to work as expected and you can’t activate your environment (FWIW, simply old python -m venv venv; source venv/bin/activate has never let me down in ~10 years of professional programming, but I do believe you when you say that Poetry and Conda have broken on you); but assuming that the tools work, the problem you’ve described completely goes away.

      • I don’t mean it doesn’t work for larger projects. Just that it’s a pain to understand other’s code when you have almost no type information, making it, to me, a no go for that

        • Larger projects in Python (like homeassistant) tend to use type-hints and enforce them through linters. Essentially, these linters (with a well-setup IDE) turn programming in large Python projects into a very similar experience to programming a statically typed language, except that Python does not need to be compiled (and type-checked) to run it. So you can still run it before you have satisfied the linters, you just can’t commit or push or whatever (depending on project setup).

          And yes, these linters and the Python type system are obviously not as good as something like a Go or Rust compiler. But then again, Python is a generalist language: it can do everything, but excels at nothing.

          • Go and rust are also generalist languages. Basically all main stream programming languages are and are equally as powerful (in terms of what they can do, rather than performance) as each other as they are all Turing complete. So you can emulate c in python or python in c for instance).

            Anything you can do in python you can do in basically any other mainstream language. Python is better at some niches than others just like all other languages are with their own niches - and all can be used generally for anything. Python has a lot of libraries that can make it easier to do a large range of things than a lot of other languages - but really so do quite a few of the popular languages these days.

            • Yes, in a good dev workflow mypy errors will not pass basic CI tests to get merged. Types are not really a problem in modern Python workflows, you can basically have a better type checker than Java out of the box (which can be improved with static analysis tools). The biggest problem with Python remains performance.

  •  OADINC   ( @OADINC@feddit.nl ) 
    link
    fedilink
    43
    edit-2
    1 year 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’

  • The best codebase I have ever seen and collaborated on was also boring as fuck.

    • Small, immutable modules.
    • Every new features was coded by extension (the ‘o’ in S.O.L.I.D)
    • All dependencies were resolved by injection.
    • All the application life cycle was managed by configurable scopes.
    • There was absolutely no boiler plate except for the initial injectors.
    • All of the tests were brain-dead and took very minimal effort to write. Tests served both as documentation and specification for modules.
    • “Refactoring” was as simple as changing a constructor or a configuration file.
    • All the input/output of the modules were configurable streams.

    There is more to it, but basically, it was a very strict codebase, and it used a lot of opinionated libraries. Not an easy codebase to understand if you’re a newbie, but it was absolutely brain dead to maintain and extend on.

    Coding actually took very little time of our day, most of it consisted of researching the best tech or what to add next. I think the codebase was objectively strictly better than all other similar software I’ve seen and worked on. We joked A LOT when it came time to change something in the app pretending it would take weeks and many 8 pointers, then we’d casually make the change while joking about it.

    It might sound mythical and bullshity, and it wasn’t perfect, it should be said that dependency injection often come in the form of highly opinionated frameworks, but it really felt like what software development should be. It really felt like engineering, boring and predictable, every PO dreams.

    That being said, I given up trying to convince people that having life-cycle logic are over the place and fetching dependencies left and right always lead to chaos. Unfortunately I cannot really tell you guys what the software was about because I am not allowed to, but there was a lot of moving parts (hence why we decided to go with this approach). I will also reiterate that it was boring as fuck. If anything, my hot take would be that most programmers are subconsciously lying to themselves, and prefer to code whatever it is they like, instead of what the codebase need, and using whatever tool they like, instead of the tools the project and the team need. Programming like and engineer is not “fun”, programming like a cowboy and ignoring the tests is a whole lot of fun.

  • Compiler checked typing is strictly superior to dynamic typing. Any criticism of it is either ignorance, only applicable to older languages or a temporarily missing feature from the current languages.

    Using dynamic languages is understandable for a lot of language “external” reasons, just that I really feel like there’s no good argument for it.

  • Go with what works

    Error messages should contain the information that caused the error. Your average Microsoft error “error 37253” is worthless to me

    Keep functions or methods short. Anything longer than 20 - 50 lines is likely too long

    Comment why is happening, not what

    PHP is actually a really nice language to work with both for web and command line utils

    Don’t over engineer, KISS. Keep It Simple Stupid

    SOLID is quite okay but sometimes there are solid reasons to break those rules

    MVC is a PITA in practice, avoid it when possible

      • Yeah, why?

        I know it’s popular to bitch on php but I’ve found it’s all for the wrong reasons. The vast majority of the internet still runs on it and it’s a breeze to work with, I love it. It’s safe, it’s fast, it’s great.

        I’ve worked with a variety of JavaScript frameworks and they all give me headaches.

          • Not sure what qualifies as ugly but I find PHP codes much easier to read than JavaScript (if that is what you meant)

            If with weak you mean weak typed then you’re partially correct: most of it can be typed and ever since … I dunno, years ago, I’ve worked exclusively with strict typing. Things have improved considerably on that front

            What part is verbose? Genuine curiosity

            The inconsistencies are true. It’s also PHP’s strength that they kept everything like that and kept everything compatible. Every JavaScript framework I have worked with caused the weekly update nightmare headaches where 5 bugs were resolved, but now 10 more were added due to changing method calls. I hated it and I love PHP for at least keeping that consistency. Over time they have worked little by little to mitigate things but at the core, yes, you have function call inconsistencies. However, good editors these days for that for you and tell you the function name and give you the parameter order.

            Then that there are few good things you can dowithout frameworks is nonsense.

            If you want to do it right you use a framework, but that goes for every language. But I’ve sen and worked on (admittedly a horrible) system that would scrape millions of pages per day and its first version was just hacked together code. Ugly but super quick and simple, no frameworks. I’ve built many similar systems and sites like it over the years.

            Now I recently built my own new framework in PHP, all strict, and it’s just fast and beautiful

            • You’re comparing to only JavaScript, have you worked with another language like python, ruby, lisp, rust? Maybe then you’d see what I mean.

              By verbose I mean that mostly PHP lacks syntactic sugar, mostly it lacks powerful features of other languages. You can mostly write very simple procedural code.

              • Well I compare to JavaScript because that’s what most people bring up. On web development, I guess JavaScript is the biggest competitor.

                I’ve worked with many languages. I even worked with assembly for a while in another life over 25 years ago, I worked with visual basic, .net, c, c++, Java, JavaScript and it’s many frameworks, loads other more obscure languages too, and I’ve played with some python over the years. Still though, php has my favorite since a loooong time

                Can you give an example of missing syntactic sugar or features that are missing?

                • Type hints and comprehensions as in Python, borrow checker, traits, code interface checking in Rust. Most functional features.

                  IDK; I just don’t like anything about PHP and I have worked with it. It seems bad at every task.

      • From what I’ve seen is that 99% of the PHP hate is people parroting slogans others came up with, and the rest is that there are inconsistencies with the function signatures.

        That last part is very true, of course, but not really an issue with modern editors as they will already tell you what’s expected. On the other hand, the inconsistencies are still there for a reason: compatibility. JavaScript what’s a nightmare to work with because every week an update would break shit because of changing method signatures in JavaScript packages. PHP always worked and remained working because it changed so little in that respect.

        In all other areas it hugely improved and matured over the years, just like all programming languages.

        So yeah, I find the PHP hate childish, really.

        • Honestly, “it’s better than JavaScript” is a pretty low bar.

          I don’t like PHP because I think the syntax is ugly and I’ve only used it on systems that are old and a pain to maintain, but I’ll also very freely admit that I have absolutely not written enough PHP to have an informed opinion on it as a language.

          • True enough on JavaScript but I mention it because people always take that for comparison. I’ve used it for hundreds of projects now and for me it’s become my default goto language because I can slap together anything with it. It now has good (optional but encouraged) type safety, which greatly improves code quality so yeah… love it

        • PHP grew “organically” out of a perl library. There was never a consistent plan/idea about the set of abstractions it provides, the type system, builtin functions etc… Everything has been bolted on here and there, some additions good, some bad, some terrible pitfalls. A language with builtin operators that are basically unusable (comparison!) and where some functions return false when the input is invalid, is really fundamentally broken. I agree that many of the worst failures of PHP have been (kind of) fixed after PHP5 and that’s nice for large existing PHP codebases (mediawiki, wordpress, nextcloud, typo3). But I just can’t understand why one would start new projects in PHP in a world where so many very well designed and well thought through languages exist.

          Edit: First sentence is misleading. Of course it wasn’t a perl lib, but basically a thrown together bunch of functionality, unified into one package, so it can replace using various perl libraries. The syntax was also very inspired by perl.

          • Yes, PHPs beginnings were very messy and even today we see results from that.

            But PHP was and remains hugely popular because it’s so easy and fast to work with and today it is very nicely designed and worked out. Yeah there are many details open but editors help you out with that. Other languages may be more consistent at the core but they have their own issues. JavaScript is a nightmare to work with for me, personally, but I o dont bitch about it every opportunity I get.

            I guess I’m just slightly annoyed with people complaining about PHP while it’s just another language and it’s success speaks for itself

              • Well, if it comes to web development (my main focus since the last decade at least) I think it’s fair to say there is little that nears PHP (or, begrudgingly, JavaScript)in functionality. With current frameworks (my own included) I can churn out highly complicated and fast sites in no time. Can’t say that for many other languages.

                Java? “Fast”? Lol no. “No time”? Lolol no.

                Python? Honestly I have too little experience with it to say, but at least frameworkoptions are much more limited anyway

    •  Omgpwnies   ( @Omgpwnies@lemmy.zip ) 
      link
      fedilink
      English
      2
      edit-2
      1 year ago

      Your average Microsoft error “error 37253” is worthless to me

      This is a security thing. A descriptive error message is useful for troubleshooting, but an error message that is useful enough can also give away information about architecture (especially if the application uses remote resources). Instead, provide an error code and have the user contact support to look up what the error means, and support can walk the user through troubleshooting without revealing architecture info.

      Another reason can be i18n/l10n: Instead of keeping translations for thousands of error messages, you just need to translate “An Error Has Occurred: {errnum}”

      • Not when it’s my own computer. My computer needs to give me useful messages.If it’s a website then the site MUST log correctly in the log files…

        If it’s a translation issue then just use English, everyone that can understand logs can (or at least should) understand that

      • Those benefits both make sense, but are those really the original motivation for Microsoft designing the Blue Screen of Death this way? They sound more like retroactive justifications, especially since BSODs were around well before security and internationalization were common concerns.

        • Linux has something similar, kernel panics. However, with Linux you get useful information dumped on your screen.

          Nothing gets logged on Linux either, just like windows and that makes sense. The kernel itself messed up and can’t trust its own memory anymore. Writing to disk may cause you to fuck up your disk, so you simply stop everything.

          Still though, Linux dumps useful info whereas windows just gives you this dumb useless code.

    • PHP the language has become pretty nice, but I recently had to work with a PHP CMS deployment, and it was an absolute pain to do. PHP frameworks seem to still exist in a world where you manually upload code to a manually configured server running apache. Dockerizing the CMS (uses Symfony) is/was an absolute pain.

      • I know that there are loads of solutions out there that can do this for you, though I don’t have much experience with it myself directly. Not a great fan of docker, still, as it’s not a requirement and in many cases that extra piece that fails and then is a PITA to fix.

        I’ll look to include it in my own framework, though