> Most won't care about the craft. Cherish the ones that do, meet the rest where they are
> (…)
> People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things.
What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not necessarily the ground truth.
What you’re essentially saying is “cherish the people who care up to the level I personally and subjectively think is right, and dismiss everyone who cares more as insane weirdos who cannot prioritise”.
There's another way to look at this: if you consider the school of thought that says that the code is the design, and compilation is the construction process, then stressing over code style is equivalent to stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor), instead of stressing over load bearing, material costs and utility of the space.
I'm fond of saying that anything that doesn't survive the compilation process is not design but code organization. Design would be: which data structures to use (list, map, array etc.), which data to keep in memory, which data to load/save and when, which algorithms to use, how to handle concurrency etc. Keeping the code organized is useful and is a part of basic hygiene, but it's far from the defining characteristic of the craft.
Some of those formatting conventions are written in blood. The clarity of a blueprint is a big deal when people are using it to convey safety critical information.
I don’t think code formatting rises anywhere close to that level, but it’s also trying to reduce cognitive load which is a big deal in software development. Nobody wants to look at multiple lines concatenated together, how far beyond that you take things runs into diminishing returns. However at a minimum formatting changes shouldn’t regularly complicate doing a diff.
I 100% agree. The problem is that after a half a century, software engineering discipline has been unable to agree on global conventions and standards. I recently had an experience where a repair crew was worried about the odd looking placement of a concrete beam in my house. I brought over the blueprints, and the technician found the schedule of beams and columns within seconds, pinpointed the beam and said, "Ah, that's why. We just need to <solution I won't go into>". Just then it struck me how we can't do this in software engineering, even when the project is basically a bog-standard business app: CRUD API backed by an RDBMS.
That’s because the few hard rules you have to comply with have workarounds and matters rarely. In house construction, you have to care about weight, material degradation, the code, etc… there’s no such limitation on software so you can get something to work even if it’s born out of a LSD trip.
But we do have some common concepts. But they’re theoretical, so only the people that read the books knows the jargon.
The value of software is both what it does now (behavior), and what you can get it to do later (structure). What you described as design and the compiled artiface is the behavior.
The craft is what gives you future choices. So when people cares about readability, writing tests, architecture, they’re just making easy for them to adjust the current behavior later when requirements change. A software is not an house, it doesn’t get build and stays a certain way.
There is definitely something to be said for the idea that a shitslop engineering blueprint which still conveys correct design (maybe; who knows really?) is shitslop, whether or not the design is sound. In the case of software engineering, the blueprint is the implementation, too, so it’s not just shitslop blueprinting, it’s also shitslop brickwork (totally sound bones though I promise!), shitslop drywalling, shitslop concrete finishing and rebar work — and maybe it’s all good under the hood! Totally fine if all you’re building is a shithouse! But I think you get where I’m going with this.
IMO, gofmt doesn't go far enough. It should sort imports and break lines automatically, or you end up with different people with slightly different preferences for breaking up lines, leading to an inconsistent style.
Something like gofumpt + golines + goimports makes more sense to me, but I'm used to ruff in Python (previous black + isort) and rustfmt.
I'd say that if you're manually formatting stuff with line breaks and spaces, that should have been automated by tooling. And that tooling should run both as a pre-commit hook and in CI.
I have a habit of putting stdlib imports, a line break, golang experimental (x) imports, a line break and external imports.
I just tested, gofmt orders imports within these blocks. If I won't use the line breaks, it'll consider it a single block and will globally sort.
golang also aligns variable spacing and inline comments to look them as unified blocks (or a table if you prefer the term) and handles indents. The only thing it doesn't do is breaking lines, which I think acceptable.
In my opinion, I think the author is criticizing bike shedding [1] rather than meaningful decisions. Of course some people will differ on whether a decision is one or the other. But as a whole, not sweating the details is a good quality to have whatever road in life you are on.
To me "craft" is about keeping code efficient, scalable, extensible, well-tested and documented. Code style is more about what naming convention to use, tabs vs spaces etc. - it's nice to have it consistent, but no need to spend more than 5 minutes arguing about it.
There is more than one type of people who stress over code style. There's the group who wants to discuss about how to style your code and then there's the group who wants to just use a common code formatter and be done with that.
For example, I have objections to rustfmt's default style. I would never start discussions on rust projects about changing that to another formatter or changing its configuration. I definitely would carefully ask that people should really use rustfmt, though, if they don't do so yet.
You've set yourself up to always be the outlier. To always need to have that discussion or tweak the rules on every project you work with.
You've increased the overhead of onboarding anyone used to the default style. You've increased the overhead of you working on anyone else's projects that is more likely to have the default style.
All of that is friction introduced because you haven't learned to live with the default style.
Do I love that the default C# rules put a new line before the else block? No, but I've learned to live with it so that I can work on all manner of projects without fussing over that style option every time.
By adhering to default rules, you never have to have the endless arguments such as tabs vs spaces again. ( Spaces won, and the tabbers got over it fairly quickly once it was the default in almost all formatters. )
What I understood from your parent comment was the exact opposite, i.e. that they’re saying “I disagree with some of the default choices of the formatter (and so would prefer they were different) but I never voice those because it’s not worth it. However, I do think everyone should use something, whatever it is (even if the default style), as opposed to nothing”.
It's not even more or less, it's just about different aspects. Consider a woodworker obsessing over sharp chisels - they don't all care beyond 'sharpish', or about the tools used to do so - but to some that's hugely important and how they are then able to do their best work.
I think the line between minutiae and craft is drawn by the effect it has on the product you're creating. Method length makes your code more manageable, for example. Placement of line breaks, not so much.
At the end of the day, we aren't paid to produce code, but working software that works today and is easy to change tomorrow.
That is a purely commercial take of the matter. I don’t think it’s controversial to argue the artisans who stand out do so because they care for the craft itself. Spending an extra hour or two perfecting the shape of the armrest in the chair may not allow you to earn more money from that one commission, but it might improve your knowledge and skill and be slightly more comfortable to the sitter. If they comment on it and appreciate it, so grows your motivation and pride.
Sometimes the code itself, and not its result, is the product. For example, when making tutorials the clarity and beauty of the code matters more than what it does.
I’m not arguing for obsessing over code formatting, but pointing out the line between “master of the craft with extensive attention to detail” and “insane weirdo with prioritisation deficits focusing on minutiae” is subjective to what each person considers important. Most of us seem to agree that being consistent in a code base is more important than any specific rule, but that being consistent does matter.
At the end of the day, we aren’t paid to eat healthily and taking care of our bodies either. But doing so pays dividends. Same for caring about the quality of your code. Getting in the habit of doing it right primes you to do it like that from the start in every new project. Like most skills, writing quality code becomes easier the more you do it.
There's a correlation-is-not-causation issue here. Yes, most very good developers pay a lot of attention to details, as well as to the bigger picture. But there are a lot of mediocre to downright bad developers who think that paying a lot of attention to code style, linting rules and other minutia will make them better developers.
Not really. Obsessing over breaking lines after famous 80 chars in Eclipse was, is and will be idiotic to be polite. Surprisingly large amount of people were obsessed by this long after we got much bigger screens, if that was ever an argument (it wasn't for me). 2 spaces vs 4 spaces or tab. Cases like these were not that rare, even though now it seems better. That's not productive focus of one's (or team's) energy and a proper waste of money for employer/customer, it brings 0 added value to products apart form polishing ego of specific individual.
Folks who care about the craft obsess (well within realm of being realistic) more about architecture, good use of design patterns, using good modern toolset (but not bleeding edge), not building monolithic spaghetti monster that can't evolve much further, avoiding quick hacks that end up being hard to remove and work with over time and so on.
If you don't see a difference between those groups, I don't think you understood author's points.
Reporting as an Eclipse user of 20+ years, and a person who cares about the craft:
The choice for me is simple:
If I'm going to view the code I'm writing in a 80x24 terminal later on, I'll break that lines, and will try really hard to not get closer to 80 chars per line.
If that code is only going to be seen in Eclipse and only by me, I won't break that lines.
I omitted your other examples for brevity.
Having bigger screens doesn't make longer lines legit or valid. I may have anything between 4-9 terminals open on my 28" 2K screen anytime, and no, I don't want to see lines going from one side to another like spikes, even if I have written them.
I'd say avoiding long lines is one of the most important rules. I regularly have 2-3 files open side by side, I don't want to have to scroll sideways to read the code.
80 characters is a bit on the low end imo but I'd rather have the code be too vertical than too horizontal. Maybe 120-150 is a more reasonable limit. It's not difficult to stay within those bounds as long as you don't do deep nesting which I don't really want to see anyway because it's hardly ever necessary and it makes code more difficult to read.
Reading vertically is much faster than reading horizontally, so I think 80 is a good soft limit. In some contexts it's hard to not go over it sometimes, e.g. in Java where it's not uncommon with very long type and method names.
And the laptop excuse is not even valid, I used a 11" MacBook Air for 10 years and even back then 80 always felt extremely limiting for me.
I just tested and: even when zooming +1 on VSCode and leaving the minimap open I can fit 140 chars without any horizontal scroll.
People demanding 80 columns always have some crazy setups, like an IDE where the editor is just a minuscule square in the centre, like an Osbourne 1 computer.
200 is entirely too fucking long, and I code on a 43” 4K. I try to stay under 90 in deference to others, and if it looks better breaking at 80, so be it.
> Most programming should be done long before a single line of code is written
Nah.
I (16+ years developer) prefer to iteratively go between coding and designing. It happens way too often that when you're coding, you stumble across something that makes you go "oh f me, that would NEVER work", which forces you to approach a problem entirely differently.
Quite often you also have eureka moments with better solutions that just would not have happened unless you had code in front of you, which again makes you approach the problem entirely differently.
ok that sounds bad, you should have the option to go back to design, but depending on what point you find that issue, depends on how much time you have wasted?
> Typed languages are essential on teams with mixed experience levels
I like this one because it puts this endless dilemma in a human context. Most discussions are technical (static typing ease refactoring and safety, dynamic typing is easier to learn and better for interactive programming etc.) and ignore the users, the programmers.
I think the size of the code base also matters: bigger size = having types is more important.
There is a contradiction here as: bigger size = compile speed more important AND types slow down compilation. More advanced typing features slow down compilation even more.
> More advanced typing features slow down compilation even more.
C++ is a bit of an outlier here. But really people should think of typechecking as shifting fault detection earlier in the process than runtime. It doesn't matter if your test suite starts slightly quicker if you have to wait for the whole thing to run to find something you could otherwise have found with types.
> Java is a great language because it's boring [...] Types are assertions we make about the world
This is less of a mind-was-changed case and more just controversial, but... Checked Exceptions were a fundamentally good idea. They just needed some syntactic sugar to help redirect certain developers into less self-destructive ways of procrastinating on proper error handling.
In brief for non-Java folks: Checked Exceptions are a subset of all Exceptions. To throw them, they must be part of the function's type signature. To call that function, the caller code must make some kind of decision about what to do when that Checked Exception arrives. [0] It's basically another return type for the method, married with the conventions and flow-control features of Exceptions.
[0] Ex: Let it bubble up unimpeded, adding it to your own function signature; catch it and wrap it in your own exception with a type more appropriate to the layer of abstraction; catch it and log it; catch it and ignore it... Alas, many caught it and wrapped it in a generic RuntimeException.
It was botched from the start because there's so many opportunities for unchecked exceptions as well. Without a more sophisticated type system that represented nullability, you can get NullPointerException anywhere. Divide by zero. And so on.
You also have a problem similar to "monads and logging": if you want to log from anywhere in your program, your logging function needs to be exception-tight and deal with all the possible problems such as running out of disk space, otherwise you have to add those everywhere.
I agree, although I would like to point out Java usually gets the blame for what was actually an idea being done in CLU, Mesa, Modula-3 and C++, before Oak came to be and turned into Java.
Additionally, the way result types work, isn't much different, from type system theory point of view.
I really miss them in .NET projects, because no one reads method documentation, or bothers to have catch all clauses, and then little fellow crashes in production.
Checked exceptions as an idea are great (Nim’s usage of something similar is excellent) but yeah Javas particular implementation was annoying and easy to avoid, so most did.
This is precisely why they are so bad: checked exceptions must not be allowed to be used outside the package (or jar, or whatever, just limit it) otherwise they cause non-local build failures in all dependencies. They're fine if you are developing the artifact that's going to be deployed.
It's already very unlikely that you can 'recover-and-proceed' in the context of any business app exception (Security violation, customer not found, no such payment, etc.).
So what's left in exception handling is logging and/or rethrowing. And the 'nasty hackish way' of doing it (RuntimeException) already passes a complete stack trace up to the caller.
There's also the fact that common methods threw exception types that were not final, and in fact overly generic. If I call a method that declares itself to throw NoSuchFileException or DirectoryNotEmptyException, I can have a pretty good idea what I might do about it. If it throws IOException without elaboration, on the other hand...
With regards to I/O, there are generally any number of weird errors you can run into, file not found, directory exists, host unreachable, permission denied, file corrupt, etc etc. Like anything file related will be able to throw any of those exceptions at almost any point in time.
I think IOException (or maybe FileSystemException) is probably the best you can do in a lot of I/O cases unless you can dedicate time to handling each of those specially (and there's often not a lot much more you can do except for saying "Access is denied" or "File not found" to the user or by logging it somewhere).
You can do it whatever way you want but match the style of the project. I've worked on too many projects where someone decides their way is best and you end up with a mix of everything.
If you want to change the code style, okay, but change it everywhere and don't forget to test everything you've changed.
> Frontend development is a nightmare
But is it weird I kind of enjoy it every so often/
> Elegance is not a real metric
You're dam right it's not! Next time someone proudly presents a super elegant, refined, and minimalistic solution I'm going to phone them at 3am on a Saturday and get them to debug it while screaming at them about lost revenue or something.
> DynamoDB is the worst possible choice for general application development
Oh man, the amount of times I've seen some form of noSql and it's used as a relational database. 9/10 some rendition of SQL is more than sufficient.
> ORMs are the devil in all languages and all implementations. Just write the damn SQL
It depends on what you're writing. I've seen enough projects writing raw SQL because of aversion to ORMs being bogged down in reinventing a lot of what ORMs offer. Like with other choices it is too often a premature optimization (for perf or DX) and a sign of prioritizing a sense of craftsmanship at the expense of the deliverables and the sanity of other team members.
It's not so much optimization but experience that on any sufficiently large project you gonna run into ORM limitation and end up with mix of ORM and direct queries. So might as well...
> Most programming should be done long before a single line of code is written
I'd rephrase this to something like: Most programming should be done before 5% of the code is written. Because "no plan survives contact with the enemy". I often develop a plan, work for just a tiny bit, and realize some new constraints. It's after that point that you should construct your grand battle plan.
> # 3 “Plan to throw one away; you will, anyhow.” (Fred Brooks, “The
Mythical Man-Month”, Chapter 11)
> Or, to put it another way, you often don’t really understand the problem until after the first time you implement a solution. The
second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at least once.
Its wrong in those day , exploratory coding is better for dynamic languges like python using jupyter notebook , and then do proper coding after exploratory step..
Interesting, I've been in software development for a little more than 10 years, and just about every point I've read, I more or less agree one, will be interesting to see if it changes the next 10.
Your team gets a clear and simple high-level goal that everyone at the company understands is important and shields you to work on it for a year without interruptions.
You don’t know it, but your manager playing up your teams contributions to the company, arranging happy coordination with other teams, occasionally intervening to resolve intra-team disputes, privately managing egos and careers, and jiu jitsu’ing any attempts to distract your team.
They trust your competence and decisions, but they understand enough to keep you on-track and provide a valuable outside view perspective.
1. For a non-manager, an indication that there is good management (project, process, etc.) in place is that the management aspect sort of seems to disappear/ moves into the background.
2. Communication becomes efficient or smooth.
How is it achieved?
1. High level goals and metric. And incremental upgrades to those. I think people/ teams need to get comfortable with one set of those before you want to improve better those metrics. Jira story points and velocity are not good metrics.
2. A manager acts as a buffer. A manager absorbs some shock and filters some data/ emotions which would otherwise flow between one (ideally more) pair of layers: one above them and one below them.
3. One kind of non-sense (from many kinds) is that people- junior or senior- are 'trying to prove their value'. This is why some people speak unnecessarily in meetings, emails go back and forth, senior management chimes in on low level issues, etc. A couple of good managers I saw were able to limit that- over a period of time.
> REPLs are not useful design tools (though, they are useful exploratory tools)
I disagree with this. I’m a Clojure dev, and most of the time, I use the REPL to iterate on features, fix bugs, and refactor, thanks to the fast feedback loop.
I used to be a Java dev—oh god, restarting the whole app after every change made me want to shoot myself in the head. Now, I use the REPL to build what I want and then move on. This brings joy back to programming.
I’m not saying other languages are bad, but working with Clojure is more enjoyable for me. I’m at least 2-3 times faster than I was with Java. Of course, there are techniques you need to know to write efficient and idiomatic functional code.
I could definitely see how if you work in Java or C# all day, repls feel like a neat curiosity. Picture telling someone who writes scheme in emacs that repls aren't a good design tool.
If you want to argue the point with non lisp people, I'd go to javascript or SQL as great examples where you really use repl's quite a bit.
I'm a heavy REPL/interactive shell user so when I do Java I abuse the testing framework, basically I put my sketches in unit tests and run those. The feedback loop is pretty tight, close to what I get in some other languages, whatever happens behind the scenes in IntelliJ it's much shorter than a full recompile and boot.
Supposedly there are some Java shells around but I haven't tried them out.
> Most won't care about the craft. Cherish the ones that do, meet the rest where they are
This becomes easier when you've transitioned from someone who cares to someone who doesn't. Some of us burn out from the industry and fall out of love with the job.
I understand my curmudgeon-ly ex-colleagues a lot more nowadays.
If the person at the top can come down for a coffee with people who endured some bad management, and ask honest, non-loaded three questions, it can be measured qualitatively but with very high accuracy.
The three questions are:
- What should we start doing?
- What should we continue doing?
- What should we stop doing?
This is an immensely powerful tool. Thanks to the awesome person who introduced me this.
Addenda: "Theory X" is something really bad. If you're working with a team which responds positively to Theory X, you have much bigger problems IMHO.
One thing that I have never been more sure about after 20 years as a software developer, is that Hibernate is awesome! Seriously, it saves me ton of time and tinkering. It has support for native queries, and it is simple to transform your custom query into JPA entities. Using Hibernate has never been easier with the introduction of LLM, tell it what it needs to do, and see beautiful Hibernate examples code.
In my Spring Boot applications I log every SQL that is generated, and quickly spot unoptimizations, like lazy loading of entities instead of using join.
How ORM's behave in other languages and frameworks, like Python, Go, Rust is probably another story.
>People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things.
This sticks out like sore thumb to me and I think you are coding solo for 10 years. If you manage to lead a team of developers or work with them you are screwed without linting rules and standardized code style. Even if they are applied it takes months to get to a get a team working in harmony - without them it will be a disaster.
- merge conflict hells because code style diferences
- bad for code reviewers
- bad to ready everyone's different code sytles.
He's not saying you shouldn't do it, he's saying you shouldn't stress over it. The "run the language's standard formatter before commit and then get on with your life" approach.
Regarding scaling… one thing that drives me bonkers about Apache Superset is that the maintainers are absolutely adamant that it must be deployed with kubernetes because it’s meant to scale. The project works just fine with a simple and slim docker/compose deployment, which is easier for small teams to manage. The lead maintainers refuse to document this and have unnecessarily sprinkled the docs with warnings.
Agree. People who join a project and insist on changing the default styling configs are insane weirdos. But people who dont want to use any styling solution on a project with several developers are EVEN MORE insane weirdos.
I strongly agree with almost all of this except the last part about project managers - a good one is invaluable, an ok one can still be helpful. The majority probably are neither (and their ability to be good at managing projects depends a lot on other org functions - not necessarily within their control) but way better than 90%+ that the author suggests.
> Typed languages are essential on teams with mixed experience levels
I'm 30 years in now, and on balance, whilst they have clear advantages, I'm still not convinced that typed languages are essential, particularly for low level or module programming.
Unless you can happily deal with '"four" + 1' your language is typed. The question is whether you want type errors reported upfront or you have to wait to find them at runtime (necessitating high test coverage).
One of these days I'd like to see a "typed assembler". It still matters what the contents of registers mean, even if they all look the same to the instruction set.
I agree but have been on teams where this slows down PR review or arguments break out. Delegating to the linter and format on save can get the team past this.
> Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy
My feeling is that a lot of negativity towards the frontend stems from assuming that the entire field is like React and its community. It's really not like that.
I think Frontend (or maybe slightly expanded App Development) is a greatly underappreciated skill. It's easy to throw a UI together, but to do it in a way that is obvious to your user's, can be maintained and can move at the speed the business needs is a tough ask.
I think trying to fit everything into the same lens is usually the real problem. Functional programming is a great methodology for a lot of things, but there are many ways to design things. Chances are really good that something elegantly written in prolog won't be as elegant in scheme or java, and vice versa.
From my experience, functional programmers come in two flavors. The ones who constantly nag others by telling them "everything you do is wrong", and "hey, come here, I want to show you something!". Unfortunately, the first camp is way more dominant than others.
Again, from the same article, there's observation "People who care about the craft are rare. Cherish the who cares, meet the rest at where they are". This is very true. The problem is, the people in the first camp can't cater to either group. First group has strong opinions and want a solid (not hostile, solid) discussion about how they can improve and how that tool works, and the second group doesn't care.
Also, every programmer has an understanding of the machine, and they program on top of that abstraction. For me, "C virtual machine", or the modern hardware is very easy to grasp. For every line of code, I can have an educated guess about how my code will run (e.g. how will the branch predictor will behave or got inadvertently poisoned), hence imperative languages and the primitive memory management is easy for me. For others who think more meta, functional paradigm is a natural think to construct in their brains. Not meeting them at where they are is again off-putting.
All in all, nobody wants to be constantly nagged to feel "stupid" about not understanding functional programming or how unelegant imperative is, and most of the functional programmers are doing this, even without knowing it.
Some of my friends who do functional programming are more reasonable people. Who sit down and look at some code or problem say "oh, this looks an interesting problem and interesting solution, can I show you how it's done in functional way", and we can go from there, and go a very long way from there.
I have never picked up Common LISP because of an academic who praised functional programming like it's the second coming of Christ. I still have the first chapter of the LISP book printed on my desk. I'll start it after 15 years, but now I don't have the time I want to spend on it.
Lastly, from an architecture/elegance perspective, I believe a good imperative program in C/C++/Go is somewhere between Bauhaus and Brutalist architecture depending on what domain you're targeting (lower the level, more Brutalism), and I find that naked nature of imperative code directly tapping into the hardware or the kernel efficiently very elegant and well-designed. For the same majority of functional programmers this is ugly and shall be got ridden with a flamethrower. Also, an imperative programming language is no lighter on PLT and mathematics which the same majority finds mouth wateringly elegant.
TL;DR: If the majority of functional programmers can be a bit less arrogant, meet in the middle and learn why we love what we love, we can build better languages, ecosystems, and a better world to live in, but no, functional elegant, imperative bad.
Robert Martin's Talk: "What Killed Smalltalk can Kill Ruby, Too": https://youtu.be/YX3iRjKj7C0 which notes a similar mechanic about Smalltalk.
I cannot agree with this. I've constantly ran into issues around where you can insert data into with an attribute name such as "status" and then when you query it, it says you cannot query with a reserved keyword.
There is a myriad of other issues I've found and when asking around chat groups and forums, people universally dislike dynamo db.
I've been loving edgedb in my typescript side projects for a number of years now. I have always hated ORMs, mostly for performance and a little bit for elegance / ergonomics. Curious if you have thoughts on a solution like that?
I like EdgeDB. The only downside I see is the lock-in, that is less of an issue with SQL.
While I have not used EdgeDB, I have used Hasura, which I really liked.
Wrt the syntax of queries, I know of https://prql-lang.org which is kind of similar of EdgeQL.
Funny that EdgeDB says on its page it tries to solve the ORM problem: I strongly believe ORMs do not solve any problem, they merely create problems (as I argue in the linked article).
Wrt my thoughts: the EdgeQL queries are usually still strings (no compile time type checking, not IDE tooling). With Hasura the GraphQL interface (that EdgeDB also supports) allows one to generate a client library based on the GraphQL schema: this allows one to have compile time checks on the queries, which is really neat.
Dependent typing is mainly just that feature of Typescript that `x: number | null` becomes just `x: number` inside an `if (x != null) { ... }` statement.
If you dig deeper into the type theory, it gets really interesting and complicated because types themselves can start to include any arbitrary code. And that's where Idris comes in! But after doing a whole project on Idris in college, I agree it is way outside the overturn window. Python and typescript rightfully keep it simple.
"Objects are extremely good at what they're good at. Blind devotion to functional is dumb.
"
Guess this hits home.
But Blind anything is bad.
I spent a decade blinded by objects being everything (original gang of four book). Then a decade where everything is functions.
> Typed languages are essential on teams with mixed experience levels
Essential, meaning 'cannot exist without', it's not. I've seen this work a number of places.
> Blind devotion to functional is dumb.
Managing/limiting state is always a worthwhile pursuit. I'd think he would agree since he seems to value simplicity
> People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things.
That's like saying don't check if your cars tires still have any pattern left, the engine is more important. Until it isn't. Streamlining the smaller details allows the brain to focus on more important stuff, but the details matter and their value increases exponentially with the size of the project.
Regarding code style etc. I get where he's coming from as plenty of people made entire careers on pursuing the perfect linter configuration. They're a net negative in every project.
> Most won't care about the craft. Cherish the ones that do, meet the rest where they are
> (…)
> People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things.
What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not necessarily the ground truth.
What you’re essentially saying is “cherish the people who care up to the level I personally and subjectively think is right, and dismiss everyone who cares more as insane weirdos who cannot prioritise”.
There's another way to look at this: if you consider the school of thought that says that the code is the design, and compilation is the construction process, then stressing over code style is equivalent to stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor), instead of stressing over load bearing, material costs and utility of the space.
I'm fond of saying that anything that doesn't survive the compilation process is not design but code organization. Design would be: which data structures to use (list, map, array etc.), which data to keep in memory, which data to load/save and when, which algorithms to use, how to handle concurrency etc. Keeping the code organized is useful and is a part of basic hygiene, but it's far from the defining characteristic of the craft.
> the formatting and conventions of the blueprint
Some of those formatting conventions are written in blood. The clarity of a blueprint is a big deal when people are using it to convey safety critical information.
I don’t think code formatting rises anywhere close to that level, but it’s also trying to reduce cognitive load which is a big deal in software development. Nobody wants to look at multiple lines concatenated together, how far beyond that you take things runs into diminishing returns. However at a minimum formatting changes shouldn’t regularly complicate doing a diff.
I 100% agree. The problem is that after a half a century, software engineering discipline has been unable to agree on global conventions and standards. I recently had an experience where a repair crew was worried about the odd looking placement of a concrete beam in my house. I brought over the blueprints, and the technician found the schedule of beams and columns within seconds, pinpointed the beam and said, "Ah, that's why. We just need to <solution I won't go into>". Just then it struck me how we can't do this in software engineering, even when the project is basically a bog-standard business app: CRUD API backed by an RDBMS.
That’s because the few hard rules you have to comply with have workarounds and matters rarely. In house construction, you have to care about weight, material degradation, the code, etc… there’s no such limitation on software so you can get something to work even if it’s born out of a LSD trip.
But we do have some common concepts. But they’re theoretical, so only the people that read the books knows the jargon.
don't stress about it so much: look how many variations of plugs and sockets are for this one quite simple thing: https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets
The value of software is both what it does now (behavior), and what you can get it to do later (structure). What you described as design and the compiled artiface is the behavior.
The craft is what gives you future choices. So when people cares about readability, writing tests, architecture, they’re just making easy for them to adjust the current behavior later when requirements change. A software is not an house, it doesn’t get build and stays a certain way.
> not the defining characteristic
Did anyone claim otherwise? Besides, I imagine bridges aren't rebuilt every week -- poor blueprints can only cause a finite amount of pain.
There is definitely something to be said for the idea that a shitslop engineering blueprint which still conveys correct design (maybe; who knows really?) is shitslop, whether or not the design is sound. In the case of software engineering, the blueprint is the implementation, too, so it’s not just shitslop blueprinting, it’s also shitslop brickwork (totally sound bones though I promise!), shitslop drywalling, shitslop concrete finishing and rebar work — and maybe it’s all good under the hood! Totally fine if all you’re building is a shithouse! But I think you get where I’m going with this.
architecture over implementation (for details).
> the school of thought that says that the code is the design
There's such a school?? Seriously??
The solution is to have computers enforce the code style. Pick a linter, pick a set of rules, and then forget about them.
Things I beleive:
- If you're picking up on code-style in PRs then your toolchain is backward.
- If you're changing linting rules every month then you're focussed on the wrong things
- It's better to have a consistent style than a perfect style
Yes. I love how gofmt has no settings, basically. Is this how you envisioned? Great. Now I don't have to think about optimizing it.
Coincidentally, the choices they made are the choices I'd made, but it doesn't matter in the end.
IMO, gofmt doesn't go far enough. It should sort imports and break lines automatically, or you end up with different people with slightly different preferences for breaking up lines, leading to an inconsistent style.
Something like gofumpt + golines + goimports makes more sense to me, but I'm used to ruff in Python (previous black + isort) and rustfmt.
I'd say that if you're manually formatting stuff with line breaks and spaces, that should have been automated by tooling. And that tooling should run both as a pre-commit hook and in CI.
gofmt sorts imports within the block they are in.
I have a habit of putting stdlib imports, a line break, golang experimental (x) imports, a line break and external imports.
I just tested, gofmt orders imports within these blocks. If I won't use the line breaks, it'll consider it a single block and will globally sort.
golang also aligns variable spacing and inline comments to look them as unified blocks (or a table if you prefer the term) and handles indents. The only thing it doesn't do is breaking lines, which I think acceptable.
This is what we did with clang-format on our code base.
The result is occasionally ugly code and nobody is 100% happy but at least it's consistent.
Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.[1]
[1] https://go-proverbs.github.io/
In my opinion, I think the author is criticizing bike shedding [1] rather than meaningful decisions. Of course some people will differ on whether a decision is one or the other. But as a whole, not sweating the details is a good quality to have whatever road in life you are on.
[1] https://en.wikipedia.org/wiki/Law_of_triviality
To me "craft" is about keeping code efficient, scalable, extensible, well-tested and documented. Code style is more about what naming convention to use, tabs vs spaces etc. - it's nice to have it consistent, but no need to spend more than 5 minutes arguing about it.
Is it ironic that this comment has evoked a discussion on minutiae?
There is more than one type of people who stress over code style. There's the group who wants to discuss about how to style your code and then there's the group who wants to just use a common code formatter and be done with that.
For example, I have objections to rustfmt's default style. I would never start discussions on rust projects about changing that to another formatter or changing its configuration. I definitely would carefully ask that people should really use rustfmt, though, if they don't do so yet.
You've set yourself up to always be the outlier. To always need to have that discussion or tweak the rules on every project you work with.
You've increased the overhead of onboarding anyone used to the default style. You've increased the overhead of you working on anyone else's projects that is more likely to have the default style.
All of that is friction introduced because you haven't learned to live with the default style.
Do I love that the default C# rules put a new line before the else block? No, but I've learned to live with it so that I can work on all manner of projects without fussing over that style option every time.
By adhering to default rules, you never have to have the endless arguments such as tabs vs spaces again. ( Spaces won, and the tabbers got over it fairly quickly once it was the default in almost all formatters. )
What I understood from your parent comment was the exact opposite, i.e. that they’re saying “I disagree with some of the default choices of the formatter (and so would prefer they were different) but I never voice those because it’s not worth it. However, I do think everyone should use something, whatever it is (even if the default style), as opposed to nothing”.
I believe you may have misunderstood my comment, as I agree.
It's not even more or less, it's just about different aspects. Consider a woodworker obsessing over sharp chisels - they don't all care beyond 'sharpish', or about the tools used to do so - but to some that's hugely important and how they are then able to do their best work.
I think the line between minutiae and craft is drawn by the effect it has on the product you're creating. Method length makes your code more manageable, for example. Placement of line breaks, not so much.
At the end of the day, we aren't paid to produce code, but working software that works today and is easy to change tomorrow.
That is a purely commercial take of the matter. I don’t think it’s controversial to argue the artisans who stand out do so because they care for the craft itself. Spending an extra hour or two perfecting the shape of the armrest in the chair may not allow you to earn more money from that one commission, but it might improve your knowledge and skill and be slightly more comfortable to the sitter. If they comment on it and appreciate it, so grows your motivation and pride.
Sometimes the code itself, and not its result, is the product. For example, when making tutorials the clarity and beauty of the code matters more than what it does.
I’m not arguing for obsessing over code formatting, but pointing out the line between “master of the craft with extensive attention to detail” and “insane weirdo with prioritisation deficits focusing on minutiae” is subjective to what each person considers important. Most of us seem to agree that being consistent in a code base is more important than any specific rule, but that being consistent does matter.
At the end of the day, we aren’t paid to eat healthily and taking care of our bodies either. But doing so pays dividends. Same for caring about the quality of your code. Getting in the habit of doing it right primes you to do it like that from the start in every new project. Like most skills, writing quality code becomes easier the more you do it.
There's a correlation-is-not-causation issue here. Yes, most very good developers pay a lot of attention to details, as well as to the bigger picture. But there are a lot of mediocre to downright bad developers who think that paying a lot of attention to code style, linting rules and other minutia will make them better developers.
Interesting read!
And that's why I don't care anymore
Yup. Doesn't matter.
Code style should be consistent and look nice, probably use the default without too much nitpicking. You have bigger fish to fry
There are better things in life to worry about
"Craft", most code goes to irrelevancy in 5 yrs. And if it doesn't it's fixable (amen for AIs)
Try to sweat up every detail right off the bat and you go nowhere
as others note, most of this minutia can be automatically enforced. Anything that can be automated is not craft.
Not really. Obsessing over breaking lines after famous 80 chars in Eclipse was, is and will be idiotic to be polite. Surprisingly large amount of people were obsessed by this long after we got much bigger screens, if that was ever an argument (it wasn't for me). 2 spaces vs 4 spaces or tab. Cases like these were not that rare, even though now it seems better. That's not productive focus of one's (or team's) energy and a proper waste of money for employer/customer, it brings 0 added value to products apart form polishing ego of specific individual.
Folks who care about the craft obsess (well within realm of being realistic) more about architecture, good use of design patterns, using good modern toolset (but not bleeding edge), not building monolithic spaghetti monster that can't evolve much further, avoiding quick hacks that end up being hard to remove and work with over time and so on.
If you don't see a difference between those groups, I don't think you understood author's points.
Reporting as an Eclipse user of 20+ years, and a person who cares about the craft:
The choice for me is simple:
If I'm going to view the code I'm writing in a 80x24 terminal later on, I'll break that lines, and will try really hard to not get closer to 80 chars per line.
If that code is only going to be seen in Eclipse and only by me, I won't break that lines.
I omitted your other examples for brevity.
Having bigger screens doesn't make longer lines legit or valid. I may have anything between 4-9 terminals open on my 28" 2K screen anytime, and no, I don't want to see lines going from one side to another like spikes, even if I have written them.
I'd say avoiding long lines is one of the most important rules. I regularly have 2-3 files open side by side, I don't want to have to scroll sideways to read the code.
80 characters is a bit on the low end imo but I'd rather have the code be too vertical than too horizontal. Maybe 120-150 is a more reasonable limit. It's not difficult to stay within those bounds as long as you don't do deep nesting which I don't really want to see anyway because it's hardly ever necessary and it makes code more difficult to read.
Reading vertically is much faster than reading horizontally, so I think 80 is a good soft limit. In some contexts it's hard to not go over it sometimes, e.g. in Java where it's not uncommon with very long type and method names.
Functional code is more chained and need more space often. Descriptive names are better; tends to be longer. Buy ultrawide.
80 is for aholes who like to use small laptop and then force it on everyone else. 120/150 is reasonable.
200 is great.
Yep.
And the laptop excuse is not even valid, I used a 11" MacBook Air for 10 years and even back then 80 always felt extremely limiting for me.
I just tested and: even when zooming +1 on VSCode and leaving the minimap open I can fit 140 chars without any horizontal scroll.
People demanding 80 columns always have some crazy setups, like an IDE where the editor is just a minuscule square in the centre, like an Osbourne 1 computer.
200 is entirely too fucking long, and I code on a 43” 4K. I try to stay under 90 in deference to others, and if it looks better breaking at 80, so be it.
> Most programming should be done long before a single line of code is written
Nah.
I (16+ years developer) prefer to iteratively go between coding and designing. It happens way too often that when you're coding, you stumble across something that makes you go "oh f me, that would NEVER work", which forces you to approach a problem entirely differently.
Quite often you also have eureka moments with better solutions that just would not have happened unless you had code in front of you, which again makes you approach the problem entirely differently.
ok that sounds bad, you should have the option to go back to design, but depending on what point you find that issue, depends on how much time you have wasted?
> Typed languages are essential on teams with mixed experience levels
I like this one because it puts this endless dilemma in a human context. Most discussions are technical (static typing ease refactoring and safety, dynamic typing is easier to learn and better for interactive programming etc.) and ignore the users, the programmers.
UX really is everywhere, once your eyes are opened to it.
I think the size of the code base also matters: bigger size = having types is more important.
There is a contradiction here as: bigger size = compile speed more important AND types slow down compilation. More advanced typing features slow down compilation even more.
> More advanced typing features slow down compilation even more.
C++ is a bit of an outlier here. But really people should think of typechecking as shifting fault detection earlier in the process than runtime. It doesn't matter if your test suite starts slightly quicker if you have to wait for the whole thing to run to find something you could otherwise have found with types.
I agree. But the nice thing about types is that they are not an afterthought, but more a "pre thought". TDD tries to make testing a pre thought...
[dead]
> Java is a great language because it's boring [...] Types are assertions we make about the world
This is less of a mind-was-changed case and more just controversial, but... Checked Exceptions were a fundamentally good idea. They just needed some syntactic sugar to help redirect certain developers into less self-destructive ways of procrastinating on proper error handling.
In brief for non-Java folks: Checked Exceptions are a subset of all Exceptions. To throw them, they must be part of the function's type signature. To call that function, the caller code must make some kind of decision about what to do when that Checked Exception arrives. [0] It's basically another return type for the method, married with the conventions and flow-control features of Exceptions.
[0] Ex: Let it bubble up unimpeded, adding it to your own function signature; catch it and wrap it in your own exception with a type more appropriate to the layer of abstraction; catch it and log it; catch it and ignore it... Alas, many caught it and wrapped it in a generic RuntimeException.
It was botched from the start because there's so many opportunities for unchecked exceptions as well. Without a more sophisticated type system that represented nullability, you can get NullPointerException anywhere. Divide by zero. And so on.
You also have a problem similar to "monads and logging": if you want to log from anywhere in your program, your logging function needs to be exception-tight and deal with all the possible problems such as running out of disk space, otherwise you have to add those everywhere.
I agree, although I would like to point out Java usually gets the blame for what was actually an idea being done in CLU, Mesa, Modula-3 and C++, before Oak came to be and turned into Java.
Additionally, the way result types work, isn't much different, from type system theory point of view.
I really miss them in .NET projects, because no one reads method documentation, or bothers to have catch all clauses, and then little fellow crashes in production.
Checked exceptions as an idea are great (Nim’s usage of something similar is excellent) but yeah Javas particular implementation was annoying and easy to avoid, so most did.
> adding it to your own function signature
This is precisely why they are so bad: checked exceptions must not be allowed to be used outside the package (or jar, or whatever, just limit it) otherwise they cause non-local build failures in all dependencies. They're fine if you are developing the artifact that's going to be deployed.
> Alas, many caught it and wrapped it in a generic RuntimeException.
Actually sounded great right up until this point. Deal with it, or explicitly acknowledge that you do not. It's honest.
Apparently other developers are why we can't have nice things.
It's already very unlikely that you can 'recover-and-proceed' in the context of any business app exception (Security violation, customer not found, no such payment, etc.).
So what's left in exception handling is logging and/or rethrowing. And the 'nasty hackish way' of doing it (RuntimeException) already passes a complete stack trace up to the caller.
remind me why they don’t work? because “throws Exception” propagates virally to every method in the codebase?
Well, if you don’t handle them then… yes? What else can be done?
There's also the fact that common methods threw exception types that were not final, and in fact overly generic. If I call a method that declares itself to throw NoSuchFileException or DirectoryNotEmptyException, I can have a pretty good idea what I might do about it. If it throws IOException without elaboration, on the other hand...
With regards to I/O, there are generally any number of weird errors you can run into, file not found, directory exists, host unreachable, permission denied, file corrupt, etc etc. Like anything file related will be able to throw any of those exceptions at almost any point in time.
I think IOException (or maybe FileSystemException) is probably the best you can do in a lot of I/O cases unless you can dedicate time to handling each of those specially (and there's often not a lot much more you can do except for saying "Access is denied" or "File not found" to the user or by logging it somewhere).
> People who stress over code style, lining
You can do it whatever way you want but match the style of the project. I've worked on too many projects where someone decides their way is best and you end up with a mix of everything.
If you want to change the code style, okay, but change it everywhere and don't forget to test everything you've changed.
> Frontend development is a nightmare
But is it weird I kind of enjoy it every so often/
> Elegance is not a real metric
You're dam right it's not! Next time someone proudly presents a super elegant, refined, and minimalistic solution I'm going to phone them at 3am on a Saturday and get them to debug it while screaming at them about lost revenue or something.
> DynamoDB is the worst possible choice for general application development
Oh man, the amount of times I've seen some form of noSql and it's used as a relational database. 9/10 some rendition of SQL is more than sufficient.
> ORMs are the devil in all languages and all implementations. Just write the damn SQL
It depends on what you're writing. I've seen enough projects writing raw SQL because of aversion to ORMs being bogged down in reinventing a lot of what ORMs offer. Like with other choices it is too often a premature optimization (for perf or DX) and a sign of prioritizing a sense of craftsmanship at the expense of the deliverables and the sanity of other team members.
It's not so much optimization but experience that on any sufficiently large project you gonna run into ORM limitation and end up with mix of ORM and direct queries. So might as well...
Depends upon the ORM. Like all frameworks, a really good one is a significant productivity boost while a bad one is faworse than none at all.
> Most programming should be done long before a single line of code is written
I'd rephrase this to something like: Most programming should be done before 5% of the code is written. Because "no plan survives contact with the enemy". I often develop a plan, work for just a tiny bit, and realize some new constraints. It's after that point that you should construct your grand battle plan.
From “The Cathedral and the Bazaar”:
> # 3 “Plan to throw one away; you will, anyhow.” (Fred Brooks, “The Mythical Man-Month”, Chapter 11)
> Or, to put it another way, you often don’t really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at least once.
https://en.m.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
Its wrong in those day , exploratory coding is better for dynamic languges like python using jupyter notebook , and then do proper coding after exploratory step..
Interesting, I've been in software development for a little more than 10 years, and just about every point I've read, I more or less agree one, will be interesting to see if it changes the next 10.
> Good management is invaluable. (I went most of my career before seeing it done well)
I don't think I've ever seen good management. Anyone care to explain what that would look like?
Your team gets a clear and simple high-level goal that everyone at the company understands is important and shields you to work on it for a year without interruptions.
You don’t know it, but your manager playing up your teams contributions to the company, arranging happy coordination with other teams, occasionally intervening to resolve intra-team disputes, privately managing egos and careers, and jiu jitsu’ing any attempts to distract your team.
They trust your competence and decisions, but they understand enough to keep you on-track and provide a valuable outside view perspective.
A couple of indicators I have seen:
1. For a non-manager, an indication that there is good management (project, process, etc.) in place is that the management aspect sort of seems to disappear/ moves into the background.
2. Communication becomes efficient or smooth.
How is it achieved?
1. High level goals and metric. And incremental upgrades to those. I think people/ teams need to get comfortable with one set of those before you want to improve better those metrics. Jira story points and velocity are not good metrics.
2. A manager acts as a buffer. A manager absorbs some shock and filters some data/ emotions which would otherwise flow between one (ideally more) pair of layers: one above them and one below them.
3. One kind of non-sense (from many kinds) is that people- junior or senior- are 'trying to prove their value'. This is why some people speak unnecessarily in meetings, emails go back and forth, senior management chimes in on low level issues, etc. A couple of good managers I saw were able to limit that- over a period of time.
Key thing good manager shields team from corporate bs as much as possible
No, objects aren't generally 'good', unless you think keeping multiple state machines in sync is 'good'.
OO is not evil, but it also shouldn't be your default solution to everything.
Also, who is this person? I immediately distrust someone who calls themselves 'a pretty cool guy'. That's for the rest of us to decide.
> REPLs are not useful design tools (though, they are useful exploratory tools)
I disagree with this. I’m a Clojure dev, and most of the time, I use the REPL to iterate on features, fix bugs, and refactor, thanks to the fast feedback loop.
I used to be a Java dev—oh god, restarting the whole app after every change made me want to shoot myself in the head. Now, I use the REPL to build what I want and then move on. This brings joy back to programming.
I’m not saying other languages are bad, but working with Clojure is more enjoyable for me. I’m at least 2-3 times faster than I was with Java. Of course, there are techniques you need to know to write efficient and idiomatic functional code.
I could definitely see how if you work in Java or C# all day, repls feel like a neat curiosity. Picture telling someone who writes scheme in emacs that repls aren't a good design tool.
If you want to argue the point with non lisp people, I'd go to javascript or SQL as great examples where you really use repl's quite a bit.
I'm a heavy REPL/interactive shell user so when I do Java I abuse the testing framework, basically I put my sketches in unit tests and run those. The feedback loop is pretty tight, close to what I get in some other languages, whatever happens behind the scenes in IntelliJ it's much shorter than a full recompile and boot.
Supposedly there are some Java shells around but I haven't tried them out.
You either REPL or do TDD.
> Most won't care about the craft. Cherish the ones that do, meet the rest where they are
This becomes easier when you've transitioned from someone who cares to someone who doesn't. Some of us burn out from the industry and fall out of love with the job.
I understand my curmudgeon-ly ex-colleagues a lot more nowadays.
> Good management is invaluable. (I went most of my career before seeing it done well)
Yes, and: it's difficult to describe, must be led from the top, and extremely difficult to evaluate from above.
If the person at the top can come down for a coffee with people who endured some bad management, and ask honest, non-loaded three questions, it can be measured qualitatively but with very high accuracy.
The three questions are:
This is an immensely powerful tool. Thanks to the awesome person who introduced me this.Addenda: "Theory X" is something really bad. If you're working with a team which responds positively to Theory X, you have much bigger problems IMHO.
sounds just like the advice in the book "The Coaching Habit" which i thought was great
One thing that I have never been more sure about after 20 years as a software developer, is that Hibernate is awesome! Seriously, it saves me ton of time and tinkering. It has support for native queries, and it is simple to transform your custom query into JPA entities. Using Hibernate has never been easier with the introduction of LLM, tell it what it needs to do, and see beautiful Hibernate examples code.
In my Spring Boot applications I log every SQL that is generated, and quickly spot unoptimizations, like lazy loading of entities instead of using join.
How ORM's behave in other languages and frameworks, like Python, Go, Rust is probably another story.
I'm curious, have you worked with Entity Framework with its legendary LINQ magic?
>People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things.
This sticks out like sore thumb to me and I think you are coding solo for 10 years. If you manage to lead a team of developers or work with them you are screwed without linting rules and standardized code style. Even if they are applied it takes months to get to a get a team working in harmony - without them it will be a disaster.
- merge conflict hells because code style diferences - bad for code reviewers - bad to ready everyone's different code sytles.
He's not saying you shouldn't do it, he's saying you shouldn't stress over it. The "run the language's standard formatter before commit and then get on with your life" approach.
Regarding scaling… one thing that drives me bonkers about Apache Superset is that the maintainers are absolutely adamant that it must be deployed with kubernetes because it’s meant to scale. The project works just fine with a simple and slim docker/compose deployment, which is easier for small teams to manage. The lead maintainers refuse to document this and have unnecessarily sprinkled the docs with warnings.
> People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things.
I just want to set up a linter that’s standard for the language and let CI deal with it. Anything other than that is mental to me.
Agree. People who join a project and insist on changing the default styling configs are insane weirdos. But people who dont want to use any styling solution on a project with several developers are EVEN MORE insane weirdos.
I strongly agree with almost all of this except the last part about project managers - a good one is invaluable, an ok one can still be helpful. The majority probably are neither (and their ability to be good at managing projects depends a lot on other org functions - not necessarily within their control) but way better than 90%+ that the author suggests.
After almost 40 years, between hobby coding, education, and professional experience, kind of share a similar view in a couple of topics.
Additionally such an extend experience gives us another point of view on trendy subjects that are experiences from the past newly repacked.
And desilusion, seeing so many great ideas taking decades to become relevant, or never at all.
> Typed languages are essential on teams with mixed experience levels
I'm 30 years in now, and on balance, whilst they have clear advantages, I'm still not convinced that typed languages are essential, particularly for low level or module programming.
Unless you can happily deal with '"four" + 1' your language is typed. The question is whether you want type errors reported upfront or you have to wait to find them at runtime (necessitating high test coverage).
One of these days I'd like to see a "typed assembler". It still matters what the contents of registers mean, even if they all look the same to the instruction set.
The author learns that Java is not a Functional Programming language; lambdas ain't enough!
I think the ultimate boring language is golang. It is almost too boring though.
> People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things.
Could not agree more.
I agree but have been on teams where this slows down PR review or arguments break out. Delegating to the linter and format on save can get the team past this.
Those teams have these weirdos the article talks about.
> Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy
My feeling is that a lot of negativity towards the frontend stems from assuming that the entire field is like React and its community. It's really not like that.
I think Frontend (or maybe slightly expanded App Development) is a greatly underappreciated skill. It's easy to throw a UI together, but to do it in a way that is obvious to your user's, can be maintained and can move at the speed the business needs is a tough ask.
It felt good to read someone who thinks like me, honestly.
Also the observation of "The trouble with functional programming is functional programmers" is absolutely correct.
This needs to be said more. Way more.
P.S.: You can ask why, and I can answer honestly, without hostility.
I think trying to fit everything into the same lens is usually the real problem. Functional programming is a great methodology for a lot of things, but there are many ways to design things. Chances are really good that something elegantly written in prolog won't be as elegant in scheme or java, and vice versa.
Yes, this is one of the bigger (if not the biggest) problems. I don't think that imperative programming is the only or the best way, either.
The different approaches can and do transform some really ugly things in one paradigm to something really neat and joyful things in another.
But reaching that level of maturity or flexibility is rather hard as far as I can see, and it's honestly sad.
Maybe say it less but it explain it more. I don't get it at all.
Let me try to explain it a bit more.
From my experience, functional programmers come in two flavors. The ones who constantly nag others by telling them "everything you do is wrong", and "hey, come here, I want to show you something!". Unfortunately, the first camp is way more dominant than others.
Again, from the same article, there's observation "People who care about the craft are rare. Cherish the who cares, meet the rest at where they are". This is very true. The problem is, the people in the first camp can't cater to either group. First group has strong opinions and want a solid (not hostile, solid) discussion about how they can improve and how that tool works, and the second group doesn't care.
Also, every programmer has an understanding of the machine, and they program on top of that abstraction. For me, "C virtual machine", or the modern hardware is very easy to grasp. For every line of code, I can have an educated guess about how my code will run (e.g. how will the branch predictor will behave or got inadvertently poisoned), hence imperative languages and the primitive memory management is easy for me. For others who think more meta, functional paradigm is a natural think to construct in their brains. Not meeting them at where they are is again off-putting.
All in all, nobody wants to be constantly nagged to feel "stupid" about not understanding functional programming or how unelegant imperative is, and most of the functional programmers are doing this, even without knowing it.
Some of my friends who do functional programming are more reasonable people. Who sit down and look at some code or problem say "oh, this looks an interesting problem and interesting solution, can I show you how it's done in functional way", and we can go from there, and go a very long way from there.
I have never picked up Common LISP because of an academic who praised functional programming like it's the second coming of Christ. I still have the first chapter of the LISP book printed on my desk. I'll start it after 15 years, but now I don't have the time I want to spend on it.
Lastly, from an architecture/elegance perspective, I believe a good imperative program in C/C++/Go is somewhere between Bauhaus and Brutalist architecture depending on what domain you're targeting (lower the level, more Brutalism), and I find that naked nature of imperative code directly tapping into the hardware or the kernel efficiently very elegant and well-designed. For the same majority of functional programmers this is ugly and shall be got ridden with a flamethrower. Also, an imperative programming language is no lighter on PLT and mathematics which the same majority finds mouth wateringly elegant.
TL;DR: If the majority of functional programmers can be a bit less arrogant, meet in the middle and learn why we love what we love, we can build better languages, ecosystems, and a better world to live in, but no, functional elegant, imperative bad.
Robert Martin's Talk: "What Killed Smalltalk can Kill Ruby, Too": https://youtu.be/YX3iRjKj7C0 which notes a similar mechanic about Smalltalk.
> Objects are extremely good at what they're good at. Blind devotion to functional is dumb.
Maybe "mutable objects"? Maybe these were intended to be isolated statements? Personally I believe functional programming is great with objects too...
It is however true that many OOP-embracing languages tend to favor an imperative style. Scala is an example of a language that embraces both.
> There is no pride in managing or understanding complexity
"is"? I see plenty.
> DynamoDB is a good database
I cannot agree with this. I've constantly ran into issues around where you can insert data into with an attribute name such as "status" and then when you query it, it says you cannot query with a reserved keyword.
There is a myriad of other issues I've found and when asking around chat groups and forums, people universally dislike dynamo db.
The comment about project managers is interesting. At my last workplace, the PMs -- all consultants -- were the only reason anything ever got done.
Depends on team's experience level
> ORMs are the devil in all languages and all implementations. Just write the damn SQL
This week wrote an article on this, since I found there's a lot to explain wrt this topic:
https://dev.to/cies/the-case-against-orms-5bh4
On HN:
https://news.ycombinator.com/item?id=42922014
I've been loving edgedb in my typescript side projects for a number of years now. I have always hated ORMs, mostly for performance and a little bit for elegance / ergonomics. Curious if you have thoughts on a solution like that?
I like EdgeDB. The only downside I see is the lock-in, that is less of an issue with SQL.
While I have not used EdgeDB, I have used Hasura, which I really liked.
Wrt the syntax of queries, I know of https://prql-lang.org which is kind of similar of EdgeQL.
Funny that EdgeDB says on its page it tries to solve the ORM problem: I strongly believe ORMs do not solve any problem, they merely create problems (as I argue in the linked article).
Wrt my thoughts: the EdgeQL queries are usually still strings (no compile time type checking, not IDE tooling). With Hasura the GraphQL interface (that EdgeDB also supports) allows one to generate a client library based on the GraphQL schema: this allows one to have compile time checks on the queries, which is really neat.
He mentions this being a follow-up to a similar earlier post: https://chriskiehl.com/article/thoughts-after-6-years .
HN discussions on that post: https://news.ycombinator.com/item?id=25887373 (4 years ago|686 comments), https://news.ycombinator.com/item?id=32162716 (3 years ago|58 comments), and https://news.ycombinator.com/item?id=41633156 (4 months ago|56 comments).
> Gradual, dependently typed languages are the future
I really interested why the author thinks this.
I've seen the general sentiment wrt "the future" go from C to C++ to Java to Ruby to JS (also server-side) and Python.
My own sentiment went from Ruby to Haskell to, well, Kotlin I guess...
I looked into Idris (dependently typed), but did not think it would fit the Overton window[1], to be a reasonable expectation for the future.
1: https://en.wikipedia.org/wiki/Overton_window
Dependent typing is mainly just that feature of Typescript that `x: number | null` becomes just `x: number` inside an `if (x != null) { ... }` statement.
If you dig deeper into the type theory, it gets really interesting and complicated because types themselves can start to include any arbitrary code. And that's where Idris comes in! But after doing a whole project on Idris in college, I agree it is way outside the overturn window. Python and typescript rightfully keep it simple.
Narrowing, as TypeScript calls it, isn't dependant typing - it's basically just a form of pattern-matching over a sum type.
> DynamoDB is a good database (IFF your workload lines up with what it's offering)
"The correct tool for the job."
Seeing a document database used for tabular purposes gives me a sad.
>People who stress over code style, linting rules, or other minutia remain insane weirdos to me.
Um, "minutiae", erm, uh.
"Objects are extremely good at what they're good at. Blind devotion to functional is dumb. "
Guess this hits home. But Blind anything is bad. I spent a decade blinded by objects being everything (original gang of four book). Then a decade where everything is functions.
Why not pass a list of objects to that function.
I actually disagree with about half of this.
> Typed languages are essential on teams with mixed experience levels
Essential, meaning 'cannot exist without', it's not. I've seen this work a number of places.
> Blind devotion to functional is dumb.
Managing/limiting state is always a worthwhile pursuit. I'd think he would agree since he seems to value simplicity
> People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things.
That's like saying don't check if your cars tires still have any pattern left, the engine is more important. Until it isn't. Streamlining the smaller details allows the brain to focus on more important stuff, but the details matter and their value increases exponentially with the size of the project.
Your rebuttals are all agreeing with him...
I don't think you're grasping the nuance he's putting out there. Instead you're choosing to be overly pedantic over the word essential.
Regarding code style etc. I get where he's coming from as plenty of people made entire careers on pursuing the perfect linter configuration. They're a net negative in every project.
I'd love some clarification if he meant people who bike shed or people who care to setup a linter and formatter as part of their workflow.