> Eloquent, moving, and more-or-less exactly what people said when cameras first hit the scene.
This is a non sequitur. Cameras have not replaced paintings, assuming this is the inference. Instead, they serve only to be an additional medium for the same concerns quoted:
The process, which is an iterative one, is what leads you
towards understanding what you actually want to make,
whether you were aware of it or not at the beginning.
Just as this is applicable to refining a software solution captured in code, just as a painter discards unsatisfactory paintings and tries again, so too is it when people say, "that picture didn't come out the way I like, let's take another one."
Photography’s rapid commercialisation [21] meant that many painters – or prospective painters – were tempted to take up photography instead of, or in addition to, their painting careers. Most of these new photographers produced portraits. As these were far cheaper and easier to produce than painted portraits, portraits ceased to be the privilege of the well-off and, in a sense, became democratised [22].
Some commentators dismissed this trend towards photography as simply a beneficial weeding out of second-raters. For example, the writer Louis Figuier commented that photography did art a service by putting mediocre artists out of business, for their only goal was exact imitation. Similarly, Baudelaire described photography as the “refuge of failed painters with too little talent”. In his view, art was derived from imagination, judgment and feeling but photography was mere reproduction which cheapened the products of the beautiful [23].
What stole the joy you must have felt, fleetingly, as a child that beheld the world with fresh eyes, full of wonder?
Did you imagine yourself then, as your are now, hunched over a glowing rectangle. Demanding imperiously that the world share your contempt for the sublime.
Share your jaundiced view of those that pour the whole of themselves into the act of creation, so that everyone might once again be graced with wonder anew.
I hope you can find a work of art that breaks you free of your resentment.
Ah well, I'm neurodivergent and it’s challenging for me to write a comment while remembering that others don’t have access to my thoughts and might interpret things differently. And it's too late to edit it now
What I wanted to show is that, clearly different from a camera or other devices, AI can copy originality. OPs comment was pretty original in it's wording, and gpt came pretty close imo. It really wasn't meant as a low effort comment
Plot twist. The comment you love is the cynical one, responding to someone who clearly embraces the new by rising above caution and concern. Your GPT addition has missed the context, but at least you've provided a nice little paradox.
What I especially enjoy is seeing those people accuse AI of being a "parrot" or a "mindless next-token predictor." Inevitably, these accusations are levied in comments whose every thought and token could have been lifted verbatim from any of a thousand such comments over the past few years, accompanied by the rusty squeak of goalpost wheels.
Cognitive skills are just like any other - use them and they will grow, do not and they will decline. Oddly enough, the more one increases their software engineering cognition, the less the distance between "The Builder" and "The Thinker" becomes.
> I've never heard of that being banned. It hasn't been banned anywhere i've written Java.
Once code such as the below is rejected in a code review, the next version often submitted is an "if-else-if" ladder using `instanceof` (which is effectively the same thing).
TheReturnType r = null;
try {
DomainType1 instance = (DomainType1)obj;
r = ...
}
catch (ClassCastException ex) {}
if (r == null)
try {
DomainType2 instance = (DomainType2)obj;
r = ...
}
catch (ClassCastException ex) {}
if (r == null)
try {
DomainType3 instance = (DomainType3)obj;
r = ...
}
catch (ClassCastException ex) {}
...
And yes, I have seen the above scenario played out in a professional setting.
If you have to ask an object what its type is, you're probably about to cast it, and these are operations that the language doesn't enforce that you do together (and so the habit of casting can lead to the habit of casting without the check...). There are times when it's appropriate but generally if you have to ask what type an object is, your code is already starting to smell (because typically dispatching on type is handled by polymorphism, not be the programmer manually implementing it).
>> The instanceof[0] operator is typically banned from use in application code and often frowned upon in library implementations.
> Never seen this being banned. Whats the reason?
Its usage encodes a priori assumptions of what a super-type could be, often expressed in an "if-else-if tree", thus making the logic doing so needlessly brittle and difficult to maintain.
Library logic sometimes needs to use this construct (I'd argue those abstractions need to be rethought however), but an application which does exhibits a failure in domain modelling IMHO.
It can be a code smell, but there are legitimate uses. This is not something that I would ever "ban".
Over-eager code analyser tools are themselves a "smell", in that you either justifiably or unjustifiably don't trust your developers, trying to make up for their real or perceived deficits with a rather dumb tool. That never goes well in my experience.
Both can be true if each group selectively provides LLM output supporting their position. Essentially, this situation can be thought of as a form of the Infinite Monkey Theorem[0] where the result space is drastically reduced from "purely random" to "likely to be statistically relevant."
For an interesting overview of the above theorem, see here[1].
> I love this, it resonates so deeply with me. Code is, for me, joy.
A credo I have held for some time is:
When making software, remember that it is a snapshot of
your understanding of the problem. It states to all,
including your future-self, your approach, clarity, and
appropriateness of the solution for the problem at hand.
Choose your statements wisely.
Cool article. It makes me think about an "old school Unix" approach which might work for some use-cases.
Essentially, the untested brainstorming-only idea is:
1. Make $HOME have 0751 permissions
2. Assume the dev project exists in $HOME/foo and has
0715 permissions
3. Assume $HOME/foo/src is where all source code resides
and has 0755 permissions (recursively)
4. Install the agent tools with a uid:gid of something
like llm:agent
5. Turn on the setuid/setgid bits for executable(s) in
the agent tools or make wrapper script(s) having
same which delegate to agent tools
This would ensure agent tooling could not read nor modify $HOME, only be able to read $HOME/foo (top-level project directory) and its files (assuming `o+r` is the default), and could only modify files in $HOME/foo/src having `o+w` permission as well. If agent directory creation in $HOME/foo/src is desired, enable `o+w` on it and directories within it.
There is probably some "post agent use" processing that would be needed as well.
Note that while containers can be leveraged to run processes at lower privilege levels, they are not secure by default, and actually run at elevated privileges compared to normal processes.
Make sure the agent cannot launch containers and that you are switching users and dropping privileges.
On a Mac you are running a VM machine that helps, but on Linux it is the user that is responsible for constraints, and by default it is trivial to bypass.
Containers have been fairly successful for security because the most popular images have been leveraging traditional co-hosting methods, like nginx dropping root etc…
By themselves without actively doing the same they are not a security feature.
While there are some reactive defaults, Docker places the responsibility for dropping privileges on the user and image. Just launching a container is security through obscurity.
It can be a powerful tool to improve security posture, but don’t expect it by default.
The "barrier to entry for building software" has not collapsed, as it was never about "where engineering shifts from writing code to shaping systems". It has always been about understanding the problem to solve and doing so in a provably correct manner.
Another way to reify this is:
When making software, remember that it is a snapshot of
your understanding of the problem. It states to all,
including your future-self, your approach, clarity, and
appropriateness of the solution for the problem at hand.
Choose your statements wisely.
> The file system as an abstraction is actually not that good at all beyond the basic use-cases. Imagine you need to find an email.
Unrelated to FUSE and MCP[1] agents, this scenario reminded me of using nmh[0] as an email client. One of the biggest reasons why nmh[0] is appealing is to script email handling, such as being able to use awk/find/grep/sed and friends.
This is a non sequitur. Cameras have not replaced paintings, assuming this is the inference. Instead, they serve only to be an additional medium for the same concerns quoted:
Just as this is applicable to refining a software solution captured in code, just as a painter discards unsatisfactory paintings and tries again, so too is it when people say, "that picture didn't come out the way I like, let's take another one."reply