What really annoys me about Python, is that a lot of problems that the language/infrastructure/community has can easily be tracked back to well understood problems that have been solved for decades in other communities. Some of these problems have been fixed with breaking changes, some others probably never will be fixed.
Just a list of bad/wrong decisions IMHO:
- Reference counting instead of using a real garbage collector
- The pyproject.toml format is under-specified, comes decades too late for a problem that has been solved good enough by Apache Maven more than 2 decades ago
- The absolutely weak support for functional programming, which then was patched by list comprehensions and co later
- venv and other solutions to isolate dependencies for a project
Python is successful because of the community support and a binding to almost everything, and this sadly outweighs a lot of poor choices from the language designers and the implementation. I just always feel frustrated, that during the great breakup from 2-3, they didn't try to fix more of the known issues (which again, have been solved by other communities decades before) instead of breaking the world and still managing to half ass it.
> I just always feel frustrated, that during the great breakup from 2-3, they didn't try to fix more of the known issues
Absolutely agreed. I would rather they left 2.x in someone else's hands entirely. Instead they were ultimately forced to produce 2.7, wheedle and bargain to not have to produce 2.8, and give 2.7 an extended support window instead; and they still got complaints and abuse from people upset about making changes that were generally quite easy to make.
I would still have completely switched to 3.x (at least when it appeared ready) simply based on it coming from the same team and advertising the main features and fixes that it ended up with.
> Reference counting instead of using a real garbage collector
This is not explicitly part of the design. You are free to use other implementations.
But before the `with` block was added (in 2.5), reference counting was useful for deterministic cleanup.
> The absolutely weak support for functional programming, which then was patched by list comprehensions and co later
I'll give you this one. GvR actually didn't like this stuff very much, which is how `reduce` lost its builtin status. The basics can take you really far, though. The important thing is that functions are first-class objects.
> venv and other solutions to isolate dependencies for a project
There is nothing fundamentally wrong with venvs. 99% of the complaints I hear about venvs are not actually the venv's fault. (They're usually pip's fault. Pip is bad.)
A venv is literally just a place to put packages (organized roughly the same way the system packages are) and a simple scheme for enabling Python to understand where that place is (so that `sys.path` can be modified at startup). Every other possibility has the same problem: either you have to learn one or more options for telling Python to use that package location, or it works by magic (which means eventually you have to understand the magic, and anyway "Explicit is better than implicit").
> The pyproject.toml format is under-specified, comes decades too late for a problem that has been solved good enough by Apache Maven more than 2 decades ago
pom.xml is not at all "good enough". The pyproject.toml format is actually quite detailed (https://packaging.python.org/en/latest/specifications/pyproj...). It also has explicit design goals of a) allowing arbitrary tools to store their config and b) being human-readable and -writable.
More importantly, Python didn't have something like Maven in 2004 alongside Maven because Maven only has to worry about Java code; the Python packaging system has to worry about potentially every programming language, and very commonly C, C++, FORTRAN and now Rust. In 2003 (with Python 2.2) it got `distutils`. That was designed (and Setuptools picked up the torch) to use code in `setup.py` for everything, because nobody had any concept of a real "ecosystem" yet (see if you can find some archives of the Cheeseshop from its first year, if you dare) and it was simple and seemed Pythonic at the time.
And now we're in a thread where OP is upset that Python code doesn't work for 30 years, which seems like a pretty common take. It turns out that when you accommodate backwards compatibility, it gets in the way of actually fixing old problems quite a bit. There are still projects out there that are just Python code that could be perfectly well built using Flit, that are using (slow!) legacy setup.py-based build setups. Not because there's anything wrong with pyproject.toml for their purposes (there absolutely isn't), but because nobody is forcing them.
People don't even keep their setup.py contents up to date, let alone pay attention to any kind of deprecation warnings. Literally the only thing that gets anyone to do anything is to break their setup, and then for most of them their action is to complain and make the Setuptools team put things back how they were.
I'm not just talking about random developers on tiny forgettable projects, either. I'm talking about PSF-managed projects like Requests that:
* are pure Python code
* are among the most popular packages on PyPI (Requests is top ten)
* had their "source builds" break this year (https://github.com/psf/requests/issues/6775) because of a removed import in setup.py for something that nobody has actually used for years (a legacy testing setup that has been completely abandoned since the project uses tox)
* already had a `pyproject.toml` file but weren't actually using it to store even basic build configuration (still in `setup.cfg`, so they had all three files for really no reason).
(Thankfully, something is actually getting done in Requests. Supposedly. The work for this was apparently "already done" in May 2024 and is supposed to appear "in the next minor version release". The last release as a patch release this August. The main branch of the repo doesn't reflect this work.)
Programmed over the years in almost all mainstream programming languages at one time or another.
Saying this, Java was and is in many ways one of the best ecosystems to write software out there, if not the best (when it comes to server side software).
Maven is my favorite build systems so far: Default directory layout means everything has its place, IDEs can easily open any kind of Maven project, and being declarative, one can easily analyze pom.xml files. (I hate writing XML and I still like Maven.)
The next thing is Javas standard library. Well documented and big. Has it better and worse parts? Sure! But what people which never used a language with a good standard library don't get, is that even a bad standard library which is widely used is far better, than the npm-of-the-week clusterfuck, which means that nobody can read three lines of code and really understand, what is happening.
The IDEs are top notch, and you get even free ones (NetBeans, Eclipse) which can rival JetBrains and Visual Studio easily.
... and finally, Java is the only language that I know of, which has multiple strong companies and initiatives behind it, thanks that nobody trusts Oracle (rightfully).
Finally, Java code also got shorter, DI style is IMHO a very good default in any programming language (OOP, FP, Imperative), the community settled mostly on JUnit, so there are never discussions which of the 23 competing test frameworks to use...
In the end, there is a lot of rightful criticism of Java (historical baggage, too late when it comes to AOT, no modern GUI frameworks and a steep learning curve). Java getting new features with the new JDK releases is kind of double edged sword: Many things are good ideas, but they make the language more complicated at the same time.
The verbosity was IMHO never a big thing, because Java was always meant to be used in an IDE, for bigger projects explicit trumps implicit and finally newer revisions introduced stuff like 'var' statements etc.
It is kind of sad, that the Linux community never really jumped/accepted Java for desktop development (which might be explainable, when looking back at the lack of speed of Java in the 90s and the disastrous Solaris Java apps which were simply to slow to be usable).
Anyway, for work I am now using Golang, and it is hilarious how many lessons Golang did not learn from Java, when it comes to language design, although the tooling is top notch and the standard library has at least almost everything needed for writing backend services.
I don't see Java making a comeback, and I don't see anything modern going to replace java at the same time.
IMHO there are a lot of problems with the advice from Eskil.
His ideas about abstraction of the platform made a lot of sense in the past decades, but IMHO are not that applicable nowadays: It is well understood to separate domain logic from UI and storage, and a desktop application has a very different UI from a mobile app or even a web app.
My next critic point is, that Eskil assumes all domain knowledge is there from the beginning and will not change over time (his idea of having perfect APIs from the beginning).
No mention about error handling, reliability, response times, atomic operations etc.
To make it very clear: I believe Eskil gives his advice in good faith and his advice served him well in his own projects. In my opinion most of his advice is just not good advice in general.
(Besides having modules as black box building blocks if possible).
Yeah, I think the first mistake is thinking 'large software project' is specific enough to have any good advice at all.
Large software projects could include AAA console videogame, or banking mobile app, or embedded vehicle entertainment system, or airport baggage handling system, or hundreds of other totally different domains.
The only good advice I can think of is given a large software project try to hire someone (or a whole team) that have built something pretty similar before.
It is an Apple problem. Virtualization has been solved for good, even the cheapest consumer hardware has virtualization support since at least a decade by now and I sometimes run virtual machines on a 4GB netbook with an Atom processor just for fun.
I am running 100% automatically deployed/configured Debian desktops on Apple hardware for several years now, Intel and M1 CPUs. (100% reproducible is another level and another story).
Right now and for most of the past years I am running VMWare Fusion, which works with the features I need as long as you don't update macOS immediately after a new major revision was released. (Apple messing up internal APIs nearly every time.)
Sometimes in the past I also used the QEMU version provided by macPorts, and the only issue I had was with my non English keyboard, if you use a US keyboard layout you shouldn't have any issues at all.
Still, I am surprised, you seem to imply that you need to provision a new VM because of trouble with TypeScript/VSCode? Not sure what you are doing, or what plugins in VSCode you are running, but that I have to provision an entirely new VM to solve such kind of problems never happened to me and I haven't heard about that in my environment (big company, quite a lot of VSCode and TypeScript users).
Running Trixie/Gnome on a machine with 4GB (3.6GB usable) w/o any trouble.
Gnome runs better than ever, the problem is in my experience usually the web browser when it comes to RAM usage. Install ZRAM and the machine should be perfectly usable, if your usage patterns are similar to mine.
(Only thing which annoys me is that I cannot find an excuse to buy a better computer, because everything simply works on the machine...)
Tried to upgrade from Bookworm to Trixie for my desktops end of April.
Only thing that was broken was the desktop background, everything else worked great w/o any issue and even solved some trouble I had to fix by hand for Bookworm (WiFi sleep mode), so I upgraded all my physical and virtual machines.
Had no issues at all, only thing annoying compared to running stable was the amount of updated packages, which again run trough w/o any hitch and I have to take full responsibility. ;-)
Highly recommended if you want a Linux distribution for a server or a desktop which simply works and keeps working.
IMHO it is one of the big tragedies of modern IT history, that JavaScript and Python 'own' the market for scripting languages in the mainstream.
From a pure technical perspective, I would guess JRuby or one of the JavaScript implementations would have been a better choice for scripting, especially given the poor state of Jython.
From a pragmatic perspective and what your users are mostly able to figure out, Python might have been the best choice. I even saw software developers with years of experience in imperative languages struggling to understand Rubys blocks...
Out of pure interest: What was the purpose of the Java application and which aspects did you allow the users of the application to script with Jython?
Most comments here surprise me: I am using Githubs Copilot / ChatGPT 4.0 at work with a code base which is mostly implements a basic CRUD service... and outside of small/trivial example (where the generated code is mostly okay), prompting is more often than not a total waste of time. Now, I wonder if I am just totally unable to write/refine good prompts for the LLM (as it works for smaller samples, I hope I am not too far off) or what could explain the huge discrepancy of experience.
(Just for the record: I would totally not mind if the LLM writes the code for the stuff I have to do at work.)
To clarify my questions:
- Who here uses LLMs to generate code for bigger projects at work? (>= 20k lines of code)
- If you use LLMs for bigger projects: Do you need to change your prompting strategy to get good results?
- What programming languages are you using in your code bases?
- Are there other people here who experience that LLMs are no help for non trivial problems?
I'm in the same boat. I've largely stopped using these tools other than asking questions about a language that I'm less familiar with or a complex type in typescript for which it can be helpful (sometimes). Otherwise, I felt like I was just wasting my time and becoming lazier/worse as a developer. I do wonder whether LLMs have hit a wall and we're in a hype cycle.
Yes, I have the same feeling about the wall/hype cycle. Most of my time is understanding code and formulating a plan to change code w/o breaking anything... even if LLMs would generate 100% perfect code on the first try, it would not help in a big way.
One thing I forgot to mention is asking LLMs questions from within the IDE instead of doing a web search... this works quite nice, but again, it is not a crazy productivity boost.
My employer gives me access to Jetbrains AI, I work on a Vue Frontend with a Kotlin Spring Boot backend.
The codebase is not too old and has grown without too much technical debt, with complex prompts I never had decent success. Its usefull for quick "what does this do" checks but any real functionality seems to be lacking.
Maybe I'm not refining my prompts good enough but doing so would take longer than implementing it myself.
Recently I tried Jetbrains Junie, which acts like Claude if I understand it correctly.
I had a really refined prompt, ran it three times with adjustments and fine tuning but the result was still lacking.
So I tossed it and wrote it myself. But watching the machine nearly getting it right was still impressive.
Jetbrains AI runs on a "discount LLM" and their ratings were below 2 stars. I tried two others, which played games with me to reduce context and use cheaper models. I then switched to Aider which leads me to believe a moderate Claude user may need to spend 30$ a month, but I use Gemini models and I didnt exceed 5$.
You are just bad with prompting or working with very obscure language/framework or bad coding pattern or all of it.
I had a talk with a seasoned engineer who has been coding for 50 years and has created many amazing things over lifetime about him having really bad results with AI tools I suggested for him.
When I use AI for the same purposes in the same repo he's working on, it works nicely. When he does it, results are always not what he wants.
It comes down to a combination of him not understanding how to guide the LLMs to correct direction and using a language/framework (he's not familiar with) he can't judge the LLMs output.
It is really important to know what you want, be able to describe it in short points (but important points). Points that you know ai will mess up if you don't specify. And also be able to figure out which direction the ai is heading with the solution and correct it EARLY rather than later.
Not overloading context/memory with unnecessary things. Focusing on key areas to improve and much more.
I'm using AI to get solutions done that I can definitely do myself but it'll take a certain amount of time to hunt down all documentation, API/lib calls etc. With AI, 1/10th time is enough.
I've had massive success with java, js/TS, html css, go, rust, python, bitbucket pipelines/GitHub actions, cdk, docker compose, SQL, flutter/dart, swift etc.
I've had the same experience as the person to whom you're responding. After reading your post, I have to ask: if you're putting so much effort into prompting it with specific points, correcting it often, etc., why not just write the code yourself? It sounds like you're putting a good deal of effort into prompting it.
Aren't you worried that overtime you'll rely on it too much and your offhand knowledge will get worse?
I'm still spending less effort/time. A very significant amount.
I do write plenty of things myself. Sometimes, I ignore AI completely and write 100s of lines. Sometimes, I take copilot suggestions every other line, as I'm writing something "common" and copilot can "read" my mind. And sometimes, I write 100s of lines purely by prompting. It is a fine line when to do which; also depends on mood.
I am not worried about that as I spend hours everyday reading. I'm also the type of person who, when something is needed in a document, do not search for it using CTRL+F, but manually look thru it. It always takes more time but I also learn adjacent things to the topic I need.
And I never commit a single line from AI without reading and understanding it myself. So it might come up with 100 line solution for me, but I probably already know what I wanted and off chance it came up with something correct but in a way I did not know, I do read and learn it.
Ultimately, to me, the knowledge that I can !reset null in docker compose override is important. Remembering if it is !null reset or reset !null or !reset null (i.e., syntax) is not important. My offhand knowledge is not getting worse as I am constantly learning things; I just focus less on specific syntaxes or API signatures now.
You can apply the same argument with IDE. Almost all developers will fail to write proper JS/TS/Java etc without IDE help.
I have read somewhere, that LLMs are mostly helpful to junior developers.
Is it possible the person claiming success with all these languages/tools/technologies is just on a junior level and is subjectively correct but has no point of reference how fast coding is for seniors and how quality code looks like?
1. You have read somewhere...but you don't have any experience. LLMs are really bad for Junior developers.
A. They have no skills/exp to judge AI output
B. They don't learn from sudden magical wall of code output
C. They don't get to explore; thus don't learn.
D. Ultimately, LLMs act as a bad drug to them that keeps them dependent and stagnant.
E. LLMs are really good for higher end of senior devs. This also means, they don't need as many Juniors anymore and they don't mentor juniors much. This is the biggest loss for Juniors.
2. I think you are absolutely right. I became a Staff Engineer with junior level LLM coding. More power to me I guess :(
Not OP, it be comes natural and doesn't take a lot of time.
Anyway, if you want to, LLMs can today help with a ton of programming languages and frameworks. If you use any of the top 5 languages and it still doesn't work for you, either you're doing some esoteric work or you're doing it wrong.
Could you point me to a youtube video or a blog post which demonstrates how LLMs help writing code which outperforms a proficient human?
My only conditions:
- It must be demonstrated by adding a feature on a bigger code base (>= 20 LOC)
- The added feature cannot be a leaf feature (means it must integrate with the rest of the system at multiple points)
- The prompting has to be less effort/faster than to type the solution in the programming language
You can chose any programming language/framework that you want. I don't care if it is Java, JavaScript, Typescript, C, Python, ... hell, I am fine with any language with or w/o a framework.
I do not rule out, that I am just very bad with prompting.
It just surprises me, that you write you had massive successes with "java, js/TS, html css, go, rust, python, bitbucket pipelines/GitHub actions, cdk, docker compose, SQL, flutter/dart, swift etc.", if you include the usual libraries/frameworks and the diverse application areas for these technologies, even with LLMs support it seems to me crazy to be able to make meaningful contributions in non trivial code bases.
Concerning SQL I can report another fail with LLMs, in a trivial code base with a handful of entities the LLM cannot come up with basic window functions.
I would be very interested if you could write up a blog post or could make a youtube video demonstrating your prompting skills... Perhaps demonstrating with a bigger open source project in any of the mentioned languages how to add a non trivial feature with your prompting skills?
Unfortunately, I'm at a stage of personal life where I do not have time to blog. I'd love to but :(
The stuff I work on for company is confidential and even getting authorization to use AI was such a hassle.
Based on some of your replies, I think you have an impression of current generation AIs that is 100% wrong. I can not blame you as the impression you have, is what the AI companies want you to have, that's what they are hyping.
In another comment, you mentioned someone should demo how AI can add a non-leaf feature to a non-trivial LOC codebase. This is what AI companies say AI can do. But the truth is, (current gen) AIs can not do this except a few rare cases. I can not demo this to you as I can't do this and do not attempt to do it either on day to day tasks.
The issue is context. What you are asking requires AI to have a huge amount of context that it simply is not equipped to handle (at least not right now).
What AIs are really good at is to do small fragment of a task given enough clear requirements.
When I want AI to write a Handler in my Controller, I don't just ask it to "write a function to handle POST call for entity E."
I write the javadoc /* */ comment that defines the signature and explains a little about how the core process of this handling works. I can even copy/paste similar handler from another controller if I think that will help.
Ultimately, my brain already knows the input, output and key transformations that needs to happen in this function. I just write minimal amount (esp comments) and get AI to complete the rest.
So if I need to write a non-leaf feature, I will break it down to several leaf features and then pass it on to AI and if needed, manually assemble them.
I had to write 500LOC bash script to handle a software deployment. This is not the way to do it but I was forced by circumstances created by someone else. Anyways, if I had to write the whole thing by hand, it'd take multiple days as bash syntax is not forgiving and the stuff I needed to do in the script were quite complex/crazy (and stupid).
I think I wrote about 50+ lines of text describing the whole process, which you can think of as a requirement document.
With a few tries, I was able to get the whole script with near accuracy. My reading revealed some issues. Pointed them to AI. It fixed them. Tests revealed some other issues. Again, AI fixed them after pointing out. I was able to get the whole thing done in just an hour or so.
Play with Cursor or Claude Code a bit and then make a decision. I am not on the this is going to replace Devs boat, but this has changed the way I code and approach things.
Could you perhaps point me to a youtube video which demonstrates an experienced prompter sculpting code with Cursor/Clause Code?
In my search I just found trivial examples.
My critic so far:
- Examples seem always to be creating a simple application from scratch
- Examples always use super common things (like create a blog / simple website for CRUD)
What I would love to see (see elsewhere): Adding a non trivial feature to a bigger code base. Just a youtube video/demonstration. I don't care about language/framework etc. ...
This morning I made this while sipping coffee, and it solves a real problem for my gf: https://github.com/kirubakaran/xmldiffer Sure it's not enormous, and it was built from scratch, but imho it's not a trivial thing either. It would've taken me at least a day or two of full time work, and I certainly don't have a couple of days to spare on a task like this. Instead, pair programming with AI made it into a fun relaxing activity.
> Now, I wonder if I am just totally unable to write/refine good prompts for the LLM (as it works for smaller samples, I hope I am not too far off) or what could explain the huge discrepancy of experience.
Programming language / stack plays plays a big role, I presume.
Same here. We have a massive codebase with large classes and the LLMs are not very helpful. Frontend stuff is okay sometimes but the backend models are too complex at this point, I guess.
Just a list of bad/wrong decisions IMHO:
- Reference counting instead of using a real garbage collector
- The pyproject.toml format is under-specified, comes decades too late for a problem that has been solved good enough by Apache Maven more than 2 decades ago
- The absolutely weak support for functional programming, which then was patched by list comprehensions and co later
- venv and other solutions to isolate dependencies for a project
Python is successful because of the community support and a binding to almost everything, and this sadly outweighs a lot of poor choices from the language designers and the implementation. I just always feel frustrated, that during the great breakup from 2-3, they didn't try to fix more of the known issues (which again, have been solved by other communities decades before) instead of breaking the world and still managing to half ass it.