971–980 of 1001 posts
Bit off topic but why in the world are people still posting on medium? The reading experience is abhorrent; I couldn’t even finish reading this article before a full screen popup literally blocked the sentence I was reading. Is there some incentive I’m not seeing?
The static vs dynamic language debate is decisively over and static has won. I called this out back in 2023, and I've only become more convinced since then. Statically typed languages are easier for the reader because you can see the types and quickly jump to their definitions (or even just hover over them in some IDEs). They're easier for the AI because they provide natural guardrails and feedback to guide it, as we…
If static has won, why are dynamic languages more popular now (even since 2023). Comically, I’ve witnessed people say this since the 90s. For me, I don’t care about static because dynamic is easier. For the very few conditions where it matters, I’ll use static. Otherwise I like the simplicity of dynamic languages, especially python. IDEs provide support and jump to definitions in dynamic languages, too.
I know the whole dynamic vs static typing is an age old flame war, but it sure seems that static is winning to me.
Earlier quoted context omitted.
Python data processing/ML in the 2010s became a huge asset for the language.
Ironically it also created a ton of really badly written Python in the process.
Earlier quoted context omitted.
This must really depend on your niche. I assume you do web stuff or something? Good luck finding any golang examples in a lot of other fields. Rust, on the other hand, is taking over the world in systems programming.
Just reporting what I’ve experienced. No need to go with the ad hominem attack. I happen to lead a team with a major Rust infra project and I stand by the experience with usage across all the LLM models.
Earlier quoted context omitted.
I’m curious about the design space of languages & frameworks which are lower level than LLM prompts but higher level than Python, Ruby and Common Lisp. Do you have any recommendations for systems where reasoning about large systems is easier than in python?
Anything with a good, static type system will be an improvement, in my opinion. Types exist to encode invariants in an enforceable way, after all. Rust is the gold standard among imperative languages, but it’s standard fare among functional languages such as Haskell, OCaml, F#. You can also get really far in C++ if you have the stomach for it.
But I don’t think types are really sufficient to solve the problem you identified earlier of understanding how “many small individually readable things interact with each other”. Maybe you meant that phrase in a different sense than I read it, but it seems to me that there are still a lot of small individually readable things to keep track of in Rust.
Earlier quoted context omitted.
Comparing rust to javascript, the gscore is rather similar in distribution, while python falls off. I don't see why python should be so much worse?
This was an unexpected result, and it held up under large sample sizes.
But under this frame, it appears that the developer's task involves prompt engineering. This is not the case. Even if an agent generates 90% of the code, each and every diff is going to be in my review queue. Code readability of Python isn't an advantage during write; it's an advantage while reviewing. As an agent generates a piece of code, I will have to read the code, comprehend the code, and determine whether it d…
> Code readability of Python isn't an advantage during write; it's an advantage while reviewing. This is completely subjective though. I personally find that Python's lack of static types makes code very difficult to reason about. Yes, some devs will write decent comments and name things in a way that's easier to read, but most devs are lazy (myself included) and things get out of hand quickly. But this is also a sub…
Static typing holds more ground while making assumptions about contracts between components in huge codebases written by many developers. But in the realm of agents, it all boils down to a simpler question, will this particular function generated by an agent do the job that was requested? Line-by-line readability of Python suffices in this case, regardless of whether type annotations are used throughout.
The pragmatic approach would be to enforce type rules where needed (i.e., when working with Pydantic schemas or in FastAPI routes), while not applying any constraints within the code itself.
Earlier quoted context omitted.
I've noticed that with clojure(script) unless you specifically instruct them to keep nesting levels low, they can hit a point where they make a paren placement error and can't debug their way out of it. Although in my case while one model made the error then couldn't find what it had done, a second model that I switched to was then able to identify it and back it out. So I suspect this is a transient weakness in toda…
I don’t know, I think it might be fundamental. They think in tokens, and )))))))) might look equivalent to ))))))). Just like the strawberry problem. The calva backseat driver extension even includes a specific paren balancer for this reason, and it works quite well
In token terms it's more like the fingers problem than the strawberry problem. ")" is a single token, but the model gets confused by several repeats of the same thing.
Earlier quoted context omitted.
Go has a very full featured standard library. It's simple (do you really ask why that's a selling point?) It's fast to compile. It's fast to run. It's good with parallelism. It has myriads of examples, and LLMs can pick it up well too. It has good backing. It has good tooling. It's fun. It statically compiles to a trivially deployable binary. It's excellent at cross compiling. It has good adoption.
Fun it is not. if err != nil It's amazing how they managed to design a new language with all the flaws of '90s languages.