I did not try Clojure so I cannot comment on how well implemented the features you quote are, when compared to CL. All I can say is that CL also provides much of the same functionality with its standard, cl-async, lparallel, parenscript, while (im)mutability is a matter of preference (IMO correct decision by CL) rather than dominance. The way I see it, is that CL is superior (opinion) due to reader macros and native compilation, rather than bytecode JVM.
> The most impressive thing humans can do is to think.
> And the best kind of thinking, or more precisely the best proof that one has thought well, is to make good new things.
> ... but making good new things is a should in the sense that this is how to live to one's full potential.
I urge you not to take these opinions as facts. Originality is admirable, but it is not "your potential", "proof of great thoughts", or "the most impressive thing you can do".
The answer to the question: What to do? is not "Make new things", but rather begins with a simple question: In what context?
The idea of dividing people into two categories: 1) those who "take care of people and the world", and those who 2) "make good new things", is harmful.
In general, a compiler takes source code and generates object code or an executable. Can you elaborate on what your compiler takes as input and generates as an output?
> I found no evidence of someone having invented it before.
Most Lisp/Scheme implementations offer tracing. Amazingly, the SICP book even shows tracing as a means of analyzing whether a recursive function is tail-recursive.
What I'm curious about is the Lisp history of tracing. Does anyone know which implementations were the first to provide tracing functionality?
Tail-call optimization is very important when writing Scheme programs. By removing those, you loose the power of recursion.
Also when it comes to macros, does that include `syntax-rules` or `syntax-case` style macros, where the latter are much more powerful?
While an embedded Scheme-like language is incredibly useful, at some point I feel as if you would simply have to include these features, and to that end it would just be Scheme reinvented.
Making something helps to get hired. Not only is it a show of expertise, but also an expression of your unique personality. What is more, I asked what you want to make right now. Even people afraid of failure make things.
> I want to get out of this learning loop where I keep experiencing that I know nothing so I keep learning and I think I am good for it and then I apply for jobs and the loop repeats itself.
So? Just stop learning. Close that book, video, course. Go make something people want. Or you want. What would you like to make?
It is not easy to follow. And there are many things worth discussing. I understand there are complications with MIPS and C++ just to name a few.
But let me stick with some basics. So, I can write and compile an x86 test.c program. Then, I use your extension and undo the linking. Then, I use the results to link again into a new executable? Are the executables identical? When does it break?
How much of a task is it to make it a standalone program? What about x64 support?
In practice, perhaps a C program that acts as a validation test. The source code of this C program is not publicly available. Only the binary is distributed. Let us name the binary ctestbox.
When ctestbox is run, it creates a multiplicity of new text or binary files. Each of these is like a unit test.
Consider a tool that decompiles a binary. Given ctestbox, this tool should make
a.out which when run, ideally creates identical text or binary files. Now you simply count the number of identical files as a metric.
Why Python? First, python is a language with a large open-source library. Second, I do not think it is used for software that is distributed as binaries?
I would devise a somewhat loose metric. Consider you assign a percentage as to how much a binary is disassembled. As in, 0% means the binary is in assembly and 100% means the whole binary is now C code. The ideal decompiler would result in 100% for any binary.
My prediction is that this percentage will increase with time. It would be interesting to construct data for this metric.
It is important to define the limitations of using LLMs for this endeavor. I would like to emphasize your subtle point. The compiler used for the original binary may not be the same as the one you use. The probability of this increases with time, as compilers improve or the platform on which the binary runs becomes obsolete. This is a problem for validation, as in you cannot directly compare original assembly code with assembly after compiling C code (that came from decompiling).
Perhaps assembly routines could be given a likelihood, as in how sure the LLM is that some C code maps to assembly. Then, routines with hand-coded assembly would have a lower likelihood.
The problem is interesting in at least two aspects. First, an ideal decompiler would eliminate proprietary source code. Second, the abundant publicly available C code allows you to simply make a dataset of paired ASM and source code. There is also a lot of variety with optimization level, compiler choice, and platform.
What is unclear to me is: why did the authors fine-tune the DeepSeek-Coder model? Can you train an LLM from zero with a similar dataset? How big does the LLM need to be? Can it run locally?