> 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.
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.
> 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.
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.
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.
> 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?
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?
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.