You ever have a user who pines for this or that feature, and when you tell him it's already implemented, he'll change the goalposts in some trivial way? It's not solutions we love, it's the warm fuzzy narcissism of complaining.
You seem challenged with having a basic discussion without resorting to baseless personal attacks. HN discussions have nosedived in quality over the time. Feel like I'm on reddit.
On the topic - here were my original points (with some extensions):
1. I want a smalltalk-like environment but with modern languages (webassembly makes this technically possible)
2. Alan Kay himself agrees smalltalk is no longer relevant in a concrete manner anymore - it's too old and outdated. The library support is absymal, and LLMs etc won't be as helpful as modern langs, since the training data available is less in quantity and quality. And I am in line with Dr. Kay's view - Smalltalk is indeed too old. I feel the same way about using Lisp for my particular goals.
3. I am not complaining in any way - just stating my requirements in explicit terms. Also I dont consider myself a "user". I am a system builder. I am fully capable of doing things myself if there's no alternative available.
Interesting stuff - none of these seem to have that Smalltalk-like visual IDE bolted right into them.
Given how big and important a platform the modern web is - I really am starting to think - something like this should exist - where I have a neat little IDE bundled right within the browser using which I can evolve the browser...
Amazon still has huge R&D spends, always had. Bezos had a dictum around having a high experimentation (and failure) rate as a matter of principle. They may not be making news-making moves, but I'm sure they'll develop the muscle in AI. Probably - just really honing on the customer use cases and working backwards over the long term.
Proof != evidence. In evidence, we corroborate, collate, add more sources, weigh evidence, judge. Proof is a totally different process. Only in the mathematical do one prove something, everywhere else we build up evidence, corroborate, etc.
Try finding PhD Students and see if you can help with their programming or experiments. You'll learn more about how to do research from a PhD student in months, rather than struggling on your own. Once you have the "learning to learn" chops, you're free to study anything you want at incredible depth.
Go's CSP model works well, if you first take the time to study it up a bit. The only drawback with the docs is they don't focus on correctness and potential concurrency bugs sufficiently. In the very least the stdlib could mark whether particular functions are goroutine safe or not. If you stay guarded for such things, you should be able to get a lot done with very few mistakes.
I have limited experience with Rust, but the ownership model and the borrow checker help with avoiding concurrency bugs as well. And personally for me, Rust slowed down the speed at which I could proceed solving the problem at hand. If you have time on your hands or you're very fluent with it, rust may give better results.
LLMs are usually used to describe goals or to provide feedback (correction or encouragement) towards its implementation.
Programming is about iteratively expressing a path towards satisfying said goals.
What LLMs are doing now is converting "requirements" into "formalizations".
I don't think Djikstra is wrong in saying - that performing programming in plain-language is a pretty weird idea.
We want to concretize ideas in formalisms. But that's not what any human (including Djikstra) starts with... you start with some sort of goal, some sort of need and requirements.
LLMs merely reduce the time/effort required to go from goals -> formalism.
reply