agree completely. I used to be (and still would love to be) a process person, enjoying hand writing bulletproof artisanal code. Switching to startups many years ago gave me a whole new perspective, and its been interesting the struggle between writing code and shipping. Especially when you dont know how long the code you are writing will actually live. LLMs are fantastic in that space.
> Tenacity. It's so interesting to watch an agent relentlessly work at something. They never get tired, they never get demoralized, they just keep going and trying things where a person would have given up long ago to fight another day.
This is true to an extent for sure and they will go much longer than most engineers without getting "tired", but I've def seen both sonnet and opus give up multiple times. They've updated code to skip tests they couldn't get to pass, given up on bugs they couldn't track down, etc. I literally had it ask "could we work on something else and come back to this"
The glorified autocomplete. Why would the LLM "work on something else then get back on this", is it's subconscious going to solve the problem during that time?
But because people say it, it says it too. Making sense is optional.
Ive found that clearing the context and getting back to it later actually DOES work. When you restart, your personal context is cleared and you might be better at describing the problem you are solving in a more informationally dense way.
I love duckdb, I use it as much as I can.
I just wish that the support for node/bun was as good as python.
And I wish that they would bundle it differently for node/bun - the way it is now it depends on a dynamic link to a library which means I cant bundle it into a bun executable.
160F, non toxic, this already sounds like something that could feasibly be used in the home. I would already be interested in installing one. And would absolutely love to see what it would do to school performance.
I think the reason python won was that it was easy to learn and read and was batteries included.
vs perl: People need to solve their problems, not fight with syntax
Theres a lot of network effects as well. The more people were using it, the more people will use it.
Python was batteries included, in the standard library, in an era where putting those kinds of things in the standard library made sense.
Now there's tons of stuff they're deathly afraid of removing, that they would never remotely consider adding if it weren't already there. (If you don't believe me, have a flip through proposals on discuss.python.org for new additions. People think of Python as a language that's constantly adding and changing stuff and inadvertently causing breakage as a result, but it's actually very conservative relative to the volume of proposals.)
>>I think the reason python won was that it was easy to learn and read and was batteries included.
This is also a big reason why AI assisted programming will wholesale replace Python programmers.
If your are optimising for people who wish to remain at beginner levels all life, and that replaced people using power tools to solve harder and bigger problems. It shouldn't be surprising that now some automation will replace you.
Perl had the batteries and it had CPAN. Python borrowed the best bits of Perl and enjoyed a reputation which overlooked its many flaws. If it had been scrutinized as much as Perl, we'd have realized it was just as bad but in different ways.
This makes no sense.. Python _was_ heavily scrutinized when it was introduced - the whole "Perl vs Python" comparison was pretty popular for a while, with either of those being declared winner, depending on the author.
If there is really a killer argument for Perl over Python that was overlooked in all those years, why don't you say that argument, or even better, write a blog post explaining why Perl is better than Python? Then we could discuss that instead of nebulous "different ways"/
Perl had charm, it was respected by hackers for the joy it brought people who 'got' it. It still remains a beautiful language that I regret not learning due to having a superior taste. Python had none of it. I still don't understand how it won, stealing the halo of a language while having nothing of the sort. The only argument you can make is boring is better imho.
Perl hacker who tried to switch to Ruby before adopting Python here:
Of _course_ boring is better. How could it not be? If you are trying to solve a problem, the last thing you want to be thinking about is the language itself.
The language you adopt to code up a solution should force you to think clearly, but no more than that. Executable pseudocode is as close to an ideal state as you can get for a high-level language.
Perl, meanwhile, was filled with multiple ways to do things -- famously and absurdly thought of as a virtue -- reveled in side effects, and did so much implicit work with variables and flow that perl was often unreadable by anybody else, including the you of three months from now.
"Python did everything other scripting languages did, but in a cleaner and more comprehensible way" tells you most of what you need to know about Python's victory, but the death blow was delivered by the perl community's love of complexity, which led to the disaster that was Raku.
By the turn of the century, it was clear that python 3 was a better plan for the future than perl 6.
> it was respected by hackers for the joy it brought people who 'got' it
Isn't that the crux of the issue? Perl was great if you're a hacker who 'got' it. For the remaining 95% of the population, Python worked.
Lisp/Scheme are also beautiful to those who 'get' it.
> I still don't understand how it won, stealing the halo of a language while having nothing of the sort.
Plenty of people have already told you. 95% of programmers do programming to get the job done. The linguistics grad student I knew 20 years ago did his work in Python because it was easy (he had no programming background). He would have simply changed his thesis topic if Python didn't exist. He would not have learned Perl.
> Isn't that the crux of the issue? Perl was great if you're a hacker who 'got' it. For the remaining 95% of the population, Python worked.
It’s really not the crux of the issue though. “Better than Perl for normal developers” is not a high bar. Most languages clear that bar whether they are successful or not. This is certainly not the only reason that Python became so successful.
Tangentially, in my experience Perl was great for one liners and small glue projects. I never saw significant, valuable works of code built in Perl even when I worked at a company (Yahoo) that widely used Perl. I am convinced that much of Perl’s beauty is in its cleverness and’s not in its utility for large projects.
> “Better than Perl for normal developers” is not a high bar. Most languages clear that bar whether they are successful or not.
Dial the clock back to 2002, and this statement is not true. Perl became popular not because of its beauty, but because of it being extremely effective glue. It was a language to get stuff done while writing little code.
Did you seriously start this thread just to ask people to confirm your bias?
In that case, yes. Perl is beautiful. Python sucks and only succeeded because idiot developers couldn’t see the beauty of Perl. Python is poorly suited at every job except stealing potential Perl devs.
I don't believe the "syntax win" scenario. Python is also ugly, due to the required indentation, like yaml.
I believe more in the ecosystem, specifically how the computer vision and machine learning movements have adopted python extensively as frontend language (the heavy weightlifting is still doing in C++).
The exploit of numpy has brought many many use cases into the language as well.
Indentation is there regardless, and is increasingly enforced by format-checking tooling which is more commonly an out-of-the-box offering for many ecosystems (gofmt).
So why not make it have syntactical meaning since it’s already there in 99% of cases?
It does feel weird at first but honestly it’s not something you’ll think about much after a while.
> don't believe the "syntax win" scenario. Python is also ugly, due to the required indentation, like yaml.
That's like, your opinion. Python was explicitly designed being easy to learn, borrowing heavily from ABC, which actually experimented with different syntaxes to see what works and what doesn't. The indentations apparently helps a lot with this, along with ':' before the introduction of indented blocks.
That 'ugly' required indentation and whitespace also made Python easier to read, especially for newbies and casual coders. A standard visual structure and a syntax that is pretty close to executable pseudo-code lowered the barrier to entry for a lot of people and made Python feel 'approachable'. This perception that it was easy to use helped increase the network effects other have noted.
It's not about being beautiful or ugly, it's about being simple.
Python is simple to read / write and easier to reason about, especially for people that need a programming language to solve a problem but are not software engineers.
The reason it won, especially in data analysis, is because most data analyst are/were not software engineer and Python feels more natural to people.
The indentation is not a big problem when a decent text editor is used
I was not exposed to much code before trying Python 2, and I always thought of the indentation and newlines as aesthetically pleasing and helpful. Same for yaml actually. Would argue that preferences on indentation etc. are just an acquired case.
"Ugly" is a very opinionated statement there. I personally find it's fine, and Python's required-indentation matches what I'd be doing anyway. It's no different to me than a project which lints indentation via something like gofmt.
I think the controversy around Python’s indentation helped it gain success. Regardless of how you feel about the choice, it’s a great opportunity for bike shedding and encouraged (and still encourages) a lot of talk about the language.
There are all sorts of other arguments people make, but it's frankly incomprehensible to me that some people find indentation-based block syntax "ugly" and the alternatives not so. I must wonder if this extends as far as not indenting code in braced languages.
Data should be data, queryable, relational. So often I have had to change enums into lookup tables - or worse, duplicate them into lookup tables - because now we need other information attached to the values. Labels, descriptions, colors, etc.
My biggest recommendation though is that if you have a lookup table like this, make the value you would have made an enum not just unique, but _the primary key_. Now all the places that you would be putting an ID have the value just like they would with an enum, and oftentimes you wont need to join. The FK makes sure its valid. The other information is a join away if you need it.
I do wish though that there were more ways to denote certain tables as configuration data vs domain data, besides naming conventions or schemas.
Edit to add: I will say there is one places where I have begrudgingly used enums and thats where we have used something like prisma to get typescript types from the schema. It is useful to have types generated for these values. Of course you can do your own generation of those values based on data, but there is a fundamental difference there between "schema" and "data".
well, if DDL (data definition language) and DML (data manipulation language), were unified and both operated on relation , manipulating meta data would have been a lot simpler, and more dynamics
you can always created data dictionary relation, where you stored the code for table creation, add meta data, and use dynamic sql to execute the DML code stored in the DB, i worked somewhere where they did this ... sort of
I'm not the author, but I think you could by using UNION ALL instead of temp tables. You could also make a view that just calls this function. I'm not sure why it would matter though.
