Earlier quoted context omitted.
Time's expensive too.
on the other hand you spend time and tokens using the AI approach
Teach yourself programming in ten years (1998)
91–100 of 142 posts
Re: Teach yourself programming in ten years (1998)
#92One of may favorite things to do was to spend some time tinkering around to learn a new programming language. I collected quite a few and it was fun to learn new paradigms and how to organize programs. But now since AI… idk I just can’t do it, it seems just completely useless in the age of AI. Like getting better at the technical aspects of programming just doesn’t feel important anymore. I don’t think I’ll ever be a…
Now I use AI to build things I genuinely like and actually use. Nothing particularly fancy.
I built a weather website that I use all the time when planning hikes. I also built a generative hiking-route tool: give it a starting point and a distance, and it tries to find interesting paths for you. I’ve made plenty of small helper tools for work and health, and now I’m wrestling with Open WebUI, trying to make it work exactly the way I want while repurposing an old Android device as the server.
Do I miss nerding out over implementing a B-tree, or learning async programming in F#, Go, Crystal, Nim, C++, C#, JavaScript workers, or Java green threads?
I don’t know, man. Maybe a little.
But it has also never been easier to say: “Hey AI, teach me this concept using five examples. Give me one task, then evaluate my solution. And teach it in this particular style.”
We lost something. I genuinely think we did.
But I also think we gained much more.
It’s okay to mourn what was lost, as long as you can still look forward.
Re: Teach yourself programming in ten years (1998)
#93Wasn't Claude supposed to do all the coding by now? Did we have a change of mind or did we run out of tokens?
I don't personally know anyone who writes code any more (for work). Is this not the case for you? The distinction I see now is between teams that read PRs and teams that don't. I still think the former is a good approach... for now, but I don't expect this will necessarily be the case in a year (or less). This article was such an inspiration to me when I was younger, and the advice, for that time, was very correct. H…
The original sin of the programming industry is not valuing expressive notation and expressive programming languages. (I am not talking about map/filter/reduce level party tricks but better metaprogramming and coherent abstractions). No amount of sacrificing tokens for Anthropicus is going to give you the same amount of understanding as writing the program.
Re: Teach yourself programming in ten years (1998)
#94Earlier quoted context omitted.
> learn a new programming language. I collected quite a few and it was fun to learn new paradigms Let's be honest here: how many actually distinct paradigms are we really talking about here? I challenge you to name more than 5 which are not just flavors of the same core approach. Bonus if they are actually all relevant for production software.
Python, Go, Rust, Lua, Racket, and of course Pony. Python and Lua being probably the most similar of the bunch. The point is not that you would use any of these production (although you could), the point is to get your feet wet in a new setting. You see what's different and what's the same. I think it's a very important part of maturing as a programmer.
I was asking about paradigms. These are 6 languages and the distinct paradigms they cover are hardly 6. Unless we have different notions of what a paradigm is.
I see imperative and functional paradigms covered in your list. Am I missing anything else? Object orientation could be counted as a separate paradigm but how much different that is from basic imperative programming is already somewhat debatable.
Re: Teach yourself programming in ten years (1998)
#95Earlier quoted context omitted.
> learn a new programming language. I collected quite a few and it was fun to learn new paradigms Let's be honest here: how many actually distinct paradigms are we really talking about here? I challenge you to name more than 5 which are not just flavors of the same core approach. Bonus if they are actually all relevant for production software.
> Bonus if they are actually all relevant for production software. Why it should be relevant for production software?
Re: Teach yourself programming in ten years (1998)
#96Earlier quoted context omitted.
I do! A lot of the work I do is not simple CRUD, and I have to think about what's going on. Reading code doesn't do that to the same degree.
Cutting-edge models are capable of much more than generating CRUD apps and understanding the details is orthogonal to whether you wrote the lines yourself or not.
Reading the code does not give you the knowledge of the 10 different approaches you would have tried and failed before coming up with that code. Why exactly a piece of code is the way that it is cannot be determined by just reading the code.
Reading a mathematical proof does not give you any meaningful understanding of it.
Re: Teach yourself programming in ten years (1998)
#97Re: Teach yourself programming in ten years (1998)
#98Earlier quoted context omitted.
What most miss today is DX - Developer Experience, many (most?) devs don't want to become Prompt Engineers. Another thing is that not many can afford Fable or similar and I don't think prices will go down, since it is already heavily subsidized?
I've always spent 90% of my work time thinking and sketching what the architecture should be to solve a problem. I find that once I've worked that out, it's actually still faster for me to code it than to try to explain it and refine it in prompts. And the code ends up more succinct and covers the edge cases I've already considered. If I need a fast script to do one thing, or unit tests, sure an LLM is faster at writ…
Re: Teach yourself programming in ten years (1998)
#99Earlier quoted context omitted.
It's not true at all. I recently vibe coded a REST API in Golang even though I never wrote any production Go code. However, I had to make copious use of my previous experience as an engineer to achieve quality. You can see this in the real world. The people who are getting the most out of AI are the ones who already have experience coding without AI. CEOs don't want to admit it but AI can't code anything non-trivial…
I agree with you, but now we have managers pushing code to production, people that never coded but are "IT versed"..so you get PR/MR not just with code, but with PR/MR comment written by Claude, Commit Message written by Claude.. all super verbose, and you know the people operating Claude, have no clue. Super dangerous combination. But part of the reality.
If you're worried about not being able to write git commit messages anymore, then you might have been in the wrong career in the first place.
The whole point of AI is to reproduce things that used to be mass produced. AI isn't generating high quality compilers or OS kernels, for example, because we haven't found a way to mass produce those yet.
I suggest you stop listening to clowns like Elon Musk and Super Mario.
Re: Teach yourself programming in ten years (1998)
#100Earlier quoted context omitted.
I see a reference to Khan Academy, but not Go?
> Learn at least a half dozen programming languages. Include one language that emphasizes class abstractions (like Java or C++), one that emphasizes functional abstraction (like Lisp or ML or Haskell), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), and one that emphasizes parallelism (like Clojure or Go).