But noone wants to look at another website anymore. People dont browse the web like in the old days or in the 2000s or in the 2010s. People are just used to being siloed now. Many dont even know what the old web was and how it felt. There are just a few silos now, FB , reddit, X and this is all they know, many dont even know much more than FB.
They were smart and didn't upload their process to github, didn't write any books or tutorials on fast food ordering process. So AI could't learn the craft. ;)
Drunk guys are the easisest to play against. You don't need GTO, you can just play exploitatively and adjust your range against his, so that you still have big range advantige preflop. And you can lower variance and decide to not go all-in with AK preflop, but this also depends on how deep the effective stack is in a given situation.
Are today's juniors never gonna reach senior levels because of AI assisted coding ? Do you think AI assisted coding has a negative impact on developer's growth ?
Is the need for developers gonna increase in the longterm but decrease in shortterm ?
Those are just some of the questions that are in my head lately. I would appreciate other people's opinion.
> Do you think AI assisted coding has a negative impact on developer's growth?
Almost certainly. Easier to do things the easier way, but you never learn unless you do it the hard way. Maybe that won't matter -- i.e., the skills that one would've learned are now to be subsumed by AI. But as long as humans are needed, it will be necessary to build deep skills and understanding of systems, which AI coding does not seem to give us.
> Are today's juniors never gonna reach senior levels because of AI assisted coding?
Some definitely will, same as some people today get really good at programming in assembly. Almost certainly fewer will -- at least to what we today consider "senior".
> Is the need for developers gonna increase in the longterm but decrease in shortterm?
It all depends on the shape of the curve -- how far AI coding will be able to take us, and how fast.
It turns out to mostly serve the same purpose as low-code/no-code, where devs are needed to do 'serious' work and mixing the two becomes difficult? I doubt there'll be a slump at all.
It turns out to obviate the need for devs entirely, but only for certain common tasks -- or, it speeds up devs across the board by enough that significant double-digit (e.g. 40-50%) percentages of their work is now handled by AI? Then yes I expect we'll see a slump of some degree. But if it's not close to a 2x multiplier I expect we slump back to the first category, given just how much code it's clear there is still to be written.
On the other hand, though: if AI continues to advance and actually replaces developers 1-to-1 at lower cost? We're probably in for a sharp exponential and the question isn't how many developer jobs will be left, it's how long humanity has left.
>> as it mainly applies to Lisp-like languages that uses parentheses heavily.
This is so wrong. Lisp does not use parentheses heavily. It doesent even use more parens than any C like language. I just dont understand the fixation with parentheses. The power of lisps comes from the fact that everything is an expression. Someone can correct me if I am wrong, since I only have experience with functional lisp Clojure, but I believe other lisps are more or less similar.
So if everything can be evaluated, then you can have a really great REPL experience. You can be inside your favorite editor and have the tightest feedback loop possible. So the absence of statements is actually a great feature of the language which improves ergonomics.
The anti parentheses argument is usually just a straw that people grasp, who have no experience with writing code in lispy languages. A quick superficial jab at something they do not know well, so that they can go on with their day, without having to deal with learning a new thing, that might change their whole view of programming.
Plus, don't forget the secret sauce of Lisp syntax: same number of parentheses, with none of the commas. Nor the semicolons. Nor the brackets. Nor the braces.
I can live with brackets and braces tho ;) Clojure <3
But that is a very nice observation that is true for traditional lisps. I need to give racket or scheme one more look.
I just don't understand the fixation with REPL. How do you use it? It sounds like you write code as black box then run it in REPL to see what it does because you don't understand it by yourself.
Perhaps because maybe you just haven't used one? I'm not talking about "a REPL" in langs like Python, where you typically have to type stuff into it. Lisp REPLs allow evaluating code directly in the source buffer, by sending it into the REPL. That REPL can be remote. Like seriously remote - NASA once did it on a spacecraft 150 million miles away from Earth. We run ours in a kubernetes cluster. Lisp REPL allows you to evaluate specific expressions, functions, or regions directly from where you are. Without saving, linting, linking, compiling, etc.
> because you don't understand it by yourself.
REPL is not about "understanding your code", it's about interactive development and exploration - it allows you to test your ideas and assumptions in real-time. Imagine being able to send http request, pull some good chunk of data, and then sort it, group it, slice it, dice it, filter it, visualize it - do whatever you want to do with it, directly from your editor. It's incredibly empowering and extremely liberating.
The only downsides - after getting used to that, using non-lispy languages sucks all the joy out of programming and you also have to explain to people what it is like.
It's like moving to an island where people have never discovered salt, pepper, and other spices, and though their cuisine looks beautiful - you just can't describe to them what they all are missing. Some even may say - "Hey, I've tried pepper once - but I don't understand your fixation with it" and you'd be like: "have you ever tried putting it into your food?"
You check assumptions about dynamic types this way? To see what the function even returns in the first place. Browser console has a similar function: you type a function invocation, run it, then the returned value is presented as a tree for inspection.
You can check any assumptions about the code. But it's not exactly like using browser's dev tools console. First — you don't have to type things "somewhere else" — you're doing it right where you're writing code. And it can be a file or a scratch buffer — you don't even have to save those experimental bits. Second — because you have things neatly wrapped into symbolic expressions (those pesky parens that non-lispers find so confusing), you don't need any ceremony for setting up the stage.
take this Javascript example:
function addFive(x) { return x + 5; }
or
const addFive = (x) => x + 5;
And its counterpart in Clojurescript:
(defn add-five [x] (+ x 5))
In javascript REPL you can eval the entire thing, but try doing it piecemeal - it makes little sense, i.e., what is (x) or => from js perspective, semantically? While Clojure variant already is a list - a native data-structure, the argument is just a vector - another native thing, etc.
So that infamous code-is-data & data-is-code mantra may not seem like a big deal in a trivial example like this, in practice, it's very nice, it allows you to do things otherwise difficult to achieve, watch this video https://www.youtube.com/watch?v=nEt06LLQaBY
and give it a thought, how does one build something like that and how using a Lispy language helps there, while using more traditional PL would make things much more difficult.
> It sounds like you write code as black box then run it in REPL to see what it does because you don't understand it by yourself.
That doesn't even make any remote sense. "I don't get the fixation with the JVM. It sounds like you write code as a black box, then compile and run it to see what it does because you don't understand it by yourself."
Internet has become dogshit wrapped in catshit.