17 ms·

How I Program in 2024

317 points by surprisetalk 2y ago

behnamoh 2y ago
> Types, abstractions, tests, versions, state machines, immutability, formal analysis, all these are tools available to us in unfamiliar terrain. Use them to taste. How did people program in Lisp for decades? I like types and such, and have even gone so far as to write Python like it's Rust. But in the end I realized dynamic languages have an appeal for a reason, and by using types all over the place, I was not getting the benefits of a dynamic language like Python. When context is mostly static, dynamic languages shine. Context could be, for example, the structure of the directory. If I want to read a file and I know that the file exists, throwing a bunch of type checks about file reading operation is just overkill and slows down the development.
- BigJono 2y ago
  The very next dot point is agreeing with you: "The ideal quantity to use these tools is tiny, much more miniscule than any of us is trained to think". And I agree tbh. The TS community has turned me off static typing for life. It's just wall to wall bikeshedding from the least productive people I've ever had the displeasure of working with.
  - trustinmenowpls 2y ago
    Honestly, that explains perfectly why all MS apps have gone from useable if a bit slow or buggy to just unusable buggy messes that crash constantly and make my machine feel like its running on molasses.
    - nl 2y ago
      It doesn't "explain" it at all (and indeed many of reject the idea that MS apps - in general - are worse. They've had a bad reputation for decades, and that isn't based on nothing).
      - behnamoh 2y ago
        Teams + the entire Office suite are two examples of Microsoft products going downhill over time.
        miffy900 2y ago
        That's true but that has absolutely nothing to do with types in programming languages; it has more to do with MS's culture of always favouring backward compatibility and never culling any features in every version.
        behnamoh 2y ago
        > it has more to do with MS's culture of always favouring backward compatibility and never culling any features in every version. The new Office suite are unbelievably buggy and slow not because of backward compatibility, but because of numerous useless "features" Microsoft added which made the software essentially bloatware. By the time Excel opens up on my Mac, I can open several Google Sheets and start working.
        nl 2y ago
        Has Teams ever been good? From the first time I used it it has always been one of the worst pieces of software I use. Office seems fine to me - not great software, but I haven't noticed any particular decline (not a heavy user, but have been using it since Word v2 in the 1990s) And in any case what does this have to do with Typescript and the (over?) use of types?
      - trustinmenowpls 2y ago
        The actual quality of their apps has significantly degraded over time. Many of their apps which use web-native technologies have become nearly unusable, and I strongly suspect it's exactly because they've gone down this insane road of bike shedding and constant re-inventing of the wheel instead of pursuing excellence.
- seer 2y ago
  Hmm, rarely have I thought types were a burden, rather than help, maybe I’m weird. Maybe I spend effort in making sure my types are useful and easy to work with, but one previous TypeScript I got to a state where _all_ of my database queries were automatically typed, and all of my requests and responses too, so both input output were guaranteed to be correct bg the compiler, so any bugs or errors that were left were business logic. It was incredibly liberating - like pairing with someone who was junior but very pedantic. I ended up writing almost no unit test and only having integration level tests, cause the job of those test was mostly covered by types. And writing the code itself was such a pleasure - you get immediate feedback if your program is correct _as you type it_. The most bizarre consequence of all this to me was writing a program for almost 2 hours, hundreds of lines of code, and then executing it and having it do exactly what you wanted on the first compile. That was both scary but exciting! One can get over-constrained with types for sure, where you’re sending more time “fighting the types” rather than writing your code. But this is all just learning, once you understand how the typesystem works it all becomes easy to work with. It was the same story with tests - once I started testing everything- it wasn’t easy to adopt my code to be testable, took effort, but then I learned how to make code pure, move state to the edges, manage dependencies etc, and all of those are useful practices in their own right, regardless if you write the tests or not. Same with types - schema design and invariants, state machines, edge cases in type conversion and how to lock and manage external dependencies. Sets, unions etc - it became the way I reason about code with of without types and my code is better for it. I also assume that types would make AI generated code much better _and more reliable_ because of the additional information and structure that it provides, so I recon they are here ti stay.
  - fendy3002 2y ago
    have you worked with java or C#? both are where types sometimes become a burden. No, you cannot just do something like this: ``` return { data, message: "OK" }; ``` you need to declare a class or struct that match the definition. There's mapper and builder everywhere. Adding / deleting 1 column from a datatype can force you to make changes in 5 places due to mapper / builder.
    - 2y ago
- tmtvl 2y ago
  I quite like Lisp 'cause I can do silly things like: (defun sum-triplet? (list) (declare (type List list)) (and (= (length list) 3) (destructuring-bind (a b c) list (and (numberp a) (numberp b) (numberp c) (= (+ a b) c))))) (deftype Sum-Triplet () '(and List (satisfies sum-triplet?)))
curry798 2y ago
Is it recommended to learn shell if you are a beginner?
- leptons 2y ago
  What you should learn, is knowing when shell is the right tool for the job.
  - curry798 2y ago
    It dawned on me, thank you.
- fragmede 2y ago
  I won't comment on which shell to learn, but you'll end up spending a lot of time in it, so learning your chosen shell well will pay off dividends for the rest of your life.
- seer 2y ago
  There was a saying that technology usually has inertia, if it was used for 30 years, and is used actively now, it will probably still be in use 30 years in the future. I learned vim by necessity after shying away from this weird old tech for years, when I was forced to work on a solaris server where there was no other way to edit the code at all. It was pain and suffering for a few hours - we really wanted to fix something that day as I was working on a machine that we were “not allowed to ssh into” been driven to a different city in order to sit in front of it. But after that day I’ve been using vim almost every day. It is not my daily driver, always felt more productive in TextMate, SublimeText and now VS Code, but it is still incredibly useful. Any remote server I ssh into there is no question what I can or cannot do - can easily edit everything I want to. And I use it for various quick edit tasks in the shell. Now learning shells wasn’t so dramatic for me but same rules apply, I don’t feel uncomfortable anywhere - that pod that is misbehaving in your cluster - well just ssh into it and poke around! You need to tie a few commands together as there isn’t something that does _exactly_ what your company needs - just whip up a quick bash script! - zero dependencies and can be deployed anywhere - your mac, the server the ci is running on, even windows machines! So general rule is - if it was used for 50 years and is used now, it is probably worth learning.
munchler 2y ago
> Giving up tests and versions, I ended up with a much better program. I can’t understand how anyone would willingly program without using source code control in 2024. Even on a single-person project, the ability to work on multiple machines, view history, rollback, branch, etc. is extremely valuable, and costs almost nothing. Maybe I’m misunderstanding what the author means by “versions”?
- shepherdjerred 2y ago
  Yeah, this is not good advice for the average person, even for solo projects.
  - codr7 2y ago
    I agree, and the author probably does as well. I didn't get the feeling it was meant as general advice.
- shermanyo 2y ago
  I think in this case, the author means coding version logic into the app itself. eg. versioned API endpoints for backwards compatibility
  - layer8 2y ago
    This is about a desktop text editor built with LUA on a C++-based native framework for writing 2D games: https://git.sr.ht/~akkartik/lines2.love https://git.sr.ht/~akkartik/lines2.love Very unlikely to have versioned API endpoints involved.
  - shepherdjerred 2y ago
    I don't think so: > Back in 2015 I was suspicious of abstractions and big on tests and version control. Code seemed awash in bad abstractions, while tests and versions seemed like the key advances of the 2000s. > In effect I stopped thinking about version control. Giving up tests and versions, I ended up with a much better program. > Version control kept me attached to the past. Both were counter-productive. It took a major reorientation to let go of them.
shove 2y ago
I’m really curious whether my agree:disagree ratio will be higher in the article or in the comments.
aetherspawn 2y ago
When you have no tests your problems go away because you don’t see any test failures. Never have I tested anything and NOT found a bug, and most things I tested I thought were already OK to ship. Thus, when you delete your tests, the only person you are fooling is probably yourself :( From reading your page I get the impression you are more burnt out from variation/configuration management which is completely relatable… I am too. This is a hard problem. But user volume is required to make $$. If the problem was easy then the market would be saturated with one size fits all solutions for everything.
- akkartik 2y ago
  > When you have no tests your problems go away because you don’t see any test failures. The flip side of this is the quote that "tests can show the presence of bugs, but never their absence". It better fits my experience here; every few months I'd find a new bug and diligently write a test for it. But then there was a new bug in a few months, discovered by someone in the first 10 minutes of using it. I'm sure I have bugs to discover in the new version. But the data structures I chose make many of the old tests obsolete by construction. So I'm hopeful that I'm a few bugs away from something fairly stable at least for idle use. Tests are definitely invaluable for a large team constantly making changes to a codebase. But here I'm trying to build something with a frozen feature set.
  - monkpit 2y ago
    If your tests break or go away when your implementation changes, aren’t those bad tests by definition?
    - akkartik 2y ago
      I have two answers: 1. Yes. To the same extent that we are all bad people by definition, made of base material and unworthy urges. I'd love to have better programmers show me how I can make my tests better. The code is out there. 2. Even if I have good tests "by definition", a radical rewrite might make old tests look like "assert(2x1 == 2), assert (2x2 == 4)". Tests exist in a context, and radically changing the context can change the tests you need. --- This is not in OP, but I do also have a problem of brittle tests in my editor. In this case I need to test a word-wrapping algorithm. This depends intimately on pixel-precise details of the font. I'd love for better programmers than me to suggest how I can write tests that are robust and also self-evidently correct without magic constants that don't communicate anything to the reader. "Failure: 'x' started at x=67 rather than x=68." Reader's thought: "Why is this a problem?" etc. Comments appreciated on https://git.sr.ht/~akkartik/lines.love/tree/main/item/text_tests.lua https://git.sr.ht/~akkartik/lines.love/tree/main/item/text_t.... The summary at https://git.sr.ht/~akkartik/lines.love/tree/main/item/text_tests https://git.sr.ht/~akkartik/lines.love/tree/main/item/text_t... might help orient readers.
layer8 2y ago
This is quite a confused article. I really wonder what about it made it be upvoted to first place.
- rectang 2y ago
  I keep trying to figure out the joke.
  - namaria 2y ago
    Author successfully drove engagement with psychological baits like bashing commonly accepted tools and practices and being intentionally obscure so a lot of people would comment about it.
    - codr7 2y ago
      Or, author has so much more experience than you, that his conclusions can't possibly make sense in your world. Not saying that's the case, but it's certainly possible. The more wisdom, the less need for rules and conventions. That being said, I do feel like we have to learn to communicate over these boundaries if we want to evolve faster, as opposed to mostly repeating the same mistakes over and over.
      - namaria 2y ago
        Yeah I am sure author has transcended such pedestrian things as versioning and testing code.
        codr7 2y ago
        No one has claimed that. It was simply suggested that in some situations, maybe they're not as important as we tend to assume. And it takes experience to see those patterns.
        deleted 2y ago
        [deleted]
xelxebar 2y ago
Data-orientation, abstraction avoidance, holistic rewrites. The values espoused by OP rhyme heavily with the stance I've begun to take after reading and writing significant amounts of APL. The best code I've seen mercilessly elides anything that doesn't serve an architectural level, problem domain-relevant concern. GADTs and hash tables, and all our nice CS tools work much better when applied as cognitive tools in a domain-specific manner as opposed to reified language syntax or library APIs, as the latter necessarily introduces cross-domain concerns and commensurate incidental complexity. The most blatant example of this in APL is using arrays and tables for everything. Trees? Can be efficiently encoded as arrays. Hash tables? Same. Tuples? Just a pair of vectors. Etc. APL's syntax really shines in this instance, since data interaction patterns become short, pithy APL expressions instead of zoos of library functions. Using direct expressions makes specialization much easier, by simply ignoring irrelevant concerns. Anyway, APL aside, I'd really like to see our software engineering zeitgeist move more toward an optimistic refining our understanding of the human practice of software engineering and away from pessimistic and programming-centric problem avoidance. (The above really came out more treatisy than intended. Oh well.)
AdieuToLogic 2y ago
> In 2022 I started working on Freewheeling Apps. I started out with no tests, got frustrated at some point and wrote thorough tests for a core piece, the text editor. This is a primary motivation for having a reasonable test suite - limiting frustration. Test suites gives developers confidence to evolve a system. When done properly, contributors often form an opinion similar to: > But I struggled to find ways to test the rest, and also found I was getting by fine anyway. This is also a common situation. As functional complexity increases, the difficulty to test components or the system as a whole can become prohibitive. > Now it's 2024, and a month ago I deleted all my tests. ... In effect I stopped thinking about version control. Giving up tests and versions, I ended up with a much better program. This philosophy does not scale beyond one person and said person having recent, intimate, memory of all decisions encoded in source code (current or historical). Furthermore, given intimate implementation knowledge, verifying any change by definition must be performed manually.
- gavinhoward 2y ago
  > This philosophy does not scale beyond one person and said person having recent, intimate, memory of all decisions encoded in source code (current or historical). Furthermore, given intimate implementation knowledge, verifying any change by definition must be performed manually. As a one-man programming team, you are correct. And quite frankly, I shudder to think of not programming with a test suite or version control, even though I work alone! Docs, tests, and version control reduce what I have to remember about the code context. Yes, I have to remember the details of the code in front of me, but if I document it, test it, and check it in with a good commit message describing the why and how and whatever, then I can discard that code from my memory and move on to the next thing.
  - AdieuToLogic 2y ago
    All of the tools and artifacts you reference as important contribute to the same goal, whether it is for me or a future-you: Understanding.
- 082349872349872 2y ago
  > This philosophy does not scale beyond one person ... having recent, intimate, memory of all decisions encoded in source code Some time ago on HN, I ran across a tale of someone who never merged code unless they'd written it all that day. If they got to the end of the day without something mergeable, well, that just meant they didn't understand the problem well enough to express it in under a day, and they tried afresh the following morning. Anyone else remember this, or am I confusing sites/anecdotes again?
Jerry2 2y ago
I wish someone would share their programming workflow when using LLMs... I feel like I'm falling behind in this area.
- passion__desire 2y ago
  The important task for you, now that llms write code, is to know the theory very well and have list of things to try out. The good thing about coding is we have very fast and tight feedback loop. You should be in a position to cross-question llm responses and that is possible only when you know your stuff. https://x.com/jdnoc/status/1791145173524545874 https://x.com/jdnoc/status/1791145173524545874
shepherdjerred 2y ago
At first glance I thought the author was plain wrong, but I think there is some good insight here. This workflow works very well for the author. Most of us can probably think of a time when Git or automated tests frustrated us or made us less productive. There are similar solutions that are simpler and get out of the way, e.g. backing up code with Dropbox, FTP, whatever. The above is works well because the author is optimizing for their productivity on a passion project where they collaborate with few others. Automated tests are useful, but it sounds like the author likes creating programs so small that the value might not surface. I think that automated tests still have value even in this context, but I think we can all agree that automated tests slow you down (though many would argue that you see eventual returns). Version control and automated tests solve real problems. It would be insane to start a project without VC today, and automated tests are a best practice for a reason. But, for the authors particular use case, this sounds reasonable. --- Aside from the controversial bits around VC/tests, I think items 7/8/9 perfectly capture my mindset when writing/refactoring a large program. Write, throw it away, write again.
- fendy3002 2y ago
  Disagree on VC, even for solo project and no multiple version branching. Human make mistakes, knowing what you change in the last 3 weeks for >100k LOC project are godsend. It helps to find and fix issues. The better feature is branching out, because you can do what you want while still having a way to go back to previous stable. As for automated tests? That's fine.
  - yellowapple 2y ago
    I think it's still worth asking "which VC?" through that lens, though. Git was designed for developing the Linux kernel - with countless LOC and contributors and commits pouring in constantly. It happened to also be readily suitable for GitHub's model of "social" FOSS development, with its PRs and such (a model that most other Git hosting systems have adopted). ...but that ain't applicable to all projects, or possibly even most projects. The vast majority of my FOSS contributions have been on projects with one or maybe two primary authors, and without all that many PRs. What is Git, or any particular Git repository host (GitHub included), really offering me? I need to track changes (so I can revert them if necessary), I need to backup the code I'm writing, and I need to distribute said code (and possibly builds thereof). Just about any VCS can do those things. I ended up trying Fossil for various new projects, and I'm liking it enough that I plan on migrating my existing projects into Fossil repos (with Git mirroring) at some point, too. It's unsurprisingly more optimized toward the needs of the SQLite development team - a small cathedral rather than a Linux-style giant bazaar - and considering that all my projects' development "teams" are tiny cathedrals it ain't terribly surprising that Fossil would be the right fit.
irjustin 2y ago
I appreciate the honest answers by the OP. Even if we all think there's fundamental flaws with what was given up. For me, ChatGPT saved a lot of my mental load. I don't think about individual lines NEARLY as much. Obviously you need to understand what the program is doing and be smart about it, but you can really focus on business problems. It spits out something like 40% of my code and 70% of tests. I've started dropping whole files into it and tell it how to combine a new code.
miffy900 2y ago
> Giving up tests and versions, I ended up with a much better program. This is one of those sentences that is clearly an opinion but stated as if it were some undeniable, incontrovertibly true statement of fact. In your opinion, you have a better program - but give the code or repository to another dev or a group of devs and I'm sure you'll hear very different things...
- inimino 2y ago
  The person who wrote both the original and new versions isn't qualified to say one is better than the other?
  - cocok 2y ago
    I'm stealing this for all my future code reviews.
  - PeeMcGee 2y ago
    If they are the only user or developer, sure. Otherwise they are the least qualified to say it's better -- like how I'd be the least qualified to declare myself winner of a handsome contest.
ggm 2y ago
There is a class of problem where you know the goal, and code which produces the goal which you can test independently is demonstrably ok. Of course the next run with different parameters may well be wrong, but if they aren't on the goal-path you don't much have to worry. I do sometimes code in this pattern. I have high confidence in charts from Google and Akamai about some data I have exposure to (a variant of the inputs unique to my situation not in their hands) and when the curves I make conform in general trend to the ones they make over the time series, I am pretty sure I have this right. If the critique is in the fine differences I do some differential on it. If the critique is in the overall shape of the curve, if mine is like theirs, why do you think I am so wrong?
zombiwoof 2y ago
I worked with a guy who was so obsessed with testing he never even bothered to ask what the feature or problem the code was to solved He happily and condescendingly told every else how much they sucked because he had 1000% test coverage When he released he had tons of bugs because his code wasn’t going what it was supposed to His answer: yelling at product and tech leads for not being clear The rest of us had tests but spent as much time asking clarifying questions The guy above is one of the reasons I just lost all interest in software. This was a major FAANG company and his smooth talking continues today with management none the wiser because “he has the tests” Arby’s
- aulin 2y ago
  Our field is burdened by complexity. Some people cannot function properly without illuding themself they can tame it. So they cling to rules, best practices, tools hoping that adopting them to the letter will protect them from the uncertainties of our job. I've seen the opposite too, devs not only not writing any test, but not trying to run a single line of the code they wrote. Reason being I cannot test all the edge cases so I won't test it at all. QA will open a bug. And somehow getting praised by management for being faster than others to ship changes.
- qngcdvy 2y ago
  Seems to intersect with my experience. The best guys I've worked with had test...to some extend...especially in places that did some work you could easily get wrong by not thinking about a small edge case. Yet, none of them had or pursued 100% coverage as they were all clearly aware of that there is no actual benefit in that number, but that it can also mean harm by heavily slowing down dev speed and tying down your feature set because you're too lazy to always port some useless tests.
ein0p 2y ago
If you don’t have tests you don’t know if your shit works, and your team size can be at most 1. I even write broad coverage tests in my private repo to have a modicum of assurance that when I change things the remaining code still works.
- akkartik 2y ago
  1. It's only a modicum of assurance. 2. There are many ways to get a modicum of assurance. Types, tests, formal methods, cleanroom software engineering, NASA's IV&V, many others that I'm sure I'm forgetting. So there are many ways to "know if your shit works" and none of them support turning off one's brain entirely (for the part beyond the "modicum"). What I did here is to explore some of the other approaches that I have long neglected.
  - ein0p 2y ago
    You don’t know if your shit works just from “types”, and formal methods are not applicable to anything real. You’re arguing for the sake of argument, you know I’m right.
    - akkartik 2y ago
      I know nothing of the sort. I'll stop arguing now.
deleted 2y ago
[deleted]
andrewstuart 2y ago
If you are writing tests but have no users then you are wasting your time and money.
- AdieuToLogic 2y ago
  > If you are writing tests but have no users then you are wasting your time and money. If you have users but are not writing tests, then your users are your tests and you are wasting their time and money.
hiAndrewQuinn 2y ago
Just dropping by to say I adore this author and Mu is one of my favorite projects. A modern Lisp machine, kinda! In QEMU! So much fun!
- akkartik 2y ago
  Thank you so much, you made my day.
huijzer 2y ago
> Most software out there is incurably infected by incentives to serve lots of people in the short term. Great quote! You can even replace “software” with “businesses” and the quote still works.
arendtio 2y ago
My approach to programming in 2024 is a bit different: When I want to code a new module, I start by talking to an AI about the requirements and let the AI generate the tests and the code. Sadly, the AI isn't capable of generating working code for all scenarios, so eventually, I take over the code and finish/fix it. The workflow itself can be quite frustrating (who doesn't love fixing bugs in other people's code?), and the act of coding isn't as much fun as it used to be, but the AI also shows me new algorithms, which is a great way of learning new things. Let's just say I am looking forward to 2025 ;-)
deleted 2y ago
[deleted]
ramzez 2y ago
The author should really setup SSL on his website and make it secure to browse to begin with.
- akkartik 2y ago
  I do have SSL. It's just optional and it seems the submitter chose http.
- strken 2y ago
  Looks fine to me. TLS 1.3 with a cert from Let's Encrypt.
ashishb 2y ago
I love end to end tests even for personal projects https://ashishb.net/all/bad-and-good-ways-to-write-automated-tests/ https://ashishb.net/all/bad-and-good-ways-to-write-automated...
- deleted 2y ago
  [deleted]
- akkartik 2y ago
  Me too! https://github.com/akkartik/mu https://github.com/akkartik/mu https://github.com/akkartik/mu1 https://github.com/akkartik/mu1 https://akkartik.name/post/tracing-tests https://akkartik.name/post/tracing-tests
0x008 2y ago
this article must be written with the intention to troll HN
nickelpro 2y ago
Insanity-grade takes end-to-end, not a single word of this should be taken seriously
pmontra 2y ago
My favorite example for point number 3 "Small changes in context (people/places/features you want to support) often radically change how well a program fits its context." is K9 Mail, which is becoming the Android version of Thurderbird now. It started with an unconventional UI with a home page listing email accounts and for each account the number of unread and total messages. There was a unified inbox but it was not forced on users. I remember that I explicitly selected this app because it fit my needs: one personal account, one work account, several work accounts that my customers gave me. I wanted those account to stay separated. Probably a lot of K9 users picked that app precisely for the same reason because there were many complaints when the developer migrated to a conventional Android UI with a list of accounts sliding from the left and an extra tap to move from an account to another. If we had liked that kind of UI chances are that we won't have picked K9 to start with. So one small change (but probably a lot of coding) destroyed the fitness of the app to its users. I keep using the old 5.600 version, the latest with the old UI, and I sideload it to any new device I buy. Furthermore, to make things even more unusual, I only use POP3 to access my accounts (I preview on phone, delete stuff, possibly reply BCCing myself, eventually download on my laptop) and K9 fit perfectly that workflow. I don't need anything fancy. An app from the 90's would be good enough for me.
- akkartik 2y ago
  I really appreciate[1] the concrete example. Worth more than my opinion in OP and everybody's opinions in this thread put together. [1] https://news.ycombinator.com/favorites?id=akkartik&comments=t https://news.ycombinator.com/favorites?id=akkartik&comments=...
alentred 2y ago
We are all a bit overwhelmed by the complexity of the field of software engineering. Arguably sometimes accidental. But I don't agree that rejecting all the ideas we have come up with over the decades is a solution. On the other hand, not all solutions should be taken to the letter or used "too much". "Overwhelming" is by definition what happens when something is used "too much". By all means, please, write tests, use the VCS, use abstractions, but *know why you use them*, and when the "why" doesn't hold - reassess.
- akira2501 2y ago
  The only reason I started to _actually_ use git was magit. I wish there were command line level "porcelains" for everything. A standard '--help=ui' output and 'dialog' style interface and it could be automatic. It's not so much being overwhelmed by the complexity, it's just that there's a limit to the amount of active muscle memory I can utilize, and I have to make the cut somewhere.
- devjab 2y ago
  I think a major source of the problem is academia. I’m an external examiner for CS students in Denmark, and they are basically still taught the OOP and onion architecture way of building abstractions up front. Which is basically one of the worst mantras in software development. What is even worse is that they are taught these things to a religious degree. What is weird to me is that there is has been a lot of good progression in how professionals write software over the years. As you state, abstractions aren’t inherently bad for everything. I can’t imagine not having some sort of base class containing “updated”, “updated_by” and so on for classic data which ends up in a SQL db. But in general I’ll almost never write an abstraction unless I’m absolutely forced to do so. Yet in academia they are still teaching the exact same curriculum that I was taught 25 years ago. It’s so weird to sit there and grade their ability to build these wild abstractions in their fancy UML and then implement them in code. Knowing that like 90% of them are never going to see a single UML diagram ever again. At least if they work in my little area of the world. It is what it is though.
dumbassidiot 2y ago
[flagged]
codr7 2y ago
I too keep wondering where this path leads. One thing is clear to me though, creating (software) by yourself is a completely different activity from doing it in a team. About testing. Tests are means, not ends. What we're looking for is confidence I think. So when I feel confident about an implementation, I'll test less. And if I desperately need to make sure something keeps working, I'll add a few integration tests at the outer edges that are not so affected by refactorings and thus won't slow me down as much. E.g poking a web backend from the outside, as opposed to testing the internals. Unit tests are good for fleshing out the design of new API's, but those tests are pretty much useless once you know where you're going.
- sebstefan 2y ago
  Plus there's so many good reasons to have tests in a single person project * Hotwiring if statements with "true ||" to go straight to the feature you're building takes time, and you're gonna have to tear it down later. Just build a test and run it, that way you get to keep it for regression testing * If you're shipping something big, or slow, (which can just mean 'I use qt' sometimes) and launching the app/building the app takes ages, just make a test. A single test loads quicker and runs quicker * If you're debugging and reproducing the bug takes 45 seconds, just write a test. It automates away the most boring part of the job, keeps your flow going, allows you to check the status of the bug as often as you want without having to think about if it's worth it or not, and, same as #1, you get to keep the test for regression testing
- akkartik 2y ago
  I favorited your comment, thank you: https://news.ycombinator.com/favorites?id=akkartik&comments=t https://news.ycombinator.com/favorites?id=akkartik&comments=...
brokegrammer 2y ago
There are some interesting ideas in this article. Not using source control and removing tests resulting in a better program is quite fascinating. It's a shame that there are so many rude comments. It seems like there are many close minded folks lurking here, forgetting that experimentation is essential in tech.
- 082349872349872 2y ago
  It's also a shame that Kartik explicitly states his goals and his problem domain, yet folks react as if he'd been making comments about their goals and their problem domain.
- lnenad 2y ago
  > Not using source control and removing tests resulting in a better program is quite fascinating. Can you clarify what is exactly fascinating here? They seem to be writing simple programs, used only by themselves. In these scenarios of course you don't *have* to use good eng practices.
  - brokegrammer 2y ago
    I don't know because no studies have been done about the so called good engineering practices. If a big company with 10 teams of 20 engineers each blogs about how they're able to ship good code with testing or source control, I won't be any more fascinated that I am here because it sort of makes sense since no one can prove that source control or testing improves the end product.
  - akkartik 2y ago
    You seem to think of writing simple programs used only by myself (and people I have a relationship with, and people who want to have a relationship with me) as some sort of special situation that doesn't require "good engineering practices." I think of it as the most basic situation of all. The most foundational engineering practice of all: tailor interventions to the context.
richrichie 2y ago
> Building durably for lots of people is too hard, just don't even try. Be ruled by what you know well, who you know well and Dunbar's number. Wikipedia on Dubar: > A replication of Dunbar's analysis on updated complementary datasets using different comparative phylogenetic methods yielded wildly different numbers. Bayesian and generalized least-squares phylogenetic methods generated approximations of average group sizes between 69–109 and 16–42, respectively. However, enormous 95% confidence intervals (4–520 and 2–336, respectively) implied that specifying any one number is futile. https://en.m.wikipedia.org/wiki/Dunbar%27s_number https://en.m.wikipedia.org/wiki/Dunbar%27s_number
SethMurphy 2y ago
I have always found integration tests most important in order to test business logic when your customers pay for your trust and especially when they rely on your code for revenue while interacting with a third party. However, they should be thrown away immediately after proving your coded logic matches business requirements as they are slow and lose value and become tech debt quickly. Unit tests, if needed, should be even more temporary in my opinion. Often a CLI can be sufficient as a "unit test" during the development process.
- djeastm 2y ago
  >However, they should be thrown away immediately after proving your coded logic matches business requirements as they are slow and lose value and become tech debt quickly. Can you expand on why integration tests should be thrown away once validated? Isn't the idea that when you make a change later, these tests will ensure you haven't introduced a regression?
  - SethMurphy 2y ago
    Integration tests can be very resource intensive. In larger projects the time it takes to run and set these up these is often daunting. Yes, the idea is regression of business logic in practice, but in reality I have found it leads to test resentment (and writers of those tests) and smaller or no test being written instead. Additionally the regressions added are often to the test suite itself and not the actual application.
mattlondon 2y ago
I have noticed a few articles recently on HN that talks about dropping tests because they are too slow or holding them back or just extra cognitive load. This kinda beggars belief for me. I wonder who these people are - do they have the "battle scars" from working on complex or big systems? Are they reasonably junior or new to the profession with less than 10 years experience? Next up? Fuck structural engineers, it's just going to slow us down building this bridge... If you are doing something for fun, sure do whatever you want. I write zero tests for my own pet projects. But please in professional environments please don't ignore hard-won lessons in reliability and engineering-velocity because you don't want to have to do the extra work to update your tests. Your customers and colleagues (potentially years in the future) will thank you.
- septimus111 2y ago
  There is adverse selection at play. The top/world-class programmers are too busy to write blogs.
- beezlebroxxxxxx 2y ago
  Tech is a relatively immature industry. And a lot of time and effort and money in it is devoted to non-critical products. I'm not directing this at the OP, because they have actually thought about it even if I disagree with them, but there are a lot of people working in tech and in software who do not care about product quality at all. They're paid a lot of money and exclusively focus on shipping ASAP, quality be damned, so they keep their metrics looking good and the $$$ flowing. Add in the industries tendency for very short term tenure at jobs and you end up in a situation where people think what they're doing is "optimal" simply because it keeps them getting $$$ --- product quality is just secondary. Their "craftsmanship" is their job-hopping. (I don't have a problem with job-hopping if the products and code are still good --- they usually aren't.) They usually don't need to care about a bridge lasting 6 decades, but then they're writing critical software for infrastructure or airplanes and, unfortunately, they can actively resist a lot of the hard learned lessons people had to make in those industries because they just want to move fast (and leave after ~2 years). The culture isn't there yet.
- akkartik 2y ago
hellectronic 2y ago
IMHO there are tests and there are tests. I had to work with codebases that had awful tests. They broke frequently because they were badly written. They used a lot of mocking when mocking was not appropriate. This tests were written for the purpose to have tests not for the purpose to really test the domain. I do not write tests for simple cases, like method in class A just delegates to method in class B. For a one man show - go on do not write tests, especially if you do not know where you will end up with the software. But in teams I find a lot of value in (good written) tests, preventing bugs and documenting bugs. Sure you can over-engineer it, as everything else too. BUT working without version control? Good that it works for you. I think version control is one of the MUST USE tools.
deleted 2y ago
[deleted]
_gabe_ 2y ago
I can sympathize with the authors love/hate relationship with tests, but I can’t help feeling like it’s because we as developers so often test the completely wrong things. I don’t typically write tests, but they do make sense for a few cases (specifically end to end tests that look for well defined outputs from well defined inputs). I was inspired by Andreas Kling’s method of testing Ladybird, where he would find visual bugs, recreate the bug in a minimum reproducible example, fix the bug, then codify the example into a test and make sure the regression was captured in his test suite[0]. This led to a seemingly large suite of tests that enabled him to continue modifying the browser without fear of regressing somewhere. I used this method of testing while I was writing a code highlighter that used TextMate grammars. Since TextMate grammars have a well defined output for some input of code + grammar, I was able to mimic that output in my own code highlighter and then compare it to TextMate’s output for testing purposes. I wrote a bunch of general purpose tests, then ran into a bunch of bugs where I would have mismatched output. As I fixed those bugs, I would add the examples to my test suite. Anyways, my code highlighter was slow, and I wanted to re-architect it to speed it up. I was able to completely change the way it worked with complete confidence. I had broken tests for a while in the middle of the refactor, but eventually I finished the refactor. As I started to fix the broken tests, there was a domino effect. I only had to fix a few tests and that ended up automatically correcting the rest. Now, I have a fast code highlighter and confidence that it’s at least bug for bug parity with the slow version :) [0]: https://youtu.be/W4SxKWwFhA0?si=PJs_7drb3zVxq0ub https://youtu.be/W4SxKWwFhA0?si=PJs_7drb3zVxq0ub
GTP 2y ago
I don't agree with point 3: "Small changes in context (people/places/features you want to support) often radically change how well a program fits its context. Our dominant milieu of short-termism doesn't prepare us for this fact." My opinion here is that short-termism is precisely a consequence of the hardness of predicting/keeping up with these small changes: businesses prefer to be able to adapt quickly to new scenarios rather than risking being stuck in the wrong direction.
slowmovintarget 2y ago
Can I just say... I love the return of the term "programming," "to program," and "programmer." "Coder" and "coding" was popular for a while, and before Steve Balmer put his stamp on it, "developers" and "development." But when I started, before 32-bit Windows was a thing, I was a programmer. If the Primeagen has helped popularize the term again, great, thank you.
- akkartik 2y ago
  I've always been a programmer. Because it was good enough for Dijkstra.
  - slowmovintarget 2y ago
    I like that take, and wholeheartedly agree.
skybrian 2y ago
> Small changes in context (people/places/features you want to support) often radically change how well a program fits its context. Our dominant milieu of short-termism doesn't prepare us for this fact. I'm wondering what would work better? Writing a small program from scratch, using a rich ecosystem of libraries, seems like one way to go. AI help makes that easier. Another approach, more common with popular apps that have more to lose, is to evolve in place.

317 points by surprisetalk 2y ago

> Types, abstractions, tests, versions, state machines, immutability, formal analysis, all these are tools available to us in unfamiliar terrain. Use them to taste. How did people program in Lisp for decades? I like types and such, and have even gone so far as to write Python like it's Rust. But in the end I realized dynamic languages have an appeal for a reason, and by using types all over the place, I was not getting the benefits of a dynamic language like Python. When context is mostly static, dynamic languages shine. Context could be, for example, the structure of the directory. If I want to read a file and I know that the file exists, throwing a bunch of type checks about file reading operation is just overkill and slows down the development.

BigJono 2y ago
The very next dot point is agreeing with you: "The ideal quantity to use these tools is tiny, much more miniscule than any of us is trained to think". And I agree tbh. The TS community has turned me off static typing for life. It's just wall to wall bikeshedding from the least productive people I've ever had the displeasure of working with.
- trustinmenowpls 2y ago
  Honestly, that explains perfectly why all MS apps have gone from useable if a bit slow or buggy to just unusable buggy messes that crash constantly and make my machine feel like its running on molasses.
  - nl 2y ago
    It doesn't "explain" it at all (and indeed many of reject the idea that MS apps - in general - are worse. They've had a bad reputation for decades, and that isn't based on nothing).
    - behnamoh 2y ago
      Teams + the entire Office suite are two examples of Microsoft products going downhill over time.
      - miffy900 2y ago
        That's true but that has absolutely nothing to do with types in programming languages; it has more to do with MS's culture of always favouring backward compatibility and never culling any features in every version.
        behnamoh 2y ago
        > it has more to do with MS's culture of always favouring backward compatibility and never culling any features in every version. The new Office suite are unbelievably buggy and slow not because of backward compatibility, but because of numerous useless "features" Microsoft added which made the software essentially bloatware. By the time Excel opens up on my Mac, I can open several Google Sheets and start working.
      - nl 2y ago
        Has Teams ever been good? From the first time I used it it has always been one of the worst pieces of software I use. Office seems fine to me - not great software, but I haven't noticed any particular decline (not a heavy user, but have been using it since Word v2 in the 1990s) And in any case what does this have to do with Typescript and the (over?) use of types?
    - trustinmenowpls 2y ago
      The actual quality of their apps has significantly degraded over time. Many of their apps which use web-native technologies have become nearly unusable, and I strongly suspect it's exactly because they've gone down this insane road of bike shedding and constant re-inventing of the wheel instead of pursuing excellence.
seer 2y ago
Hmm, rarely have I thought types were a burden, rather than help, maybe I’m weird. Maybe I spend effort in making sure my types are useful and easy to work with, but one previous TypeScript I got to a state where _all_ of my database queries were automatically typed, and all of my requests and responses too, so both input output were guaranteed to be correct bg the compiler, so any bugs or errors that were left were business logic. It was incredibly liberating - like pairing with someone who was junior but very pedantic. I ended up writing almost no unit test and only having integration level tests, cause the job of those test was mostly covered by types. And writing the code itself was such a pleasure - you get immediate feedback if your program is correct _as you type it_. The most bizarre consequence of all this to me was writing a program for almost 2 hours, hundreds of lines of code, and then executing it and having it do exactly what you wanted on the first compile. That was both scary but exciting! One can get over-constrained with types for sure, where you’re sending more time “fighting the types” rather than writing your code. But this is all just learning, once you understand how the typesystem works it all becomes easy to work with. It was the same story with tests - once I started testing everything- it wasn’t easy to adopt my code to be testable, took effort, but then I learned how to make code pure, move state to the edges, manage dependencies etc, and all of those are useful practices in their own right, regardless if you write the tests or not. Same with types - schema design and invariants, state machines, edge cases in type conversion and how to lock and manage external dependencies. Sets, unions etc - it became the way I reason about code with of without types and my code is better for it. I also assume that types would make AI generated code much better _and more reliable_ because of the additional information and structure that it provides, so I recon they are here ti stay.
- fendy3002 2y ago
  have you worked with java or C#? both are where types sometimes become a burden. No, you cannot just do something like this: ``` return { data, message: "OK" }; ``` you need to declare a class or struct that match the definition. There's mapper and builder everywhere. Adding / deleting 1 column from a datatype can force you to make changes in 5 places due to mapper / builder.
  - 2y ago
tmtvl 2y ago
I quite like Lisp 'cause I can do silly things like: (defun sum-triplet? (list) (declare (type List list)) (and (= (length list) 3) (destructuring-bind (a b c) list (and (numberp a) (numberp b) (numberp c) (= (+ a b) c))))) (deftype Sum-Triplet () '(and List (satisfies sum-triplet?)))

curry798 2y ago

Is it recommended to learn shell if you are a beginner?

leptons 2y ago
What you should learn, is knowing when shell is the right tool for the job.
- curry798 2y ago
  It dawned on me, thank you.
fragmede 2y ago
I won't comment on which shell to learn, but you'll end up spending a lot of time in it, so learning your chosen shell well will pay off dividends for the rest of your life.
seer 2y ago
There was a saying that technology usually has inertia, if it was used for 30 years, and is used actively now, it will probably still be in use 30 years in the future. I learned vim by necessity after shying away from this weird old tech for years, when I was forced to work on a solaris server where there was no other way to edit the code at all. It was pain and suffering for a few hours - we really wanted to fix something that day as I was working on a machine that we were “not allowed to ssh into” been driven to a different city in order to sit in front of it. But after that day I’ve been using vim almost every day. It is not my daily driver, always felt more productive in TextMate, SublimeText and now VS Code, but it is still incredibly useful. Any remote server I ssh into there is no question what I can or cannot do - can easily edit everything I want to. And I use it for various quick edit tasks in the shell. Now learning shells wasn’t so dramatic for me but same rules apply, I don’t feel uncomfortable anywhere - that pod that is misbehaving in your cluster - well just ssh into it and poke around! You need to tie a few commands together as there isn’t something that does _exactly_ what your company needs - just whip up a quick bash script! - zero dependencies and can be deployed anywhere - your mac, the server the ci is running on, even windows machines! So general rule is - if it was used for 50 years and is used now, it is probably worth learning.

munchler 2y ago

> Giving up tests and versions, I ended up with a much better program. I can’t understand how anyone would willingly program without using source code control in 2024. Even on a single-person project, the ability to work on multiple machines, view history, rollback, branch, etc. is extremely valuable, and costs almost nothing. Maybe I’m misunderstanding what the author means by “versions”?

shepherdjerred 2y ago
Yeah, this is not good advice for the average person, even for solo projects.
- codr7 2y ago
  I agree, and the author probably does as well. I didn't get the feeling it was meant as general advice.
shermanyo 2y ago
I think in this case, the author means coding version logic into the app itself. eg. versioned API endpoints for backwards compatibility
- layer8 2y ago
  This is about a desktop text editor built with LUA on a C++-based native framework for writing 2D games: https://git.sr.ht/~akkartik/lines2.love https://git.sr.ht/~akkartik/lines2.love Very unlikely to have versioned API endpoints involved.
- shepherdjerred 2y ago
  I don't think so: > Back in 2015 I was suspicious of abstractions and big on tests and version control. Code seemed awash in bad abstractions, while tests and versions seemed like the key advances of the 2000s. > In effect I stopped thinking about version control. Giving up tests and versions, I ended up with a much better program. > Version control kept me attached to the past. Both were counter-productive. It took a major reorientation to let go of them.

shove 2y ago

I’m really curious whether my agree:disagree ratio will be higher in the article or in the comments.

aetherspawn 2y ago

When you have no tests your problems go away because you don’t see any test failures. Never have I tested anything and NOT found a bug, and most things I tested I thought were already OK to ship. Thus, when you delete your tests, the only person you are fooling is probably yourself :( From reading your page I get the impression you are more burnt out from variation/configuration management which is completely relatable… I am too. This is a hard problem. But user volume is required to make $$. If the problem was easy then the market would be saturated with one size fits all solutions for everything.

akkartik 2y ago
> When you have no tests your problems go away because you don’t see any test failures. The flip side of this is the quote that "tests can show the presence of bugs, but never their absence". It better fits my experience here; every few months I'd find a new bug and diligently write a test for it. But then there was a new bug in a few months, discovered by someone in the first 10 minutes of using it. I'm sure I have bugs to discover in the new version. But the data structures I chose make many of the old tests obsolete by construction. So I'm hopeful that I'm a few bugs away from something fairly stable at least for idle use. Tests are definitely invaluable for a large team constantly making changes to a codebase. But here I'm trying to build something with a frozen feature set.
- monkpit 2y ago
  If your tests break or go away when your implementation changes, aren’t those bad tests by definition?
  - akkartik 2y ago
    I have two answers: 1. Yes. To the same extent that we are all bad people by definition, made of base material and unworthy urges. I'd love to have better programmers show me how I can make my tests better. The code is out there. 2. Even if I have good tests "by definition", a radical rewrite might make old tests look like "assert(2x1 == 2), assert (2x2 == 4)". Tests exist in a context, and radically changing the context can change the tests you need. --- This is not in OP, but I do also have a problem of brittle tests in my editor. In this case I need to test a word-wrapping algorithm. This depends intimately on pixel-precise details of the font. I'd love for better programmers than me to suggest how I can write tests that are robust and also self-evidently correct without magic constants that don't communicate anything to the reader. "Failure: 'x' started at x=67 rather than x=68." Reader's thought: "Why is this a problem?" etc. Comments appreciated on https://git.sr.ht/~akkartik/lines.love/tree/main/item/text_tests.lua https://git.sr.ht/~akkartik/lines.love/tree/main/item/text_t.... The summary at https://git.sr.ht/~akkartik/lines.love/tree/main/item/text_tests https://git.sr.ht/~akkartik/lines.love/tree/main/item/text_t... might help orient readers.

layer8 2y ago

This is quite a confused article. I really wonder what about it made it be upvoted to first place.

rectang 2y ago
I keep trying to figure out the joke.
- namaria 2y ago
  Author successfully drove engagement with psychological baits like bashing commonly accepted tools and practices and being intentionally obscure so a lot of people would comment about it.
  - codr7 2y ago
    Or, author has so much more experience than you, that his conclusions can't possibly make sense in your world. Not saying that's the case, but it's certainly possible. The more wisdom, the less need for rules and conventions. That being said, I do feel like we have to learn to communicate over these boundaries if we want to evolve faster, as opposed to mostly repeating the same mistakes over and over.
    - namaria 2y ago
      Yeah I am sure author has transcended such pedestrian things as versioning and testing code.
      - codr7 2y ago
        No one has claimed that. It was simply suggested that in some situations, maybe they're not as important as we tend to assume. And it takes experience to see those patterns.
        deleted 2y ago
        [deleted]

xelxebar 2y ago

Data-orientation, abstraction avoidance, holistic rewrites. The values espoused by OP rhyme heavily with the stance I've begun to take after reading and writing significant amounts of APL. The best code I've seen mercilessly elides anything that doesn't serve an architectural level, problem domain-relevant concern. GADTs and hash tables, and all our nice CS tools work much better when applied as cognitive tools in a domain-specific manner as opposed to reified language syntax or library APIs, as the latter necessarily introduces cross-domain concerns and commensurate incidental complexity. The most blatant example of this in APL is using arrays and tables for everything. Trees? Can be efficiently encoded as arrays. Hash tables? Same. Tuples? Just a pair of vectors. Etc. APL's syntax really shines in this instance, since data interaction patterns become short, pithy APL expressions instead of zoos of library functions. Using direct expressions makes specialization much easier, by simply ignoring irrelevant concerns. Anyway, APL aside, I'd really like to see our software engineering zeitgeist move more toward an optimistic refining our understanding of the human practice of software engineering and away from pessimistic and programming-centric problem avoidance. (The above really came out more treatisy than intended. Oh well.)

AdieuToLogic 2y ago

> In 2022 I started working on Freewheeling Apps. I started out with no tests, got frustrated at some point and wrote thorough tests for a core piece, the text editor. This is a primary motivation for having a reasonable test suite - limiting frustration. Test suites gives developers confidence to evolve a system. When done properly, contributors often form an opinion similar to: > But I struggled to find ways to test the rest, and also found I was getting by fine anyway. This is also a common situation. As functional complexity increases, the difficulty to test components or the system as a whole can become prohibitive. > Now it's 2024, and a month ago I deleted all my tests. ... In effect I stopped thinking about version control. Giving up tests and versions, I ended up with a much better program. This philosophy does not scale beyond one person and said person having recent, intimate, memory of all decisions encoded in source code (current or historical). Furthermore, given intimate implementation knowledge, verifying any change by definition must be performed manually.

gavinhoward 2y ago
> This philosophy does not scale beyond one person and said person having recent, intimate, memory of all decisions encoded in source code (current or historical). Furthermore, given intimate implementation knowledge, verifying any change by definition must be performed manually. As a one-man programming team, you are correct. And quite frankly, I shudder to think of not programming with a test suite or version control, even though I work alone! Docs, tests, and version control reduce what I have to remember about the code context. Yes, I have to remember the details of the code in front of me, but if I document it, test it, and check it in with a good commit message describing the why and how and whatever, then I can discard that code from my memory and move on to the next thing.
- AdieuToLogic 2y ago
  All of the tools and artifacts you reference as important contribute to the same goal, whether it is for me or a future-you: Understanding.
082349872349872 2y ago
> This philosophy does not scale beyond one person ... having recent, intimate, memory of all decisions encoded in source code Some time ago on HN, I ran across a tale of someone who never merged code unless they'd written it all that day. If they got to the end of the day without something mergeable, well, that just meant they didn't understand the problem well enough to express it in under a day, and they tried afresh the following morning. Anyone else remember this, or am I confusing sites/anecdotes again?

Jerry2 2y ago

I wish someone would share their programming workflow when using LLMs... I feel like I'm falling behind in this area.

passion__desire 2y ago
The important task for you, now that llms write code, is to know the theory very well and have list of things to try out. The good thing about coding is we have very fast and tight feedback loop. You should be in a position to cross-question llm responses and that is possible only when you know your stuff. https://x.com/jdnoc/status/1791145173524545874 https://x.com/jdnoc/status/1791145173524545874

shepherdjerred 2y ago

At first glance I thought the author was plain wrong, but I think there is some good insight here. This workflow works very well for the author. Most of us can probably think of a time when Git or automated tests frustrated us or made us less productive. There are similar solutions that are simpler and get out of the way, e.g. backing up code with Dropbox, FTP, whatever. The above is works well because the author is optimizing for their productivity on a passion project where they collaborate with few others. Automated tests are useful, but it sounds like the author likes creating programs so small that the value might not surface. I think that automated tests still have value even in this context, but I think we can all agree that automated tests slow you down (though many would argue that you see eventual returns). Version control and automated tests solve real problems. It would be insane to start a project without VC today, and automated tests are a best practice for a reason. But, for the authors particular use case, this sounds reasonable. --- Aside from the controversial bits around VC/tests, I think items 7/8/9 perfectly capture my mindset when writing/refactoring a large program. Write, throw it away, write again.

fendy3002 2y ago
Disagree on VC, even for solo project and no multiple version branching. Human make mistakes, knowing what you change in the last 3 weeks for >100k LOC project are godsend. It helps to find and fix issues. The better feature is branching out, because you can do what you want while still having a way to go back to previous stable. As for automated tests? That's fine.
- yellowapple 2y ago
  I think it's still worth asking "which VC?" through that lens, though. Git was designed for developing the Linux kernel - with countless LOC and contributors and commits pouring in constantly. It happened to also be readily suitable for GitHub's model of "social" FOSS development, with its PRs and such (a model that most other Git hosting systems have adopted). ...but that ain't applicable to all projects, or possibly even most projects. The vast majority of my FOSS contributions have been on projects with one or maybe two primary authors, and without all that many PRs. What is Git, or any particular Git repository host (GitHub included), really offering me? I need to track changes (so I can revert them if necessary), I need to backup the code I'm writing, and I need to distribute said code (and possibly builds thereof). Just about any VCS can do those things. I ended up trying Fossil for various new projects, and I'm liking it enough that I plan on migrating my existing projects into Fossil repos (with Git mirroring) at some point, too. It's unsurprisingly more optimized toward the needs of the SQLite development team - a small cathedral rather than a Linux-style giant bazaar - and considering that all my projects' development "teams" are tiny cathedrals it ain't terribly surprising that Fossil would be the right fit.

irjustin 2y ago

I appreciate the honest answers by the OP. Even if we all think there's fundamental flaws with what was given up. For me, ChatGPT saved a lot of my mental load. I don't think about individual lines NEARLY as much. Obviously you need to understand what the program is doing and be smart about it, but you can really focus on business problems. It spits out something like 40% of my code and 70% of tests. I've started dropping whole files into it and tell it how to combine a new code.

miffy900 2y ago

> Giving up tests and versions, I ended up with a much better program. This is one of those sentences that is clearly an opinion but stated as if it were some undeniable, incontrovertibly true statement of fact. In your opinion, you have a better program - but give the code or repository to another dev or a group of devs and I'm sure you'll hear very different things...

inimino 2y ago
The person who wrote both the original and new versions isn't qualified to say one is better than the other?
- cocok 2y ago
  I'm stealing this for all my future code reviews.
- PeeMcGee 2y ago
  If they are the only user or developer, sure. Otherwise they are the least qualified to say it's better -- like how I'd be the least qualified to declare myself winner of a handsome contest.

ggm 2y ago

There is a class of problem where you know the goal, and code which produces the goal which you can test independently is demonstrably ok. Of course the next run with different parameters may well be wrong, but if they aren't on the goal-path you don't much have to worry. I do sometimes code in this pattern. I have high confidence in charts from Google and Akamai about some data I have exposure to (a variant of the inputs unique to my situation not in their hands) and when the curves I make conform in general trend to the ones they make over the time series, I am pretty sure I have this right. If the critique is in the fine differences I do some differential on it. If the critique is in the overall shape of the curve, if mine is like theirs, why do you think I am so wrong?

zombiwoof 2y ago

I worked with a guy who was so obsessed with testing he never even bothered to ask what the feature or problem the code was to solved He happily and condescendingly told every else how much they sucked because he had 1000% test coverage When he released he had tons of bugs because his code wasn’t going what it was supposed to His answer: yelling at product and tech leads for not being clear The rest of us had tests but spent as much time asking clarifying questions The guy above is one of the reasons I just lost all interest in software. This was a major FAANG company and his smooth talking continues today with management none the wiser because “he has the tests” Arby’s

aulin 2y ago
Our field is burdened by complexity. Some people cannot function properly without illuding themself they can tame it. So they cling to rules, best practices, tools hoping that adopting them to the letter will protect them from the uncertainties of our job. I've seen the opposite too, devs not only not writing any test, but not trying to run a single line of the code they wrote. Reason being I cannot test all the edge cases so I won't test it at all. QA will open a bug. And somehow getting praised by management for being faster than others to ship changes.
qngcdvy 2y ago
Seems to intersect with my experience. The best guys I've worked with had test...to some extend...especially in places that did some work you could easily get wrong by not thinking about a small edge case. Yet, none of them had or pursued 100% coverage as they were all clearly aware of that there is no actual benefit in that number, but that it can also mean harm by heavily slowing down dev speed and tying down your feature set because you're too lazy to always port some useless tests.

ein0p 2y ago

If you don’t have tests you don’t know if your shit works, and your team size can be at most 1. I even write broad coverage tests in my private repo to have a modicum of assurance that when I change things the remaining code still works.

akkartik 2y ago
1. It's only a modicum of assurance. 2. There are many ways to get a modicum of assurance. Types, tests, formal methods, cleanroom software engineering, NASA's IV&V, many others that I'm sure I'm forgetting. So there are many ways to "know if your shit works" and none of them support turning off one's brain entirely (for the part beyond the "modicum"). What I did here is to explore some of the other approaches that I have long neglected.
- ein0p 2y ago
  You don’t know if your shit works just from “types”, and formal methods are not applicable to anything real. You’re arguing for the sake of argument, you know I’m right.
  - akkartik 2y ago
    I know nothing of the sort. I'll stop arguing now.

deleted 2y ago

[deleted]

andrewstuart 2y ago

If you are writing tests but have no users then you are wasting your time and money.

AdieuToLogic 2y ago
> If you are writing tests but have no users then you are wasting your time and money. If you have users but are not writing tests, then your users are your tests and you are wasting their time and money.

hiAndrewQuinn 2y ago

Just dropping by to say I adore this author and Mu is one of my favorite projects. A modern Lisp machine, kinda! In QEMU! So much fun!

akkartik 2y ago
Thank you so much, you made my day.

huijzer 2y ago

> Most software out there is incurably infected by incentives to serve lots of people in the short term. Great quote! You can even replace “software” with “businesses” and the quote still works.

arendtio 2y ago

My approach to programming in 2024 is a bit different: When I want to code a new module, I start by talking to an AI about the requirements and let the AI generate the tests and the code. Sadly, the AI isn't capable of generating working code for all scenarios, so eventually, I take over the code and finish/fix it. The workflow itself can be quite frustrating (who doesn't love fixing bugs in other people's code?), and the act of coding isn't as much fun as it used to be, but the AI also shows me new algorithms, which is a great way of learning new things. Let's just say I am looking forward to 2025 ;-)

deleted 2y ago

[deleted]

ramzez 2y ago

The author should really setup SSL on his website and make it secure to browse to begin with.

akkartik 2y ago
I do have SSL. It's just optional and it seems the submitter chose http.
strken 2y ago
Looks fine to me. TLS 1.3 with a cert from Let's Encrypt.

ashishb 2y ago

I love end to end tests even for personal projects https://ashishb.net/all/bad-and-good-ways-to-write-automated-tests/ https://ashishb.net/all/bad-and-good-ways-to-write-automated...

deleted 2y ago
[deleted]
akkartik 2y ago
Me too! https://github.com/akkartik/mu https://github.com/akkartik/mu https://github.com/akkartik/mu1 https://github.com/akkartik/mu1 https://akkartik.name/post/tracing-tests https://akkartik.name/post/tracing-tests

0x008 2y ago

this article must be written with the intention to troll HN

nickelpro 2y ago

Insanity-grade takes end-to-end, not a single word of this should be taken seriously

pmontra 2y ago

My favorite example for point number 3 "Small changes in context (people/places/features you want to support) often radically change how well a program fits its context." is K9 Mail, which is becoming the Android version of Thurderbird now. It started with an unconventional UI with a home page listing email accounts and for each account the number of unread and total messages. There was a unified inbox but it was not forced on users. I remember that I explicitly selected this app because it fit my needs: one personal account, one work account, several work accounts that my customers gave me. I wanted those account to stay separated. Probably a lot of K9 users picked that app precisely for the same reason because there were many complaints when the developer migrated to a conventional Android UI with a list of accounts sliding from the left and an extra tap to move from an account to another. If we had liked that kind of UI chances are that we won't have picked K9 to start with. So one small change (but probably a lot of coding) destroyed the fitness of the app to its users. I keep using the old 5.600 version, the latest with the old UI, and I sideload it to any new device I buy. Furthermore, to make things even more unusual, I only use POP3 to access my accounts (I preview on phone, delete stuff, possibly reply BCCing myself, eventually download on my laptop) and K9 fit perfectly that workflow. I don't need anything fancy. An app from the 90's would be good enough for me.

akkartik 2y ago
I really appreciate[1] the concrete example. Worth more than my opinion in OP and everybody's opinions in this thread put together. [1] https://news.ycombinator.com/favorites?id=akkartik&comments=t https://news.ycombinator.com/favorites?id=akkartik&comments=...

alentred 2y ago

We are all a bit overwhelmed by the complexity of the field of software engineering. Arguably sometimes accidental. But I don't agree that rejecting all the ideas we have come up with over the decades is a solution. On the other hand, not all solutions should be taken to the letter or used "too much". "Overwhelming" is by definition what happens when something is used "too much". By all means, please, write tests, use the VCS, use abstractions, but *know why you use them*, and when the "why" doesn't hold - reassess.

akira2501 2y ago
The only reason I started to _actually_ use git was magit. I wish there were command line level "porcelains" for everything. A standard '--help=ui' output and 'dialog' style interface and it could be automatic. It's not so much being overwhelmed by the complexity, it's just that there's a limit to the amount of active muscle memory I can utilize, and I have to make the cut somewhere.
devjab 2y ago
I think a major source of the problem is academia. I’m an external examiner for CS students in Denmark, and they are basically still taught the OOP and onion architecture way of building abstractions up front. Which is basically one of the worst mantras in software development. What is even worse is that they are taught these things to a religious degree. What is weird to me is that there is has been a lot of good progression in how professionals write software over the years. As you state, abstractions aren’t inherently bad for everything. I can’t imagine not having some sort of base class containing “updated”, “updated_by” and so on for classic data which ends up in a SQL db. But in general I’ll almost never write an abstraction unless I’m absolutely forced to do so. Yet in academia they are still teaching the exact same curriculum that I was taught 25 years ago. It’s so weird to sit there and grade their ability to build these wild abstractions in their fancy UML and then implement them in code. Knowing that like 90% of them are never going to see a single UML diagram ever again. At least if they work in my little area of the world. It is what it is though.

dumbassidiot 2y ago

[flagged]

codr7 2y ago

I too keep wondering where this path leads. One thing is clear to me though, creating (software) by yourself is a completely different activity from doing it in a team. About testing. Tests are means, not ends. What we're looking for is confidence I think. So when I feel confident about an implementation, I'll test less. And if I desperately need to make sure something keeps working, I'll add a few integration tests at the outer edges that are not so affected by refactorings and thus won't slow me down as much. E.g poking a web backend from the outside, as opposed to testing the internals. Unit tests are good for fleshing out the design of new API's, but those tests are pretty much useless once you know where you're going.

sebstefan 2y ago
Plus there's so many good reasons to have tests in a single person project * Hotwiring if statements with "true ||" to go straight to the feature you're building takes time, and you're gonna have to tear it down later. Just build a test and run it, that way you get to keep it for regression testing * If you're shipping something big, or slow, (which can just mean 'I use qt' sometimes) and launching the app/building the app takes ages, just make a test. A single test loads quicker and runs quicker * If you're debugging and reproducing the bug takes 45 seconds, just write a test. It automates away the most boring part of the job, keeps your flow going, allows you to check the status of the bug as often as you want without having to think about if it's worth it or not, and, same as #1, you get to keep the test for regression testing
akkartik 2y ago
I favorited your comment, thank you: https://news.ycombinator.com/favorites?id=akkartik&comments=t https://news.ycombinator.com/favorites?id=akkartik&comments=...

brokegrammer 2y ago

There are some interesting ideas in this article. Not using source control and removing tests resulting in a better program is quite fascinating. It's a shame that there are so many rude comments. It seems like there are many close minded folks lurking here, forgetting that experimentation is essential in tech.

082349872349872 2y ago
It's also a shame that Kartik explicitly states his goals and his problem domain, yet folks react as if he'd been making comments about their goals and their problem domain.
lnenad 2y ago
> Not using source control and removing tests resulting in a better program is quite fascinating. Can you clarify what is exactly fascinating here? They seem to be writing simple programs, used only by themselves. In these scenarios of course you don't *have* to use good eng practices.
- brokegrammer 2y ago
  I don't know because no studies have been done about the so called good engineering practices. If a big company with 10 teams of 20 engineers each blogs about how they're able to ship good code with testing or source control, I won't be any more fascinated that I am here because it sort of makes sense since no one can prove that source control or testing improves the end product.
- akkartik 2y ago
  You seem to think of writing simple programs used only by myself (and people I have a relationship with, and people who want to have a relationship with me) as some sort of special situation that doesn't require "good engineering practices." I think of it as the most basic situation of all. The most foundational engineering practice of all: tailor interventions to the context.

richrichie 2y ago

> Building durably for lots of people is too hard, just don't even try. Be ruled by what you know well, who you know well and Dunbar's number. Wikipedia on Dubar: > A replication of Dunbar's analysis on updated complementary datasets using different comparative phylogenetic methods yielded wildly different numbers. Bayesian and generalized least-squares phylogenetic methods generated approximations of average group sizes between 69–109 and 16–42, respectively. However, enormous 95% confidence intervals (4–520 and 2–336, respectively) implied that specifying any one number is futile. https://en.m.wikipedia.org/wiki/Dunbar%27s_number https://en.m.wikipedia.org/wiki/Dunbar%27s_number

SethMurphy 2y ago

I have always found integration tests most important in order to test business logic when your customers pay for your trust and especially when they rely on your code for revenue while interacting with a third party. However, they should be thrown away immediately after proving your coded logic matches business requirements as they are slow and lose value and become tech debt quickly. Unit tests, if needed, should be even more temporary in my opinion. Often a CLI can be sufficient as a "unit test" during the development process.

djeastm 2y ago
>However, they should be thrown away immediately after proving your coded logic matches business requirements as they are slow and lose value and become tech debt quickly. Can you expand on why integration tests should be thrown away once validated? Isn't the idea that when you make a change later, these tests will ensure you haven't introduced a regression?
- SethMurphy 2y ago
  Integration tests can be very resource intensive. In larger projects the time it takes to run and set these up these is often daunting. Yes, the idea is regression of business logic in practice, but in reality I have found it leads to test resentment (and writers of those tests) and smaller or no test being written instead. Additionally the regressions added are often to the test suite itself and not the actual application.

mattlondon 2y ago

I have noticed a few articles recently on HN that talks about dropping tests because they are too slow or holding them back or just extra cognitive load. This kinda beggars belief for me. I wonder who these people are - do they have the "battle scars" from working on complex or big systems? Are they reasonably junior or new to the profession with less than 10 years experience? Next up? Fuck structural engineers, it's just going to slow us down building this bridge... If you are doing something for fun, sure do whatever you want. I write zero tests for my own pet projects. But please in professional environments please don't ignore hard-won lessons in reliability and engineering-velocity because you don't want to have to do the extra work to update your tests. Your customers and colleagues (potentially years in the future) will thank you.

septimus111 2y ago
There is adverse selection at play. The top/world-class programmers are too busy to write blogs.
beezlebroxxxxxx 2y ago
Tech is a relatively immature industry. And a lot of time and effort and money in it is devoted to non-critical products. I'm not directing this at the OP, because they have actually thought about it even if I disagree with them, but there are a lot of people working in tech and in software who do not care about product quality at all. They're paid a lot of money and exclusively focus on shipping ASAP, quality be damned, so they keep their metrics looking good and the $$$ flowing. Add in the industries tendency for very short term tenure at jobs and you end up in a situation where people think what they're doing is "optimal" simply because it keeps them getting $$$ --- product quality is just secondary. Their "craftsmanship" is their job-hopping. (I don't have a problem with job-hopping if the products and code are still good --- they usually aren't.) They usually don't need to care about a bridge lasting 6 decades, but then they're writing critical software for infrastructure or airplanes and, unfortunately, they can actively resist a lot of the hard learned lessons people had to make in those industries because they just want to move fast (and leave after ~2 years). The culture isn't there yet.
akkartik 2y ago

hellectronic 2y ago

IMHO there are tests and there are tests. I had to work with codebases that had awful tests. They broke frequently because they were badly written. They used a lot of mocking when mocking was not appropriate. This tests were written for the purpose to have tests not for the purpose to really test the domain. I do not write tests for simple cases, like method in class A just delegates to method in class B. For a one man show - go on do not write tests, especially if you do not know where you will end up with the software. But in teams I find a lot of value in (good written) tests, preventing bugs and documenting bugs. Sure you can over-engineer it, as everything else too. BUT working without version control? Good that it works for you. I think version control is one of the MUST USE tools.

deleted 2y ago

[deleted]

_gabe_ 2y ago

I can sympathize with the authors love/hate relationship with tests, but I can’t help feeling like it’s because we as developers so often test the completely wrong things. I don’t typically write tests, but they do make sense for a few cases (specifically end to end tests that look for well defined outputs from well defined inputs). I was inspired by Andreas Kling’s method of testing Ladybird, where he would find visual bugs, recreate the bug in a minimum reproducible example, fix the bug, then codify the example into a test and make sure the regression was captured in his test suite[0]. This led to a seemingly large suite of tests that enabled him to continue modifying the browser without fear of regressing somewhere. I used this method of testing while I was writing a code highlighter that used TextMate grammars. Since TextMate grammars have a well defined output for some input of code + grammar, I was able to mimic that output in my own code highlighter and then compare it to TextMate’s output for testing purposes. I wrote a bunch of general purpose tests, then ran into a bunch of bugs where I would have mismatched output. As I fixed those bugs, I would add the examples to my test suite. Anyways, my code highlighter was slow, and I wanted to re-architect it to speed it up. I was able to completely change the way it worked with complete confidence. I had broken tests for a while in the middle of the refactor, but eventually I finished the refactor. As I started to fix the broken tests, there was a domino effect. I only had to fix a few tests and that ended up automatically correcting the rest. Now, I have a fast code highlighter and confidence that it’s at least bug for bug parity with the slow version :) [0]: https://youtu.be/W4SxKWwFhA0?si=PJs_7drb3zVxq0ub https://youtu.be/W4SxKWwFhA0?si=PJs_7drb3zVxq0ub

GTP 2y ago

I don't agree with point 3: "Small changes in context (people/places/features you want to support) often radically change how well a program fits its context. Our dominant milieu of short-termism doesn't prepare us for this fact." My opinion here is that short-termism is precisely a consequence of the hardness of predicting/keeping up with these small changes: businesses prefer to be able to adapt quickly to new scenarios rather than risking being stuck in the wrong direction.

slowmovintarget 2y ago

Can I just say... I love the return of the term "programming," "to program," and "programmer." "Coder" and "coding" was popular for a while, and before Steve Balmer put his stamp on it, "developers" and "development." But when I started, before 32-bit Windows was a thing, I was a programmer. If the Primeagen has helped popularize the term again, great, thank you.

akkartik 2y ago
I've always been a programmer. Because it was good enough for Dijkstra.
- slowmovintarget 2y ago
  I like that take, and wholeheartedly agree.

skybrian 2y ago

> Small changes in context (people/places/features you want to support) often radically change how well a program fits its context. Our dominant milieu of short-termism doesn't prepare us for this fact. I'm wondering what would work better? Writing a small program from scratch, using a rich ecosystem of libraries, seems like one way to go. AI help makes that easier. Another approach, more common with popular apps that have more to lose, is to evolve in place.