3 ms·
Programming is encoding: some reduction of reality into a model suited to algorithms doing what we need. The reduction to model and scope to algorithms are nec
by w10-1 4y ago
Programming is encoding: some reduction of reality into a model suited to algorithms doing what we need.
The reduction to model and scope to algorithms are necessary and unavoidable. All of the criticisms made are objections to the selected model or limited set of algorithms.
That includes text as the standard "model". By contrast, IBM VisualAge in the 1990's had a true AST-based model of the code, and showed text as views. It did (some) amazing things, but people hated it because there was no way to make it do other things they wanted.
I would add the disparity between the granularity of commits and comments. Clearly, I should be able to describe specific changes in a file and provide high-level account of a long-running task without collapsing everything into one history.
Proposal: A single AST model, configurable for multiple languages, with JVM & LLVM back-ends, and automagic support for IDE's via LSP and program transforms like language conversion, slicing, and aspects.
The killer app there would be transforms for parallelism to the processor-specific vector instructions. That would capture more of the value of the oncoming onslaught of processor architectures.
- galaxyLogic 4y agoOne of the brilliant things about Smalltalk was its change-management. You didn't just store programs, you stored "changes" to existing programs which assumes a context of existing 'classes" into which such changes can be applied. Contrast that with current CVSes like git where you don't store changes to the objects you create or have created earlier, but just changes to which files exist in your (git-based virtual) file-system. Git only knows about things like "files" and "folders", not about objects the user creates. Therefore you can not view a git-repo as a set of changes to your "program", it is only a set of changes to files and folders.
- ElectricalUnion 4y agoGit don't even know about "folders", it's just implied from file names stored in the git trees. https://git.wiki.kernel.org/index.php/GitFaq#Can_I_add_empty_directories.3F https://git.wiki.kernel.org/index.php/GitFaq#Can_I_add_empty... > Currently the design of the Git index (staging area) only permits files to be listed, and nobody competent enough to make the change to allow empty directories has cared enough about this situation to remedy it. > Directories are added automatically when adding files inside them. That is, directories never have to be added to the repository, and are not tracked on their own. > You can say "git add <dir>" and it will add the files in there. > If you really need a directory to exist in checkouts you should create a file in it. .gitignore works well for this purpose (there is also a tool MarkEmptyDirs using the .NET framework which allows you to automate this task); you can leave it empty or fill in the names of files you do not expect to show up in the directory.