twa927

> Code becomes only one representation of thought among many overlapping ones.

This is wrong, code is the concrete "truth" being executed, the rest (plans, prompts, agent instructions) are just temporary artifacts used to generate the code. What's left is the code alone.

LLMs don't have any semantics, they can't execute anything with 100% certainty. So far programming languages are the only langugues that can do that.

It's like if class-based society materialized within the IT. And the manager class collectively pushes the narrative of AI replacing ICs.

Note that it has beaten capitalism, making rational choices to increase earnings has lost to this AI dream.

Yes I'm using Sonnet 4.5. Thanks for the tip, will try Opus 4.5, although costs might become an issue.

Hmm, your comment gave me the idea that maybe we should invent "What You Describe Is What You Get|. To replace HTML+Tailwind spaghetti with prompts generating it.

I don't see the AI capacity jump in the recent months at all. For me it's more the opposite, CC works worse than a few months ago. Keeps forgetting the rules from CLAUDE.md, hallucinates function calls, generates tons of over-verbose plans, generates overengineered code. Where I find it a clear net-positive is pure frontend code (HTML + Tailwind), it's spaghetti but since it's just visualization, it's OK.

Found something here: https://github.com/bccp/covid-19-data

> However, at some point it seems that everyone at my stage is moving into management or higher level positions doing project management, meetings, architectural discussions

This impression is mostly generated by your head, to be more specific - by the social pressure to "make a career" and to regard technical skills as inferior to management skills. I don't think it's real, I saw many old people working as programmers, and there will be many more because there are more programmers among the current 20-30 year-olds, compared to the older generations. Also there's simply many more technical jobs available and there won't be enough management positions available to allow the switch for everyone. And the pandemic looks also like a quite big factor in reducing the number of management jobs (it looks like you often can work as usual without all the managers...).

The problem I experienced multiple times in 50-200 KLOC projects is not the time needed to import the modules, but the memory consumption caused by the imports. Moving some imports from top-level module statements to inner functions' code could improve the memory consumption several times, e.g. from 250MB per process to 80MB per process.

One tool I used was https://github.com/mnmelo/lazy_import but I'm not sure it's updated for Python 3.7/3.8.

That's very nice code and Python is non-functional. I love its generators.

That's my version to make it more "functional":

  from itertools import cycle, islice
  from operator import add

  fizz = cycle(['', '', 'Fizz'])
  buzz = cycle(['', '', '', '', 'Buzz'])
  strings = map(add, fizz, buzz)
  strings_or_nos = (s or i for i, s in enumerate(strings, start=1))
  print(list(islice(strings_or_nos, 100)))

Yes, this also seems weird to me. And I think it might be a cultural thing, I noticed that in Europe renting dedicated servers is far more popular than in the US.

I ride a bicycle daily and vape e-cigs. If anything I notice an increased performance immediately after vaping, I feel like I'm less tired and have more energy.

Overall this is an interesting topic because contrary to popular opinion many athletes use nicotine and find that it increases their performance: Nicotine [...] use is widespread amongst professional team/strength sports (e.g. American football, ice hockey, wrestling, bobsleigh, gymnastics, rugby, skiing) whereby active consumption of nicotine and nicotine-containing substances in-competition occurs in approximately 25–50% of such athletes [1].

The meta-analysis [1] found that two studies observed an ergogenic effect, one an ergolytic with the remaining seven reporting no change.

[1]: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5684328/

But even for fully on-site teams the preferred format of a "knowledge base" is digital (wiki, Google Docs, etc.), because it's something that lasts, can be improved over time and is always accessible. And having the discussions stored digitally (Github issues, emails) is also usually preferred because it's "asynchronous" and it's something that can be looked up in the future.

So on-site teams also use Wikis/issue trackers/emails a lot. The difference is that instead of a face-to-face chat remote teams have to use Slack. Which is also largely used in on-site teams... So my point is that some of the modern IT offices already resemble a "co-working" space because all the tools are already digital, and all meaningful knowledge sharing already happens in the digital space.

You must be more active when working remotely wrt. seeking social interactions. When working on-site, you get some of the interactions for free. When working remotely, you must actively organize them by yourself. I know people who get MORE social interactions from working remotely because they have more energy/time for things like meeting with friends, clubs meetings etc.

Quite nice presentation about remote work from PyCon 2019: https://www.youtube.com/watch?v=CTWgKyLk6mo

This is generally pro-remote but it includes research results.

So where should I look up the definition of a DSL?

> That's an unjustified qualification. I could throw together a spreadsheet format that is all text. The spreadsheet GUI then becomes a advanced text editor that, when editing that particular format, exposes advanced content-aware controls not at all unlike advanced text editors like emacs can for s-expressions.

If you could invent a text format that could be efficiently edited with a basic text editor then I would agree it's a DSL. But I feel like you would lose a lot by dropping a dedicated GUI, e.g.:

- horizontal scrolling of columns, adding, hiding columns

- "smart copying" a formula by scrolling down

- selection of rows/columns/cells

I don't think anybody would use such DSL using a basic editor.

Overall it's discussion about the definitions of terms, but I don't understand why people want to capture anything having some "editable format" as a "DSL" when addtional terms like "visual programming" allow more differentiation?

I think these are examples of a https://en.wikipedia.org/wiki/Visual_programming_language, while https://en.wikipedia.org/wiki/Domain-specific_language#Examp... are purely text-based.

Are such successful DSLs described somewhere?

Generally my feeling is somehow similar to the one expressed in the blog post, ie. that DSLs don't work for non-technical people. If someone is able to use a DSL then he/she is also able to do regular programming, and many people don't have such abilities. And regular programming languages are better tools for the ones with the abilities.

I think DSLs are about defining a 100% textual format. And spreadsheets are GUI apps. There's a DSL for defining a cell formula but in total it's a small part of the experience of using a spreadsheet app.

I skimmed over it but it's again mostly about internal design. The high level use case I see is "publish-subscribe" which is handled by RabbitMQ and a dozen of other solutions.

One use case I see is that the events published into Kafka are persisted so e.g. some component can see a history of some events (so this is something not handled by RabbitMQ). Is it right?

Can someone provide actual high-level use cases for using Kafka? Prefereably use-cases not handled by RabbitMQ.

I've seen a few talks about Kafka but they focused on the internals. My guess is that Kafka is for large systems for which managing a multi-node RabbitMQ cluster is too much trouble.

> just because capitalist are competing for labor doesn't mean that management switches from being agents of capital to agents of labor. Valuable, contested human resources are still resources, not owners.

Yes, I generally agree, but it goes as follows:

1. The business owners care only about achieving their business goals.

2. To achieve the business goals the owners need to have good employees.

3. To hire and retain good employees some business decisions should take into cosiderations the needs of the employees.

So even from the purely economical point of view there should be some balance between 1. and 3.

And overall your purely economical point of view seems too rigid to me. One example that comes to my mind is the cultural shift happening at Microsoft. The company made many decisions with little business sense like open sourcing many projects and providing free developer tools. But the effect is that developers like the company more. This has measurable effects like Azure success or hiring better employees. I think this is an example of a bottom-up-built success which doesn't fit your top-down viewpoint.

This sounds like early 20th century capitalism... I don't think it's very applicable to the current programming industry, where companies have to fight to retain good employees. Also, the top-down structure is no longer preserved within the Agile's "self-organizing teams". So in this landscape I think it's very reasonable to take seriously what programmers think about the given internal software.

Yes, reflection voids many JIT paths in PyPy, AFAIK. Maybe it was worth rewriting the Python code to get rid of the reflection?

It's good that the managers care for the higher-level "business" goals, but shouldn't they care for their subordinates more? In the end it also contributes to a business metric - employee happiness. When I was switching a corporate job to a startup job the fact that I switched from a corporate Outlook and a proprietary issue software to GMail and Github made me happier.

For some reason many "enterprise" software products are clunky and buggy. I guess this is because the decision to use the software is made by managers who don't ever use it.

If this was using a loop processing a single byte in an iteration I would expect a greater speedup on PyPy. I've seen 100x speedup in such cases.