I write the parentheses before I start writing inside the block. When something goes wrong, the scope of what I’ve done wrong is narrowed to within that specific block.
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.
An iterator is commonly understood to be an object and thus something much more complex than a simple integer. This is the exact opposite of more clear.
I have a convention to correlate the size of variable scope with its name length.
If a variable is used all over the program, it will be named “response”. If it is <15 lines, then it can be “res”. If it is less than 3 lines, it can be only “r”.
This makes reading code a bit simpler, because it makes unimportant, local vars short and unnoticeable.
Index can be useful but start looking for mapping and sorting functions. Or foreach. If you really must index, sure go use index or I if it’s conventionally understood. But reading something like for I in e where p == r.status is really taxing to make sense of
Oh yeah, I map, filter and reduce pretty much everywhere I can. But sometimes you need the index and i is so commonly understood to be that, it’d say it could even be less legible to deviate from that convention
It’s not incoherent, it just takes a tiny bit more effort to mentally parse as it’s not a stereotypical for loop. Maybe it’s just me, but let me try and explain
With the i example if you’re familiar enough with a language, your brain will gloss over the unimportant syntax, you go straight to the comparison and then whether it’s incrementing or decrementing.
With the other example, the first my brain did was notice it’s not following convention, which then pushes me to read the line carefully as there is probably a reason it doesn’t.
I’m not saying it’s a huge difference or anything, but following code conventions like this makes things like code reviews much easier cumulatively.
Honest question: is there a mapping function that handles the case where you need to loop through an iterable, and conditionally reference an item one or two steps ahead in the iterable?
Something like parsing a string that could have command codes in it of varying length. So I guess the difference is, is this a 1-, 2-, or 3-character code?
I have something like this in a barcode generator and I keep trying to find a way to make it more elegant, but I keep coming back to index and offset as the simplest and most understandable approach.
This would map arr and return halved values for elements for which the element two steps ahead is even. This should be available in languages where map is present. And sorry for possible typos, writing this on mobile.
I’d say except indices in general. Just bloats every line where you need to use them. Imagine writing CUDA C++ where you regularly add and multiply stuff and every number is referenced via (usually) 1-3 indices. Horrible.
Yeah, but it’s easy to overuse it. If your for loop is much longer. For a few lines I’d agree, don’t bother using something longer.
Code should scream out it’s intent for the reader to see. It’s why you are doing something that needs to be communicated, not what you are doing. “i”, “counter” or “index” all scream out what you are doing, not why. This is more important than the name being short (but for equal explanations of intent, go with the shorter name). The for loop does that already.
If you can’t do that, be more precise. At the least make it “cardIndex”, or “searchIndex”. It makes it easier to connect the dots.
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.
Genuine question: why? What makes, say a semicolon, so superior to the the newline or tab characters?
To be clear: I don’t think whitespace as a part of syntax is an awesome idea which should be more popular. It’s definitely a bit more error prone in some ways. It’s not perfect. But it’s okay.
I’ve written a lot of Python and I don’t think I have ever seen a syntax error caused by incorrect whitespace. I’m not exaggerating. I regularly forget semicolons in other languages but I never type out incorrectly indented code. Maybe that’s just me though…
From some one who used Python as it was the easiest solution to few of my problems, and having to experience languages with brackets and/or endif/fi/done as ways to limit scope, I find that having things like brackets and/or scope terminators easier to parse and less error-prone. I’m thinking about moving on to Ruby whenever I had a need where Python would be a good choice, but the time it takes for me to understand a new language is blocking me from that.
I honestly think the scripting languages like fish have got it right.
Newline by default completes a line and can optionally be escaped. Saves you most of the semicolons and even implicitly highlights multi-line statements.
Whitespace doesn’t matter except for separating names.
Blocks are explicitely ended without braces you can confuse with brackets or parentheses, no matter the coding style.
If Rust and fish had a baby, I think it would be the best language to have ever been created.
A vast majority of the code in question is the code I’ve written for my work projects with multiple active contributors and refactoring is very common too. We all like to shit on Python for various reasons but no one in my environment ever complained about whitespace.
Like I said, I don’t think whitespace is perfect as a part of syntax but I’m much more likely to forget a semicolon than a proper indentation and this applies to any language. I guess it’s not universal tough, because you can often see code with messed up indentation on online forums etc. TBH this is just unthinkable to me, indentation is absolutely necessary for me to be able to read code and reason about it. When I’m thinking about blocks and scopes it’s not because I counted semicolons and braces, it’s 100% indentation.
Load-bearing whitespace is the fucking devil. This thread about hot takes is topped by a comment highlighting how people can’t even agree what kind of whitespace to use.
Python - you want code to fail if someone from one camp copy-pastes code from another camp, and the characters that make a difference are invisible?
KDE is ridiculously unintuitive and has become too awkward to use to recommend to a newbie.
Arch is not a general purpose distro. Theres too many things that can break it unless you meticulously follow the patch notes and participate in the community.
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.
Yes and no. I mean sure, if you are going to leverage this to gain a significant edge in the market, that works.
If you add a tool to the project, that you need to understand to maintain some parts of it, which adds to the learning curve of someone joining said team, then the gains have best be worth the effort.
We adopt so many librairies/plugins/tools over time that adding more complexity than you need this way is just terrible.
Amen! One thing which drives me crazy is that most people confuse beginner friendly and user friendly, the two things are absolutely not the same thing. There is nothing wrong with having tools which are beginner friendly, especially for stuff one does once in a while. There is everything wrong with nerving tools which are for pros or even everyday usage: If I use something everyday I have rather an optimization for the mid or long run, than for the first few hours…
Composition over inheritance has become a meme that people repeat without understanding. Both have their uses, but if composition is all you use, then you’re using a hammer on everything. There is no silver bullet in life and most undeniably not in programming.
Also, electron has a reason for existing. If it didn’t have a use, it wouldn’t have the number of users it has. You can’t tell me in all seriousness that Qt, Gtk, Swing, Tkinter is easier to use than electron for the common developer.
While I completely agree with you about electron, I still don’t have to enjoy the fact that companies are outsourcing their lack of development in native tech to my wallet in terms of wasting resources on my device. Now perhaps the cost of the associated services would be higher if they had a native app which is a fair response. I still don’t have to like it.
Written as a user (and occasionally enjoyer) of electron based software.
It’s especially infuriating when you have a giant like Microsoft rolling Electron on their flagship applications (Teams), and then deprecating support for some platforms (Linux). What’s the point of your nice, memory-gobbling, platform-agnostic app framework if you’re not even going to use it to provide cross platform support?
I don’t enjoy it either and will go through the pain of writing GUI apps in anything but HTML,CSS and JS, but the ground beneath me doesn’t exist as no contributions are coming from my side to make an easier electron alternative. There are other places I am hypocritical though.
Absolutes in programming are most useful for clickbait and little else. Use what makes sense for your use case, following a trend will only lead to pain.
Types and unit tests are bloat that increase the maintenance cost of whatever code they are involved in. Most types force premature design/optimization. Most unit tests lock up some specific implementation (increasing cost of inevitable refactors) rather than prevent actual bugs.
Nil-punning in clojure has spoiled me rotten, and now every other language is annoyingly verbose and pedantic.
I do get where you’re coming from, however. Dynamically typed languages are great for prototyping and if you’re dealing with a small codebase, it can stay that way, but IMO large codebases without typing are not fun to navigate and understand.
“Which class am I dealing with now?” is such a common problem that I’d rather have it explicitly written than guessing or assuming to know.
Very happy to share this hot-take :) Definitely code-base and team-size are a huge factor, and I mostly work on my own projects, so each project is very different. still, I expect to get downvoted into oblivion by the last decade’s influx of typey-langs and -devs.
I think most love for types is folks being happy they don’t need to assert on the input to every function, i.e. static analysis and reduced unit-tests. It’s hard for me to not see types as asking folks to pre-design their entire system (by defining types first!), before you’ve even started writing a few functions, which are actually what the system should codify (behaviors, integration tests). It’s also frustrating b/c types don’t guarantee that the system does-the-thing, only that the type-system and compiler are happy, so it’s like pleasing the wrong boss, or some metaphor like that.
I like to work with behavior directly in functions, which should be the same regardless of the type passed in. Unfortunately most dynamic languages have their flaws (js,python,etc), so this kind of opinion suffers b/c of those languages… similar to type-favoring opinions suffering b/c of langs like typescript.
Nil-punning makes me very happy - that’s a hill I will actually die on. Almost every project i’ve worked on, there’s no reason to go out of the way to specifically handle every case of not the right input or oh-no-it’s-null! Whenever you have null, you just return null from this function too, and guess what, everything’s fine - no need to crash and blow up b/c one thing wasn’t there. Mostly this is a complaint about things completely crashing for no reason, rather than being incomplete (i.e. some data missing) but still working for the user.
Anyway, lots of different use-cases, and use the right tool for the job, etc etc. types and unit tests are useful for some things.
Meanwhile here I am thinking about pivoting my career from Python to Rust because I’ve grown to hate Python’s lack of typing. I also religiously write unit test even for minor personal projects.
I suppose i should at least caveat by saying i don’t by any means advocate for all dynamic langs over statically typed, and i agree types/unit tests are necessary for most languages. So please don’t make me write python over rust!
You can get the benefits of types/unit-tests via static analysis on a per-function basis with clojure and a library like malli, and for me that hits a minimalist sweet-spot.
Sorry, I liked this hot-take setup and I’m shooting from the hip a bit. Maybe i actually mean objects/classes, not types? Can’t everything just be a bag of key-values, like in clojure?
I have been building mostly prototypes (games and wm-tools) for a year, so most of my context is getting things working to see if they are useful rather than locking them down.
I thought about my argument a bunch, and while i have alot of complaints, it all sounds like non-specific whining to me, so i’ve decided to give up.
types and unit-tests have their place. Fine! I admit it! i was pushing a hot-take I’ve had on a few occasions, and I’m glad to see this programming community is alive and well! If you need me I’ll be in my clojure repl.
It’s also important to acknowledge how different is prototyping from writing production code which has to be extendable and maintainable for years by multiple developers.
Your take isn’t even very hot when we are talking about prototyping 😉
I’m a longtime fan of python, but honestly I don’t know how I lived with it before type hints. It still feels a little backwards from the original design philosophy of python, and it’s more verbose than other strongly typed languages, but it’s come to feel pretty natural all the same.
I disagree. What you’re saying is true for Java-like OOP languages because OOP is actually complete garbage if you want to design good abstractions. Types are way more elegant in functional or functional-inspired languages.
I think you’re right re:oop - let’s throw that in there too.
One problem is naming things - bad names/naming conventions can start things off in a bad direction, so you spend forever figuring one out… but do you really need this thing you’re naming after all?
Maybe the hot-take is more like: All code is bad, so less code is better…. what should we drop first?
types are bloat for maintenence? id rather get a compiler error in 0.1 seconds than spend hours tracking down where in the code my number was coersed into a string.
The programming languages you use, and the variety of languages you learn, deeply influence how you think about software design.
Software would be much more reliable (in general) if Erlang had become one of the dominant languages for development.
Go sacrifices too much for superficial simplicity; but I would like to see a language that’s nearly as easy to learn, but has a better type system and fewer footguns.
Unit testing is often overrated. It is not good for discovering or protecting against most bugs.
Build/test/deploy infrastructure is a genuinely hard problem that needs better tooling, particularly for testability.
Build/test/deploy infrastructure is a genuinely hard problem that needs better tooling, particularly for testability. (Naturally, this is a hard problem, but I think very few developers are working on it.)
Agreed and it’s not treated as one which is a compounding issue. 😬
hard agree. I’m sick of all the “it doesn’t matter what languages you learn” talk because it’s just not true. yes, there are broad foundational skills that apply to nearly every language, but beyond that, you’re specializing, and the way the language you choose is designed will stick with you. I’ve seen the concept that you get accents in programming languages just as much as spoken ones, and I think it’s totally true - when you learn a new language, you’re bringing your habits and assumptions from the last one. so to be honest I don’t care about the language design opinions of people who only know dynamically typed languages
I think unit testing is good at enforcing a spec so other developers know what to expect from your module and how to maintain it. It also kinda force you to dogfood your own stuff.
Imo it is strictly something you do when you write something like a library or any sort of module that you expect other developers to interact with. I’ve seen teams get all smug about code coverage as if this made them diligent. My personal experience is that developers who understand why unit tests are important tend to write better code than those who skip them or do it “just because”.
If I explain myself or add nuance, it won’t be a “hot take” anymore, but here goes…
I’ve mostly worked on small teams, but have maintained fairly large codebases (I think the largest single repo I’ve worked in was about 1.5 million LoC). I’ve also maintained software used by other teams, though in fairly small software organizations (under 100 developers total).
I’ve written code with 100% unit test coverage, and code with almost no coverage. The 100% coverage was in a library that was intended to be core functionality shared across multiple teams.
I definitely agree that they can be useful as both usage examples and as a way to enforce some rules (and consistency) in the API. But I’m not sure I’d go so far as to call that a “spec”, because it’s too easy to make a breaking change that isn’t detected by unit tests. I also feel that mocking is often needed to prevent unit tests from becoming integration tests, but it often hides real errors while excessively limiting the amount of code that’s actually being exercised.
I also think that actual integration tests are often a better demonstration of your API than unit tests are.
I haven’t used any of these methods as much as I’d like to, but I suspect that each of them is strictly more useful than standard unit testing:
contract tests (arguably just a form of unit testing, but not the way I’ve generally seen it done)
property-based tests
mutation tests
preconditions & postconditions (with language support)
Makes a lot of sense. I figure contract tests is more or less what I have been doing then.
I think there is that misconception that unit tests are about validating each line of code and preventing logic bugs. Though obviously you understand that this isn’t just about that, or not at all about that I would argue. Unit tests won’t prevent accidental breaking changes, but you can at least add new tests every time this happen, so you’re at least guaranteed that the next maintainer won’t be doing the same mistake.
In an ideal world we could probably have nothing but integration tests, but in my experience if you only do integration testing you end up working really hard maintaining tests that are prone to break and costly to run. Unit tests are cheap to code and cheap to run, it is a great place to enforce your “contracts” with tests that are theoretically immutable. After those tests are out of the way, you can focus only on the actual interaction between your systems with the more expensive tests.
Anyway, you have a good take I am just blabbering. This is based on my personal experience as someone who only cared integration tests but was later converted by a person much smarter than I am. And then later on by joining a team that exclusively did integration testing, hundred of tests. It was hell (imo), we had to change dozens of tests for every little bit of modification. The rest of the team seemed fine with it though. We rarely shipped bugs but progress was incredibly slow for a module of such low complexity. Testing wasn’t the only issue with that codebase though.
The one part of that that sounds weird to me is needing to change integration tests frequently when changing the code. Were you changing the behavior of existing functionality a lot?
Yes, and the test suites were insane. The program was outputting a lot of data, and we basically asserted on anything and everything for any given integration. I mentioned that testing wasn’t the only issue, well there was a lot of issues. Unfortunately the behaviour changes were requested by the stakeholders and there was no way around it. That being said, had this thing we maintained been properly developed those changes would have been a breeze imo. The actual requirements were very simple.
But anyway, I realize this is maybe an extreme example to paint integration tests negatively, but the point remain. In this scenario, every time we changed a bit of code it broke dozens of integration tests instead of breaking just a relevant integration test, had everything that could have been unit tested been written that way. The integration tests could probably also had been less… exhaustive, but it was probably for the best considering the codebase.
Go sacrifices too much for superficial simplicity; but I would like to see a language that’s nearly as easy to learn, but has a better type system and fewer footguns.
“Easy to learn” and “good type system” will by necessity be opposing forces IMO. If you want to work with a good type system you’re gonna have to put in the effort, I’m not sure there’s this magical formulation of a good type system that’s also intuitive for most new developers. Hope to be proven wrong one day tho but so far no dice.
I think TypeScript has a pretty good type system, and it’s not too hard to learn. Adding sum types (i.e. enums or tagged unions) to Go would be a huge improvement without making it much harder to learn. I also think that requiring nullability to be annotated (like for primitives in C#, but for everything) would be a good feature for a simple type system. (Of course that idea isn’t compatible with Go for various reasons.)
I also think that even before “proper” generics were added, Go should have provided the ability to represent and interact with “a slice (or map) of some type” in some way other than just interface{}. This would have needed dedicated syntax, but since slice and map are the only container types and already have special syntax, I don’t think it would have been that bad.
Add comment