11 comments

[ 5.5 ms ] story [ 27.8 ms ] thread
It lacks a conclusion, except I can see that 750>500
This is my project! I made the Odin version to learn the language, not to create a 1:1 comparison. I 100% prefer Odin over C and will use it wherever I can where I would have otherwise used C.

Also I've moved it from Github to my own Forgejo instance: https://git.liten.app/krig/LISP

My impression of Odin is that it's a better C while still very much retaining the same flavor as C. It adds very little (no classes, no runtime) so porting from C is very straightforward, and it fixes a lot of the dark corners of C. It also seems to be pretty much finished as far as the language goes, so no big incompatible changes coming as far as I can tell.

I would say though that while the memory management story is vastly better than C^, it's still manual as fuck, so be prepared for that.

^: There's builtin test support, bounds checking and an optional leak detection allocator, plus as far as I know no UB.

At first look the Odin version seems less verbose.

The function/struct definition in C could be placed in a header.

Thanks for sharing. Not knowing Odin's syntax yet, having had a quick look at the code, a few things are strange:

Are there two types of assignment?

  p1[0] = 0
  ...
  n := 0
What should this mean? The comma notation usually indicates a pair or left-to-right control flow (Python and C, respectively), but why (appear to) assign a pair to itself? This probably means something else, but it reads odd.

  car, cdr := car, cdr
If Odin is so similar to C, what are the "dark corners" where it outshines it?
Is there something inherent to Lisp that allows it to be implemented in so little code?

I believe I saw someone demonstrate that almost nothing in a Lisp implementation was written as a "built-in" language feature that required the underlying interpreter to provide the functionality.

Yes there's something inherent. Namely this: the ability to drop all sorts of requirements off the table, yet still call it some kind of Lisp.

It does not need to be compiled to be a Lisp. It doesn't need arbitrary precision integers. It doesn't need hash tables. Garbage collection doesn't have to work; it can just run out of space and terminate. It can just crash on errors without a trace. It doesn't need to report the line number where a syntax error likely began. You get the picture.

I’ll remove even more and _still_ call it a lisp and there is nothing you can do to stop me.

Any memory management solution will run out of space and terminate unless there is literally infinite memory available.

But I guess hash tables is what people think about when thinking about what makes something a lisp or not.

Whereas in contrast, you cannot have a race this kind of race for the bottom with most other languages; tripping over the other contestants to see who can remove the most features, yet still have Python or Java.

See?

There you go, mrweasel; I think we hit the nail on the head.

> When I posted this to lobste.rs, gingerBill (creator of Odin) was kind enough to make a more direct translation of the C code into Odin.

Glad he has helped you. Maybe he listened to me, maybe not, but last time (almost year ago?) I saw an interaction with him on GitHub, he was nothing short of an a**hole, and not in the sense of Linus or Theo. In fact, he was not educational, he was just like "Many problems. I could write this better, GTFO". I saw it on GitHub, so I am reluctant to submit a PR of any sort myself in before he tells me he can implement it better and rejects my PR with this reasoning as he did with someone else. Like yeah, of course you may be able to implement it better, whereas someone new to the language might not, even though I tried it (the rejected PR, which was supposed to end up in vendor/ not the core library, AFAIK) and it was fully functional (and without any leaks), and to my eyes it seemed fine as well, but maybe I do not know Odin enough. In fact, I probably do not know it as much as he does, but by his logic, everything should be implemented by him because he knows better. This experience (albeit not mine) was enough to put me off of Odin. The C3 lead developer, on the other hand, was extremely helpful here on HN and on GitHub as well.

I have a feeling he has helped you because of the article and some fame along with it. :)

So my comment reflects a negative publicity. I cannot find the GitHub link right now, but it is there as it cannot be deleted, AFAIK. Look around rejected PRs in / for vendor/, I think. I am not logged in to GitHub and I cannot do so at the moment.

Just my second-hand experience. Feel free to down-vote but please leave a comment afterwards. Not everyone and everything is sunshine and butterflies. The down-votes DO NOT invalidate anything. Or perhaps Bill's bots / fans are in play here. ;) God forbid someone voices negative experiences with a person. Only positives are allowed! I forgot...

750 lines and 0 comments.
The antivirus program forced to be installed by my company does not allow .odin file to exist, as there is a ransomware which encrypts files into *.odin.

Of course, git cloning the ALE plugin (linter + languageserver) for VIM also fails as ALE has an .odin file in its repo.