00:00:00 --- log: started forth/21.07.18
01:06:36 --- join: Glider_IRC_ joined #forth
01:09:28 --- quit: Glider_IRC (Ping timeout: 120 seconds)
02:24:55 --- quit: Glider_IRC_ (Connection closed)
02:25:34 --- join: Glider_IRC_ joined #forth
03:00:10 <cbridge_> <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
03:00:22 <cbridge_> <veltas> In B you can just use it as a function, there are no type annotations
03:00:49 <cbridge_> <siraben> the notation is regrettable, is it done that way for parsing reasons?
03:01:59 <cbridge_> <siraben> `bool (*fun_ptr)(int) = &fun;` could be cleaned up to `(bool → int) *fun_ptr = &fun;`, IMO
03:02:09 <cbridge_> <siraben> oops, `(int → bool)`
05:25:25 <cbridge_> <veltas> siraben: It makes it easier to define and parse the declarators because they match their usage exactly
05:25:30 <cbridge_> <veltas> Well they used to
05:31:08 --- quit: Vedran (Ping timeout: 120 seconds)
05:31:44 --- join: Vedran joined #forth
06:19:55 <cbridge_> <siraben> Syntax stuck in the 70s. Parsing technology has improved greatly since.
06:20:42 <cbridge_> <siraben> I like Rust's inspiration from ML languages, `fn even(x: uint) : bool { ... }`
06:21:10 <cbridge_> <siraben> er, confused it with Coq :P, it's actually `fn even(x: uint) → bool`
08:15:32 <cbridge_> <veltas> What does a function pointer type look like in Rust?
08:16:00 <cbridge_> <veltas> Or the equivalent
08:16:40 <cbridge_> <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
08:17:25 <cbridge_> <siraben> veltas: that, and parsing as well: https://jeffreykegler.github.io/personal/timeline_v3
08:19:02 <cbridge_> <siraben> veltas: very ML-like, `fn do_twice(f: fn(i32) -> i32, arg: i32) -> i32 { f(arg) + f(arg) }`
08:19:07 <cbridge_> <veltas> Our understanding of parsing did not improve the language
08:19:27 <cbridge_> <veltas> C's parsing did not get significantly more complicated from when it was written as a simplistic recursive descent parser
08:19:35 <cbridge_> <siraben> I see
08:19:50 <cbridge_> <siraben> Hm, I feel like a better syntax could have been chosen even using recursive-descent
08:19:53 <cbridge_> <veltas> And frankly there's not really any new language I can think of that you can't write an old-school parser
08:19:55 <cbridge_> <veltas> for
08:20:05 <cbridge_> <siraben> many functional languages can be parsed with recursive descent
08:20:29 <cbridge_> <siraben> matching the usage as you said might have been the reason they opted for that syntax in C
08:20:39 <cbridge_> <veltas> Parsing theory has probably improved the maintainence of such parsers and efficiency, but not increased the scope of languages in practice
08:20:57 <cbridge_> <siraben> Yeah.
08:23:24 <cbridge_> <veltas> The limitations of C's syntax are about time and memory
08:24:05 <cbridge_> <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
08:26:27 --- quit: Vedran (Ping timeout: 120 seconds)
08:26:48 --- join: Vedran joined #forth
08:26:59 <cbridge_> <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
08:27:12 <cbridge_> <veltas> Your theory is a bit redundant to the compiler if recursive descent works and is faster, sorry
08:32:13 <cbridge_> <eris[m]1> whuch article?
08:33:55 <cbridge_> <veltas> https://jeffreykegler.github.io/personal/timeline_v3
08:34:59 <cbridge_> <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
08:35:23 <cbridge_> <veltas> The reason I did it was for better error messages and that's one of the reasons they do it too
08:51:31 <cbridge_> <siraben> veltas: no worries, fun speculating
08:55:07 <cbridge_> <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
08:55:29 <cbridge_> <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.
08:55:31 <cbridge_> <siraben> constant factors matter when n is small
08:55:39 <cbridge_> <veltas> Yep
08:56:06 <cbridge_> <siraben> but when n is very large, then theory definitely helps
08:56:35 <cbridge_> <siraben> I'm thinking of graph algorithms from my class, I wonder how much they actually get used in practice
08:56:38 <cbridge_> <veltas> GCC got performance gains switching to recursive descent
08:57:02 <cbridge_> <siraben> on small graphs you might as well brute force, but that becomes at least polynomially worse as you add more edges
08:57:26 <cbridge_> <veltas> "I wonder how much they actually get used in practice" it's not interesting to them, they're theorists
08:57:59 <cbridge_> <siraben> I'm sure they get used but for what N I don't know
08:58:07 <cbridge_> <veltas> Google uses it
08:58:09 <cbridge_> <veltas> And Facebook
08:58:18 <cbridge_> <siraben> hah, yes, N is huge there
08:58:29 <cbridge_> <veltas> But Facebook do really dumb stuff that make me wonder if even they need it
08:58:58 <cbridge_> <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
08:59:07 <cbridge_> <siraben> but no comparison sort can do better than O(n log n)
08:59:26 <cbridge_> <siraben> if the range*
08:59:26 <cbridge_> <veltas> Insertion sort is the fastest sorting algorithm on computers in many typical situations
08:59:56 <cbridge_> <veltas> Even though it's rubbish algorithmically
09:00:01 <cbridge_> <siraben> oh yeah cache can have a big effect on observed performance
09:01:21 <cbridge_> <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
09:01:21 <cbridge_> <siraben> veltas: wrt. parsing, there was a really neat line of work on parsing with derivatives, but the complexity is currently cubic
09:01:24 <cbridge_> <siraben> https://arxiv.org/abs/1604.04695
09:01:32 <cbridge_> <siraben> that makes sense
09:01:46 <cbridge_> <siraben> another one where you want to switch algorithms past a certain size is integer multiplication
09:02:19 <cbridge_> <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"
09:04:59 <cbridge_> <siraben> meanwhile we use unary arithmetic all the time in Coq (more efficient numbers are also there if one needs them)
09:05:04 <cbridge_> <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
09:05:07 <cbridge_> <siraben> for the pure reason that the induction is nice
09:06:00 <cbridge_> <siraben> Oh yeah, for parsing it seems more or less like a solved problem
09:06:26 <cbridge_> <veltas> Apparently Dijkstra didn't use computers much and actually avoided using them
09:06:40 <cbridge_> <siraben> hence his famous EWD notes
09:07:09 <cbridge_> <veltas> And then he wants to tell people how to write programs and they listen
09:08:10 <cbridge_> <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
09:08:53 <cbridge_> <siraben> Sure, I'm fairly open minded wrt. that
09:09:07 <cbridge_> <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
09:09:41 <cbridge_> <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
09:10:01 <cbridge_> <siraben> MISRA?
09:10:07 <cbridge_> <veltas> There's no standard for 'good code' unfortunately, try as they may
09:10:26 <cbridge_> <veltas> https://en.wikipedia.org/wiki/MISRA_C
09:11:06 <cbridge_> <siraben> oh man
09:11:12 <cbridge_> <siraben> sounds like a lot of bureaucracy
09:11:52 <cbridge_> <veltas> "the only people to benefit from the MISRA C 2004 update would appear to be tool vendors" LOL -- this guy gets it
09:12:16 <cbridge_> <siraben> https://xkcd.com/927/
09:13:00 <cbridge_> <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
09:13:23 <cbridge_> <veltas> And to assist engineers who need a technicality to stop their business from trying to rush mission-critical software
09:15:02 <cbridge_> <veltas> I find that a lot of engineering standards and conventions are more about politics than about technology. It's very human
12:39:24 --- join: WickedShell joined #forth
12:39:49 --- quit: WickedShell (Connection closed)
13:06:40 --- join: Glider_IRC__ joined #forth
13:08:30 --- join: mark4 joined #forth
13:08:30 --- mode: ChanServ set +o :mark4
13:09:32 --- quit: Glider_IRC_ (Ping timeout: 120 seconds)
16:11:29 <cbridge_> <dave0> maw
16:15:22 <cbridge_> <crc> hi dave0
16:18:26 <cbridge_> <dave0> maw crc 
19:11:44 <cbridge_> <dave0> re maw
20:01:33 --- quit: cbridge_ (Connection closed)
20:03:02 --- join: cbridge_ joined #forth
22:57:20 --- quit: proteusguy (Ping timeout: 120 seconds)
23:10:50 --- join: proteusguy joined #forth
23:59:59 --- log: ended forth/21.07.18