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.
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.
Most calls I have at work are like group therapy sessions, as everyone has ideas of what they believe is correct, but they know if they keep pressing with management or take the time to do what is right, it won’t go well for them.
This is coming from a guy who lasted a year and a half in the office. Sounds like it's a systematic issue..
Today I removed code from a codebase that was added in 2021 and never ever used. Sadly, some people are as content to litter in their repo as they are in the woods.
Why do you need time to refactor? It is just part of the work you need to do and should be accounted for when doing any other work. IMO a big mistake people make is thinking refactoring is some separate thing they need permission to do. You don't, if you need to make a change in some area refactor it first to make it easier to accept your change, then add your change then refactor to clean up. This is not three separate tasks, just three steps in one task. You should be given enough time to do the whole task, not just part of it.
I guess I need to refactor for readability. What you just explained is the entire point of the comment I posted. Refactoring is part of the job. Don't give your manager a choice on whether or not it needs done.
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.
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.
If you only know C and you're looking at Python, the absence of curly braces on code blocks is temporarily unfamiliar to you.
But if you only know Python and you're looking at C, the fact that indentation doesn't matter is temporarily unfamiliar to you.
Once you learn the new language, it's not unfamiliar to you anymore.
"Unintuitive" often suggests that there's something wrong with the language in a global sense, just because it doesn't look like the last one you used — as if the choice to use (or not use) curly braces is natural and anything else is willfully perverse on the part of the language designer.
“Unintuitive” often suggests that there’s something wrong with the language in a global sense
I mean only if you consider "Intuition" to be some monolithic, static thing that's also identical for everyone. Everyone has their own intuition, and their intuition changes over time. Intuition is akin to an opinion - it's built up based on your own past experiences.
just because it doesn’t look like the last one you used — as if the choice to use (or not use) curly braces is natural and anything else is willfully perverse on the part of the language designer.
I don't think it's that deep. All people mean when they say it is that "[thing] defied my expectation/prior experience". It's like saying "sea food tastes bad". There's an implicit "to me" at the end, it's obvious i'm not saying "sea food factually tastes bad, and anyone who says they like it is wrong or lying".
You could say that about anything. Of course you have to learn something the first time and it's "unintuitive" then. Intuition is literally an expectation based on prior experience.
Intuitive patterns exist in programming languages. For example, most conditionals are denoted with "if", "else", and "while". You would find it intuitive if a new programming language adhered to that. You'd find it unintuitive if the conditionals were denoted with "dnwwkcoeo", "wowpekg cneo", and "coebemal".
Languages also have inner consistency. E.g. the mentioned python len function is inconsistent with the rest of the same language - and that is a statement that is true in itself, without an external reference point.
But there are languages that require varying degrees of effort to become natural. Something like Malbolge will pretty much never be natural while something like Python can become natural to you in a few days.
Idk, I don't see a problem with saying a new language is unintuitive. For example, in js I still consider the horrible type coercion and the "fix" with the triple-equals very unintuitive indeed. On the flip side, when learning C# I found the multiple ways of making comparisons to be pretty intuitive, and not footguns.
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".
Yeah. I've written in six or so different languages and am using Go now for the first time. Even then, I'm trying to be optimistic and acknowledge things are just different or annoying for me. It doesn't mean anything is wrong with the language.
ZZT-OOP is fun to work with though, definitely not meant for doing anything more complex than light gameplay, and yet people have done ridiculous things with it.
Though I personally did most of my coding in that vein in MegaZeux with their Robotic language, which is basically ZZT-OOP++.
I really don't like how rails brings things into scope and you just have no idea what's there or how it got there unless you know all of the conventions. I guess that's a rails issue and not ruby though.
I learned in python and C++ so I'm biased towards things that are extremely specific. Definitely doesn't mean ruby is necessarily bad, I just don't like it.
This is very true! Languages being unintuitive also becomes less of an issue the more languages you look into.
There will be many concepts that multiple languages have since ultimately they are all trying to do similar things and the more you learn the more you will recognize making it easier to get into even more languages.
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.
Tools that use a GUI are just as good (if not better) than their CLI equivalents in most cases. There's a certain kind of dev that just gets a superiority complex about using CLI stuff.
Indeed, the problem with gui apps is when you can’t script them!
I always loved alfred on osx, then loved scripting rofi on linux, only to come back to osx years later and find alfred can’t be invoked with stdin options. It’s damn shame….
I used to think something like this when I was younger. I spent an inordinate amount of time looking for good gui versions of cli tools. I have come to understand that this is not usually the case and cli tools are more convenient much of the time. I would not classify this as superiority complex, unless I’m being a jerk about it. I don’t care what you use, I just use whatever has the lowest barrier to entry with the most standardization, which is usually the original cli tool.
It also depends on the specifics — in many cases when a GUI is just a wrapper over the CLI tool, it is instructive to learn the CLI, similarly how you are a better programmer if you know about at least a layer beneath the one you are programming at (e.g. you can reason about this usage of hashmap because you roughly know what it does).
It is probably the most visible in git, but if you can only do commit and push from a GUI, just please learn the CLI as well. You don’t have to use it, but understanding it is important and the GUI may abstract away too much from you.
I agree only when your job function is specifically geared around those tools... Otherwise high quality guis are more valuable.
Just because I can do everything in gdb that I can do in visual studio doesn't mean 99% of most debugging tasks isn't easier and faster in visual studio. Now if my job was specifically aimed at debugging/reverse engineering there are certain things that gdb does better on the CLI... But for most software devs... CLI gdb isn't valuable.
There are some massive intrinsic advantages of the CLI though, that apply for everyone, not just leetcoders:
The terminal can remember everything you ever did. Forgotten the command you wrote 2 months ago? You can do a search for it with a tool like fzfand run the exact same command again.
Communicating with others. GUI programs require step by step instructions, often accompanied by screenshots while CLI may be copy/pasted.
Combining programs together. There are a few different techniques for combining CLI programs to search/format output, use secrets without ever having them in the clipboard or on disk, monitor something frequently/constantly etc etc
So while I agree with you that there's plently of elitism around the CLI, you do yourself a disservice if you try to avoid it.
Just no. CLI can be automated, which makes it superior. It's not a superiority complex, it's a fact. I'm not a minimal wage worker pushing buttons I don't understand. I'm not a technician who learnt your shitty software to do the most basic tasks.
That's the gold standard as far as I'm concerned. Haven't used the ytdlp-gui yet, but it's simple stupid.. I might want a few more switches (more exactly the extract audio/subtitles) to turn
Aside from automation, CLI can support significantly more complicated apps reliably. It can also be tested more reliably.
GUIs are better for anything simple, and good UX designers can make a moderately complex one, but anything like server administration/git/configs are 100x better on CLI
This depends a lot on the GUI and the tool. Some cli tools are great alone or for scripting, others benefit from the extra attention to ux and exposure of options that a GUI can offer
For git in particular, I encourage juniors to learn and use the CLI. I find that GUI git clients often do some or all of the following:
Use non-git terminology that ends up being confusing. "Sync" comes to mind as a frequent offender, I can think of several incompatible things that could refer to.
Ignore the useful ability to stage your changes
Don't permit or encourage a review of the changes
Implement only the basics and make remediation of branching issues difficult
In the worst case, I've seen people end up using the git GUI like a "save" button, blindly commiting and pushing the current state of their code, including to-be-removed print statements and other cruft. Yeah, git cli is a bit complex compared to that, but you gain a lot for that added complexity.
That said, I've definitely jumped into a git GUI from time to time just for a visualization of whenever branching snafu I'm trying to untangle. None of the above invalidates GUIs if you take care to still understand the underlying tool properly!
Sure try to replace the one or two people that hold the whole team together. I've seen it a couple times, a good team disintegrates right after one or two key people leave.
Also, if you replace half the team, prepare for some major learning time whenever the next change is being made. Or after the next deployment. 🤷♂️
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.
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?
Imo reviews are more for checking that someone didn't drop malware into the code base. It's rare that I get a good review that goes beyond checking for malice.
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.
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.
You can always solve a problem by adding more layers of abstraction. Good software design isn't to add more layers of abstractions, it's to solve problems with the minimum amount of abstractions necessary while still having maintainable, scalable code.
There are benefits to abstraction but they also have downsides. They can complicate code and make code harder to read.
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 still hoping for browsers to become some kind of open standard application environments and web apps to become actual apps running on this environment.
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.
Actual hot take, Blazor is awesome, it is like Microsoft looked into ASP.NET Forms, ASP.NET MVC and Razor, and bundled it to one quick framework to do simple WebApps.
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.
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.
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.
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.
And at least as far as Firefox goes I'm running it on gnome and there's a beautiful theme that makes it look native for it. I'm sure there's one for windows too if you look.
The desktop website is so bad... I ask for a light theme in my settings, they don't care (it's white on black) because it's HARD to add a few CSS rules. Then there is a flash of light which could give a seizure to someone with a condition. It's shitty design at its peak. That doesn't really inspire confidence...
Firefox is really badly integrated in MacOS. The fn + arrow shortcut doesn't work, for example, it's not integrated in the menu system (the menu shortcuts don't work) etc.
But there is Sideberry, so...
Its IDE is based on Scintilla. And it is very fast, even on an ancient PC it runs.
It is specific for the programming language.
And here some advantages it has compared to a simple text editor:
Autocomplete of all functions and many API functions of the OS
Hints about parameters
F1 Help for all functions by just placing the cursor on them
Jumping to errors in the code
Automatic backups of all the progress of your codes, no problem to backtrace even if you forgot to save or commit.
Manage Projects (Groups of source codes and different targets)
Well integrated debugger
I agree with you in many points. Most other IDEs I am forced to work with are horribly slow. Especially those which rely on electron. Sometimes they lack features every basic editor has by now.
This is to say: Good IDEs can exist and are a great benefit for the programmer. But modern IDEs often chase keyword features and use complex and bloated frameworks to achieve them. Sometimes even forgetting to add basic features which made IDEs a thing initially. An IDE should take almost no time to setup to your needs and should not hinder with complex operations which take seconds to run, it should only support in code creation and aim to make features like autocomplete show suggestions in milliseconds.
In my experience it HEAVILY depends on the language you're using. Nothing beats Intellij for Java or Kotlin, but Rust and Go feel at home in any editor.
I know that LSPs and DAPs somewhat take care of these, but the following are often easier in IDEs:
Refactorings, including really smart language specific ones
Support for fancy frameworks. For example, Intellij can analyse all annotations for Dependency Injection or Spring stuff, and will then tell you exactly how everything connects on a higher "framework" level. Arguably, this is a solution to a problem Enterprise Java created
Debugging is easier
In general, stuff works "well enough" out of the box. As a fan of Neovim, I've definitely been frustrated a lot the first time I had to set something up
Fancy integrations, for example linking frontend code calling backend code directly, or an entire little Database Manager builtin, with magic SQL code completion
Jetbrains IDEs do a lot of indexing and caching so that operations that normally take a bit are faster. Full text search, find usages, identifying interface usage in duck types, etc.
But the killer feature for me is the refactoring tools. Changing a function signature, extracting an interface, moving code to new files or packages, etc. I pair with folks who use VS Code and its a bit tedious watching them use find and replace for renaming things.
I've never been able to benefit from an IDE in a way that make up for how much slower and more bloated they are.
That does sound legit if you have resource limitations. Thankfully I've always worked for corporations that hand out MacBook Pros like candy. Normal day for me is having two Jetbrains IDEs open with Chrome, Slack, Zoom, and a dozen containers. Still runs smooth.
Python development without PyCharm (or IntelliJ) and the IdeaVim plugin is unbearable. List usages is a game changer. Don't care much for anything else.
Yup. Emacs, here, but same thing. Never used PyCharm or any other Python-capable IDE, and I've been coding large python projects for the same company for almost a decade.
Yeah, well, that's just Python for you. List usages is now an LSP feature for most languages, so will work with "lesser" editors too.
All that being said, I use Intellij with Java daily, so I can see where you're coming from. But for example Rust or Go works wonderfully with Neovim (or VSCode).
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.
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.
In unit testing, a "unit" does not have to be the smallest possible section of code. It can be a while class or module or even set of related classes/modules. Testing individual functions in isolation leads to brittle tests that easily break during refactoring. Testing overall system behaviour results in more robust tests that require fewer changes during refactoring which gives you more confidence then you have not introduced a regression.
IMO, you should usually test only stable interfaces.
If you have no stable interface all the way into the UI, then you shouldn't test anything all the way into the UI, and focus your tests there. Odds are that your code isn't very good, because it is rare that you don't need anything stable all the way through, but well, "rare" is not the same as "impossible".
Martin Fowler called them sociable tests. The only way to properly test your units' behavior is to pull in their dependencies. Isolated tests are useless, brittle and slow to write.
Honestly, I don't think unit tests are a useful name. Everyone has a different idea of what a unit is and the line between unit tests and integrations tests is IMO not very useful. As long as your tests are
isolated from external factors (ie they completely control the test environment),
fast to run
repeatable, aka not flaky
can identify problems easily
Then where you draw the line between unit and integration is meaningless. It was meant to be that ingratiation tests were slow, so you wanted to shrink them down to make them faster to run. But I have not had a problem with the speed of more integration style tests in a long time.
I also don't think interacting with the OS is such a bad idea. For instance the filesystem (what everyone always points to as an example) IMO is fine if done right. The big issue with interacting with the FS is keeping your tests isolated - too many people end up reading/writing the same file locations and thus breaking isolation. But you can always create a unique tmp dir for each test and do what ever you want inside that. Interacting with the filesystem on modern system is fast, and reliable - especially given that tmp locations are generally in ram these days.
I think the better term you are looking for is mocks and mocking. IMO these should be kept to a minimum. Like the above - you dont need to mock out the filesystem API when you can just use the filesystem in an isolated way. Same with network services - I really like gos httptest module, it lets you easily spin up a webserver that you can respond with whatever you need to. No need to create a mockable API when you can spin up a fast and reliable http endpoint to respond how you need it to.
Which leads to fakes (ie fake, simple implementations of a real external API). IMO these are far more useful than mocks and should be your first resort with mocks being your last resort. Such as things like gofakes3 an in memory s3 implementation in go that you can use any s3 client to talk to. Things like this let you create tests that you spin up the server (a unique one for each test), put objects into it to set things up how you need them, run your function and assert the contents are what you expect. Makes your tests more complete (and that you are not just testing your mock implementation rather than your actual logic) while keeping them isolated and fast - all the benefits of a small unit test combined with the wider scope of an integration test.
Couldn't agree more with this comment and the thread in general, it's a relief to see. I get so frustrated as so many of my colleagues seem to cling to this very old concept of the testing pyramid and associated definitions. It's completely meaningless in a modern setting. We should mock as little and as far back as possible, yet others seem to delight in locking huge chunks of functionally out of the test base just 'because'.
I believe we should have a new word that differentiates between ultra-basic tiny unit tests, and bigger unit tests that are still not integration tests.
E.g. rust and some other newer languages have a way to write basically an inline test for a function — that would constitute my former category. These make sense during development as a reality check. “Yes, this ad hoc stack I need inside this class should have two elements if I push two elems” sort of thing. That implementation may not even be accessible from the outside in case of an OOP language so you can’t even properly test it. Also, these are the ones that should change with the code and removing them is no big deal.
The other kind should work against the public APIs of libs/classes and they should not be rewritten on internal changes at all.
I actually love that they’re so brittle because it quickly catches problems that need fixing.
Tests are not brittle when they catch actual problems. Tests are brittle when they break for no good reason. And really when you are refactoring something tests should not break - you are not changing behaviour, just reorganising things. If you need to do big changes, rewrite or even delete tests when you refactor something then your tests IMO are brittle and much less likely to catch regressions in behaviour. Yeah you will need to tweak them some times, but these should be kept to a minimum and not be happening every time you refactor anything.
When writing new code small tests can feel good, they are easy to write and you can test things quickly in isolation. But after that point how much value do they give you? Tests do have a cost - beyond the original time you spent writing them, you have to maintain them, and keep them uptodate, they take time to run etc... If they cannot properly catch a regression when it happens then IMO they are not worth the cost of keeping them around. Larger tests tend to be better at catching regressions and are less prone to need to be tweaked when you refactor the internals of something.
So, generally speaking I tend to prefer testing public APIs of something and ignore internal helper functions (unless some helper is sufficiently large/complex enough that it warrants extra dedicated tests, which is not common). Note that this does not mean public to downstream users of your library/script/binary, but also larger internal modules API that the rest of the application can use. Though I do find quite a few smaller applications you only need to test the actual public API from an end users perspective.
A lot of that has to do with type checking and a lot of the methods would have huge consequences if they were off.
Uhg, This is a big reason I don't like loosely typed languages. Yeah that might be one case where smaller tests are needed but IMO testing input types should not be required at all - that is something a compiler can do for you for free. At least assuming you have a strongly typed language. People always say loosely typed languages are faster to code in - but this benefit is completely lost when you spend ages writing tests for different inputs types that a compiler in a stronger typed language would just reject.
I am not smart enough to effectively code with certain languages and design patterns and that's ok. There is nothing wrong with accessibility being prioritized or with making tradeoffs for the sake of reducing complexity.
Agile isn't that bad. People just believe they are more productive if they are "heads down" and not held accountable for what they write/do.
Functional programming isn't that great and doesn't solve all of the world's problems; it just pushes the issues with state to other parts of your design, and doesn't scale well in deeply nested solutions.
IDEs with proper code support (i.e. automatic structure analysis, autocomplete, etc.) are one of the best ways to deal with a large codebase that needs refactoring. Doing widescale refactors without one is asking for trouble. If you believe you don't need it, either your codebase is just that small (which is fine) or playing with fire.
Much of the advice out there on architecture and tooling isn't properly contextualized on the codebase, market, and team situation. If you believe you have the One True Architecture Solution, you are naive. (Ex. Microservices, large complex code pipelines, monorepos, etc.) Be especially wary of anything from FAANG engineering blogs unless you are also in another letter of FAANG.
There. Got it out of my system. Have fun dissecting it.
Designing good UX can be as difficult as writing good code.
Source: Im UI/UX designer and project manager and also QA/QC and also devops and also write the specs and documentation. The only thing I dont do is write the code, DB schema and architecture . The hardest of all those roles is UX. The easiest is project management ("Did anything go tits-up today? No? Well carry on, then ")
Biases: I have no formal training in any of those things and was actually hired as a helpdesk tech.
Web development feels like it's stuck in the early 2000's. I've ranted a lot about it over the years but I just don't know how everyone is okay with it. I'm sure tons of people will disagree.
HTML is bad. The language itself feels unintuitive and is clunky compared to modern markdown languages, and let's be honest, your webpage just consists of nested <div> tags.
CSS is bad. Who knew styling can be so unintuitive and unmanageable? Maybe it made sense 25 years ago, but now it's just terrible. It's very clunkily integrated with HTML too in my opinion. Styling and markdown should be one easier to use language where 50% of it isn't deprecated.
Javascript has been memed to death so I won't even go there. Typescript is OK I suppose.
And now for my hottest take: ~10+ years ago I saw web building tools like Wix and I completely expected web development to head in the direction using a GUI to create, style, and script from one interface, even allowing you to create and see dynamic content instantly. I've seen competitors and waited for "the big one" that's actually free and open source and good enough to be used professionally. It never happened. Web dev has just gone backwards and stuck in its old ways, now it's a bloated mess that takes way more time than it deserves.
The Godot engine is actually a pretty good option for creating GUI apps and it's exactly what I envisioned web dev should've been this past decade. One language, intuitive interface, simple theming and easy rapid development... Shame it never happened.
We use too many libraries. This may be an actual unpopular opinion though. I find that the more a library tries to do, and the more dependencies it has itself, the more hesitant I am to use it. It just feels like a tower of cards ready to fall at any moment.
I'm not a very trusting person and work alone though so this might just be an emotional decision. But it is nice having a project be composed of code that does just what is needed and nothing else. It makes it easier to fix bugs and especially to maintain the code.
I do use libraries, but only if they're absolutely necessary or if they're very focused and don't try to do a million things. It's not about size but complexity.
MATLAB is an okay programming language when used in the right context. It’s intended for scientific applications, so trying to do your standard object oriented programming with it gets weird. I think we forget that some things were made for a specific purpose- you know, a hammer can’t do everything and all that.
My hot take: Vi, make and C would have gone the way of COBOL a long time ago if it wasn't for a lot of programmers thinking "my tools are more difficult to use, hence I'm a better programmer".
I don't find this helps. More often your assumptions about how something might change are wrong and when the actual change comes in you can end up causing yourself more work undoing the abstractions you made. IMO keep things simple as you can for as long as you can and add in abstractions when they are needed and remove them when they are not. Write code that is easy to change when change is needed, not code that tries to account for all possible future changes as this is impossible to do.
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.
If white space carries any function that the compiler/interpreter needs to know about like structure or scope, it's probably not a very good programming language.
I really love the project structure of C++. I know that it is an archaic design developed like this due to lack of resources, but I find packages extremely offputting.
The first reason is that splitting declaration and implementation across files makes it easier to figure out what something does.
Second reason is that I feel that I have more control over libraries and packages that have to be manually added to a project rather than using a package manager.
Third, I feel like modern languages iterate over too many versions too fast. C++ has version releases too, but I feel that versioning is handled better from time, compatibility and stability point of view.
Just copy some code over into a not properly configured vim.
People seem to forget that not everything is a fully configured development environment working locally on your laptop which attempts to fix the issues introduced by that design decision.
It also greatly improved readability of the language. Since switching to the standard of using 4-space tabs, I've not had any problems except when dredging up someone's old Python 2 code.
You can create some really ugly code in spite of the forced indentation in python. Indentation does not really help here at all. In all languages you can correctly or incorrectly format things. A code formatter strictly applying a coding standard helps far more here than indents vs bracers. Take a look at black it takes the pep8 standards and adds more strict things on top making code look a lot more consistent and thus makes it easier to read.
And all formatters will indent code consistently, so having it as part of the language parser does not really help improve readability at all. And even without a formatter everyone I know will still correctly indent their code no matter the language used. But sometimes forcing new lines to have a meaning does make things worst - just look at pythons lambdas which have to be a single line.
Indentations does not really help readability that much in case of really, really, long code, and in some cases, a code can execute without with unexpected result because of one single indentation being off. Both of these why I like things like curly braces/brackets and terminators like endif/fi/done/end/etc. But, at the end of the day, if there's a readability problem, then that's a sign that the code needs to be reworked on.
Braces too can be wrong. But, one is less likely to get it wrong. Modern editors often allows one to highlight matching braces immediately after selection, and rainbow braces(if available) makes it clear on the nest level.
Oh I think indentation helps a ton with readability. Even for bad, long or otherwise hard to read code - it would be way, way worst with no or wrong indentation. Correct indentation helps a lot. It is not the only thing that can be done to improve readability but it is the first and simplest fix you can apply to a code base. So a language enforcing it with syntax does not matter when even basic text editors can correctly and automatically indent your code.
Though one thing I do like about bracers is I can be lazy with formatting and let my formatter sort it out for me on save. With a white space sensitive language you need to get it correct from the start or else the program just does the wrong thing.
I didn't say it doesn't help. But, it alone does not really help for bad and long code, but you are correct in that it would be worse with the wrong indentation. Like you pointed out, the program could do the wrong thing if there is a wrong indentation where indentation matters which is one of my issue with something like Python. And languages with explicit exit scope tend to not have that issue while adding to the benefit of making longer code readable. Where white-space sensitive languages really shine on in my opinion are small codes, and that's where I think of using Python.
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.
Heh, I was about to comment how my hot take is that Python is overrated. It's... fine and I don't really have anything against it for the most part, but I greatly prefer Ruby to Python.
I'm speaking purely about the language itself here, not any libraries available for it (since someone will always point out how great Python is for data work).
My impression at the time was that Ruby and Python both caught on with people who were ready to be done with Perl.
And, later, that Go set out to be a replacement for Java, but ended up with one of its major use cases being a replacement for Python for ops and SRE folks who were ready for type checking and built-in multithreading.
Oh man, I actually like the language, but you made me think of my own hot take:
Python has inexcusably poor docs.
Just a smattering of examples, which aren't even that good, while failing to report key information like all the parameters a function can take, or all the exceptions it can throw. Any other popular language I can think of has this locked down and it makes things so much easier.
Python has had syntax support for type annotations for a while now. The Python runtime doesn't enforce the typing at all, but it can be enforced by a linter or by your IDE. And I believe you can introspect the type annotations at runtime, because they are actually part of the syntax.
There's even an alternative way of doing type annotations through specially formatted comments, just in case you might still need to write code that is backwards compatible with Python 2.
I'd argue, 99% of the code written is not performance critical in the sense that a different language could help. Either performance really doesn't matter that much, or it's an IO problem. You can process as fast as you want, if the DB takes 100ms to respond, you won't get below 100ms overall.
For bigger projects, anything with MANDATORY types is a must for me. Optional, not compiler checked hinting doesn't cut it.
Not that i hate the language, but I do hate the tooling around it. I don't think I've ever had a pleasant experience with setting up a Python project. And all the data stuff is just wrappers for code in other languages, making the packaging story even uglier, even harder.
You're right now to compromise on this, but you can give yourself mandatory types in Python, using MyPy, if that's your only issue with it.*
Because you don't need elegant subprocess handling, intuitive reliable logging, and don't mind needing a to autonate a linter to check for whitesoace bullshit.*
**Python is my favorite language, actually. Really.
Most frameworks are garbage and most programmers that use them have no idea how they work and that makes them shitty programmers. I hate when people use frameworks without even knowing why they’re using them.
Oh I agree that questions are two often badly answered! The exemple of "why don't you use this instead" is the worst offender. I didn't understand you were talking about this, and I'm still traumatised by javascript after 14 years.
This isn't limited to JS. Too many times have I seen someone ask a question of how to do XYZ in language ABC where most of the replies were some form of "Just use this library bro" while not actually answering the question. And usually the library that's being suggested is some big monolith that implements a ton of shit that no one really uses.
TDD is overrated. Code coverage is extremely overrated. Both of these tend to lead to a morass of tests that prove the compiler works at its most basic level while simultaneously generating a surplus of smugness about the whole situation.
Tests have their place. Tests can be, and often are, valuable. But the easier the test is to write, the easier it would've been to just encode it into the type system to begin with.
Most technology, programming languages and frameworks feel just the same, in a professional environment. Majority of web and apps is so simple that literally anything will do. Simple api consumption, simple database crud stuff. The tech stack doesn't matter that much.
If programmers stick to what they know and not try to solve every problem at hand with the latest thing/programming language they've learned then there would be fewer bugs and projects would end by the estimated dates.
I think failed estimated dates just highlight how much we don't know about ourselves, our systems and our own knowledge.
It is the abyss of the unknown talking back to us. We have the privilege of having the stuff we don't know thrown back at us to prove us wrong. And we often fail to be humbled by it.
Much of the job is dealing with the unknown. A surprise in scheduling can either shorten a task or lengthen it. It can't be shortened past the time it takes to recognize it's finished, but it can be lengthened indefinitely.
🌶️🥵Many people consume Facebook meta company's tech stack wholesale, don't know how to actually traditionally program their way out of a paper bag, and web dev and devops caused a massive layoff (250k people) at the end of 2022, start of 2023 because it was all vaporware. They consume the same software in droves if the other guy uses it.
There is an entire subculture around it that is just a bunch of medium.com writers, YouTubers and twitter handles just trying to get the clicks for their ad money. Some of these guys have never written valid software or done anything noteworthy. If you meet them head on you'd find they have enormous egos and can't find a counter argument when presented with reason.
I'll even add on that there are many programmers who don't know how to code outside a web app.
Why is something like [react, graphql, react ssr, devops, tailwind, unit tests, containers] vaporware?
there are other frameworks even with component libraries that are easier to read the code for large codebases, better maintained, and have cohesive full stack solutions, and even faster to develop in, to name one quasarJS or even just plain ecmascript
if you look at the anatomy of these enterprises using these solutions they've evolved to have micro front ends requiring armies of workers.
devops is a sales term, the actual implementation of it is so contextual that you'd probably find you don't need a full time job for it half the time and most are relatively easy to setup inside of a business quarter
not everything is Facebook scale: unless you're padding your resume why did some of these get adopted? How complicated does your app need to be? Did you really need to transpile JavaScript for it?
unit tests were code to test your code that you're going to have to functionally test anyways: you're telling me that you have to write your code...twice? How the hell did this ever get justified to mangers? Why did the culture not evolve into literal automated smoke tests of the actual builds, instead of testing whether a function that is probably type annotated is going to fire anyways???
docker/containers suck ass: great that they solved a problem but created a whole new one. we moved to python and JS which were JIT without artifacts and suddenly everything needs a generalized build system to run it. C lang variants and Rust lang compile to a binary you can just run... Ship the small ass binary not an entire container to run your shitty web app
You know the stuff I don't hear about?
Javascript and Python were steps in the evolution but never the end goal. I'd even say the same of java. There are new solutions but JavaScript in the browser especially should be replaced.
eye appeal is buy appeal
that eye appeal shouldn't always mean you need to use a library or framework; vanilla apps work okay too.
well written logging to the point someone can tell what the application was doing without seeing code
using all these compsci algorithms to actually write new products and searches from scratch instead of being a framework baby: do you actually need ELK or Splunk for your search? Really?
you probably don't need MySQL for a lot of projects, I bet you an async library with sqlite would be the same for many of these projects.
small teams with feature rich apps using SSR, the value of an SSR web app
the value of a SPA
the value of traditional desktop software and not using REST APIs
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.
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.
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.
Write the whole thing, and only then, scrap it and rewrite it. This way you actually have a good understanding of the entire implementation when you are rewriting. When I refractor while writing my draft I will slow myself down and trip over myself, I'll be way more likely to rewrite something I've already rewritten.
Sure there is a limit to the size of projects this can work for, but even for massive projects they can still be broken into decently sized chunks. I'm just advocating for not rewriting function A as soon as you finish function B.
Write the whole thing, and only then, scrap it and rewrite it.
Exactly. And that's the part a lot of folks don't understand about writing tests. If we're not sure an interface will survive into the rewrite, it probably doesn't belong in the test suite.
And the rewrite can be very fast, if we tested the right things.
Python, and dynamically typed languages in general, are known as being great for beginners. However, I feel that while they’re fun for beginners, they should only be used if you really know what you’re doing, as the code can get messy real fast without some guard rails in place (static typing being a big one).
Good programmers need to be creative, flexible (soft skills with others), critical thinkers, and problem solvers. Lacking those kinds of features makes for a rigid and terrible programmer that is near impossible to work with or code behind. Leave the ego at the door.
If your function is longer than 10 statements, parts can almost always be extracted into smaller parts. If named correctly, this improves readability significantly
Having fun when programming should be much more important than having correct or fast code when you're a programmer and should be what we should aim for first.
Don't enforce using the same tech stack on each new project. When customer, domain, environment, requirements etc differ, so might the tool suite, languages, frameworks etc
I find that S-expressions are the best syntax for programming languages. And in general infix operators are inferior to either prefix or postfix notation.
I never understood how concatenative programmers can hold the current state of the stack in their head and never get confused about what is where, especially when changing complex code.
depends on the company/team culture. are other people gonna have to fix or extend code you wrote? are you the sole engineer working on entire modules? do you hate feedback?
We'v known this for twenty years and had the data ta back it up for ten. Github flow is one of the most damaging things to ever happen to software teams
Got asked about this twice so I'm cut/pasting my answer, but happy to discuss further
Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker.
what data? just curios because there are so many ways to do PRs properly.. like for everything, if it's done badly better not do it. does not mean it is inherently bad
Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker.
My crazy take is that there needs to be a interpretative language alternative to Python which uses brackets to define scope and/or things like elif/else/fi/endif/done. Much easier that way in my opinion, and the ";" shouldn't be necessary. I'm used to Python, but if I had another language which can be used to serve similar purpose to Python with those features, I would never code in Python again when it comes up.
Having to code in Julia and G'MIC (Domain-Specific Interpretative language that is arguably the most flexible for raster graphics content creation and editing), they're the closest to there, but they're more suitable for their respective domain than generic ones.
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.
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.
That the HTML/CSS structure of web programming is absolutely disgusting and not necessary. The internet could be and should be so much more from a developer pov. Also people who double space instead of tab often have their mouths open while mashing space 16 times.
I completely understand and clearly see that web development is the future, but I still think it’s all gross and will always prefer targeted efficient compiled code. Why? Because I’m a huge fucking dork.
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.
If your code files don't contain more lines of comments than lines of actual code, then you're doing it wrong. (For Python, docstrings count as comments)
And your comments shouldn't say what each line of code is doing. If you can code, then you can already tell what each line is doing by just reading the code. The comments should explain WHY it's being done this way, or HOW it's being done, or highlight some pitfalls that might snare a future developer, and generally just give some higher level context to a line or block of code.
Oh fuck I hate encountering this level of commenting. If it's complicated, you should have a design doc. Source code is not where you write your dissertation. Simple explanations are good, especially since the code could be updated while the comment is likely to remain unchanged. Long expositions are usually the result of bad coding or improperly allocated design.
Absolutely agreed. If your code line by line isn't clear, then the code is the problem.
Commenting before a block of code (a function / algorithm or whatever) explaining what it is meant to do, absolutely that's great though, saves time when revisiting.
And that one single line that makes zero FUCKING SENSE AND YOU SPENT 5 DAYS TRYING TO FIX IT!!! That definitely needs a comment so the next idiot (aka you in 6 months) doesn't think "what useless shit is this? Let's delete this!".
Comments are for revision control systems. We have a strictly no comments in code policy because comments too often end up being wrong or misleading throwing everyone believing in them for a wild ride. The only thing that is worse than bad code is bad comments.
When you read sensible and thorough commit messages you generally have the notion that whatever it says was probably true at the time of the commit, whereas when you read comments in code it can still be correct or just plain utterly wrong.
@nthcdr this assumes that people write sensible and thorough commit messages, instead of brief five-word ones or, say, song lyrics. Both of which I've seen.
I at least try, except maybe for the other day where my commit message consisted entirely of an exasperated "why", followed by a revert.
That being said, every commit message where I work is required to contain a ticket number (and the server will reject the push if you don't) so at least there's that for context.
Yes there need to be some assumption that your co-workers write reasonable commit message even if they have their lapses now and then.
Another problem with comments in code is that they tend to be short because nobody likes to read code interspersed by walls of prose. But many times if something really needs explaining you also need a little more room doing it. Thus when committing in code people tend to gloss over important detail.
Then of course there is literate programming. The other end of the spectrum, but then we're talking code in documentation not comments in code.
I left the company, worked at other places in other languages, the company restructured, moved to India and back, got new premises, headhunted me because someone remembered that I wrote this particular system (serial port controller for certain industrial machinery). When revisiting code that I wrote 15 years ago, I was glad that my comments explained what I was doing, and why, and how, because all the other documentation was long gone. Don’t imagine that the original design documentation will still exist when you come back to it.
Front end and back end are different enough that you can really specialize in one or the other. They take very different mindsets. I know how to make css obey, I don't know how to make sql performant. Its possible to have both, but not as well.
For every front-end dev, you need 3 back-end guys and a designer.
Programmers are not bad at our jobs, its just not a mature disclipline yet.
I'm not convinced that "strong pairing" is the best way to pair but even people who rail against agile ideology tell you that you're pairing wrong if you don't follow it precisely.
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?
You absolutely do not need a computer telling you what types you can put in a collection. Put an assert, write some unit tests, if you aren't sure where data sources come from and can't write a one-line comment.
Dynamic typing makes you fast, it's empowering. Try it and quit being so scared.
No matter how many unit tests or comments you write, it's impossible to "prove" type correctness in a dynamically typed language - and it will eventually blow up in your face when you have to refactor. There's a reason for the adage "testing can't prove the absence of bugs."
People like static typing because it offers strong guarantees and eliminates entire classes of bullshit bugs, not because they're "weak minded."
Incorrect. Static typing can prove many things, depending on the quality of the type system.
At the very least, it proves that your data is organized, stored, passed around and used in a logically valid and consistent manner. Make that proof impossible, and the compiler complains. (And with good reason - it doesn't matter how good your program logic is if you're feeding it bad data. Garbage in, garbage - or a runtime error - out.)
In a dynamically typed language, your program logic still implicitly depends on that proof holding - it's just that you, the fallible human, has to make sure everything checks out. Python added type hints for precisely this reason.
Additionally, with more advanced static type systems, it becomes possible to issue guarantees beyond simple type safety. Patterns like typestate (found in TS, Haskell and Rust, off the top of my head) can be used to make illegal states unrepresentable at compile time. Try to write to a closed file or make an invalid state machine transition? The compiler will see it and say no.
It just creates bugs and crashes.
In what universe are runtime errors turned compile-time errors a source of bugs and crashes? A statically-typed program won't blow up in production because some poor intern wasn't able to keep the implicit type bounds of every single function parameter in his head.
There's some math & CS papers you should read, Gödel's incompleteness theorem, Turing's halting problem. YOU CANNOT prove your way out of logic errors. You cannot make a universal type system. All you're doing is wasting time with false confidence.
I'm not any faster in languages without static types. It's the opposite, I'm fastest when I can write accurate type hints, since it makes the editor experience much better.
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.
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.
Only if the code base is well tested.
Edit: always add tests when you change code that doesn’t have tests.
And also try to make tests that don't have to change if you refactor in future (although there are some exceptions)
Doesn't everybody agree with this? I really never thought of it as a hot take.
I highly doubt most corps do
Corps != people.
People just pass the buck and nobody stands up for what is most correct
This
This is coming from a guy who lasted a year and a half in the office. Sounds like it's a systematic issue..
Today I removed code from a codebase that was added in 2021 and never ever used. Sadly, some people are as content to litter in their repo as they are in the woods.
Our company motto is: "leave it cleaner than you found it"
Who is in the wrong? Your manager, for not giving you time to refactor? Or you for giving him the option?
Why do you need time to refactor? It is just part of the work you need to do and should be accounted for when doing any other work. IMO a big mistake people make is thinking refactoring is some separate thing they need permission to do. You don't, if you need to make a change in some area refactor it first to make it easier to accept your change, then add your change then refactor to clean up. This is not three separate tasks, just three steps in one task. You should be given enough time to do the whole task, not just part of it.
I guess I need to refactor for readability. What you just explained is the entire point of the comment I posted. Refactoring is part of the job. Don't give your manager a choice on whether or not it needs done.
Yes please. Many times when I add a feature I end up refactoring some of the code first to better accommodate it.
thank_you_michael_scott.gif
We used to call this ‘Code is Cheap’ at my last job - you’re spot on about the value of it
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
inton 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.
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.
If you only know C and you're looking at Python, the absence of curly braces on code blocks is temporarily unfamiliar to you.
But if you only know Python and you're looking at C, the fact that indentation doesn't matter is temporarily unfamiliar to you.
Once you learn the new language, it's not unfamiliar to you anymore.
"Unintuitive" often suggests that there's something wrong with the language in a global sense, just because it doesn't look like the last one you used — as if the choice to use (or not use) curly braces is natural and anything else is willfully perverse on the part of the language designer.
I mean only if you consider "Intuition" to be some monolithic, static thing that's also identical for everyone. Everyone has their own intuition, and their intuition changes over time. Intuition is akin to an opinion - it's built up based on your own past experiences.
I don't think it's that deep. All people mean when they say it is that "[thing] defied my expectation/prior experience". It's like saying "sea food tastes bad". There's an implicit "to me" at the end, it's obvious i'm not saying "sea food factually tastes bad, and anyone who says they like it is wrong or lying".
No programming language is “natural/obvious/without effort”.
You could say that about anything. Of course you have to learn something the first time and it's "unintuitive" then. Intuition is literally an expectation based on prior experience.
Intuitive patterns exist in programming languages. For example, most conditionals are denoted with "if", "else", and "while". You would find it intuitive if a new programming language adhered to that. You'd find it unintuitive if the conditionals were denoted with "dnwwkcoeo", "wowpekg cneo", and "coebemal".
Languages also have inner consistency. E.g. the mentioned python len function is inconsistent with the rest of the same language - and that is a statement that is true in itself, without an external reference point.
Yes, I agree that the
len()thing in Python, and inconsistency in general, is bad. But pretty much all popular languages have many inconsistencies.But there are languages that require varying degrees of effort to become natural. Something like Malbolge will pretty much never be natural while something like Python can become natural to you in a few days.
Yeah. The original comment was about programmers who say that a language is “unintuitive” because it doesn't look like another language they know.
Idk, I don't see a problem with saying a new language is unintuitive. For example, in js I still consider the horrible type coercion and the "fix" with the triple-equals very unintuitive indeed. On the flip side, when learning C# I found the multiple ways of making comparisons to be pretty intuitive, and not footguns.
Yeah. I've written in six or so different languages and am using Go now for the first time. Even then, I'm trying to be optimistic and acknowledge things are just different or annoying for me. It doesn't mean anything is wrong with the language.
ZZT-OOP is fun to work with though, definitely not meant for doing anything more complex than light gameplay, and yet people have done ridiculous things with it.
Though I personally did most of my coding in that vein in MegaZeux with their Robotic language, which is basically ZZT-OOP++.
I still think ruby is a bad language, even though I agree with you
I found ruby horribly confusing until I got over the intial learning bump.
Now I love it. It really is lovely. In terms of design that is. Not sure about the monkeypatching
I really don't like how rails brings things into scope and you just have no idea what's there or how it got there unless you know all of the conventions. I guess that's a rails issue and not ruby though.
I learned in python and C++ so I'm biased towards things that are extremely specific. Definitely doesn't mean ruby is necessarily bad, I just don't like it.
I'm one of those weirdoes who likes ruby and has never used rails, so no opinion there.
This is very true! Languages being unintuitive also becomes less of an issue the more languages you look into. There will be many concepts that multiple languages have since ultimately they are all trying to do similar things and the more you learn the more you will recognize making it easier to get into even more languages.
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.
Tools that use a GUI are just as good (if not better) than their CLI equivalents in most cases. There's a certain kind of dev that just gets a superiority complex about using CLI stuff.
The big thing you can do from the command line is script it.
Indeed, the problem with gui apps is when you can’t script them!
I always loved alfred on osx, then loved scripting rofi on linux, only to come back to osx years later and find alfred can’t be invoked with stdin options. It’s damn shame….
I used to think something like this when I was younger. I spent an inordinate amount of time looking for good gui versions of cli tools. I have come to understand that this is not usually the case and cli tools are more convenient much of the time. I would not classify this as superiority complex, unless I’m being a jerk about it. I don’t care what you use, I just use whatever has the lowest barrier to entry with the most standardization, which is usually the original cli tool.
That said, jetbrains git integration is awesome.
It also depends on the specifics — in many cases when a GUI is just a wrapper over the CLI tool, it is instructive to learn the CLI, similarly how you are a better programmer if you know about at least a layer beneath the one you are programming at (e.g. you can reason about this usage of hashmap because you roughly know what it does).
It is probably the most visible in git, but if you can only do commit and push from a GUI, just please learn the CLI as well. You don’t have to use it, but understanding it is important and the GUI may abstract away too much from you.
I agree only when your job function is specifically geared around those tools... Otherwise high quality guis are more valuable.
Just because I can do everything in gdb that I can do in visual studio doesn't mean 99% of most debugging tasks isn't easier and faster in visual studio. Now if my job was specifically aimed at debugging/reverse engineering there are certain things that gdb does better on the CLI... But for most software devs... CLI gdb isn't valuable.
There are some massive intrinsic advantages of the CLI though, that apply for everyone, not just leetcoders:
fzfand run the exact same command again.So while I agree with you that there's plently of elitism around the CLI, you do yourself a disservice if you try to avoid it.
Just no. CLI can be automated, which makes it superior. It's not a superiority complex, it's a fact. I'm not a minimal wage worker pushing buttons I don't understand. I'm not a technician who learnt your shitty software to do the most basic tasks.
My gold standard app is a CLI where I have the option to visually add the flags. I'm thinking of the ytdlp-gui type programs.
Which yt-dlp GUI do you use?
On windows I was using youtube-dl-wpf
That's the gold standard as far as I'm concerned. Haven't used the ytdlp-gui yet, but it's simple stupid.. I might want a few more switches (more exactly the extract audio/subtitles) to turn
Aside from automation, CLI can support significantly more complicated apps reliably. It can also be tested more reliably.
GUIs are better for anything simple, and good UX designers can make a moderately complex one, but anything like server administration/git/configs are 100x better on CLI
I don't know, a tool we use at my work has a git GUI integrated, and it breaks all the time, lol.
This depends a lot on the GUI and the tool. Some cli tools are great alone or for scripting, others benefit from the extra attention to ux and exposure of options that a GUI can offer
For git in particular, I encourage juniors to learn and use the CLI. I find that GUI git clients often do some or all of the following:
Use non-git terminology that ends up being confusing. "Sync" comes to mind as a frequent offender, I can think of several incompatible things that could refer to.
Ignore the useful ability to stage your changes
Don't permit or encourage a review of the changes
Implement only the basics and make remediation of branching issues difficult
In the worst case, I've seen people end up using the git GUI like a "save" button, blindly commiting and pushing the current state of their code, including to-be-removed print statements and other cruft. Yeah, git cli is a bit complex compared to that, but you gain a lot for that added complexity.
That said, I've definitely jumped into a git GUI from time to time just for a visualization of whenever branching snafu I'm trying to untangle. None of the above invalidates GUIs if you take care to still understand the underlying tool properly!
Programing is a lot less important than people and team dynamics
People can always be replaced, they're irrelevant.
The code can always be rewritten, it is irrelevant.
And it will change next week anyway. 😁
Sure try to replace the one or two people that hold the whole team together. I've seen it a couple times, a good team disintegrates right after one or two key people leave.
Also, if you replace half the team, prepare for some major learning time whenever the next change is being made. Or after the next deployment. 🤷♂️
Not sure if these are hot takes:
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.
If code reviews in your org are glorified "styleguide checks", then they are not really code reviews at all.
Also, if you're only getting design input at code review time, that's WWAAYY too late in the process.
Code reviews should be:
Establishing that the code has proper test coverage (functional correctness VIA coverage, not code observation)
Establishing that it doesn't have unintended consequences in the ** implementation** (making db calls in a loop, exposing secure information, etc)
That the implementation is of the high-level design that was already established and agreed upon by the larger development unit.
A opportunity to ask questions to learn from whoever wrote the code
An opportunity for the reviewers to teach techniques that could have helped in the code
You missed one:
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.
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?
Imo reviews are more for checking that someone didn't drop malware into the code base. It's rare that I get a good review that goes beyond checking for malice.
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.
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.
Most modern software is way too complex for what it actually does.
Python is only good for short programs
The best codebase I have ever seen and collaborated on was also boring as fuck.
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.
You can always solve a problem by adding more layers of abstraction. Good software design isn't to add more layers of abstractions, it's to solve problems with the minimum amount of abstractions necessary while still having maintainable, scalable code.
There are benefits to abstraction but they also have downsides. They can complicate code and make code harder to read.
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 still hoping for browsers to become some kind of open standard application environments and web apps to become actual apps running on this environment.
How are browser not that already? What's missing?
They are an open standard and used to make many thousands of apps.
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.
Actual hot take, Blazor is awesome, it is like Microsoft looked into ASP.NET Forms, ASP.NET MVC and Razor, and bundled it to one quick framework to do simple WebApps.
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.
Server-side works better, webassembly and fat client on general imo aren't worth it. It's benefits require millions of users.
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.
This is the only way;
Not
Also because of my dyslexia I prefer variable & function names like this; 'File_Acces' I find it easier to read than 'fileAcces'
Internet would be better if javascript was never invented.
Agile in it’s current implementation with excessive meetings wastes more time than the mistakes it tries to avoid.
Dynamically typed languages don’t scale. Large project bases become hard to maintain, read and refactor.
Basic type errors which should be found in compilation become runtime errors or unexpected behavior.
Hot take: people who don’t like code reviews have never been part of a good code review culture.
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.
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.
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
You can use all the classes, patterns, functions, methods you want but if it's not readable it's garbage.
Make your app use native components instead of making your own crappy theme for the 782th time
Full IDEs kinda suck.
Entirely agree with this.
And at least as far as Firefox goes I'm running it on gnome and there's a beautiful theme that makes it look native for it. I'm sure there's one for windows too if you look.
The desktop website is so bad... I ask for a light theme in my settings, they don't care (it's white on black) because it's HARD to add a few CSS rules. Then there is a flash of light which could give a seizure to someone with a condition. It's shitty design at its peak. That doesn't really inspire confidence...
Firefox is really badly integrated in MacOS. The fn + arrow shortcut doesn't work, for example, it's not integrated in the menu system (the menu shortcuts don't work) etc. But there is Sideberry, so...
Some languages really do suck so much they're all but unwriteable by plain text, and need constant compiler tree parsing to get right.
But that's an incentive to quit using bad languages. Write in something you can read and write in ed, and you can hold it in your head.
Not arguing either side, but I'd love to hear your reasoning.
A linter a debugger and a clean interface in general are all I need. And most text editors suffice for that.
I've never been able to benefit from an IDE in a way that make up for how much slower and more bloated they are.
I'd love to hear what some of the main benefits are though.
Niche language, but try out PureBasic.
Its IDE is based on Scintilla. And it is very fast, even on an ancient PC it runs. It is specific for the programming language.
And here some advantages it has compared to a simple text editor:
I agree with you in many points. Most other IDEs I am forced to work with are horribly slow. Especially those which rely on electron. Sometimes they lack features every basic editor has by now.
This is to say: Good IDEs can exist and are a great benefit for the programmer. But modern IDEs often chase keyword features and use complex and bloated frameworks to achieve them. Sometimes even forgetting to add basic features which made IDEs a thing initially. An IDE should take almost no time to setup to your needs and should not hinder with complex operations which take seconds to run, it should only support in code creation and aim to make features like autocomplete show suggestions in milliseconds.
In my experience it HEAVILY depends on the language you're using. Nothing beats Intellij for Java or Kotlin, but Rust and Go feel at home in any editor.
I know that LSPs and DAPs somewhat take care of these, but the following are often easier in IDEs:
Jetbrains IDEs do a lot of indexing and caching so that operations that normally take a bit are faster. Full text search, find usages, identifying interface usage in duck types, etc.
But the killer feature for me is the refactoring tools. Changing a function signature, extracting an interface, moving code to new files or packages, etc. I pair with folks who use VS Code and its a bit tedious watching them use find and replace for renaming things.
That does sound legit if you have resource limitations. Thankfully I've always worked for corporations that hand out MacBook Pros like candy. Normal day for me is having two Jetbrains IDEs open with Chrome, Slack, Zoom, and a dozen containers. Still runs smooth.
VS Code absolutely has refactoring built in. Pressing F2 on a token renames it everywhere it's referenced
Interesting. I'll have to find some docs and share it with my co-workers because they definitely don't use build-in refactoring. Thanks!
Huh. I've only ever tried jetbrains stuff for about five minutes. Got mad confused and angry and gave up.
I might give it another go. Thanks.
I think they mean xcode.
I love intellij. The gut Integration and diff utilities alone are worth using it. However, it is so. Fucking. Slow!
Seems fast enough for me. Never really had to wait on the ide for anything
it really struggles with mid sized monorepo (think react libraries managed via NX)
Python development without PyCharm (or IntelliJ) and the IdeaVim plugin is unbearable. List usages is a game changer. Don't care much for anything else.
Whaaat? I program Python with plain vim. C or Java, on the other hand, with a large enough codebase, is unbearable without an IDE.
Depends on how large your Python projects are. If you have a million lines of Python code, navigating quickly and directed is invaluable.
I used plain vim before for Python projects, but these never grew above 50k lines of code.
Yup. Emacs, here, but same thing. Never used PyCharm or any other Python-capable IDE, and I've been coding large python projects for the same company for almost a decade.
Yeah, well, that's just Python for you. List usages is now an LSP feature for most languages, so will work with "lesser" editors too.
All that being said, I use Intellij with Java daily, so I can see where you're coming from. But for example Rust or Go works wonderfully with Neovim (or VSCode).
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.
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.
Microsoft has not made a good product. Ever. Every program has issues that should not be there if you're selling it. Yet they get away with it
Oop is overrated
I never can understand classes
In unit testing, a "unit" does not have to be the smallest possible section of code. It can be a while class or module or even set of related classes/modules. Testing individual functions in isolation leads to brittle tests that easily break during refactoring. Testing overall system behaviour results in more robust tests that require fewer changes during refactoring which gives you more confidence then you have not introduced a regression.
IMO, you should usually test only stable interfaces.
If you have no stable interface all the way into the UI, then you shouldn't test anything all the way into the UI, and focus your tests there. Odds are that your code isn't very good, because it is rare that you don't need anything stable all the way through, but well, "rare" is not the same as "impossible".
This is the correct comment.
Martin Fowler called them sociable tests. The only way to properly test your units' behavior is to pull in their dependencies. Isolated tests are useless, brittle and slow to write.
Yeah I'm of the opinion that unit tests are usually a waste of time and people should only write integration tests.
The only time I think unit tests are valuable is for checking edge cases when e.g. interacting with the operating system.
Honestly, I don't think unit tests are a useful name. Everyone has a different idea of what a unit is and the line between unit tests and integrations tests is IMO not very useful. As long as your tests are
Then where you draw the line between unit and integration is meaningless. It was meant to be that ingratiation tests were slow, so you wanted to shrink them down to make them faster to run. But I have not had a problem with the speed of more integration style tests in a long time.
I also don't think interacting with the OS is such a bad idea. For instance the filesystem (what everyone always points to as an example) IMO is fine if done right. The big issue with interacting with the FS is keeping your tests isolated - too many people end up reading/writing the same file locations and thus breaking isolation. But you can always create a unique tmp dir for each test and do what ever you want inside that. Interacting with the filesystem on modern system is fast, and reliable - especially given that tmp locations are generally in ram these days.
I think the better term you are looking for is mocks and mocking. IMO these should be kept to a minimum. Like the above - you dont need to mock out the filesystem API when you can just use the filesystem in an isolated way. Same with network services - I really like gos httptest module, it lets you easily spin up a webserver that you can respond with whatever you need to. No need to create a mockable API when you can spin up a fast and reliable http endpoint to respond how you need it to.
Which leads to fakes (ie fake, simple implementations of a real external API). IMO these are far more useful than mocks and should be your first resort with mocks being your last resort. Such as things like gofakes3 an in memory s3 implementation in go that you can use any s3 client to talk to. Things like this let you create tests that you spin up the server (a unique one for each test), put objects into it to set things up how you need them, run your function and assert the contents are what you expect. Makes your tests more complete (and that you are not just testing your mock implementation rather than your actual logic) while keeping them isolated and fast - all the benefits of a small unit test combined with the wider scope of an integration test.
Couldn't agree more with this comment and the thread in general, it's a relief to see. I get so frustrated as so many of my colleagues seem to cling to this very old concept of the testing pyramid and associated definitions. It's completely meaningless in a modern setting. We should mock as little and as far back as possible, yet others seem to delight in locking huge chunks of functionally out of the test base just 'because'.
I believe we should have a new word that differentiates between ultra-basic tiny unit tests, and bigger unit tests that are still not integration tests.
E.g. rust and some other newer languages have a way to write basically an inline test for a function — that would constitute my former category. These make sense during development as a reality check. “Yes, this ad hoc stack I need inside this class should have two elements if I push two elems” sort of thing. That implementation may not even be accessible from the outside in case of an OOP language so you can’t even properly test it. Also, these are the ones that should change with the code and removing them is no big deal.
The other kind should work against the public APIs of libs/classes and they should not be rewritten on internal changes at all.
Tests are not brittle when they catch actual problems. Tests are brittle when they break for no good reason. And really when you are refactoring something tests should not break - you are not changing behaviour, just reorganising things. If you need to do big changes, rewrite or even delete tests when you refactor something then your tests IMO are brittle and much less likely to catch regressions in behaviour. Yeah you will need to tweak them some times, but these should be kept to a minimum and not be happening every time you refactor anything.
When writing new code small tests can feel good, they are easy to write and you can test things quickly in isolation. But after that point how much value do they give you? Tests do have a cost - beyond the original time you spent writing them, you have to maintain them, and keep them uptodate, they take time to run etc... If they cannot properly catch a regression when it happens then IMO they are not worth the cost of keeping them around. Larger tests tend to be better at catching regressions and are less prone to need to be tweaked when you refactor the internals of something.
So, generally speaking I tend to prefer testing public APIs of something and ignore internal helper functions (unless some helper is sufficiently large/complex enough that it warrants extra dedicated tests, which is not common). Note that this does not mean public to downstream users of your library/script/binary, but also larger internal modules API that the rest of the application can use. Though I do find quite a few smaller applications you only need to test the actual public API from an end users perspective.
Uhg, This is a big reason I don't like loosely typed languages. Yeah that might be one case where smaller tests are needed but IMO testing input types should not be required at all - that is something a compiler can do for you for free. At least assuming you have a strongly typed language. People always say loosely typed languages are faster to code in - but this benefit is completely lost when you spend ages writing tests for different inputs types that a compiler in a stronger typed language would just reject.
I am not smart enough to effectively code with certain languages and design patterns and that's ok. There is nothing wrong with accessibility being prioritized or with making tradeoffs for the sake of reducing complexity.
Oh boy, here we go (inhales):
Agile isn't that bad. People just believe they are more productive if they are "heads down" and not held accountable for what they write/do.
Functional programming isn't that great and doesn't solve all of the world's problems; it just pushes the issues with state to other parts of your design, and doesn't scale well in deeply nested solutions.
IDEs with proper code support (i.e. automatic structure analysis, autocomplete, etc.) are one of the best ways to deal with a large codebase that needs refactoring. Doing widescale refactors without one is asking for trouble. If you believe you don't need it, either your codebase is just that small (which is fine) or playing with fire.
Much of the advice out there on architecture and tooling isn't properly contextualized on the codebase, market, and team situation. If you believe you have the One True Architecture Solution, you are naive. (Ex. Microservices, large complex code pipelines, monorepos, etc.) Be especially wary of anything from FAANG engineering blogs unless you are also in another letter of FAANG.
There. Got it out of my system. Have fun dissecting it.
Designing good UX can be as difficult as writing good code.
Source: Im UI/UX designer and project manager and also QA/QC and also devops and also write the specs and documentation. The only thing I dont do is write the code, DB schema and architecture . The hardest of all those roles is UX. The easiest is project management ("Did anything go tits-up today? No? Well carry on, then ")
Biases: I have no formal training in any of those things and was actually hired as a helpdesk tech.
Web development feels like it's stuck in the early 2000's. I've ranted a lot about it over the years but I just don't know how everyone is okay with it. I'm sure tons of people will disagree.
HTML is bad. The language itself feels unintuitive and is clunky compared to modern markdown languages, and let's be honest, your webpage just consists of nested
<div>tags.CSS is bad. Who knew styling can be so unintuitive and unmanageable? Maybe it made sense 25 years ago, but now it's just terrible. It's very clunkily integrated with HTML too in my opinion. Styling and markdown should be one easier to use language where 50% of it isn't deprecated.
Javascript has been memed to death so I won't even go there. Typescript is OK I suppose.
And now for my hottest take: ~10+ years ago I saw web building tools like Wix and I completely expected web development to head in the direction using a GUI to create, style, and script from one interface, even allowing you to create and see dynamic content instantly. I've seen competitors and waited for "the big one" that's actually free and open source and good enough to be used professionally. It never happened. Web dev has just gone backwards and stuck in its old ways, now it's a bloated mess that takes way more time than it deserves.
The Godot engine is actually a pretty good option for creating GUI apps and it's exactly what I envisioned web dev should've been this past decade. One language, intuitive interface, simple theming and easy rapid development... Shame it never happened.
We use too many libraries. This may be an actual unpopular opinion though. I find that the more a library tries to do, and the more dependencies it has itself, the more hesitant I am to use it. It just feels like a tower of cards ready to fall at any moment.
I'm not a very trusting person and work alone though so this might just be an emotional decision. But it is nice having a project be composed of code that does just what is needed and nothing else. It makes it easier to fix bugs and especially to maintain the code.
I do use libraries, but only if they're absolutely necessary or if they're very focused and don't try to do a million things. It's not about size but complexity.
MATLAB is an okay programming language when used in the right context. It’s intended for scientific applications, so trying to do your standard object oriented programming with it gets weird. I think we forget that some things were made for a specific purpose- you know, a hammer can’t do everything and all that.
Using single character variable names is always bad practice
Software was a mistake
JavaScript isn't bad. Sure it has its quirks, but it's not as bad as everyone makes it sound it is
Not everyone can or even should learn programming.
My hot take: Vi, make and C would have gone the way of COBOL a long time ago if it wasn't for a lot of programmers thinking "my tools are more difficult to use, hence I'm a better programmer".
Except if your adhd includes the perfectionist trait, because then you will never get to write the next line of code.
and how you could test it easily! it's incredible how much it helps for cleaner architectures
This is actually a pro tip.
I don't find this helps. More often your assumptions about how something might change are wrong and when the actual change comes in you can end up causing yourself more work undoing the abstractions you made. IMO keep things simple as you can for as long as you can and add in abstractions when they are needed and remove them when they are not. Write code that is easy to change when change is needed, not code that tries to account for all possible future changes as this is impossible to do.
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.
If white space carries any function that the compiler/interpreter needs to know about like structure or scope, it's probably not a very good programming language.
Not sure about here but is was a hot take on reddit:
Pointers are not that hard and really useful
I really love the project structure of C++. I know that it is an archaic design developed like this due to lack of resources, but I find packages extremely offputting.
The first reason is that splitting declaration and implementation across files makes it easier to figure out what something does.
Second reason is that I feel that I have more control over libraries and packages that have to be manually added to a project rather than using a package manager.
Third, I feel like modern languages iterate over too many versions too fast. C++ has version releases too, but I feel that versioning is handled better from time, compatibility and stability point of view.
Python is stupid. Using non printable characters as anything other than token separation is just asking for trouble.
The space is a printable character.
What trouble have you gotten into due to this?
Just copy some code over into a not properly configured vim.
People seem to forget that not everything is a fully configured development environment working locally on your laptop which attempts to fix the issues introduced by that design decision.
I use (Neo)Vim and never had a problem with indentation. When pasting code, I can easily indent it to any level I want with the
>operator.Which actually breaks the code if you don't have sw configured to the same width as used by the code.
If anything that proves my point.
Add YAML to that for the same reason.
Actually I did below! You are absolutely correct.
NO
Is Haskell, YAML, or Sass also stupid? 🤔
Absolutely yes. JSON and SCSS > YML and SASS
YAML can die in a fire, thanks
Just use a modern editor and you'll never have this problem
You can work around most issues in any language with the right tools. That's not the point.
If a design decision introduced a whole new class of errors it is probably just bad design.
It also greatly improved readability of the language. Since switching to the standard of using 4-space tabs, I've not had any problems except when dredging up someone's old Python 2 code.
You can create some really ugly code in spite of the forced indentation in python. Indentation does not really help here at all. In all languages you can correctly or incorrectly format things. A code formatter strictly applying a coding standard helps far more here than indents vs bracers. Take a look at black it takes the pep8 standards and adds more strict things on top making code look a lot more consistent and thus makes it easier to read.
And all formatters will indent code consistently, so having it as part of the language parser does not really help improve readability at all. And even without a formatter everyone I know will still correctly indent their code no matter the language used. But sometimes forcing new lines to have a meaning does make things worst - just look at pythons lambdas which have to be a single line.
Indentations does not really help readability that much in case of really, really, long code, and in some cases, a code can execute without with unexpected result because of one single indentation being off. Both of these why I like things like curly braces/brackets and terminators like endif/fi/done/end/etc. But, at the end of the day, if there's a readability problem, then that's a sign that the code needs to be reworked on.
Indentation can be wrong, but braces can't?
Braces too can be wrong. But, one is less likely to get it wrong. Modern editors often allows one to highlight matching braces immediately after selection, and rainbow braces(if available) makes it clear on the nest level.
Oh I think indentation helps a ton with readability. Even for bad, long or otherwise hard to read code - it would be way, way worst with no or wrong indentation. Correct indentation helps a lot. It is not the only thing that can be done to improve readability but it is the first and simplest fix you can apply to a code base. So a language enforcing it with syntax does not matter when even basic text editors can correctly and automatically indent your code.
Though one thing I do like about bracers is I can be lazy with formatting and let my formatter sort it out for me on save. With a white space sensitive language you need to get it correct from the start or else the program just does the wrong thing.
I didn't say it doesn't help. But, it alone does not really help for bad and long code, but you are correct in that it would be worse with the wrong indentation. Like you pointed out, the program could do the wrong thing if there is a wrong indentation where indentation matters which is one of my issue with something like Python. And languages with explicit exit scope tend to not have that issue while adding to the benefit of making longer code readable. Where white-space sensitive languages really shine on in my opinion are small codes, and that's where I think of using Python.
It's a choice, do you want to deal with brackets or indents? Pick one
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.
Heh, I was about to comment how my hot take is that Python is overrated. It's... fine and I don't really have anything against it for the most part, but I greatly prefer Ruby to Python.
I'm speaking purely about the language itself here, not any libraries available for it (since someone will always point out how great Python is for data work).
My impression at the time was that Ruby and Python both caught on with people who were ready to be done with Perl.
And, later, that Go set out to be a replacement for Java, but ended up with one of its major use cases being a replacement for Python for ops and SRE folks who were ready for type checking and built-in multithreading.
Oh man, I actually like the language, but you made me think of my own hot take:
Python has inexcusably poor docs.
Just a smattering of examples, which aren't even that good, while failing to report key information like all the parameters a function can take, or all the exceptions it can throw. Any other popular language I can think of has this locked down and it makes things so much easier.
I really enjoy typescript these days. Is there a Python typed equivalent?
Python has had syntax support for type annotations for a while now. The Python runtime doesn't enforce the typing at all, but it can be enforced by a linter or by your IDE. And I believe you can introspect the type annotations at runtime, because they are actually part of the syntax.
There's even an alternative way of doing type annotations through specially formatted comments, just in case you might still need to write code that is backwards compatible with Python 2.
@escapesamsara @navi @programming
I'd argue, 99% of the code written is not performance critical in the sense that a different language could help. Either performance really doesn't matter that much, or it's an IO problem. You can process as fast as you want, if the DB takes 100ms to respond, you won't get below 100ms overall.
For bigger projects, anything with MANDATORY types is a must for me. Optional, not compiler checked hinting doesn't cut it.
Not that i hate the language, but I do hate the tooling around it. I don't think I've ever had a pleasant experience with setting up a Python project. And all the data stuff is just wrappers for code in other languages, making the packaging story even uglier, even harder.
You're right now to compromise on this, but you can give yourself mandatory types in Python, using MyPy, if that's your only issue with it.*
Because you don't need elegant subprocess handling, intuitive reliable logging, and don't mind needing a to autonate a linter to check for whitesoace bullshit.*
**Python is my favorite language, actually. Really.
SQL is the core language that everyone should be required to learn first and foremost.
Most frameworks are garbage and most programmers that use them have no idea how they work and that makes them shitty programmers. I hate when people use frameworks without even knowing why they’re using them.
For their credit basic javascript is a garbage language.
Oh I agree that questions are two often badly answered! The exemple of "why don't you use this instead" is the worst offender. I didn't understand you were talking about this, and I'm still traumatised by javascript after 14 years.
This isn't limited to JS. Too many times have I seen someone ask a question of how to do XYZ in language ABC where most of the replies were some form of "Just use this library bro" while not actually answering the question. And usually the library that's being suggested is some big monolith that implements a ton of shit that no one really uses.
Yes…and, worse yet, the jQuery responses are almost never a good way to do things or they use things that are deprecated. It’s a hot mess out there.
TDD is overrated. Code coverage is extremely overrated. Both of these tend to lead to a morass of tests that prove the compiler works at its most basic level while simultaneously generating a surplus of smugness about the whole situation.
Tests have their place. Tests can be, and often are, valuable. But the easier the test is to write, the easier it would've been to just encode it into the type system to begin with.
PHP aint all that bad
GNU make is confusing as hell and shouldn't be used in today's world.
Most technology, programming languages and frameworks feel just the same, in a professional environment. Majority of web and apps is so simple that literally anything will do. Simple api consumption, simple database crud stuff. The tech stack doesn't matter that much.
If programmers stick to what they know and not try to solve every problem at hand with the latest thing/programming language they've learned then there would be fewer bugs and projects would end by the estimated dates.
I think failed estimated dates just highlight how much we don't know about ourselves, our systems and our own knowledge.
It is the abyss of the unknown talking back to us. We have the privilege of having the stuff we don't know thrown back at us to prove us wrong. And we often fail to be humbled by it.
Much of the job is dealing with the unknown. A surprise in scheduling can either shorten a task or lengthen it. It can't be shortened past the time it takes to recognize it's finished, but it can be lengthened indefinitely.
SCRUM is good, actually
If I spend more than a month away from a language or tool, I have to constantly Google how to do basic shit.
I do that or just reference my personal library of half assed projects
🌶️🥵Many people consume Facebook meta company's tech stack wholesale, don't know how to actually traditionally program their way out of a paper bag, and web dev and devops caused a massive layoff (250k people) at the end of 2022, start of 2023 because it was all vaporware. They consume the same software in droves if the other guy uses it.
There is an entire subculture around it that is just a bunch of medium.com writers, YouTubers and twitter handles just trying to get the clicks for their ad money. Some of these guys have never written valid software or done anything noteworthy. If you meet them head on you'd find they have enormous egos and can't find a counter argument when presented with reason.
I'll even add on that there are many programmers who don't know how to code outside a web app.
Why is something like [react, graphql, react ssr, devops, tailwind, unit tests, containers] vaporware?
You know the stuff I don't hear about?
I actually like C.
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.
I like 1-index because its what I learned first, and you like 0-index because that's what you learned first
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.
See Write Everything Twice (WET) principle.
Oh I have some!
Computer science is still a hobby and has a lot to go through before it is an actual industry.
Developers are too often bad engineers.
Short development cycles are a bad thing.
POO is trash. It's a manager tool, not an engineering one.
Here's another: most code reviews on larger companies are BS, just for show and nitpicking.
Carbon? Just what we were all hoping for, yet another programming language from Google. They can keep it.
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.
The only thing a GUI text editor can be better at than a terminal editor is making it easier to use the mouse.
A lot of programmers need to work on their soft skills.
Abstraction will be the death of traditional software development as we know it
My mantra has always been to bring solutions not problems. Applying that to code reviews makes for a far more productive experience.
Rather than just pointing out errors in code help the developer with prompts towards the solution.
Or, if you're too lazy to explain why something shouldn't be done then why should another developer have to act on your criticism?
Programming is the easy part, and a useless skill on its own.
If you can only program in one language, you can't program.
C++ is the single best language to learn programming.
Stupid mistakes you make are not bugs, at least not for you.
Doing this is a hot take, but "clean architecture" is a joke.
My company is obsessed with it.
Write the whole thing, and only then, scrap it and rewrite it. This way you actually have a good understanding of the entire implementation when you are rewriting. When I refractor while writing my draft I will slow myself down and trip over myself, I'll be way more likely to rewrite something I've already rewritten.
Sure there is a limit to the size of projects this can work for, but even for massive projects they can still be broken into decently sized chunks. I'm just advocating for not rewriting function A as soon as you finish function B.
Exactly. And that's the part a lot of folks don't understand about writing tests. If we're not sure an interface will survive into the rewrite, it probably doesn't belong in the test suite.
And the rewrite can be very fast, if we tested the right things.
Python, and dynamically typed languages in general, are known as being great for beginners. However, I feel that while they’re fun for beginners, they should only be used if you really know what you’re doing, as the code can get messy real fast without some guard rails in place (static typing being a big one).
If you're not a programming superstar you can probably make more money writing nothing but Terraform code for hapless enterprises.
Good programmers need to be creative, flexible (soft skills with others), critical thinkers, and problem solvers. Lacking those kinds of features makes for a rigid and terrible programmer that is near impossible to work with or code behind. Leave the ego at the door.
Modern PHP is great and people judging it by PHP 5 (version that's almost 20 years old) are idiots.
If your function is longer than 10 statements, parts can almost always be extracted into smaller parts. If named correctly, this improves readability significantly
Having fun when programming should be much more important than having correct or fast code when you're a programmer and should be what we should aim for first.
Don't enforce using the same tech stack on each new project. When customer, domain, environment, requirements etc differ, so might the tool suite, languages, frameworks etc
I find that S-expressions are the best syntax for programming languages. And in general infix operators are inferior to either prefix or postfix notation.
In case you haven't heard, Factor just had a new stable release, and is tons of fun for postfix enthusiasts.
I never understood how concatenative programmers can hold the current state of the stack in their head and never get confused about what is where, especially when changing complex code.
100%! It was mind-blowing to realize lisps are actually syntactically simpler than all the non-lisps so popular today
Takes a bit of love from editor standpoint unfortunately, so most devs will just never attempt that hurdle
Mandatory pull requests + approvals within a team are a waste of everyone's time.
sounds like your company sucks. I'm sorry, must be lonely
depends on the company/team culture. are other people gonna have to fix or extend code you wrote? are you the sole engineer working on entire modules? do you hate feedback?
Big hot take to me; especially in an organization with a large size and code high standard
We'v known this for twenty years and had the data ta back it up for ten. Github flow is one of the most damaging things to ever happen to software teams
Source?
Got asked about this twice so I'm cut/pasting my answer, but happy to discuss further
Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker.
what data? just curios because there are so many ways to do PRs properly.. like for everything, if it's done badly better not do it. does not mean it is inherently bad
Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker.
Depends how good you are at what you're doing. I'd argue that humans err and it saves a bunch of time to catch bugs before debugging in the wild
All programming languages suck, therefore the language you use doesn't matter
You can never have too many children
My crazy take is that there needs to be a interpretative language alternative to Python which uses brackets to define scope and/or things like elif/else/fi/endif/done. Much easier that way in my opinion, and the ";" shouldn't be necessary. I'm used to Python, but if I had another language which can be used to serve similar purpose to Python with those features, I would never code in Python again when it comes up.
Having to code in Julia and G'MIC (Domain-Specific Interpretative language that is arguably the most flexible for raster graphics content creation and editing), they're the closest to there, but they're more suitable for their respective domain than generic ones.
You might enjoy Ruby
Here's something weird. I haven't written a ruby program in 15 years, but I still use
irbas my calculator.I love that :) Try Pry, too!
Sounds like Bython is the language for you! (only half-joking)
Spaces look the same on every screen.
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.
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.
Log levels are superstition.
That the HTML/CSS structure of web programming is absolutely disgusting and not necessary. The internet could be and should be so much more from a developer pov. Also people who double space instead of tab often have their mouths open while mashing space 16 times.
I completely understand and clearly see that web development is the future, but I still think it’s all gross and will always prefer targeted efficient compiled code. Why? Because I’m a huge fucking dork.
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.
If your code files don't contain more lines of comments than lines of actual code, then you're doing it wrong. (For Python, docstrings count as comments)
And your comments shouldn't say what each line of code is doing. If you can code, then you can already tell what each line is doing by just reading the code. The comments should explain WHY it's being done this way, or HOW it's being done, or highlight some pitfalls that might snare a future developer, and generally just give some higher level context to a line or block of code.
@257m @programming
Oh fuck I hate encountering this level of commenting. If it's complicated, you should have a design doc. Source code is not where you write your dissertation. Simple explanations are good, especially since the code could be updated while the comment is likely to remain unchanged. Long expositions are usually the result of bad coding or improperly allocated design.
Absolutely agreed. If your code line by line isn't clear, then the code is the problem.
Commenting before a block of code (a function / algorithm or whatever) explaining what it is meant to do, absolutely that's great though, saves time when revisiting.
As long as it's updated when the code changes
And that one single line that makes zero FUCKING SENSE AND YOU SPENT 5 DAYS TRYING TO FIX IT!!! That definitely needs a comment so the next idiot (aka you in 6 months) doesn't think "what useless shit is this? Let's delete this!".
@TerrorBite @257m @programming
Comments are for revision control systems. We have a strictly no comments in code policy because comments too often end up being wrong or misleading throwing everyone believing in them for a wild ride. The only thing that is worse than bad code is bad comments.
When you read sensible and thorough commit messages you generally have the notion that whatever it says was probably true at the time of the commit, whereas when you read comments in code it can still be correct or just plain utterly wrong.
@nthcdr this assumes that people write sensible and thorough commit messages, instead of brief five-word ones or, say, song lyrics. Both of which I've seen.
I at least try, except maybe for the other day where my commit message consisted entirely of an exasperated "why", followed by a revert.
That being said, every commit message where I work is required to contain a ticket number (and the server will reject the push if you don't) so at least there's that for context.
@257m @programming
@TerrorBite
Yes there need to be some assumption that your co-workers write reasonable commit message even if they have their lapses now and then.
Another problem with comments in code is that they tend to be short because nobody likes to read code interspersed by walls of prose. But many times if something really needs explaining you also need a little more room doing it. Thus when committing in code people tend to gloss over important detail.
Then of course there is literate programming. The other end of the spectrum, but then we're talking code in documentation not comments in code.
@257m @programming
I left the company, worked at other places in other languages, the company restructured, moved to India and back, got new premises, headhunted me because someone remembered that I wrote this particular system (serial port controller for certain industrial machinery). When revisiting code that I wrote 15 years ago, I was glad that my comments explained what I was doing, and why, and how, because all the other documentation was long gone. Don’t imagine that the original design documentation will still exist when you come back to it.
Pure text is probably not the best way to write code, even if it is the most interoperable format
Real programmer learned Assembly.
VHDL is a good language.
If you think to be a good programmer, you're the opposite.
Front end and back end are different enough that you can really specialize in one or the other. They take very different mindsets. I know how to make css obey, I don't know how to make sql performant. Its possible to have both, but not as well.
For every front-end dev, you need 3 back-end guys and a designer.
Programmers are not bad at our jobs, its just not a mature disclipline yet.
I'm not convinced that "strong pairing" is the best way to pair but even people who rail against agile ideology tell you that you're pairing wrong if you don't follow it precisely.
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?
Python should replace JavaScript on the browser
People who insist on using semicolons in Javascript don't understand why and are just following a cargo cult.
Remove the semicolons, be free.
Edit: lmao I hit some nerve here
Strong typing is for weak minds.
You absolutely do not need a computer telling you what types you can put in a collection. Put an assert, write some unit tests, if you aren't sure where data sources come from and can't write a one-line comment.
Dynamic typing makes you fast, it's empowering. Try it and quit being so scared.
No matter how many unit tests or comments you write, it's impossible to "prove" type correctness in a dynamically typed language - and it will eventually blow up in your face when you have to refactor. There's a reason for the adage "testing can't prove the absence of bugs."
People like static typing because it offers strong guarantees and eliminates entire classes of bullshit bugs, not because they're "weak minded."
Typing can't prove anything, either. It just creates bugs and crashes.
Your program logic is the part that will not be fixed by it.
Incorrect. Static typing can prove many things, depending on the quality of the type system.
At the very least, it proves that your data is organized, stored, passed around and used in a logically valid and consistent manner. Make that proof impossible, and the compiler complains. (And with good reason - it doesn't matter how good your program logic is if you're feeding it bad data. Garbage in, garbage - or a runtime error - out.)
In a dynamically typed language, your program logic still implicitly depends on that proof holding - it's just that you, the fallible human, has to make sure everything checks out. Python added type hints for precisely this reason.
Additionally, with more advanced static type systems, it becomes possible to issue guarantees beyond simple type safety. Patterns like typestate (found in TS, Haskell and Rust, off the top of my head) can be used to make illegal states unrepresentable at compile time. Try to write to a closed file or make an invalid state machine transition? The compiler will see it and say no.
In what universe are runtime errors turned compile-time errors a source of bugs and crashes? A statically-typed program won't blow up in production because some poor intern wasn't able to keep the implicit type bounds of every single function parameter in his head.
There's some math & CS papers you should read, Gödel's incompleteness theorem, Turing's halting problem. YOU CANNOT prove your way out of logic errors. You cannot make a universal type system. All you're doing is wasting time with false confidence.
I never said that static typing stops all logic errors or fully proves program correctness, but go off I guess...
How is dynamic typinf faster? Is typing
num = 1instead ofint num = 1really that much faster?Plus, most statically typed languages either do type inference by default or let you opt in somehow.
Even Java, which is probably the reason everyone hated static typing for the first decade of the century or so, now has
var.I'm not any faster in languages without static types. It's the opposite, I'm fastest when I can write accurate type hints, since it makes the editor experience much better.