Duplicate code can be a code smell, but it’s far better to have the same function definition or code block appear twice in the code than extracting a function that tightly couples two components that should not be coupled at all.
Also, some of the deep, highly abstract, functional techniques to reduce duplication are too clever for their own good. Your dev team might worship you as a programming God until someone needs to debug it. Back off on that, even if it means duplicating more code.
This. Especially if your team does not follow SOLID principles (as then someone fixes a bug in a base class method that shouldn’t be shared. This fixes an issue in a subclass but introduces one in another. Rinse, repeat.
Same , but in my experience this can backfire even worse because the other person thinks you are trying to show off as well as make them look bad. But the problem is less with you and me, and more with this type of person
There are two many programming languages and frameworks. There is a lot of doubling. Why the heck is there Dart/Flutter? Just use Javascript/TypeScript. Why Swift, when you have D, Go, Rust, Python with type annotations, etc.? In my opinion, just too much waste. Of course, in a niche, like OS development or embedded, there can be actually a need for hyper optimized special solutions. But the “mainstream” rest?
There is a lot of doubling. Why the heck is there Dart/Flutter? Just use Javascript/TypeScript.
This blend of comment was once targeted at TypeScript. Still is.
The truth of the matter is that the purpose of tools is to help people achieve their goal. JavaScript is awfully broken, and many people have been investing their time to come up with solutions to fix it. TypeScript is one of the approaches, but Dart is another one. JavaScript doesn’t go away because it’s the de facto standard to run arbitrary code in a browser, and it carries decades of legacy code. Thus people try and try. TypeScript is now on its 5th major release, and there’s still plenty of work to improve upon the mess that’s JavaScript. No wonder corporations like Google invest their resources building alternatives.
I understand OOP. I like it. I also took my first coding classes in the late 90s and we were taught OOP as though it was the last coding paradigm that would ever be needed. It really set me back because I didn’t even understand the principles of the functional paradigm until I was already at my first coding gig
I think of OOP as encapsulation, abstraction, and polymorphism primarily. Inheritance is definitely taught as part of it, but it seems like most people have found that to be the least used part of it.
It seems like you understand oop, but find it overrated, from your post it sounded like you didn’t understand it – but maybe you meant you didn’t understand it’s popularity.
I absolutely understand OOP, its explosion took over everything that took a long time to recover from.
The problem with OOP is that it’s pushed as a cure-all both by teachers who do not the problems it solves and also do not understand its own limitations.
In almost every situation where OOP makes sense, something else makes more sense to use.
Agreed. Inheritance, specifically, is a huge code smell.
When inheritance is acting as a quick way to implement an interface, it’s lovely.
When an object is acting as a fancy dictionary, it’s lovely.
When a class has more than one parent in it’s chain of inheritance (upwards or sideways), that’s a code smell.
It specifically tells us that the developers are trying to manage program state (variables and data) that simply should have been refactored out (or have drifted very far from the code they’re actually needed by).
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.
It’s just that it’s an ugly and weak language, overly verbose, and riddled with inconsistencies. There are few good things you can do in PHP without huge frameworks.
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 hinting? There. Traits? There. Interfaces? There. I could go on but PHP has all these features that people keep saying are missing.
I’m not saying you don’t have to like PHP, everyone likes there own labgua and that’s fine.
However, people keep making shit up about phpt and then use that shit to smear it and it’s annoying. PHP is great for web sites, small and complicated, it’s great for command line scripting, it’s great for a large list of tasks and it seems that what you need is there.
It doesn’t really count if you need a huge framework for it. Frankly I never saw PHP used well, and I never saw it do anything better than other languages can do.
Hahaha this is great! All points are basically entirely obvious and common sense and then you hit us with that ridiculous statement about PHP. Outrageous!
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.
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.
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
If the method does a long thing, the keep it long. I do a lot of data analysis and simulation, and so often people who came before had this urge to shorten methods, so we get:
<span style="color:#323232;">def do_calculation(N, X, y, z, a, b, c):
</span><span style="color:#323232;"> # Setup stuff
</span><span style="color:#323232;"> for i in range(N):
</span><span style="color:#323232;"> calclation(X[i], y, z, a, b, c)`
</span>
Sometimes there’s a place for that, like if calculation could be swapped for a different function, or if calculation is used all over the program. It’s a pretty good clue that something is up though when the signatures are almost identical. Of course, that has just led to people writing:
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}”
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
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.
I think it suffers from the same problem as SQL. A bunch organizations and companies would need to agree to make improvements, you don’t want to break compatibility, so nothing really improves. You just get some extensions to it here and there which just makes it messier.
Idk anything about web assembly but I 100% agree that JS is absurd and feels like it was created in a weekend by some schmuck who just wanted to be able to edit html on the fly because it was.
Answering my own question here. If you don’t have any interest in how the tools you use work, programming isn’t “for you” (take that with a grain of salt). If you are writing code and have never looked into how compilers/interpreters work or are using a library and haven’t even taken a peak at the library’s source code you should because it will make you a better programmer in the long run. And I’m not saying you can’t get anything done without that curiosity but curiosity is a major part of being a programmer. Also you don’t need to have a deep understanding of the tool just a overview of what it’s doing. Like for a compiler understanding what lexers, parsers, ASTs, code generators are will allow you to write code with that in mind.
My experience with people from university is that they have extremely strong opinions about things they don’t know very much how they work outside theory. There is this syndrome that you have to do everything from scratch with low level languages and keep shitting on anything that uses abstraction to make your life easier.
I don’t know why people in this industry have this need of feeling that they’re better than others.
I think this is because there is just such a vast amount of information that as humans, each of us individually can only know so much of, and it creates a bit of an imposter syndrome to know how little you know, so many people feel the need to convince themselves that their little section of information is better or more important than other sections of information
It could also be the “well I had to spend years learning how to do what I do and you’re using a tool you learned in 2 days so obviously it’s not that easy and something HAS to be wrong”
I see that particular issue as the same as sending a spaceship to colonize a planet many light year away, but when they get there, there’s been an established civilization for hundreds of years because they developed a better system of travel after the first one left. Same thing, person B got to the game later, but got their goal first, so person A thinks B isn’t a real programmer because they didn’t have to grind and struggle with interior tools and tech.
The programming languages you use, and the variety of languages you learn, deeply influence how you think about software design.
Software would be much more reliable (in general) if Erlang had become one of the dominant languages for development.
Go sacrifices too much for superficial simplicity; but I would like to see a language that’s nearly as easy to learn, but has a better type system and fewer footguns.
Unit testing is often overrated. It is not good for discovering or protecting against most bugs.
Build/test/deploy infrastructure is a genuinely hard problem that needs better tooling, particularly for testability.
Build/test/deploy infrastructure is a genuinely hard problem that needs better tooling, particularly for testability. (Naturally, this is a hard problem, but I think very few developers are working on it.)
Agreed and it’s not treated as one which is a compounding issue. 😬
hard agree. I’m sick of all the “it doesn’t matter what languages you learn” talk because it’s just not true. yes, there are broad foundational skills that apply to nearly every language, but beyond that, you’re specializing, and the way the language you choose is designed will stick with you. I’ve seen the concept that you get accents in programming languages just as much as spoken ones, and I think it’s totally true - when you learn a new language, you’re bringing your habits and assumptions from the last one. so to be honest I don’t care about the language design opinions of people who only know dynamically typed languages
I think unit testing is good at enforcing a spec so other developers know what to expect from your module and how to maintain it. It also kinda force you to dogfood your own stuff.
Imo it is strictly something you do when you write something like a library or any sort of module that you expect other developers to interact with. I’ve seen teams get all smug about code coverage as if this made them diligent. My personal experience is that developers who understand why unit tests are important tend to write better code than those who skip them or do it “just because”.
If I explain myself or add nuance, it won’t be a “hot take” anymore, but here goes…
I’ve mostly worked on small teams, but have maintained fairly large codebases (I think the largest single repo I’ve worked in was about 1.5 million LoC). I’ve also maintained software used by other teams, though in fairly small software organizations (under 100 developers total).
I’ve written code with 100% unit test coverage, and code with almost no coverage. The 100% coverage was in a library that was intended to be core functionality shared across multiple teams.
I definitely agree that they can be useful as both usage examples and as a way to enforce some rules (and consistency) in the API. But I’m not sure I’d go so far as to call that a “spec”, because it’s too easy to make a breaking change that isn’t detected by unit tests. I also feel that mocking is often needed to prevent unit tests from becoming integration tests, but it often hides real errors while excessively limiting the amount of code that’s actually being exercised.
I also think that actual integration tests are often a better demonstration of your API than unit tests are.
I haven’t used any of these methods as much as I’d like to, but I suspect that each of them is strictly more useful than standard unit testing:
contract tests (arguably just a form of unit testing, but not the way I’ve generally seen it done)
property-based tests
mutation tests
preconditions & postconditions (with language support)
Makes a lot of sense. I figure contract tests is more or less what I have been doing then.
I think there is that misconception that unit tests are about validating each line of code and preventing logic bugs. Though obviously you understand that this isn’t just about that, or not at all about that I would argue. Unit tests won’t prevent accidental breaking changes, but you can at least add new tests every time this happen, so you’re at least guaranteed that the next maintainer won’t be doing the same mistake.
In an ideal world we could probably have nothing but integration tests, but in my experience if you only do integration testing you end up working really hard maintaining tests that are prone to break and costly to run. Unit tests are cheap to code and cheap to run, it is a great place to enforce your “contracts” with tests that are theoretically immutable. After those tests are out of the way, you can focus only on the actual interaction between your systems with the more expensive tests.
Anyway, you have a good take I am just blabbering. This is based on my personal experience as someone who only cared integration tests but was later converted by a person much smarter than I am. And then later on by joining a team that exclusively did integration testing, hundred of tests. It was hell (imo), we had to change dozens of tests for every little bit of modification. The rest of the team seemed fine with it though. We rarely shipped bugs but progress was incredibly slow for a module of such low complexity. Testing wasn’t the only issue with that codebase though.
The one part of that that sounds weird to me is needing to change integration tests frequently when changing the code. Were you changing the behavior of existing functionality a lot?
Yes, and the test suites were insane. The program was outputting a lot of data, and we basically asserted on anything and everything for any given integration. I mentioned that testing wasn’t the only issue, well there was a lot of issues. Unfortunately the behaviour changes were requested by the stakeholders and there was no way around it. That being said, had this thing we maintained been properly developed those changes would have been a breeze imo. The actual requirements were very simple.
But anyway, I realize this is maybe an extreme example to paint integration tests negatively, but the point remain. In this scenario, every time we changed a bit of code it broke dozens of integration tests instead of breaking just a relevant integration test, had everything that could have been unit tested been written that way. The integration tests could probably also had been less… exhaustive, but it was probably for the best considering the codebase.
Go sacrifices too much for superficial simplicity; but I would like to see a language that’s nearly as easy to learn, but has a better type system and fewer footguns.
“Easy to learn” and “good type system” will by necessity be opposing forces IMO. If you want to work with a good type system you’re gonna have to put in the effort, I’m not sure there’s this magical formulation of a good type system that’s also intuitive for most new developers. Hope to be proven wrong one day tho but so far no dice.
I think TypeScript has a pretty good type system, and it’s not too hard to learn. Adding sum types (i.e. enums or tagged unions) to Go would be a huge improvement without making it much harder to learn. I also think that requiring nullability to be annotated (like for primitives in C#, but for everything) would be a good feature for a simple type system. (Of course that idea isn’t compatible with Go for various reasons.)
I also think that even before “proper” generics were added, Go should have provided the ability to represent and interact with “a slice (or map) of some type” in some way other than just interface{}. This would have needed dedicated syntax, but since slice and map are the only container types and already have special syntax, I don’t think it would have been that bad.
Types and unit tests are bloat that increase the maintenance cost of whatever code they are involved in. Most types force premature design/optimization. Most unit tests lock up some specific implementation (increasing cost of inevitable refactors) rather than prevent actual bugs.
Nil-punning in clojure has spoiled me rotten, and now every other language is annoyingly verbose and pedantic.
I do get where you’re coming from, however. Dynamically typed languages are great for prototyping and if you’re dealing with a small codebase, it can stay that way, but IMO large codebases without typing are not fun to navigate and understand.
“Which class am I dealing with now?” is such a common problem that I’d rather have it explicitly written than guessing or assuming to know.
Very happy to share this hot-take :) Definitely code-base and team-size are a huge factor, and I mostly work on my own projects, so each project is very different. still, I expect to get downvoted into oblivion by the last decade’s influx of typey-langs and -devs.
I think most love for types is folks being happy they don’t need to assert on the input to every function, i.e. static analysis and reduced unit-tests. It’s hard for me to not see types as asking folks to pre-design their entire system (by defining types first!), before you’ve even started writing a few functions, which are actually what the system should codify (behaviors, integration tests). It’s also frustrating b/c types don’t guarantee that the system does-the-thing, only that the type-system and compiler are happy, so it’s like pleasing the wrong boss, or some metaphor like that.
I like to work with behavior directly in functions, which should be the same regardless of the type passed in. Unfortunately most dynamic languages have their flaws (js,python,etc), so this kind of opinion suffers b/c of those languages… similar to type-favoring opinions suffering b/c of langs like typescript.
Nil-punning makes me very happy - that’s a hill I will actually die on. Almost every project i’ve worked on, there’s no reason to go out of the way to specifically handle every case of not the right input or oh-no-it’s-null! Whenever you have null, you just return null from this function too, and guess what, everything’s fine - no need to crash and blow up b/c one thing wasn’t there. Mostly this is a complaint about things completely crashing for no reason, rather than being incomplete (i.e. some data missing) but still working for the user.
Anyway, lots of different use-cases, and use the right tool for the job, etc etc. types and unit tests are useful for some things.
Meanwhile here I am thinking about pivoting my career from Python to Rust because I’ve grown to hate Python’s lack of typing. I also religiously write unit test even for minor personal projects.
I suppose i should at least caveat by saying i don’t by any means advocate for all dynamic langs over statically typed, and i agree types/unit tests are necessary for most languages. So please don’t make me write python over rust!
You can get the benefits of types/unit-tests via static analysis on a per-function basis with clojure and a library like malli, and for me that hits a minimalist sweet-spot.
Sorry, I liked this hot-take setup and I’m shooting from the hip a bit. Maybe i actually mean objects/classes, not types? Can’t everything just be a bag of key-values, like in clojure?
I have been building mostly prototypes (games and wm-tools) for a year, so most of my context is getting things working to see if they are useful rather than locking them down.
I thought about my argument a bunch, and while i have alot of complaints, it all sounds like non-specific whining to me, so i’ve decided to give up.
types and unit-tests have their place. Fine! I admit it! i was pushing a hot-take I’ve had on a few occasions, and I’m glad to see this programming community is alive and well! If you need me I’ll be in my clojure repl.
It’s also important to acknowledge how different is prototyping from writing production code which has to be extendable and maintainable for years by multiple developers.
Your take isn’t even very hot when we are talking about prototyping 😉
I’m a longtime fan of python, but honestly I don’t know how I lived with it before type hints. It still feels a little backwards from the original design philosophy of python, and it’s more verbose than other strongly typed languages, but it’s come to feel pretty natural all the same.
I disagree. What you’re saying is true for Java-like OOP languages because OOP is actually complete garbage if you want to design good abstractions. Types are way more elegant in functional or functional-inspired languages.
I think you’re right re:oop - let’s throw that in there too.
One problem is naming things - bad names/naming conventions can start things off in a bad direction, so you spend forever figuring one out… but do you really need this thing you’re naming after all?
Maybe the hot-take is more like: All code is bad, so less code is better…. what should we drop first?
types are bloat for maintenence? id rather get a compiler error in 0.1 seconds than spend hours tracking down where in the code my number was coersed into a string.
Composition over inheritance has become a meme that people repeat without understanding. Both have their uses, but if composition is all you use, then you’re using a hammer on everything. There is no silver bullet in life and most undeniably not in programming.
Also, electron has a reason for existing. If it didn’t have a use, it wouldn’t have the number of users it has. You can’t tell me in all seriousness that Qt, Gtk, Swing, Tkinter is easier to use than electron for the common developer.
While I completely agree with you about electron, I still don’t have to enjoy the fact that companies are outsourcing their lack of development in native tech to my wallet in terms of wasting resources on my device. Now perhaps the cost of the associated services would be higher if they had a native app which is a fair response. I still don’t have to like it.
Written as a user (and occasionally enjoyer) of electron based software.
It’s especially infuriating when you have a giant like Microsoft rolling Electron on their flagship applications (Teams), and then deprecating support for some platforms (Linux). What’s the point of your nice, memory-gobbling, platform-agnostic app framework if you’re not even going to use it to provide cross platform support?
I don’t enjoy it either and will go through the pain of writing GUI apps in anything but HTML,CSS and JS, but the ground beneath me doesn’t exist as no contributions are coming from my side to make an easier electron alternative. There are other places I am hypocritical though.
Absolutes in programming are most useful for clickbait and little else. Use what makes sense for your use case, following a trend will only lead to pain.
Add comment