00:00:00 --- log: started forth/13.02.26 00:19:20 --- quit: I440r (Remote host closed the connection) 00:29:11 --- part: sw2wolf left #forth 00:48:14 --- quit: impomatic (Quit: http://about.me/john_metcalf) 00:53:43 --- quit: nighty^ (Quit: Disappears in a puff of smoke) 00:56:58 --- join: nighty^ (~nighty@tin51-1-82-226-147-104.fbx.proxad.net) joined #forth 01:02:10 --- quit: nighty^ (Quit: Disappears in a puff of smoke) 01:25:39 --- join: nighty^ (~nighty@tin51-1-82-226-147-104.fbx.proxad.net) joined #forth 01:54:28 --- join: lazyden (~lazyden@58.185.121.38) joined #forth 02:22:33 --- join: DocPlatypus (~skquinn@c-76-30-236-86.hsd1.tx.comcast.net) joined #forth 02:22:48 --- quit: tgunr (Ping timeout: 260 seconds) 02:34:29 --- quit: DocPlatypus (Ping timeout: 272 seconds) 02:34:58 --- join: DocPlatypus (~skquinn@98.195.26.149) joined #forth 02:36:15 --- join: tgunr (~davec@cust-66-249-166-11.static.o1.com) joined #forth 02:55:21 --- quit: epicmonkey (Ping timeout: 245 seconds) 03:11:08 --- join: epicmonkey (~epicmonke@91.247.221.56) joined #forth 03:24:25 --- quit: tgunr (Quit: Nity nite) 03:31:09 --- quit: obobo (Read error: Connection reset by peer) 03:31:48 --- join: obobo (~chatzilla@98.124.5.67) joined #forth 03:36:28 --- join: protist (~protist@125.224.69.111.dynamic.snap.net.nz) joined #forth 04:34:51 --- join: krad (~qk@unaffiliated/krad) joined #forth 04:36:15 --- quit: epicmonkey (Ping timeout: 276 seconds) 04:39:30 --- quit: protist (Quit: Konversation terminated!) 04:46:00 --- quit: lazyden (Quit: lazyden) 05:04:18 --- quit: Eth|cal (Quit: Leaving) 05:04:39 --- join: Eth|cal (~sam@ppp59-167-172-238.static.internode.on.net) joined #forth 05:13:37 --- quit: Bahman (Remote host closed the connection) 05:59:37 --- join: impomatic (~digital_w@146.90.165.144) joined #forth 06:34:07 --- nick: tangentsleep -> tangentstorm 06:56:31 --- quit: krad () 08:31:41 --- join: Tod-Work (~thansmann@host-25.pl1071005.fiber.net) joined #forth 08:55:11 --- join: ncv (~quassel@79.114.79.235) joined #forth 08:55:11 --- quit: ncv (Changing host) 08:55:11 --- join: ncv (~quassel@unaffiliated/neceve) joined #forth 09:43:22 --- quit: impomatic (Read error: Connection reset by peer) 10:00:21 --- nick: ASau` -> ASau 10:17:03 --- join: impomatic (~digital_w@146.90.165.144) joined #forth 11:54:32 --- join: tgunr (~davec@cust-66-249-166-11.static.o1.com) joined #forth 12:12:48 --- quit: tgunr (Read error: Connection reset by peer) 12:16:30 --- join: tgunr (~davec@cust-66-249-166-11.static.o1.com) joined #forth 12:18:52 --- join: epicmonkey (~epicmonke@195.182.194.214) joined #forth 12:48:07 --- quit: ncv (Remote host closed the connection) 12:58:06 --- join: ncv (~quassel@unaffiliated/neceve) joined #forth 13:02:27 --- quit: tgunr (Quit: Nity nite) 13:09:47 --- join: tgunr (~davec@cust-66-249-166-11.static.o1.com) joined #forth 13:19:23 --- join: nighty-_ (~nighty@tin51-1-82-226-147-104.fbx.proxad.net) joined #forth 13:23:02 --- join: JDat (JDat@89.248.91.5) joined #forth 13:26:07 --- join: Onionnion (~ryan@76.229.156.185) joined #forth 13:33:58 --- join: kumul (~mool@c-76-26-237-95.hsd1.fl.comcast.net) joined #forth 13:47:27 --- quit: impomatic (Ping timeout: 276 seconds) 14:11:41 --- nick: tangentstorm -> tangentwork 14:21:49 --- join: impomatic (~digital_w@146.90.165.144) joined #forth 14:23:25 --- join: kumool (~mool@c-76-26-237-95.hsd1.fl.comcast.net) joined #forth 14:26:20 --- quit: epicmonkey (Ping timeout: 248 seconds) 14:26:24 --- quit: kumul (Ping timeout: 248 seconds) 14:46:30 --- join: kumul (~mool@c-76-26-237-95.hsd1.fl.comcast.net) joined #forth 14:49:18 --- quit: kumool (Ping timeout: 248 seconds) 14:52:55 --- quit: JDat () 14:53:57 --- quit: ncv (Remote host closed the connection) 14:56:14 --- quit: kumul (Ping timeout: 248 seconds) 14:57:00 --- join: kumul (~mool@c-76-26-237-95.hsd1.fl.comcast.net) joined #forth 15:03:39 --- join: RodgerTheGreat (~rodger@71-13-215-142.dhcp.mrqt.mi.charter.com) joined #forth 15:13:41 --- quit: kulp (Quit: Ping timeout (-2147483648 seconds)) 15:14:55 --- quit: nighty-_ (Quit: Disappears in a puff of smoke) 15:19:17 --- join: kulp (~kulp@unaffiliated/kulp) joined #forth 15:25:36 --- quit: tgunr (Quit: Nity nite) 15:29:52 --- quit: kumul (Ping timeout: 248 seconds) 15:49:10 kulp: so, fun new development in the analysis pass from hell 15:50:08 --- join: kumul (~mool@c-76-26-237-95.hsd1.fl.comcast.net) joined #forth 15:52:43 --- quit: Tod-Work (Quit: Leaving) 16:09:18 --- quit: kumul (Ping timeout: 248 seconds) 16:15:19 --- join: kumul (~mool@c-76-26-237-95.hsd1.fl.comcast.net) joined #forth 16:29:32 --- join: lazyden (~lazyden@58.185.121.38) joined #forth 16:31:26 --- quit: nighty^ (Read error: Connection reset by peer) 16:44:26 --- quit: lazyden (Quit: lazyden) 16:47:42 --- join: lazyden (~lazyden@58.185.121.38) joined #forth 17:22:30 --- join: protist (~protist@202.36.179.68) joined #forth 17:30:46 --- quit: protist (Ping timeout: 276 seconds) 17:36:05 --- join: kumool (~mool@c-76-26-237-95.hsd1.fl.comcast.net) joined #forth 17:38:56 --- quit: kumul (Ping timeout: 248 seconds) 17:55:15 --- join: kumul (~mool@c-76-26-237-95.hsd1.fl.comcast.net) joined #forth 17:55:33 --- join: protist (~protist@202.36.179.68) joined #forth 17:57:33 --- quit: kumool (Ping timeout: 248 seconds) 17:59:26 --- join: kumool (~mool@c-76-26-237-95.hsd1.fl.comcast.net) joined #forth 18:01:52 --- quit: kumul (Ping timeout: 248 seconds) 18:43:14 --- nick: tangentwork -> tangentstorm 18:58:50 --- quit: protist (Quit: Konversation terminated!) 19:07:51 RodgerTheGreat: do tell 19:07:57 you found out someone else is doing it ? 19:08:03 no this is way better 19:08:39 I believe that I have found a detail which was skimmed over in the original paper that, when you actually have to work everything out, ends up being an NP-complete sub-problem 19:08:58 like seriously, god damn 19:09:17 nobody should ever be allowed to write a fucking dissertation without implementing algorithms described therein 19:09:42 what's the problem? 19:09:53 RodgerTheGreat: ouchhhh 19:09:56 minimizing boolean expressions 19:10:00 oh haha 19:10:05 here i have a module you can use 19:10:08 tractable for a small number of variables, sure 19:10:19 but in general NP-hard 19:10:26 http://search.cpan.org/~kulp/Algorithm-QuineMcCluskey-0.01/lib/Algorithm/QuineMcCluskey.pm 19:10:30 the first perl module i ever wrote 19:10:35 it's awful don't look at it 19:10:41 * tangentstorm looks 19:10:44 noooooooo 19:10:47 it may still be doable in practice but it blows the complexity analysis of the overall algorithm to hell 19:10:51 --- join: kumul (~mool@c-76-26-237-95.hsd1.fl.comcast.net) joined #forth 19:10:58 heuristically things do it all the time 19:10:59 but yeah 19:11:06 fun fun :D 19:11:28 I'm going to spend all day tomorrow trying to figure out if there's some special property I can leverage to make it tractable 19:11:40 but this is bullshit 19:11:44 --- quit: kumool (Ping timeout: 248 seconds) 19:11:50 probably the original author discovered this 19:11:59 and carefully worked his thesis around it 19:12:03 I am so angry about the failure of due diligence here 19:12:19 kulp: the thought had occurred to me 19:13:42 it has the potential to invalidate a bunch of later results which build on the premise that we can build this IR in a reasonable timeframe for general CFGs 19:13:43 what does it mean to minimize a boolean expression? like simplifying in algebra? 19:13:53 you have some predicate 19:14:13 it's computed based on some number of values and the operators NOT, AND and OR 19:14:38 you must simplify it to the minimum number of said operators with the same truth table 19:14:48 there's a pretty straightforward brute-force approach 19:15:04 and it should be obvious that said approach scales exponentially on the number of values 19:15:24 that's Bad(tm) 19:16:14 hmm. no it's not obvious to me yet. let me think about it. 19:16:19 ok 19:17:14 you're picturing it as brute force generation of the tables, so every column you add to the table compounds the possibilities 19:17:25 yeah 19:17:37 well if you can make it non-exponential 19:17:38 i was picturing it as a tree 19:17:43 then potentially you have solved P = NP 19:17:49 so the algorithm as stated just glosses over it and it's like "just figure out predicates which distinguish the paths from definitions to their use-site" 19:18:08 and I do that, and I get these gnarly but as far as I can tell correct predicates 19:18:30 if i just show you a truth table and you have to guess how it's implemented, that's SAT, right? 19:18:45 isomorphic to SAT yeah 19:18:51 but the problem is whenever I introduce an AND or OR between flow control predicates I have to insert code 19:19:10 but this isn't the same because you already have one answer 19:19:11 (between flow control predicates which already exist naturally in the code) 19:19:51 but if I cannot simplify expressions the number of instructions I may have to insert grows exponentially 19:19:54 which is Bad(tm) 19:20:03 ™ 19:20:03 and completely defeats the utility of the algorithm 19:20:04 there you go 19:20:15 ™ 19:20:19 option-2 on a mac 19:20:41 yes 19:20:45 that's how i did it :D 19:20:50 sorry, derailing :( 19:21:10 basically everywhere you have an if-else "saddle" in the CFG you have the potential to join together these gnarly predicates to produce something that, with sufficient analysis just evaluates to "true" 19:21:25 but proving that is computationally expensive 19:21:43 and, roughly, exponentially bounded with respect to the connectivity of the CFG 19:21:49 again, Bad™ 19:22:00 what would connectivity mean? 19:22:31 http://en.wikipedia.org/wiki/Graph_connectivity 19:22:52 it ends up being significant for various compiler things 19:23:10 because of short circuit evaluation? 19:23:36 not really unless I misunderstand you 19:23:55 you're hoping to remove chunks of the expression by "pre-short-circuiting" them... like at compile time 19:24:14 in a very vague sense 19:24:18 like if i say if ( 1 and 1 and 1 and 1 ) or x that could be compiled away 19:25:01 it's a little more subtle than that 19:25:14 I'm afraid I can't really delve into intricate details 19:25:17 but those are constants and that's trivial... so you're probably thinking about variables 19:25:34 ok 19:26:38 but so the long and the short of it is the existing complexity analysis of the algorithm places it in the same ballpark as existing SSA construction algorithms, but doing this sort of predicate simplification is implicit and required 19:26:49 and simplifying predicates like this is in general NP hard 19:27:26 so unless I can exploit some special property of the predicates, how the are constructed or how they are used, this algorithm is in general intractable and this process will dominate the runtime performance of the algorithm 19:27:43 for generalized CFGs 19:28:10 it may still be useful but it'll have a serious achilles heel which may under further examination invalidate a lot of results 19:28:22 does generalized cfg just mean "cfgs in general" or is it a thing? 19:28:30 the former 19:28:46 like you can just throw arbitrary CFGs at one of these algorithms and you expect it to work 19:28:53 ok 19:29:22 but how would it know what in the grammar corresponds to a predicate? 19:29:24 in practice functions contain relatively small numbers of basic blocks and a sanely bounded number of branches, thus a sanely bounded number of these predicates being combined and such 19:29:38 tangentstorm: a computed value used to control a branch 19:29:53 that is all 19:29:57 but how would it know what is computed and what is branching? 19:30:05 they exist, identifying them is trivial 19:30:16 you are sliding past the point 19:30:31 in my language "if a = b then print 7" is the command to add 7 to the last input value. 19:30:57 you are willfully sliding past the point 19:31:17 I'm talking about examining a control flow graph for some known ISA 19:31:52 as are ALL compiler analysis algorithms 19:32:03 because the syntax of a language is utterly immaterial 19:32:14 sorry, i'm just trying to picture how it would know how to do this. 19:32:14 i will assume that we've told the algorithm. :) 19:32:31 how simple does it really have to be? 19:33:01 O(polynomial) 19:33:02 :) 19:33:23 i was reading CFG as context free grammar. that makes much more sense. sorry. :) 19:33:39 our Control Flow Graph consists of a series of basic blocks each containing precisely one conditional or unconditional branch and an arbitrary number of instructions which perform straight-line computation 19:33:45 i was too :( 19:33:47 conditional branches are predicated on some value 19:34:29 kulp: you have written compilers, shame on you 19:34:40 you should know in this context what CFG refers to 19:35:20 * tangentstorm scrolls back and re-reads this whole thing with that in mind 19:35:41 RodgerTheGreat: covering up for ambiguity ! 19:35:49 RodgerTheGreat: i've only written compilers, not read about them :( 19:35:50 ;) 19:37:08 haha me too :D 19:37:12 well i've read a lot 19:37:16 but not about that stuff 19:37:51 RodgerTheGreat: you have some code and you are trying to optimize it for what? 19:38:01 i mean what aspect are you optimizing? 19:38:09 speed? size? 19:38:30 I'm trying to perform analysis to gain more information about the code which can be used to perform various optimizations later 19:38:44 it is related to converting code into Static-Single Assignment form 19:41:17 why do you need a graph for that? ... that actually would make more sense to do at the grammar/ast level, wouldn't it? that's why cfg=context free grammar made sense to me 19:42:00 in many situations that drags in enormous complexity that is not necessary 19:42:01 * tangentstorm is obviously not being helpful here. sorry. 19:42:15 it makes your optimizations and analysis dependent on a source language for one 19:42:52 if it was C for example you would care about the differences in semantics between a ternary operator and an if statement 19:43:03 hmm 19:43:09 no i don't picture it that way 19:43:16 if you manipulate a CFG you are in essence manipulating the generated assembly 19:43:30 thus, a common intermediate representation 19:43:36 shared by all frontends 19:43:50 yes i agree with that notion but i wouldn't use assembly 19:43:51 and shared by all backends which produce actual machine code for a given architecture 19:44:14 well whoop-de-fucking-doo, this is how all industrial-strength compilers work 19:44:20 i would use something like oberon or that guarded command language dijkstra used (that you implemented) 19:44:29 it's just how it's fucking done 19:44:48 but you're writing a paper that's meant to change how it's done 19:44:54 otherwise why write it? 19:45:01 I don't know what the hell to tell you because clearly I am not going to convince you WHY it is done this way without reciting a compilers textbook to you 19:45:09 AUGH 19:45:28 you are talking in circles 19:46:03 "you're making a better car? Well honestly a bike would be better. Why not, you said you wanted something better and different!" 19:46:04 nah, man. sorry. like i said, i can see i'm not being helpful here. 19:46:37 i don't know what you're working on, i only know about this subproblem. 19:46:45 compiler internal representations resemble an abstract assembly language, full stop 19:47:07 * kulp writes a paper to change this 19:47:26 * kulp leaves out critical details about how this drags in enormous complexity that is not necessary 19:47:46 * kulp leaves his paper for the next graduate student 19:47:47 this algorithm I am working on creates an internal representation similar in many ways to an ordinary IR but with subtle changes in semantics which make it easier to perform certain optimizations by exposing information in a more convenient way, full stop 19:48:17 that is the problem space I am operating within 19:48:52 I am not in a position to instead say that what we should do is build flow charts out of lego pieces to represent information about programs for use by compilers 19:49:04 sorry. 19:49:09 and even if I was that would not change the problem I am actually dealing with 19:49:42 to be honest I have not had a great day for a variety of reasons so I hope I am not coming across in an unnecessarily harsh manner 19:49:50 --- join: kumool (~mool@c-76-26-237-95.hsd1.fl.comcast.net) joined #forth 19:50:15 is your mission to convert things to SSA form though? 19:50:24 an SSA form 19:50:45 yeah. that's what you're trying to accomplish i mean, or just for this sub-problem? 19:50:46 the IR I am generating is SSA but structured differently to expose different information 19:51:10 like it has the static single assignment property 19:51:39 but the IR and the algorithm for generating it differ from garden variety "SSA conversion" algorithms 19:51:44 --- quit: kumul (Ping timeout: 248 seconds) 19:51:55 and in fact tackle some different problems along the way 19:53:20 my job is to read the tea leaves of a paper written by a previous PhD student to produce a fully working industrial strength implementation which can then be used as a basis for future novel work and applications 19:53:46 oh. is the paper online? 19:53:47 so I am taking a pile of theory and some worked out examples and turning it into an actual, embodied algorithm 19:53:51 --- quit: malyn (*.net *.split) 19:53:51 no 19:53:58 ah 19:54:37 but the input to your algorithim is some arbitrary control flow graph and the output is that graph transformed to a special ssa form. 19:54:48 problem is, since said algorithm is underspecified my task is in fact to *invent* an algorithm that works as described, occasionally filling in bits which correspond to pseudocode from the paper 19:54:54 tangentstorm: yes 19:55:54 --- join: malyn (~malyn@unaffiliated/malyn) joined #forth 19:55:55 got it now. earlier i thought you were saying that you just needed it in ssa form for whatever you were doing... that's why i was trying to move the conversion upstream 19:56:02 the paper describes the high-level important points of what has to happen but in order to get it to work I have to actually do everything which constantly exposes omissions and occasional outright mistakes in the paper 19:56:51 weak 19:56:53 so coming full circle I appear to have discovered that one of the things the paper takes for granted appears to in fact be an NP-hard subproblem 19:57:19 and it's easy to see how this was never discovered because NOBODY HAS EVER IMPLEMENTED IT BEFORE 19:57:32 haha 19:57:40 welcome to research ? 19:57:41 :(( 19:57:45 it's not so easy to see why that guy got a phd out of it 19:57:57 examples have been worked out by hand but lots of things seem trivially easy when working out contrived examples by hand because as it turns out humans are good at solving small algebra problems 19:58:15 well, humans besides me 19:58:45 tangentstorm: because the theory seems sound and contains good ideas with justifications and at the end of the day that's mostly what theoretical math dissertations contain 19:59:22 CS is unique in that our theory can generally be transformed into a thing you can empirically poke and prod for consistency 19:59:38 kulp: *small* algebra problems 20:00:14 hmm. fair enough. 20:00:17 a&(¬a|b) -> ? 20:00:22 but you're in computer science, not theoretical math, so you don't have that luxury. 20:00:23 RodgerTheGreat: oh yes, i suppose sufficiently small would work by definition even for me :D 20:00:35 umm uhhh 20:00:40 * kulp panics 20:00:59 a&b ? 20:01:04 bingo 20:01:14 * kulp dries himself 20:01:42 so just by looking at that problem you can magically come up with an answer and the expression is small enough that you could say with some degree of confidence that you've found a minimal version of it 20:02:24 for a problem of the same form but over, say 8 variables, with two dozen &s and |s, it would take you quite a while 20:02:32 now think about writing a program to do that 20:02:41 if you don't think about it very much it seems pretty easy 20:02:46 just some little tree walker things 20:03:05 but you can't actually simplify general expressions by just looking at local regions of expressions 20:03:06 --- quit: Onionnion (Ping timeout: 255 seconds) 20:03:17 you can pick up various special cases 20:03:42 but if you try writing such a program you start to realize that all your inference rules are exploding and the problem isn't getting smaller 20:04:32 a thing that, for a small example, is easy for a person to glance at and solve is VERY difficult when scaled up and done by computer 20:04:33 --- join: tgunr (~davec@cust-66-249-166-11.static.o1.com) joined #forth 20:04:53 so as I said earlier, it's a vital detail which seems to have been overlooked 20:05:14 indeed :( 20:05:31 but does your algorithm depend on having the simplest possible form? 20:05:32 as I have said before, I'm gonna very carefully check my logic to make sure there aren't some assumptions which can guide a solution- sometimes you can weasel out of NP-hardness like that 20:06:06 tangentstorm: yes, because I can trivially construct CFGs which cause predicates to grow in size exponentially with respect to the size of the graph 20:06:38 and do so in ways that defeat any fixed pattern-matching simplification rules 20:06:49 so just getting them to be "better" is not sufficient 20:07:19 if "better" is not "optimal" there will be CFGs for which the algorithm is intractable 20:07:44 follow my logic? 20:08:04 not yet 20:08:09 * RodgerTheGreat sighs 20:08:17 kulp: am I explaining this clearly? 20:09:16 RodgerTheGreat: i think so, but i am also very gullible and egotistic 20:09:27 so if someone asks me "follow my logic" i am very unlikely to say "no" :( 20:09:37 smart lad, have a cookie 20:09:59 you could make me go away just by giving me a specific example to simplify :) 20:11:32 earlier i asked whether you were optimizing for speed at runtime or size of the generated code 20:12:07 I'm not doing either 20:12:12 I am performing analysis 20:12:55 I am computing dataflow information which incorporates these predicates 20:13:46 the reason is because i was imaginging a sort of escape hatch, where the thing says: well this made the code way too big, so just forget it. 20:13:55 if the code contains any kind of loop with an exit branch that depends on the input, there's no way to say that it's the most efficient implementation. 20:14:32 are predicates allowed to be recursive in your definition? 20:14:42 I look forward to the reactions of users of your compiler which says "nope, your code is too big, do it again" 20:14:51 no 20:15:05 IO isn't even at play here 20:15:13 we're talking CFGs which represent pure functions 20:17:46 it has variables though 20:17:47 i mean logical variables 20:17:47 those are still inputs 20:17:47 like if you say "a & b" then there's no way to know if that's true or false until you get the inputs 20:18:05 well no shit 20:18:19 the information you are computing is about static properties of the CFG 20:18:21 what i'm getting at is how do you know whether anything is optimal or not? that's the halting problem. 20:18:28 things that hold for any input 20:18:45 jesus H christ I never said anything about optimal CFGs 20:19:50 I will briefly digress to say that by a diagonalization argument, if you know a program halts you can find any programs which computes the same thing in fewer steps 20:20:12 but that is neither here nor there 20:20:32 when people talk about "optimization" in compilers they don't actually mean "optimal" they mean "better" 20:20:43 "optimizers" make programs better in some way 20:20:49 not optimal 20:20:54 well that's what i asked earlier 20:21:00 and AGAIN, that has nothing to do with what I am working on 20:21:04 and you said "if "better" is not "optimal" there will be CFGs for which the algorithm is intractable" :) 20:21:43 that is not referring to programs or CFGs it is referring to logical expressions 20:22:01 expression trees fucking halt 20:22:14 you can determine if an expression tree is minimal 20:26:57 you your problem is something like this: http://link.springer.com/chapter/10.1007/978-3-540-39724-3_5 20:27:15 but more general 20:28:02 that could be related 20:28:33 I'll look it up next time I'm in the office 20:28:45 can't access publications from home 20:29:16 i'm just trying to find a description of how people attack the problem.... is it called "expression minimalization?" 20:32:58 ah. i found a presentation about the topic, and a "predicate minimization logic" called MIN: https://docs.google.com/file/d/1pi8zu9-KcBEV0MbZ5CtkKfGeWpAbJAf5limVASexSGBdUK0u7y0zu4AffIUr/edit?usp=sharing 20:33:45 there's all sorts of heuristic methods for doing this 20:33:58 my point is simply that those approaches break down in general 20:34:19 solvers are available to handle something on the order of a hundred variables or so 20:34:37 and like I keep saying, it may still be practical to apply this algorithm 20:34:49 for sufficiently small CFGs 20:35:58 people should just write simpler programs 20:36:13 oh if only 20:41:24 the problem isn't even the notation, it's that there's not even any easy way to search for what the symbols mean :( 20:41:34 my greatest fear is writing a dissertation that extends the lifetime of some awful fortran program from 1958 20:42:02 well, my greatest academic fear 20:42:17 haha 20:42:27 you could just save the world that way 20:42:43 it would still suck as a legacy 20:42:51 I'm sure it's going to happen 20:43:01 it happens to everyone doing compilers research 20:43:17 without even realizing the true consequences of your work 20:43:34 i know a guy who worked at IBM in compiler research 20:43:44 they were translating visual basic and cobol into python and other languages 20:43:54 at least that code changes form i guess :) 20:43:59 one of the first refactoring tools was for cobol :) 20:44:01 * RodgerTheGreat dry heaves 20:44:51 when the structured program theorem came out, someone wrote a tool to convert cobol code to structued form 20:45:10 why the hate for COBOL? 20:45:13 I have to ask 20:45:24 who's hating 20:45:28 maybe RodgerTheGreat doesn't like python ! 20:45:29 ;) 20:45:38 I do not like python 20:46:14 * tangentstorm wrote a python compiler. not a very smart one though. 20:46:37 it is an ugly perl-alike filled with misfeatures and the usual goofy special-case syntax crap in every scripting language 20:46:40 --- quit: kumool (Ping timeout: 248 seconds) 20:46:56 it has utterly broken scope 20:47:14 functions have one level of scope 20:47:21 that's been fixed 20:47:25 and there's a keyword for REMOVING VARIABLES FROM THE CURRENT SCOPE. 20:47:29 WHY 20:47:44 oh yeah and it's overloaded for removing elements from data structures because why the hell not right 20:47:50 bloody awful 20:47:59 every time I learn more about it I become less happy 20:48:04 other way around... 20:48:05 because the author is a Guido 20:48:07 i mean what 20:48:20 it's crummy and I do not like it 20:48:25 the current scope is a data structure 20:48:44 also obligatory "COBOL called, it wants its whitespace-delimited syntax back" 20:49:23 --- join: kumul (~mool@c-76-26-237-95.hsd1.fl.comcast.net) joined #forth 20:50:03 if people want to write small programs for their exclusive use in python, perl, ruby, SNOBOL or whatever the hell they want, more power to them 20:50:37 but I think python is a mess and encourages sloppy coding practices, and I dread having to maintain someone else's python code at some point in the future 20:51:15 I guarantee that 30 years from now people will agree with my present-day sentiment that python code is awful 20:51:16 so just stick to clean, maintainable forth then? :) 20:51:35 if you can write a concise forth program it will at least actually be simple 20:51:36 --- quit: kumul (Read error: Connection reset by peer) 20:51:50 forth would be terrible for writing something intrinsically complex like a web browser 20:52:03 --- join: kumul (~mool@c-76-26-237-95.hsd1.fl.comcast.net) joined #forth 20:52:18 the golden rule of forth is "if it is simple, you are allowed to do it. If it isn't, you aren't" 20:52:43 forth is unsuitable for writing 100k line programs 20:52:51 arguably 100k line programs should not exist 20:53:01 but if somehow they must, forth is not appropriate for doing so 20:56:18 i agree re should not exist 20:56:31 i wouldn't mind working my whole career on programs that are 10k lines max 20:56:48 (i think) 20:56:49 for now huge monster codebases exist and we have to deal with it 20:56:52 (what do i really know though) 20:56:55 as do bloated standards 20:57:09 which are the root cause of many of those monster codebases 20:57:27 it's easy to sling code, it's hard to simplify 20:58:32 NP hard apparently :) 20:58:43 tangentstorm: we have come full circle 20:59:55 do you mean root cause in a rigorous sense there? 21:00:33 I have no idea what nit you are picking this time 21:00:49 do i come off as nit picky? 21:01:28 i guess so. huh. my bad. 21:02:07 i guess when someone says something like that i start trying to make the connections in my head between the cause and the effect. 21:03:13 i thought it was an interesting assertion and i was wondering if you meant you'd actually analyzed the problem and come to that conclusion or if you were just throwing it out there. 21:04:42 i'm not trying to trap you or argue with you or anything, just trying to understand. 21:06:06 --- quit: RodgerTheGreat (Ping timeout: 255 seconds) 21:07:10 although i guess usually if i feel the need to do that it's probably because something doesn't fit with the understanding i already have about the world. 21:07:28 --- quit: kumul (Ping timeout: 248 seconds) 21:07:28 --- quit: nighty- (Ping timeout: 248 seconds) 21:09:05 i see these two problems we've talked about tonight as more or less isomorphic (the problem of optimization inside a compiler and the problem of sprawling code bases and bloated standards) 21:09:56 it's hard for people for the same reason it's hard for compilers 21:11:17 ... which i guess is insufficient processing power and working ram 21:11:35 okay i will stop rambling now. 21:30:28 --- join: nighty- (~nighty@TOROON12-1279662182.sdsl.bell.ca) joined #forth 21:31:59 --- quit: nighty- (Read error: Connection reset by peer) 21:40:34 --- join: nighty- (~nighty@TOROON12-1279662182.sdsl.bell.ca) joined #forth 21:41:59 --- quit: nighty- (Read error: Connection reset by peer) 21:57:23 --- join: nighty- (~nighty@static-68-179-124-161.ptr.terago.net) joined #forth 22:02:06 --- quit: nighty- (Ping timeout: 264 seconds) 22:13:36 --- join: nighty- (~nighty@static-68-179-124-161.ptr.terago.net) joined #forth 22:30:14 --- quit: malyn (Read error: Connection reset by peer) 22:30:19 --- join: malyn_ (~malyn@unaffiliated/malyn) joined #forth 22:31:14 --- nick: malyn_ -> malyn 22:38:54 --- nick: tangentstorm -> tangentsomething 22:58:39 --- join: ncv (~quassel@unaffiliated/neceve) joined #forth 23:28:48 --- quit: DocPlatypus (Quit: Leaving) 23:31:11 --- join: epicmonkey (~epicmonke@46.164.134.18) joined #forth 23:44:16 --- quit: epicmonkey (Ping timeout: 248 seconds) 23:46:33 --- quit: ncv (Remote host closed the connection) 23:56:33 --- quit: impomatic (Quit: http://about.me/john_metcalf) 23:57:09 --- join: epicmonkey (~epicmonke@46.164.134.18) joined #forth 23:59:59 --- log: ended forth/13.02.26