201–210 of 236 posts
Earlier quoted context omitted.
I've found JS/TS Web stacks equally lacking and ugly after Django. I'm totally spoiled by a decade in Django. Just let me build a CRUD app, on the server, that spits out HTML without an excessive swamp of unmaintained nonsense and a cultish abhorrence of simplicity.
what do django do that's contrived in js or say aspnet or rails?
Earlier quoted context omitted.
It's unrelated to the lazy keyword. Instead it's another feature related to error messages. The example: >> 'hello'.toUpperCase() Traceback (most recent call last): ... AttributeError: 'str' object has no attribute 'toUpperCase'. Did you mean '.upper'?
I’ve often thought it would be funny if instead of an error message for stuff like this, a language could be designed to be “typo-insensitive”. If a method or function call is similar enough to an existing one or a common one from other languages, to just have it silently use that.
Earlier quoted context omitted.
This is straightforward in the first instance, but how do you see maintenance of those projects going forward - especially adding more complex features ? I can see one way forward being to prototype them in python and convert.
It’s completely the opposite. LLMs write awful python. Horrendous. They write pretty reasonable go and do it quite quickly. We started in Python because of “the ecosystem”. It was a mistake. The amount of time we spend ripping out each dependency and pruning it to what we need is way higher than if we’d spent the month building out what we need. I miss compilers and LLMs will NOT generate config driven code or things…
I've been using Claude Opus and it's pretty competent. I rarely have to make steering corrections. Once I had to deal with confusion, but, overall, the code is neat and the approaches sensible. It all depends on how much context you give it to work from, for instance. If it's building on top of a well organized codebase with a good best-practices document, it performs just fine.
Earlier quoted context omitted.
I’ve often thought it would be funny if instead of an error message for stuff like this, a language could be designed to be “typo-insensitive”. If a method or function call is similar enough to an existing one or a common one from other languages, to just have it silently use that.
At the very least Python could quit on `quit` instead of saying that it knows what I want, but won't do it.
Earlier quoted context omitted.
On most unix-likes all "imports" via shared libraries (e.g. in C / C++) are lazy by default.
Eh, resolving object symbols is something done at runtime. #include absolutely is eager. I wouldn’t compare this in any way to Python’s lazy imports.
I used to be obsessed about language design and now, since I almost never write code directly (it's always Claude), I completely lost interest. It feels like a total waste of time and I wonder if other feel the same. One of the consequences of the LLM tsunami might be the freezing of research and development in programming languages. Maybe we'll be stuck with J's and python forever...
> I almost never write code directly (it's always Claude) Who, then, understands the code? If the answer is "no one really", entropy will overwhelm your codebase sooner or later. Otherwise, you need to read the code, and for that the knowledge of language is still relevant.
Earlier quoted context omitted.
Well it might prefer libraries but the culture around basic DX things like ORMs is toxic. Just write the SQL yourself they say, until they themselves optimise to a half baked in-house ORM of their own.
I don't think I will ever understand the culture of Go. The syntax of a very low level language (needlessly verbose), combined with the performance of a very high level language (needlessly slow), with a bizarre aversion to any DX conveniences (pattern matching, ORMs, etc). If you're already giving up all that performance, why would you not take the extra convenience? Not to mention that the demographic using Go - a…
Had the rewrites not taken place, or Rust already being 1.0 by then, most likely would have had as many commercial success as Oberon and Limbo managed to.
You see this happening nowadays newer CNCF projects tend to be done in Rust, and there are even some that even go the C++ way, e.g. Envoy.
Earlier quoted context omitted.
> When an AttributeError on a builtin type has no close match via Levenshtein distance, the error message now checks a static table of common method names from other languages (JavaScript, Java, Ruby, C#) and suggests the Python equivalent Oh, that is such a nice thing.
It's unrelated to the lazy keyword. Instead it's another feature related to error messages. The example: >> 'hello'.toUpperCase() Traceback (most recent call last): ... AttributeError: 'str' object has no attribute 'toUpperCase'. Did you mean '.upper'?
Earlier quoted context omitted.
It's unrelated to the lazy keyword. Instead it's another feature related to error messages. The example: >> 'hello'.toUpperCase() Traceback (most recent call last): ... AttributeError: 'str' object has no attribute 'toUpperCase'. Did you mean '.upper'?
I’ve often thought it would be funny if instead of an error message for stuff like this, a language could be designed to be “typo-insensitive”. If a method or function call is similar enough to an existing one or a common one from other languages, to just have it silently use that.
Earlier quoted context omitted.
It turns out that volume of training data isn't the most important thing. Elixir beats Kotlin and C#, which beat pretty much everything else. Kotlin is probably the sweet spot for most things.
"sweet spot for most things." care to expand on this a bit? Thanks.