Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tilde, My LLVM Alternative

yasserarg.com

Post reply on HN
Print view View original

51–60 of 165 posts

Re: Tilde, My LLVM Alternative

#51

Post by Rochus »

uecker wrote: post #43
Rochus wrote: post #20

Earlier quoted context omitted.

We are fortunately free to ignore "C23 and C2y" and stick with C89 (with the common extensions) or C99.

What are the specific things you do not like about C23 or the C2y road map (whatever this is, it is more random walk)? I have my own list of course, but overall I still have some hope that C2y does not turn out to be a total disaster.

I've spent too little time with the recent standards/draft to give a specific answer. But I have a general attitude: C89 with extensions or C99 were just perfect for almost any purpuse; newer standards may well correct minor inadequacies or integrate things, that used to be implemented by proven libraries, directly into the language; but the price for these relatively minor improvements is high; people who write supposedly reusable code in the newer standards effectively force all older projects to switch to the newer standard; the costs of this are rarely justifiable. And there is C11 which made mandatory parts of the C99 standard optional, thus breaking backwards compatibility.

Re: Tilde, My LLVM Alternative

#52

Post by o11c »

jcranmer wrote: post #35
muke101 wrote: post #19

If you're going to rewrite LLVM, you should avoid just trying to 'do it again but less bloated', because that'll end up where LLVM is now once you've added enough features and optimisation to be competitive. Rewriting LLVM gives you the opportunity to rethink some of its main problems. Of those I think two big ones include Tablegen and peephole optimisations. The backend code for LLVM is awful, and tablegen only part…

> The backend code for LLVM is awful, and tablegen only partially addresses the problem. Most LLVM code for defining instruction opcodes amounts to multiple huge switch statements that stuff every opcode into them, its disgusting. This code is begging for a more elegant solution, I think a functional approach would solve a lot of the problems. So one of the main problems you run into is that your elegant solution onl…

"Everything should be as simple as it can be but not simpler!" —Roger Sessions, loosely after Albert Einstein

Re: Tilde, My LLVM Alternative

#53

Post by pkal »

pveierland wrote: post #40
fguerraz wrote: post #16

Looking at the commit history inspires some real confidence! https://github.com/RealNeGate/Cuik/commits/master/

Eh, when you're hacking away as a solo developer on something big and new I don't think this matters at all. In my current project I did about 200x commits marked "wip" before having enough structure and stability to bother with proper commit messages. Whatever lets you be productive until more structure is helpful.

Perhaps, but I still think it is lazy. A very nice counter example of someone with high commit standards can be seen in this repository: https://github.com/rmyorston/pdpmake/commits/master/

Re: Tilde, My LLVM Alternative

#54

Post by apocalypses »

KolmogorovComp wrote: post #30
artemonster wrote: post #25

Earlier quoted context omitted.

went to write exactly that. Ambitions are great and I dont want to be dissuasive, but monumental tasks require monumental effort and monumental effort requires monumental care. That implies good discipline and certain "beauty" standards that also apply to commit messages. Bad sign :)

Not really. In the initial phase of a project there is usually so much churn than enforcing proper commit messages is not worth it, until the dust settle down.

I massively disagree. It would have taken the author approximately 1 minute to write the following high quality hack-n-slash commit message:

``` Big rewrites

* Rewrote X

* Deleted Y

* Refactored Z ```

Done

Re: Tilde, My LLVM Alternative

#55

Post by kccqzy »

torstenvl wrote: post #49
kccqzy wrote: post #37

Earlier quoted context omitted.

I am deeply suspicious of anyone who doesn't bother or who is unable to explain this churn. For the right kind of people, this is an excellent opportunity to reflect: why is there churn? Why did the dust not settle down? Why was the initial approach wrong and reworked into a new approach? I can understand this if you are coding for a corporate. But if it's your own project, you should care about it enough to write go…

Is your objection to the inevitable fact that requirements churn early on (regardless whether you're doing agile or waterfall)? Or is your objection that solo devs code up prototypes and toy with ideas in live code instead of just in their mental VM in grooming sessions? Or is your objection that you don't think early prototypes and demos should be available in the source tree?

None of the above. My objection is the lack of explanation.

Churn is okay. Prototypes are okay. Toying with ideas is okay. They should all be in the source tree. But I would want an explanation for the benefit of future readers, including the future author. Earlier in my life I have more than once run blame on a piece of code to find myself writing a line of code where the commit message does not explain it adequately. These days it's much rarer because I ask myself to write good commit messages. Furthermore the act of writing a commit message is also soothing and a nice break from writing for computers.

Explain how requirements have changed. Explain how the prototype didn't work and led to a rewrite. Explain why some idea that was being toyed with turned out to be bad.

Notice that the above are explanations. They do not come with any implied actions. "Why is there churn" is a good question to answer but "how do we avoid churn in the future" is absolutely not. We all know churn is inevitable.

Re: Tilde, My LLVM Alternative

#58

Post by kibwen »

sylware wrote: post #10

Again, somebody who comes to the realization something is seriously wrong with ultra-complex languages in the SDK (c++ and similar). In other words, since this alternative LLVM is coded in plain and simple C, it is shielded against those who are still not seeing that computer languages with an ultra complex syntax are not the right way to go if if want sane software. You also have QBE, which with cproc will give you…

C itself is an ultra-complex language. I do not understand the mindset of the "C is simple" crowd. Is it nostalgia or romanticism for the past? If we want to devise a truly simple language, we need to start by realizing that C is just the Javascript of its day: hacked together in a weekend by someone who wished they were using a different language and then accidentally catapulted into the future by platform effects.

Re: Tilde, My LLVM Alternative

#59

Post by fuhsnn »

uecker wrote: post #44
sylware wrote: post #10

Again, somebody who comes to the realization something is seriously wrong with ultra-complex languages in the SDK (c++ and similar). In other words, since this alternative LLVM is coded in plain and simple C, it is shielded against those who are still not seeing that computer languages with an ultra complex syntax are not the right way to go if if want sane software. You also have QBE, which with cproc will give you…

It is great to see some new C tooling emerge. I will likely make my own C FE public some time but it now uses some toy backend which needs be replaced...

There is no shame in simple codegen if it is correct and unsurprising!

Re: Tilde, My LLVM Alternative

#60

Post by twic »

oguz-ismail wrote: post #46
IshKebab wrote: post #32

I dunno if "twice as fast as Clang" is very impressive. How fast is it compared to Clang 1.0? Also starting a new project like this in C is an interesting choice.

> interesting choice No serious alternative

Compilation is high-level work, so you could do it in any high-level language.
Post reply on HN