If they are paying you in company stock and this is their pitch run. Don't look back. If you need resume exp then do it maybe and then run but don't stick around. But you're honestly better off making something presentable on github.

The value added to using open source and tweaking a few things is almost nothing. So the company is worth almost nothing. The vast majority of startups that pay people in stock fail and you get nothing. Just don't do it.

If they want to pay you money that is fair for your work to make a worthless company and you need the job tho go for it.

It's good if you are facebook or a likesize company. I'm convinced the only reason so many people want to use it is to bump their resume to get into such a company. Because it's honestly crap for most people.

Actually heard people refuse to use something else "because it wouldn't help their resume". Like lmao. LMAO. Boy-o you better hope I'm not in charge of hiring I'm cutting all the React devs out with a hot knife from the selection process.

Why make complex problems simple, if you can make simple problems complex. Why convey more accurately your ideas in a paragraph if you can just type out 3 pages of a mess.

@c3r38r170 that sounds like too many shitty plugins or too much data for the infrastructure, like I said once the table rows get to a certain size the db design isn't the greatest and you need to start using costly solutions like NDB or implement diff caching layers.

There is a code profiler plugin that is very good at telling you just what is slowing things down same with query monitor. Often it's a few plugins or few bad queries and then you can address that nothing should be that slow.

This is pretty one sided to a point of inaccuracy. You need both. A very successful person once told me their observation on this.

"You can either be 60% good at your job and 40% likable or 60% likable and 40% good at your job but the rest don't make it to the top".

@DEVil666 Automation via AI is an unstoppable force at this point. It improves a lot every year. Full replacement won't happen fast but it will happen.

UBI doesn't mean you can't work. It doesn't mean you will be poor or eat bugs. It means you profit off some of the automation too.

If you don't like that wait for the "I asked Chat GPT to do the work of most my software engineers"

Support UBI

Scripting languages are faster to get things done but I wish more people were competent in C, it is fast and an easy language to learn and maintain.

@neriald In dynamically typed interpreted languages you're left to do as little or as much type checking as you want. Making people do strict typing for everything to avoid a programmer not doing their job properly is throwing the baby out with the bathwater.

If you have unexpected input you can typecast, if you are checking for errant data there's utility functions. For data you fully expect, there is often not much need for this. Does that leave room for a bug to pop up? Sure. But painting your entire program with strict typing to avoid a bug like that is overkill and misuse of the language.

The number of errors I have had where types are an issue are few and far between, and usually very easy to fix.

Static typing is great for memory management. It's a bad crutch for trying to write less buggy code.

I only mentioned Linus cuz of prior posts and your topic seemed to come up out of the blue.

Testing can be done to mock function calls too.

@sariel one day you may grow up and have conversations like an adult and support your arguments with actual substance. But maybe not, there is a reason they say once a fool always a fool.

@neriald there was a point in time dynamic typing was seen as a benefit of interpreted languages. In my view it still is.

Introducing strict typing to an interpreted already dynamic language is a misuse of the language, you should pick something else. Something where typing is already strict.

People think it matters for code stability and so on but they are just uncomfortable. It only matters if you want exact control over memory.

As for the seeing branches of code thing I can only think you're talking about Linus statement on OOP while at the same time misunderstanding it. OOP will have unexpected behaviors on the hardware level, something that is terrible for something like a kernel.

OOP being able to do anything procedural can do and more though is just wrong. C++ converts OOP class method for example to a function with prepended names, it converts to procedural just ugly versions of it. You aren't doing anything in OOP unique, unless you count wasting cpu cycles.

@iceb I've worked alone a lot, but it's not like I never worked on teams. First college group project I was the lead, it was all procedural and it was used and liked by the medical department at our college.

The first job I had out of college was a 3 developer team, procedural based but also had to integrate with a ton of other systems. I thrived in that environment to be honest.

I think organization is very made up. There is no way to organize that is actually better from group t group. What works for one group might not for another.

A lot of hiring these days is very based on "culture fit". Bootcamps exist to train the uneducated to think like a companies existing infrastructure and fit as a cog in a wheel, ready to go, without dissent.

I guess this is one way to get people to work together better. I would not be one to say it's a very good one though. If everyone is on the same page and beliefs you work together better. It doesn't make those beliefs sound though.

@sariel A child avoids touching fire when it burns them. I don't think that's any reason to say you shouldn't believe them touching fire is bad.

I have had my fair share of burnings from OOP architecture. Far too many. My dislike is not from some armchair but from experience. Just because I choose to code on my own without OOP when I can doesn't mean I haven't had it be part of almost every project I have had to do for clients, if it's not somehow part of the CMS or ecommerce store it's in one of its libraries. If I didn't know how to code with it I'd not be able to deliver things to clients.

That does not mean I like it or have seen one iota of benefit from it in any paradigm. What I have seen is over engineering to the detriment of many a library/cms.

The amount of assumptions you make in such little time is what makes me take your posts with a grain of salt. You think something that makes you feel superior and then put it in post without any interest in validity.

@hardCoding I'll check out the book but there's already been studies finding programming paradigm have little to nothing to do with productivity. Being someone that has experienced it making me far less productive, I'm not about to be moved by one guys book. A large scale scientific study maybe that controls for various parameters like what is commonly taught in schools. That'd be convincing.

The closest I've seen was a study that measured different times to complete an app using different languages. C came out high on lines of code per hour iirc as well as project completion time. Wish I could link it but I can't find the reddit post that linked it.

I think you're making assumptions on a lot of variables. Assumptions which I'm both skeptical of and are contrary to personal experiences.

@iceb Polymorphism is kind of hated even by OOP enthusiasts at this point isn't it? Strange he'd list that as a unique benefit.

I'd also say it's been wildly popular rather than wildly successful. That it's been successful would mean defining what it was trying to achieve. In my view that should be less complex programs with better run time that uses fewer resources and better developer productivity. I frequently see it fail on if not one then all three of those metrics.

@Demolishun I haven't heard that story, but I've heard of John Carmack pushing back against Oculus team members, Linus Torvalds having to push back heavily against OOP for linux kernals, a domain it has NO business being in. It sounds like to me they got some developers on board that simply weren't comfortable without OOP.

One argument people like to try to make is OOP helps with big projects. The linux kernel is over 8 million lines of code though and more solid than most software ever will be today. Entirely in C. And I'm fairly certain they aren't trying to make OOP happen in C.

@sariel projecting much, I smell a lot of pretension but it's not from my own posts but yours.

The object oriented project was due to the platform the client chose, I just agreed to do it for him at his asking. The modifications I did using the platform, custom plugins I did, and suiting it to his business needs were the project. 98% of the codebase was not my doing, it was done likely by people who think much like you do.

As far as being a shitty developer, my clients will disagree. You don't stay in business by yourself for 12+ years with clients that you have had for 9+ sticking with you by delivering bad work. I've had clients personally tell me my work for them has saved their own businesses and changed the way they do business for the better.

Come back when you can handle a difference of opinion maturely, when I called you a fool it wasn't an insult, it was an observation.

@Voxera I don't feel there's much a use case for OOP at all, that can't be better fitted to another paradigm.

@Lensflare I'm not against using and learning multiple methodologies I hope the story I shared shows I have taken the time to do that.

However, I have never been in an environment where OOP has made me either enjoy my work more or be more productive. There's good and bad code for all paradigms, and good procedural is imo by far the easiest to work with.

I find John Carmack said it best. "Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework." He is probably referring to functional programming but it works for procedural too. Imo the thing the industry needs is a call to brevity and simplicity rather than over abstraction. Over abstraction makes maintenance harder as does over complication.

@sariel you're the exact kind of fool I expected to get when writing this post. I've talked to hundreds of people like you. Starting the conversation off with a given that is not true.

Let me ask you this, did the entire industry of programmers that had no use of OOP and made working solutions to problem really give a fuck about what you thought is a hammer or a screwdriver? OOP is less a screwdriver and more like a kazoo. Many solutions also exist to this day that run things you wouldn't even understand on languages like C, that are core to the world even functioning. Not a piece of OOP in sight.

@hjk101 I'd say drush is S tier for modules and managing your drupal install. I've used it for a ton of things over the years from cron job scripts to resetting passwords to upgrading. Even sql or php one liners.

composer's other features are generalized in comparison and not made for drupal. I'm also not a fan of a lot of the php libraries people use out there and it often adds bloat. For instance using guzzle at an uncomfortable number of SLOC vs using curl. If you need the equivalent of curl functionality abstracted away to make you comfortable I just think you're a bad dev, and I haven't seen a case yet where curl can't do what I need easily.

@Lucky-Loek I find the opposite is true, symfony is over-engineered and hard to customize and purposefully opaque. Drupal was straight forward and simple.

I've done entire projects in a few weeks in Drupal that I would never trust to Symfony/Laravel. I've setup other people's Laravel projects and just installing and configuring it took an obscene amount of time compared to a drupal install. Honestly I'd be fine if I woke up tomorrow and both of them were vanished off the planet.

As an experiment I tried to add a php tag to execute php code in twig, which was tied into symfony. The result after 10 hours work was reading their code and altering it was a nightmare and I recommend it to exactly no one.

@hjk101 B) is not a plus, drush was fast, took little ram, almost always worked and wouldn't mess up your install even once. composer on the other hand takes tons of ram, is super slow, and even after using so many resources manages to screw up your installs and become a time sink. Every project I have had to use composer in it was a minus. I'm not against package managers but apt or yum composer is NOT. It's a wonder how they managed to code such an inefficient error prone mess.

D) is a silly thing to care about most the API's I've seen are just glorified versions of function calls, or call the same thing from a URL using REST or SOAP. It's mostly a buzzword imo, one you don't really need for drupal unless you are integrating it with another application, which I've never had to even do, and if I did, I'd just setup database access because it's more powerful. The only time it's that useful is if 3rd parties are integrating.

@sariel it was increasing in userbase up to 2015 when drupal 8 came out and it powers a lot of companies.

One of my friends was a CIS major and did her entire research paper on it for a class. It was birthed from a failed project that was over time and over budget and its successes are touted with zero evidence. Software development snake oil.

@iceb the complaint wasn't on something as simple as passing parameters to a class method or a function, it's on the clusterfuck of xml file configs, compiled classes, boilerplat vomit spit out by command line and context god objects many have turned it into and still call it a good thing. It is not.

@lorentz an apt analogy is creating a housing bubble from bad lending policies that you then try to fix with a bailout by giving money to some of the same people that created the situation in the first place.

C avoids the problems because it didn't create them. It's more than capable of solving any problem you give it. Programmers that solve problems they created aren't good programmers, since they're being paid to create and solve problems though they could be classified as con artists.

@IntrusionCM C manages to avoid a lot of bad things because it doesn't support OOP wonder why that is?

@IntrusionCM I haven't worked with Zend Framework Registry but I have worked on many frameworks, libraries and in house solutions for 15+ years. Using something like Magento2 makes me want to not use something like Magento2 which leans heavily on it. In fact my company moved off of it due to many of its issues, their DI implementation only one of many reasons.

Wordpress doesn't use such systems and is better off for it. Neither did any C programs. DI is poo.

@hypervtechnics most likely reading and using code someone like you made and claims they never had issue with. It's because you made it someone else's problem.