2021-07-18 00:36:37 <siraben     > function pointers are neat
2021-07-18 05:59:46 <veltas      > MrMobius, siraben: I think the issue is that in C you need to declare it as that type, which does indeed look a bit messy to most people
2021-07-18 06:00:00 <veltas      > In B you can just use it as a function, there are no type annotations
2021-07-18 06:00:25 <siraben     > the notation is regrettable, is it done that way for parsing reasons?
2021-07-18 06:01:36 <siraben     > `bool (*fun_ptr)(int) = &fun;` could be cleaned up to `(bool → int) *fun_ptr = &fun;`, IMO
2021-07-18 06:01:45 <siraben     > oops, `(int → bool)`
2021-07-18 08:25:01 <veltas      > siraben: It makes it easier to define and parse the declarators because they match their usage exactly
2021-07-18 08:25:05 <veltas      > Well they used to
2021-07-18 09:19:31 <siraben     > Syntax stuck in the 70s. Parsing technology has improved greatly since.
2021-07-18 09:20:18 <siraben     > I like Rust's inspiration from ML languages, `fn even(x: uint) : bool { ... }`
2021-07-18 09:20:45 <siraben     > er, confused it with Coq :P, it's actually `fn even(x: uint) → bool`
2021-07-18 11:15:09 <veltas      > What does a function pointer type look like in Rust?
2021-07-18 11:15:35 <veltas      > Or the equivalent
2021-07-18 11:16:17 <veltas      > It's not like understanding of parsing improved it, it's more that we were willing to spend more time writing compilers and have more memory to store compilers in
2021-07-18 11:17:01 <siraben     > veltas: that, and parsing as well: https://jeffreykegler.github.io/personal/timeline_v3
2021-07-18 11:18:37 <siraben     > veltas: very ML-like, `fn do_twice(f: fn(i32) -> i32, arg: i32) -> i32 { f(arg) + f(arg) }`
2021-07-18 11:18:44 <veltas      > Our understanding of parsing did not improve the language
2021-07-18 11:19:04 <veltas      > C's parsing did not get significantly more complicated from when it was written as a simplistic recursive descent parser
2021-07-18 11:19:11 <siraben     > I see
2021-07-18 11:19:27 <siraben     > Hm, I feel like a better syntax could have been chosen even using recursive-descent
2021-07-18 11:19:28 <veltas      > And frankly there's not really any new language I can think of that you can't write an old-school parser
2021-07-18 11:19:31 <veltas      > for
2021-07-18 11:19:42 <siraben     > many functional languages can be parsed with recursive descent
2021-07-18 11:20:04 <siraben     > matching the usage as you said might have been the reason they opted for that syntax in C
2021-07-18 11:20:14 <veltas      > Parsing theory has probably improved the maintainence of such parsers and efficiency, but not increased the scope of languages in practice
2021-07-18 11:20:33 <siraben     > Yeah.
2021-07-18 11:22:59 <veltas      > The limitations of C's syntax are about time and memory
2021-07-18 11:23:42 <veltas      > Most of the work to add types to the syntax was done by one person, quite quickly, and on a machine that had something in the order of 64KB of RAM
2021-07-18 11:26:34 <veltas      > What's funny in that article is they complained about how GNU C replaced their parser with a recursive descent parser, for performance reasons, and they are talking about throwing away decades of development of their theory
2021-07-18 11:26:48 <veltas      > Your theory is a bit redundant to the compiler if recursive descent works and is faster, sorry
2021-07-18 11:31:50 <eris[m]1    > whuch article?
2021-07-18 11:33:31 <veltas      > https://jeffreykegler.github.io/personal/timeline_v3
2021-07-18 11:34:35 <veltas      > I thought I was being a bit of a luddite for doing only hand-written parsers after finishing my compiler theory course, but apparently all the major compilers do this
2021-07-18 11:34:59 <veltas      > The reason I did it was for better error messages and that's one of the reasons they do it too
2021-07-18 11:51:08 <siraben     > veltas: no worries, fun speculating
2021-07-18 11:54:43 <veltas      > I wonder how much more of my CS degree was over-idealistic stuff that doesn't get used in practice because it's slow
2021-07-18 11:55:06 <veltas      > I saw an xkcd comic the other day complaining about linked lists being old and useless, but they're used all the time at a low level.
2021-07-18 11:55:08 <siraben     > constant factors matter when n is small
2021-07-18 11:55:15 <veltas      > Yep
2021-07-18 11:55:41 <siraben     > but when n is very large, then theory definitely helps
2021-07-18 11:56:11 <siraben     > I'm thinking of graph algorithms from my class, I wonder how much they actually get used in practice
2021-07-18 11:56:15 <veltas      > GCC got performance gains switching to recursive descent
2021-07-18 11:56:38 <siraben     > on small graphs you might as well brute force, but that becomes at least polynomially worse as you add more edges
2021-07-18 11:57:02 <veltas      > "I wonder how much they actually get used in practice" it's not interesting to them, they're theorists
2021-07-18 11:57:34 <siraben     > I'm sure they get used but for what N I don't know
2021-07-18 11:57:43 <veltas      > Google uses it
2021-07-18 11:57:45 <veltas      > And Facebook
2021-07-18 11:57:55 <siraben     > hah, yes, N is huge there
2021-07-18 11:58:06 <veltas      > But Facebook do really dumb stuff that make me wonder if even they need it
2021-07-18 11:58:36 <siraben     > reminds me of algorithms that let you do sorting in linear time, if the of the items that's being sorted is small enough
2021-07-18 11:58:44 <siraben     > but no comparison sort can do better than O(n log n)
2021-07-18 11:59:01 <siraben     > if the range*
2021-07-18 11:59:02 <veltas      > Insertion sort is the fastest sorting algorithm on computers in many typical situations
2021-07-18 11:59:32 <veltas      > Even though it's rubbish algorithmically
2021-07-18 11:59:37 <siraben     > oh yeah cache can have a big effect on observed performance
2021-07-18 12:00:58 <veltas      > GNU std::sort uses a sort of combination of algorithms that converges on merge sort eventually because the standard needs it to require n*log(n), but most n*log(n) algorithms are out-performed in smaller cases
2021-07-18 12:00:59 <siraben     > veltas: wrt. parsing, there was a really neat line of work on parsing with derivatives, but the complexity is currently cubic
2021-07-18 12:01:00 <siraben     > https://arxiv.org/abs/1604.04695
2021-07-18 12:01:09 <siraben     > that makes sense
2021-07-18 12:01:24 <siraben     > another one where you want to switch algorithms past a certain size is integer multiplication
2021-07-18 12:01:55 <veltas      > Yes and it's easier to appreciate there why the academic algorithms is inferior to "I have a circuit that just does this immediately"
2021-07-18 12:04:34 <siraben     > meanwhile we use unary arithmetic all the time in Coq (more efficient numbers are also there if one needs them)
2021-07-18 12:04:40 <veltas      > I think the academic side of parsing is interesting and I'm sure lots of very brilliant people work on it, but I think I lean heavily to the engineer end of the spectrum when we start talking about the best way to write an actual compiler
2021-07-18 12:04:43 <siraben     > for the pure reason that the induction is nice
2021-07-18 12:05:38 <siraben     > Oh yeah, for parsing it seems more or less like a solved problem
2021-07-18 12:06:02 <veltas      > Apparently Dijkstra didn't use computers much and actually avoided using them
2021-07-18 12:06:17 <siraben     > hence his famous EWD notes
2021-07-18 12:06:44 <veltas      > And then he wants to tell people how to write programs and they listen
2021-07-18 12:07:47 <veltas      > I just think a lot of academia's influence has been pompous and not that helpful. There's a lot of signal within all the noise, but you need to be open minded and not assume the CS giants were larger than the people they actually were
2021-07-18 12:08:28 <siraben     > Sure, I'm fairly open minded wrt. that
2021-07-18 12:08:43 <veltas      > Even today I have to write code sometimes following standards to avoid returning early because of stuff Dijkstra influenced, all that code is worse for it and probably contains more bugs
2021-07-18 12:09:18 <veltas      > Like I have to use some of the MISRA C rules at work right now, including that one, and I keep remarking to people that bugs I find in testing would never have happened if it wasn't for a MISRA rule
2021-07-18 12:09:38 <siraben     > MISRA?
2021-07-18 12:09:44 <veltas      > There's no standard for 'good code' unfortunately, try as they may
2021-07-18 12:10:01 <veltas      > https://en.wikipedia.org/wiki/MISRA_C
2021-07-18 12:10:41 <siraben     > oh man
2021-07-18 12:10:49 <siraben     > sounds like a lot of bureaucracy
2021-07-18 12:11:29 <veltas      > "the only people to benefit from the MISRA C 2004 update would appear to be tool vendors" LOL -- this guy gets it
2021-07-18 12:11:51 <siraben     > https://xkcd.com/927/
2021-07-18 12:12:37 <veltas      > If there is any reason for stuff like this it's to make certain kinds of very low-denominator engineers actually do their job properly
2021-07-18 12:12:59 <veltas      > And to assist engineers who need a technicality to stop their business from trying to rush mission-critical software
2021-07-18 12:14:37 <veltas      > I find that a lot of engineering standards and conventions are more about politics than about technology. It's very human
2021-07-18 16:08:10 <cbridge     > -!- ChanServ changed mode/#forth -> +o  mark4
2021-07-18 19:11:04 <dave0       > maw
2021-07-18 19:14:59 <crc         > hi dave0
2021-07-18 19:18:03 <dave0       > maw crc
2021-07-18 22:11:21 <dave0       > re maw
2021-07-18 23:30:20 <siraben     > veltas: what have you been working on lately?
2021-07-18 23:30:44 <siraben     > heh https://news.ycombinator.com/item?id=27872280 "It's oh so convenient until it isn't; until you need to make distinctions between missing values and booleans."
2021-07-18 23:30:52 <siraben     > I'm glad Scheme distinguishes between booleans and the empty list