From the recent threads, it feels like the other half is totally, willfully ignorant. Hence the responses.
As someone who is part of that other half, I agree.
Readit NewsDeleted Comment
rhizome31 commented on Andrew Ng: Building Faster with AI [video] youtube.com/watch?v=RNJCf... · Posted by u/sandslash
rhizome31 commented on Can we test it? Yes, was can [video] youtube.com/watch?v=MqC3t... · Posted by u/zdw
I think what people really mean when they say "This can't be tested" is:
"The cost of writing these tests outweighs the benefit", which often is a valid argument, especially if you have to do major refactors that make the system overall more difficult to understand.
I do not agree with test zealots that argue that a more testable system is always also easier to understand, my experience has been the opposite.
Of course there are cases where this is still worth the trade-off, but it requires careful consideration.
Testing is a skill. The more you do it, the less expensive it becomes.
rhizome31 commented on Why agents are bad pair programmers justin.searls.co/posts/wh... · Posted by u/sh_tomer
Sadly, I mean my current employer is doing the whole "tracking to see AI usage rates" and basically checking in performance reviews if people are using as much AI as the AI sales people told the CEO people need to use.
We're a SaaS company so we own all our code.
Wow, really?! I had no idea that such policies existed. Quite astonishing I have to say.
rhizome31 commented on Why agents are bad pair programmers justin.searls.co/posts/wh... · Posted by u/sh_tomer
I don't share anything with openai/anthropic that I wouldn't feel comfortable pasting into a web search prompt.
So no AI autocomplete I suppose?
I assume AI autocomplete may send any part of your code base or even all of it to a third-party.
rhizome31 commented on Why agents are bad pair programmers justin.searls.co/posts/wh... · Posted by u/sh_tomer
I basically only use it in the workplace, and largely because of one of those AI mandates.
I don't think it actually saves me enough time (or for many tasks, any time) so I wouldn't pay for it for my own projects, and also for my own projects, the enjoyability is a big factor, and I enjoy doing more than prompting.
Thank you for the reply. What do you mean by "AI mandates"? Does it mean your company has an explicit policy allowing sharing code with AI services?
rhizome31 commented on Why agents are bad pair programmers justin.searls.co/posts/wh... · Posted by u/sh_tomer
As a developer who doesn't use AI for coding, except for the occasional non-project specific question to a chat bot, I am wondering if you use it for client projects or only for your own projects. If you do use it for client projects, do you have some kind of agreement that you're going to share their code with a third-party? I'm asking because most clients will make you sign a contract saying that you shouldn't disclose any information about the project to a third-party. I even once had a client who explicitly stated that AI should not be used. Do you find clients willing to make an exception for AI coding agents?
rhizome31 commented on Show HN: Audiocube – A 3D DAW for Spatial Audio audiocube.app... · Posted by u/noahfk
Bitwig is all right though.
rhizome31 commented on Ask HN: Organize local communities without Facebook? · Posted by u/recvonline
> it's been developped by the fine folks of framasoft
This is enough to tell me it's not gonna be suitable.
Their software are all absolutely awful because their organization follows the skewed principle that FOSS is enough to "sell" and they don't take UX into consideration at all.
Literally none of their alternatives are successful, always for this reason.
Framapad, Framacalc and Framadate are used quite a lot around here.
- duplicate code isn't always bad
Sometimes* the same code copy/pasted or repeated is much easier to understand than pulling it all into a subroutine. It seems logical when writing code, but kills understanding when reading code. Predictable is better than compact a lot of times.
- code should fail early
Sometimes* "being robust", correcting errors or continuing after an error is the wrong thing to do. When something unexpected happens, failing, and failing quickly might be important.
- explicit is better than implicit
Sometimes* it is much better hardcode a list of things instead of constructing the list from whatever is there.
concrete example would be a makefile that compiles .c vs a makefile that compiles one.c two.c three.c. Hardcode the list. Make it hard fail if something is missing or something is added. Yeah, it is more work, but the madness it prevents is worthwhile.
there are probably thousands of these things. All are opinion, like camelcase sucks and indent should be 4, but not with tab characters.
* not always
Don't catch errors unless doing something actually useful with them. Even then, it's often a good idea to re-raise.