31–40 of 48 posts
"Because of my own personal philosophy regarding technology and AI, all the code in this repository that was written by me - I wrote 100% on my own. There is and will be no usage of Github Co-Pilot or any other AI tool." As a developer that recently went to the dark side with co-pilot... all I can say is that from my perspective having used AI-augmented IDEs, arguments like this seem to me like a carpenter refusing t…
"Because of my own personal philosophy regarding technology and AI, all the code in this repository that was written by me - I wrote 100% on my own. There is and will be no usage of Github Co-Pilot or any other AI tool." As a developer that recently went to the dark side with co-pilot... all I can say is that from my perspective having used AI-augmented IDEs, arguments like this seem to me like a carpenter refusing t…
“I believe that the massive usage of AI will cause people to stop thinking and using their minds and the resulting havoc is unthinkable” Immediate utility aside that’s a probable prediction by the author though. Let’s hope the optimists will be right… https://github.com/MrIceman/go-uml#warning---ai-not-welcome-...
I guess the argument is "I already know Go" (or Python etc.). But you probably already know json (yaml), too. And if not, it won't take long to learn.
Love the thought mentioned the warning section https://github.com/MrIceman/go-uml#warning---ai-not-welcome-...
I'm a bit biased, but I feel diagrams-as-code should use a stateless, declarative language (like json or yaml) and not a programming language. Programming languages have so much functionality that just doesn't apply to the output you're generating. I guess the argument is "I already know Go" (or Python etc.). But you probably already know json (yaml), too. And if not, it won't take long to learn.
I go farther, all told. I think any sort of diagram should almost certainly be process/pipeline based. Parts can be generated by a declarative markup, certainly. But you need a pipeline to "hand tune" things or you will end with diagrams that are clearly generated by a program. Fine for some things, sure. But there is a reason most of the diagrams that you remember the looks of were bespoke authored in a much more graphical environment.
"Because of my own personal philosophy regarding technology and AI, all the code in this repository that was written by me - I wrote 100% on my own. There is and will be no usage of Github Co-Pilot or any other AI tool." As a developer that recently went to the dark side with co-pilot... all I can say is that from my perspective having used AI-augmented IDEs, arguments like this seem to me like a carpenter refusing t…
On a less snarky note, this seems like a pretty serious exaggeration. You could have learned about .every() and .some() in many many other ways
I'm a bit biased, but I feel diagrams-as-code should use a stateless, declarative language (like json or yaml) and not a programming language. Programming languages have so much functionality that just doesn't apply to the output you're generating. I guess the argument is "I already know Go" (or Python etc.). But you probably already know json (yaml), too. And if not, it won't take long to learn.
Depends heavily on the diagram? I go farther, all told. I think any sort of diagram should almost certainly be process/pipeline based. Parts can be generated by a declarative markup, certainly. But you need a pipeline to "hand tune" things or you will end with diagrams that are clearly generated by a program. Fine for some things, sure. But there is a reason most of the diagrams that you remember the looks of were be…
> Because of my own personal philosophy regarding technology and AI, all the code in this repository that was written by me - I wrote 100% on my own. There is and will be no usage of Github Co-Pilot or any other AI tool. I became a software developer because of my passion for our craft - Software Engineering. I build this tool because I enjoy programming. Every single line of code you'll read in this repo, that was written by me, is produced first in my mind and then manifested into reality through my hands. I encourage any contributor to follow the same principle, though I can't and don't want to put any restrictions on this. Just like people stopped walking because they commute by cars and trains, which caused an increase in obesity and illness, I believe that the massive usage of AI will cause people to stop thinking and using their minds and the resulting havoc is unthinkable.
AI Gatekeeping... What a time to be alive!
Love the thought mentioned the warning section https://github.com/MrIceman/go-uml#warning---ai-not-welcome-...
I don't. It's fine making a personal choice to not use AI, but to go on to just openly insult anyone who uses AI is absurd and too far. Everyone is allowed their choices and we should respect that. The doom-whispering is not charming or insightful, good grief.
"Because of my own personal philosophy regarding technology and AI, all the code in this repository that was written by me - I wrote 100% on my own. There is and will be no usage of Github Co-Pilot or any other AI tool." As a developer that recently went to the dark side with co-pilot... all I can say is that from my perspective having used AI-augmented IDEs, arguments like this seem to me like a carpenter refusing t…
> like a carpenter refusing to try power saws and power drills because craftsmanship will be lost compared to using handsaws and awls + hand drills Rejecting AI-backed software tooling reminds me more of Amish power tools. https://www.npr.org/sections/money/2013/02/22/172626089/insi...