2024-08-04 01:20:24 what exotic ways are there to write C? 2024-08-04 01:21:10 legitimately curious. I think sometimes about writing preprocessors to do various things for my C code but usually dont since no one would want to work on it 2024-08-04 01:21:53 for example, I still havent figured out how to get base 10 floats into C source in a sane way. one project just encodes them as strings so they have to be parsed every time you need them which sucks 2024-08-04 01:22:01 IOCCC? 2024-08-04 01:22:19 That is one way, using a lot of preprocessor hacks 2024-08-04 01:22:35 E.g. Simon Tatham's coroutines 2024-08-04 01:24:58 I feel less icky about preprocessing assembly. ive inserted forth code directly into blocks in it before 2024-08-04 03:43:36 i think it's fair to say that outgrowing c is actually why i'm here 2024-08-04 03:44:46 i got to where i started implementing coroutines and closures and other tricky things in assembler, but i hate that the moment i do that, it introduces a hard dependency on a specific tool chain 2024-08-04 03:45:18 so: time to start rolling my own tool chain 2024-08-04 03:45:27 and here i am 2024-08-04 07:46:34 C is bad, but, forth has no optimizer 2024-08-04 07:47:27 its weird that its even compared considering forth is so slow compared to it. 2024-08-04 07:47:50 and you're writing to a VM, C writes to C 2024-08-04 10:56:58 if we would have a postfix lisp ((2 2 +) 4 *) == 16 <- wholdn't this just be THE SAME of Forth because of the Forth stack? e.g. ((2 2 +) 4 *) equivalent to Forth `2 2 + 4 *` ? 2024-08-04 11:04:58 More or less 2024-08-04 11:05:35 rendar: in that case, but what do words like dup, drop or drop do? 2024-08-04 11:05:38 The difference with Lisp is you can do (+ 1 2 3 4 5), it doesn't just work on two operands 2024-08-04 11:06:24 GeDaMo, indeed 2024-08-04 11:07:02 pkal, well yes, of course it was just a simple example 2024-08-04 11:08:04 indeed `((1 2 3 +) 4 *)` wouldn't be equal `to 1 2 3 + 4 *` 2024-08-04 11:18:56 rendar: yeah, but I think the explanation ("because of the forth stack") is wrong, even though the specific example is correct. A postfix lisp is pretty much isomorphic to a prefix lisp, and I would assume it would have the same evaluation strategy. You could argue that ( just creates a new stack and ) pops it keeping the TOS, while + and * operate on the entire stack, not just two elements 2024-08-04 11:19:36 yes, i agree 2024-08-04 11:19:40 TOS? 2024-08-04 11:20:58 Top Of Stack 2024-08-04 11:23:11 i see 2024-08-04 14:42:40 nmz: speed isn't always everything, and of course forth can have an optimizer 2024-08-04 17:20:56 There's only one thing worse than all the different implementations of forth, and that is all the different implementations of lisp %$#$%@#$!@# 2024-08-04 17:21:34 I don't want to learn fucking clojure T_T 2024-08-04 17:30:54 you only have to learn common lisp 2024-08-04 17:31:19 https://youtu.be/HM1Zb3xmvMc 2024-08-04 17:32:07 hehe clips is toooo big 2024-08-04 17:32:10 clisp* 2024-08-04 18:32:58 zelgomer: I disagree on that, speed is everything, if speed wasn't everything, I'd be using shellscript and forking my code away 2024-08-04 22:20:54 nmz: i said it isn't always everything. it isn't never everything, either. are you telling me you never use shell scripts? 2024-08-04 22:31:04 I rewrite a shell script when it gets longer than about 25 lines or has something slow and tricky like a while loop 2024-08-04 23:45:44 idk about you guys but even when i'm writing c, i generally use the simplest, easiest data structure or algorithm first and never optimize it 2024-08-04 23:47:05 especially if you're on a bare metal microcontroller or something. if you aren't sharing resources with another appllication, you gain absolutely nothing by completing the task faster than required. 2024-08-04 23:58:02 i also tend to go with what might be the most simple and/or naive approach first. some problems deserve optimization, some don't. all that matters is that you've solved the problem in a way that you're comfortable living with.