00:00:08 | filwit | gradha: there are many different designs |
00:00:27 | Araq | btw you remember you can have a 'class' macro, right? |
00:00:35 | filwit | in Unity 3D, a "script" (MonoBehavior) is an self-contained object, and that has it's benefits |
00:00:50 | filwit | for instance, you can apply the same (and multiple) scripts to different objects |
00:01:17 | filwit | Araq: i know, it's ugly, i have ideas, lets talk sometime |
00:01:35 | Araq | filwit: alright |
00:01:49 | filwit | in my Game Engine design (similar to WPF), we use the concept of signals |
00:02:17 | filwit | there are not "Script Objects", there is only an "Object" but it has callbacks and uses self-contained functionality |
00:02:54 | gradha | one thing is sure: your pretty class of objects for the art toolchain doesn't resemble a bit what ends up in a game engine, which tends to be the "flattened" version of a fancy object hierarchy |
00:02:56 | filwit | virtual functions are useful in it, but it's true usually you don't use those |
00:03:14 | filwit | which is the reason for my 'mode' design.... (in my language) |
00:03:19 | gradha | unless you are doing non performance critical games |
00:03:19 | filwit | but that's an extension to OOP |
00:03:27 | filwit | which, like i said, I'm not against |
00:04:02 | filwit | no, it's much more complicated than that gradha |
00:04:20 | filwit | first, even without "character as a class" you don't need to flatten every part |
00:04:29 | filwit | there is still a lot of virtual function use |
00:04:53 | filwit | and many small, hand written games are fine with classical OOP |
00:05:10 | filwit | the problem comes when you have to batch things for performance |
00:05:22 | Araq | filwit: the pdf argues that the code not only becomes faster |
00:05:26 | Araq | but also simpler btw |
00:05:27 | filwit | and no matter what you do, you can't get away from that, OOP or otherwise |
00:05:44 | Araq | and it's interesting it says "methods left out for clarity" |
00:06:01 | Araq | so the slide only contains the 'struct' part of the class ... |
00:06:18 | filwit | Araq: yes, because all they're doing is breaking a monolithic construct into manageable pieces... something which OOP fits just fine. |
00:06:42 | filwit | remember, i also like the idea of free-functions |
00:06:49 | Araq | what? |
00:06:53 | Araq | since when? |
00:06:57 | filwit | i just don't want them to float around when you include a module |
00:07:10 | filwit | and my reasoning for that is readability |
00:07:20 | filwit | Console.write() |
00:07:23 | filwit | vs |
00:07:27 | filwit | writeln() |
00:07:40 | Araq | Computer.Console.write()? :P |
00:08:01 | filwit | no need for that extra layer |
00:08:11 | filwit | but you can orginize that way if you want |
00:08:27 | filwit | the point is, we mentally associate things into groups |
00:08:33 | * | XAMPP joined #nimrod |
00:08:55 | gradha | filwit: have you heard of this "functional" programming fad? |
00:09:40 | Araq | gradha, filwit, Araq: enough of it |
00:09:41 | filwit | i'm sorry, but you're making a "argument from popularity" which isn't convincing to me |
00:10:15 | filwit | Araq: okay sure, again though I didn't bring this up :) |
00:10:20 | gradha | hrm... I wonder now if it's functionality what ticks people or the lack of side effects... |
00:10:39 | filwit | just my presents here seems to spark these conversations because you folks know i have different ideas |
00:11:01 | Araq | the problem is not that you think differently about it |
00:11:15 | Araq | the problem is you think it matters for nimrod's popularity |
00:11:30 | Araq | I see many other reasons why Nimrod is where it is |
00:11:52 | gradha | oh, right, we were talking about nimrod popularity |
00:11:59 | filwit | i never said it was the _sole_ reason, but i do think it's very big |
00:12:00 | gradha | man, had forgotten about that |
00:12:30 | Araq | and I think you vastly overestimate this issue, but we'll skype about it |
00:12:34 | gradha | so going back to popular things, now that nimrod gets a fancy crown logo, what's the mascot, a king? |
00:12:44 | filwit | so i guess you're "arguments from popularity" where valid, in context of our orginal point |
00:12:59 | Araq | thanks :-) |
00:13:07 | filwit | gradha: yes, i offered to design a mascot, but Araq didn't want it |
00:13:14 | Araq | what? |
00:13:20 | Araq | oh yeah |
00:13:28 | filwit | Araq: that doesn't mean there aren't a bunch of popular languages (i would argue the most popular) that use OOP |
00:13:36 | filwit | so i still think it's invalid |
00:13:39 | gradha | what else can graciously wear a crown? |
00:13:46 | Araq | I don't think a PL needs a mascot |
00:14:03 | gradha | a disabled mascot |
00:14:04 | Araq | and I don't think I've ever seen a mascot that I like |
00:14:08 | filwit | plus, the languages that are procedural (non OOP) that are popular, i would argue are popular for other reasons |
00:14:13 | filwit | like C and JS |
00:14:34 | Araq | there are lots of people who love C for being procedural |
00:14:35 | gradha | C is popular because it came with unix, and js came with browsers? |
00:14:45 | filwit | are popular because one has no side-effects (in theory), and the other because of it's history on the web |
00:15:16 | filwit | C is great for low-level programming, and linking |
00:15:20 | gradha | C without side effects? what parallel universe is this? am I sleeping? |
00:15:41 | Araq | gradha: he means functional programming |
00:15:44 | filwit | so if you have something that's designed to be used in other langauges, you're pretty much going to have to flatten your structures into flat-C anyways |
00:16:08 | filwit | JS, yes because it came with the web |
00:16:19 | filwit | and look how many people are trying to remake it (Coffee Scripe, Dart, etc) |
00:16:58 | gradha | unforunately most people lack imagination, so most people can only do minimal incremental improvements on what they know |
00:17:11 | filwit | gradha: i mean C without hidden functionality |
00:17:19 | filwit | meaning you get what you see |
00:17:29 | filwit | there's nothing too the structure really |
00:17:50 | filwit | like Nimrod, only without hierarchy of any kind. |
00:18:06 | filwit | so you don't have to refer to a language spec to know what your memory looks like |
00:18:43 | filwit | gradha: i have a lot of imagination and my language changes things in many different ways |
00:18:58 | gradha | yet you are still thinking in objects |
00:19:14 | filwit | even the issue of broken encapsulation in games i'm trying to address with an OOP way |
00:19:55 | filwit | gradha: yet you're still thinking procedurally :P isnt' your own argument that there's a "fad" going around? |
00:20:07 | * | Trix[a]r_za is now known as Trixar_za |
00:20:34 | NimBot | Araq/Nimrod 6e97453 Araq [+1 ±4 -0]: object constructors work now |
00:20:57 | Araq | and with this push I shall finally sleep |
00:21:11 | Araq | good night guys |
00:21:37 | gradha | I don't know anything about functional, I was just surprised you seem to think everything in terms of OOP but there are successful languages without such constructs |
00:21:39 | filwit | night |
00:22:18 | filwit | yes, there are successful languages that are purely functional |
00:22:20 | gradha | I always read about erlang being an example of encapsulation and hot-swappable code, does it have oop? |
00:22:36 | filwit | but i find it telling that the most popular languages for large applications are not |
00:22:45 | filwit | besides C |
00:22:45 | filwit | which is used for other reasons |
00:22:50 | filwit | Java, C++, now C# |
00:23:03 | gradha | well, popular doesn't necessarily mean good |
00:23:11 | filwit | yes of course not |
00:23:21 | filwit | but popularity is important for a language |
00:23:36 | filwit | because the only way a language exists is because people write it |
00:23:39 | Araq | Ada has been used for millions of lines too btw |
00:23:43 | filwit | and people (today) need to get paid |
00:23:50 | gradha | hrm.. let's change programming languages for music: do you think popularity is required for death metal to succeed in the musical landscape? |
00:23:54 | filwit | doesn't ADA have Objects? |
00:24:10 | Araq | filwit: it's OO structure is quite like Nimrod's |
00:24:25 | Araq | and the original Ada had none OO to speak of |
00:24:45 | Araq | but sure, it's not popular |
00:24:48 | filwit | either way, I never thoght Nimrods structure was entirely horrible in every way |
00:24:58 | filwit | i think it makes things complicated when it doens't need to |
00:25:04 | filwit | like with creating objects |
00:25:15 | filwit | and with it's ability to define everything |
00:25:22 | Araq | creating objects is inherently complicated :P |
00:25:27 | filwit | so you don't really know what a symbol means unless you read the docs |
00:25:38 | filwit | it doesn't have to be at all |
00:25:44 | gradha | filwit: what? |
00:26:03 | * | q66 quit (Remote host closed the connection) |
00:26:05 | gradha | please ellaborate on "you don't really know what a symbol means unless you read the docs" |
00:26:30 | filwit | proc '#" (f:TFOO) = ... |
00:26:33 | filwit | in the standard lib |
00:26:43 | filwit | and all over the place in any custom libs |
00:26:59 | filwit | you have to know what these symbols mean |
00:27:04 | filwit | it's not written english |
00:27:13 | filwit | so you can't make assumptions by their name |
00:27:31 | filwit | i don't mind abbreviations or special sugar |
00:28:10 | filwit | but i think the language and stdlib should be both clear, and encourage people from poor mistakes like defining a bunch of custom operators that do things |
00:28:42 | filwit | type stuttering is an issue, this is why in my design, you can realiase things |
00:28:53 | filwit | func write = Console.write |
00:28:59 | filwit | then use use: write("...") |
00:29:06 | filwit | but you have to do with for each file |
00:29:18 | filwit | so someone reading the code has a very clear picture of what's going on |
00:29:30 | filwit | without hunting through a bunch of docs/other-files |
00:29:51 | gradha | just like int printf() in the standard library? |
00:29:51 | gradha | or to be more in C++, operator overloading |
00:29:52 | gradha | did you see nimrod's use of / for path joining? that's excellent |
00:29:52 | gradha | now I see every other language as inferior because I can't do that |
00:29:52 | gradha | but since you are an advocate for IDEs, the IDE will deal with that, showing a bubble with documentation and context |
00:29:52 | gradha | so... make an IDE for nimrod! |
00:29:52 | gradha | oh, wait, Aporia |
00:29:52 | gradha | yeah, looks like you have to roll your own language |
00:30:00 | filwit | woah... lag |
00:30:08 | filwit | one sec, don't know when you posted all that |
00:30:45 | gradha | yep, lag, good we aren't playing a fps |
00:30:49 | Araq | the stdlib is not full of uncommon operators |
00:30:49 | Araq | it's quite conservative in fact |
00:30:49 | Araq | but I really have to sleep, good night |
00:30:53 | filwit | no, i like Operator overloading, but only for math object or for the concept of adding/subtracting |
00:31:06 | filwit | night, Araq |
00:31:08 | gradha | good night |
00:31:30 | filwit | gradha: i don't like custome operators |
00:31:37 | filwit | meaning you can't define "#" |
00:31:53 | gradha | I'm not sure why |
00:31:54 | filwit | cause it has not _commonly understood_ meaning |
00:32:01 | filwit | that is the key |
00:32:19 | filwit | a langauge should be easy to learn, and easy to read |
00:32:29 | gradha | but commonly understood meaning means you can't do anything which deviates too stringly from what people already know, that's really boring |
00:32:43 | filwit | it's really productive |
00:32:48 | gradha | if a language doesn't show me things in a different way, why would I learn another just mee-too lang? |
00:32:52 | filwit | i don't care if it's boring or not |
00:32:59 | filwit | langauges are used to make interesting things |
00:33:12 | filwit | they shouldn't be a challenge themselves |
00:33:33 | filwit | but about the "why should i learn".. many reasons... |
00:33:41 | filwit | first, people want a better C++ |
00:33:43 | filwit | for games |
00:33:45 | filwit | for apps |
00:33:50 | filwit | cause C++ doesn't have a GC |
00:34:04 | filwit | cause it's fast, but has OOP |
00:34:08 | filwit | (aka, not C) |
00:34:16 | filwit | D is almost that |
00:34:24 | filwit | and look how popular it's becoming |
00:34:27 | gradha | yeah, people from C++ seem to be blind to objc, just they dislike brackets |
00:34:41 | filwit | but peoples biggest gribes about D, is that it requires a GC |
00:34:48 | gradha | actually, objc is more popular than D! |
00:34:56 | gradha | all hail objc |
00:35:01 | filwit | Objective C is so ugly only it's mother (Apple) could love it |
00:35:10 | filwit | and i've written a fair bit of it |
00:35:19 | gradha | any recently? |
00:35:24 | filwit | yes |
00:35:30 | filwit | as in a month or so ago |
00:35:39 | gradha | half of the good things were added in the last two years |
00:36:06 | filwit | yes, but Objective C is only really bad cause it chose syntax which didn't conflict with C |
00:36:23 | filwit | either that or the designer was retarded |
00:36:31 | filwit | :P |
00:36:32 | gradha | so you want different syntax, but don't want to redefine #... |
00:36:39 | gradha | ok |
00:36:43 | filwit | actually, i like Nimrod syntax a lot |
00:37:02 | filwit | i like keywords like "var/ref/prt/type/func/etc" |
00:37:13 | filwit | and i like comments with "#" not "//" |
00:37:23 | filwit | but i prefer curly brackets |
00:37:29 | filwit | though i don't care all that much |
00:37:37 | filwit | i think it's visually easier to parse |
00:37:48 | gradha | I like languages by how much work it takes me to get from a mental picture to working code, syntax is irrelevant (unless it's overly verbose like java) |
00:38:08 | filwit | yes, Java is overly verbose |
00:38:21 | filwit | however, both Java and C# understand that names should be descriptive |
00:38:25 | filwit | they just take it too far |
00:38:55 | filwit | like i said, I don't mind abbreviation, but things should be clear |
00:39:06 | filwit | and uncommon things should be extra clear |
00:39:15 | filwit | for instance, "int" vs "Integer" |
00:39:23 | filwit | is so commonly used, it makes sense |
00:39:41 | gradha | I think you might be arguing too hard about minor details |
00:39:44 | filwit | cause the cost of learning it doesn't outweight the annoyance to typing the longer name |
00:39:57 | filwit | but library functions should be very clear |
00:40:06 | gradha | macros are something people won't understand coming from most languages |
00:40:12 | gradha | how do you make that easy? |
00:40:19 | filwit | like this: |
00:40:24 | filwit | func foo(x, y) |
00:40:29 | filwit | func foo(x:int, y:int) |
00:40:34 | filwit | one is typeless |
00:40:44 | filwit | the other requires "int,int" |
00:40:52 | filwit | the typeless one is compiler-type checked |
00:41:01 | filwit | and is the same thing as Nimrods macros |
00:41:06 | filwit | well... |
00:41:12 | filwit | not really |
00:41:15 | filwit | this would be: |
00:41:17 | gradha | not at all |
00:41:30 | filwit | func foo(x:Compiler.Expressoin) |
00:41:43 | filwit | no wait... |
00:41:45 | filwit | this... |
00:42:13 | filwit | func foo(e:Compiler.Expression) : Compiler.Code { ... } |
00:42:20 | filwit | or something like that |
00:42:28 | gradha | cool, so what about the macro? |
00:42:38 | filwit | what about it? |
00:42:39 | gradha | how do you explain to somebody he can emit code at compile time? |
00:42:53 | gradha | how do you make that "natural" and "without surprises" |
00:42:58 | filwit | that get's into advanced features of the documentation |
00:43:23 | filwit | you have a beginners area, and an advanced area |
00:43:34 | filwit | and macro functions are advanced |
00:43:39 | filwit | but other typeless functions are not |
00:43:42 | filwit | for instance: |
00:43:49 | filwit | func add(a, b) { return a + b } |
00:44:03 | filwit | makes sense, even though it's a template function (in C++/D) |
00:44:10 | filwit | and is very easy to learn |
00:44:24 | filwit | in fact, i think Nimrod already does that |
00:44:31 | filwit | or is in the process of doing it |
00:44:46 | filwit | Araq mentioned it the other day, and we had talked about it months ago |
00:45:00 | gradha | I think you can do that with templates, where a/b are expr |
00:45:10 | filwit | yes |
00:45:18 | filwit | but my design only has "func" |
00:45:25 | filwit | so it's easier to learn |
00:45:41 | filwit | remember, my design is only really just that ATM |
00:45:42 | filwit | i only have a basic compiler working |
00:45:47 | filwit | (it can add ints) |
00:45:55 | filwit | (and only in interprited mode) |
00:46:00 | gradha | hrm... so if you drop the type and presume expr, and make all functions accepting expressions templates, you have what you want? |
00:46:13 | filwit | no, Expr is not assumed |
00:46:24 | filwit | well... actually it might be |
00:46:39 | gradha | how else would it work, the compiler is doing your work |
00:46:57 | gradha | fancy word: type inference |
00:47:07 | filwit | yes basically it would be Expr, you're right |
00:47:14 | filwit | i haven't gotten that far yet |
00:47:21 | filwit | i have something special with types |
00:47:35 | filwit | like Nimrod's distinct type |
00:47:39 | filwit | but mine is different |
00:47:50 | filwit | for instance i have this: |
00:47:53 | filwit | int - int |
00:47:55 | filwit | def - float |
00:48:00 | filwit | num - int or dec |
00:48:04 | filwit | so you can do this: |
00:48:09 | filwit | func foo(x:num) |
00:48:17 | filwit | which can take either a int or dec |
00:48:27 | filwit | but not a string, etc |
00:48:52 | filwit | i have a ton of other areas that are different about my language |
00:49:05 | filwit | https://gist.github.com/PhilipWitte/4974439 |
00:49:10 | gradha | that would be like a template which can be specialized to a specific list of allowed types |
00:49:13 | filwit | i'm still working on that gist |
00:49:36 | filwit | gradha: yes exactly, only the syntax is clean, easy to learn, and consistent |
00:49:45 | gradha | btw, why would you want to restrict that to not strings? |
00:50:04 | filwit | it depends on what the function is doing.... |
00:50:24 | filwit | if something can work with num types, it means it's doing math or something |
00:50:43 | filwit | and you don't want to have to duplicate the function for both types |
00:50:58 | gradha | I think you can fake that in nimrod with some boilerplate, which would make for an interesting macro |
00:51:13 | filwit | yes, you can fake a lot of things in Nimrod |
00:51:14 | gradha | imagine a template with expression, and inside a when for the types you want, else error |
00:51:28 | filwit | and before i was trying to come up with clever ways of doing what i wanted, in Nimrod |
00:51:30 | gradha | I wonder if that's possible |
00:51:57 | filwit | but I came to some convictions about language design that i think make Nimrod fundamentally flawed |
00:52:14 | filwit | and all languages that do similar things... like D, and C++ |
00:52:44 | gradha | I understand you still argue here because you aren't fully decided yet? |
00:52:49 | filwit | gradha: i'm not sure about global 'when' statements |
00:53:13 | filwit | no, i still argue here cause I am a friend of Araq and dom96's |
00:53:31 | filwit | and i ultimately wish we could find common ground and work together |
00:53:37 | gradha | enjoying the verbal exchange |
00:53:43 | filwit | yes |
00:53:56 | filwit | and if you haven't noticed, i don't always bring this up |
00:54:03 | filwit | but i do defend my ideas |
00:54:10 | filwit | because i think they have validity |
00:54:15 | filwit | and sometimes that gets wordy |
00:54:26 | gradha | I'm more of the "demonstrate shit" camp, sorry |
00:54:38 | filwit | yes i understand that |
00:54:44 | gradha | that's why I couldn't follow half the things you were talking about, I don't even know the words they use for them |
00:54:57 | filwit | and that's ultimately what i am going to need to do to convince you folks, i know |
00:55:26 | filwit | yes i know, things get lost in the translation |
00:55:34 | filwit | you folks are also Spanish/German speakers |
00:55:40 | filwit | and i'm english only |
00:55:42 | filwit | (US) |
00:55:48 | filwit | so there's also that |
00:55:48 | gradha | that's an advantage |
00:56:05 | filwit | yes, it's good to have more perspectives |
00:56:22 | filwit | but it means we're using different terms maybe for something things |
00:56:28 | filwit | or some terms aren't as common |
00:56:33 | filwit | so they aren't as clear |
00:56:34 | filwit | etc |
00:56:51 | gradha | actually, I thought being US is an advantage |
00:56:59 | gradha | you don't need to think twice to understand words |
00:57:04 | filwit | are you religious? |
00:57:17 | filwit | if so, you will be good here |
00:57:27 | gradha | crap |
00:57:29 | filwit | if not, then it's harder, depending on where you live |
00:57:35 | filwit | i'm not |
00:57:50 | filwit | so i can relate to a lot of Europeans more sometimes |
00:58:02 | gradha | ah, yes, in the USA being atheist is worse than being satan |
00:58:15 | filwit | people aren't just religious though,... it kinda permeates through their other ideas... |
00:58:18 | filwit | lol |
00:58:25 | filwit | yes, it is |
00:58:46 | filwit | you don't know how many times my father has called said I'm aligned with the devil |
00:58:46 | gradha | well, you can't have social inequality without population mind control |
00:59:08 | filwit | or how misconstruction people assume you are |
00:59:20 | gradha | here we joke being the devil is cool and fun |
00:59:23 | filwit | being an Atheist here is "a teenage phase" in most peoples eyes |
01:00:15 | filwit | yes, the social inequality is what i meant by "religious ideas permeating to other areas of thought" |
01:00:50 | filwit | most people here see nothing wrong with "the pledge of allegiance" we force our kids to say in schools |
01:01:15 | filwit | and when you bring those kinds of things up (depending on where you are) you get looked at funny |
01:01:24 | gradha | well, most people here see nothing wrong with santa or the tooth fairy, yet they are also imaginary friends and lies |
01:01:27 | filwit | like you just asked someone if they wanted to smoke crack with you |
01:02:08 | filwit | lol, yes |
01:03:09 | filwit | it's silly how so many people can't make the logical connection between other imaginary things and the god their believe in |
01:03:29 | filwit | i guess cause it is a more complex topic |
01:03:46 | gradha | do you know about the asian squat? |
01:04:05 | filwit | and there's the possibility that things have and odd physical feed-back loop or some other yet-undiscovered thing |
01:04:16 | filwit | no, never heard to the asian squat |
01:04:22 | gradha | http://www.youtube.com/watch?v=gWTmg4dHiKg |
01:04:48 | gradha | basically, asians squat in a different way than easterns |
01:04:58 | gradha | what is interesting is why/how they do that |
01:05:05 | filwit | lol |
01:05:16 | gradha | I can't do the asian squat because I never did it when I was small |
01:05:22 | gradha | I lost the flexibility of that movement |
01:05:32 | filwit | that sux |
01:05:34 | gradha | in my eyes, I'm a crippled person compared to somebody who exercised their flexibility |
01:05:36 | filwit | i work from home |
01:05:46 | filwit | so i do pushups and stuff randomly through the day |
01:05:59 | filwit | which i couldn't really do in an office... |
01:06:01 | gradha | religion is the same, it cripples your curiosity and capacity to question things |
01:06:28 | gradha | that's why religious people sometimes don't see the connection non religious people do |
01:06:33 | filwit | interesting analogy |
01:06:35 | gradha | they aren't used to that way of thinking |
01:06:44 | filwit | very true |
01:06:48 | gradha | and that's why religion, when you are an adult is harmless |
01:06:54 | gradha | the problem is when you are a kid |
01:07:00 | filwit | and funny how that behavior is evident in other areas of American society |
01:07:09 | gradha | you don't see adults changing religion every year |
01:07:10 | filwit | (like McDonals fat people) |
01:07:35 | filwit | yes, ture |
01:07:49 | filwit | but i have seen grown-up loose their faith |
01:07:54 | filwit | granted, not many |
01:07:59 | filwit | compared to how many don't |
01:08:06 | gradha | yes, but they don't loose faith to another religion |
01:08:18 | gradha | they just realise "what the hell was I thinking?" |
01:08:51 | filwit | so, i always like to ask this to other Atheists, do you know about the Zeitgeist Movement? |
01:09:01 | gradha | no |
01:09:07 | filwit | k, nevermind |
01:09:07 | gradha | btw, I'm not an atheist |
01:09:15 | gradha | I'm a member of a minor sect |
01:09:22 | filwit | oh, well you're obviously not hugely religious |
01:09:31 | gradha | we are like about six people I think |
01:09:36 | filwit | what do you call yourself? |
01:09:37 | gradha | and we hail satan |
01:09:42 | filwit | hahaha |
01:09:48 | gradha | but our prophet is one friend |
01:09:50 | filwit | wait... seriously? |
01:09:52 | gradha | so we are his disciples |
01:09:57 | gradha | sure, he's a geologist |
01:10:07 | gradha | can't get wrong with somebody who knows how old earth is |
01:10:08 | filwit | lol, this must be a joke... |
01:10:16 | gradha | we even have a mailing list |
01:10:30 | gradha | unfortunately we always end up talking about kpop rather than world domination |
01:10:36 | filwit | lol |
01:10:44 | filwit | i see, so Atheist with a sense of humor |
01:11:22 | gradha | in theory we were to commit mass suicide the sixth of june of 2006 in front of Spain's Guggenheim museum |
01:11:42 | gradha | but our profet's girlfriend had her birthday, so we postponed it |
01:12:15 | gradha | ah, those were the good days |
01:12:26 | filwit | lol |
01:13:15 | filwit | well man, i'm going play a game or something |
01:13:24 | filwit | was nice talking to you |
01:13:37 | gradha | sure, bye, and have no lag |
01:13:48 | filwit | thanks, bye! |
01:13:50 | * | filwit quit (Quit: Leaving) |
01:36:01 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
03:00:39 | * | ccssnet quit (Read error: Connection reset by peer) |
03:05:11 | * | Trixar_za is now known as Trix[a]r_za |
03:19:15 | * | ccssnet joined #nimrod |
05:57:51 | * | xcombelle joined #nimrod |
07:47:00 | * | gour joined #nimrod |
08:20:48 | * | xcombelle quit (Remote host closed the connection) |
09:11:32 | * | Araq_ joined #nimrod |
09:20:46 | * | Araq_ quit (Quit: ChatZilla 0.9.90 [Firefox 19.0/20130215130331]) |
10:54:00 | * | gradha joined #nimrod |
10:56:27 | gradha | dom96: just a quick note, my laptop did overheat a few times in recent days and after stopping all tasks it kept burning fuel, so to speak |
10:56:46 | gradha | looking at the cpu usage it seems that the builder program is not really idle http://dl.dropbox.com/u/145894/t/builder_not_so_idle.png |
10:57:07 | gradha | there you can see it gobling the CPU for itself, yet on the right you can see the log of pings, it wasn't doing anything at all |
10:57:36 | gradha | I don't want to burn my desk so I'm disabling the builder for the time being |
10:57:55 | gradha | I can assist you later to find out what's wrong with it and why it is not idle |
10:58:11 | * | gradha quit (Client Quit) |
12:01:48 | * | Boscop quit (Quit: Boscop) |
12:43:35 | * | Trix[a]r_za is now known as Trixar_za |
13:05:19 | gour | there was heated discussion with filwit yesterday about (possible) reasons preventing nimrod to become more popular... |
13:29:18 | * | gour quit (Ping timeout: 245 seconds) |
13:37:11 | * | Trixar_za is now known as Trix[a]r_za |
13:59:22 | * | q66 joined #nimrod |
16:27:21 | * | Araq_ joined #nimrod |
16:31:05 | * | Araq_ quit (Client Quit) |
16:43:56 | * | XAMPP quit (Read error: Connection reset by peer) |
16:44:02 | * | XAMPP_ joined #nimrod |
18:48:21 | * | avarus joined #nimrod |
20:45:18 | * | avarus quit (Remote host closed the connection) |
21:22:31 | * | filwit joined #nimrod |
21:27:40 | reactormonk | Araq, might you kick me a bit for implementing the lambda lifting? |
21:28:28 | Araq | reactormonk: sure; first step is to activate the transformation for the JS backend |
21:28:42 | Araq | it's in transf.nim iirc |
21:30:01 | reactormonk | you have two when false in there btw |
21:30:06 | reactormonk | err, 3 |
21:30:18 | Araq | so what? |
21:30:56 | reactormonk | enable? How so? There do not seem to be any whens around for the JS backend |
21:31:06 | filwit | btw, i discovered that GEdit comments/uncomments based the .lang file |
21:31:25 | filwit | so the block comment extension works well with '#' style comments |
21:31:45 | Araq | nice but we don't use gedit anymore :P |
21:31:46 | filwit | Aporia should follow that design I think, dom96 |
21:32:05 | filwit | yes, i was just saying i discovered it the other day |
21:32:17 | filwit | and that it worked out very well automatically |
21:32:27 | Araq | alright |
21:32:29 | dom96 | Well you see, if you were to test Aporia you would see that Aporia already does ;) |
21:32:38 | filwit | oh does it? |
21:32:39 | filwit | nice |
21:32:57 | filwit | Araq said something the other day about it using "when false:" |
21:32:57 | dom96 | yeah, although I broke it recently :P |
21:33:01 | filwit | so I assumed that |
21:33:09 | dom96 | But it's a minor thing |
21:33:17 | filwit | yes, well that's good to hear |
21:34:13 | filwit | GEdit also has the "forget you're not using tabs" extension |
21:34:30 | filwit | which is basically what i was trying to make in Aporia before |
21:35:03 | filwit | just thought those two things where nice for Python-style coding |
21:35:56 | Araq | dom96: when I tested it it inserted discard """ """ |
21:37:29 | dom96 | Araq: yeah, it does that. |
21:38:10 | Araq | well filwit wants insertion of # |
21:38:19 | Araq | and I want 'when false:' ;-) |
21:38:57 | dom96 | yeah, I'll implement that |
21:42:10 | filwit | oh, do whatever you think is best |
21:42:19 | filwit | i was just saying i like that way is all |
21:42:31 | Araq | reactormonk: my bad, the checks are in lambdalifting.nim; if gCmd == cmdCompileToJS |
21:42:33 | filwit | and block commenting something works well in GEdit like that... |
21:42:48 | filwit | one thing i like about having actual comments is that things are "greyed out" |
21:43:13 | filwit | whereas "when false:" is difficult to distinguish if there's a lot of code |
21:43:26 | Araq | you can grey out it too |
21:43:34 | Araq | but it's more difficult to implement |
21:43:45 | filwit | yeah |
21:44:11 | Araq | though it's not that different from any other block really |
21:44:12 | dom96 | greying out discard """ """ would be quite easy |
21:45:02 | filwit | if it was up to me, I would have made "when false:" a compiler error and not had the "discard """" thing |
21:45:08 | filwit | ... but it's not up to me of course |
21:45:25 | filwit | i just don't know why they're in there i guess |
21:45:34 | Araq | huh? |
21:45:48 | Araq | discard """ """ is a feature that has been discovered |
21:46:01 | Araq | it was not designed to mean "comment like" |
21:46:12 | filwit | yes well, i understand that one |
21:46:17 | filwit | nevermind |
21:46:32 | Araq | and how could 'when false' be a compiler error? |
21:47:03 | filwit | if it finds a when statement which has 'false' literal |
21:47:09 | Araq | and why is it bad to distinguish between old code and an actual *comment*? |
21:47:10 | filwit | it throws and error |
21:47:30 | filwit | nevermind, i don't know why i brought it up |
21:47:33 | Araq | so you would make it a special case |
21:47:44 | filwit | yes, for debugging |
21:47:58 | filwit | just like how D prevents doing this: for (...); |
21:48:02 | Araq | for debugging? |
21:48:25 | filwit | it will barf, so you don't accidentally add and ending mark to that |
21:48:51 | Araq | so you think you write 'when false' accidentally? |
21:48:53 | filwit | it's a special case in the compiler, but designed to catch common, hard to see mistakes |
21:49:04 | filwit | no, but you might forget you did |
21:49:11 | filwit | or not notice it in someone elses code |
21:49:20 | Araq | I fail to see how you can compare a semicolon with "when false" |
21:49:32 | filwit | it's not a perfect comparison |
21:50:07 | filwit | but it's inline with the same idea: "catch dumb mistakes that arise out of code not being easy to read" |
21:50:17 | dom96 | Yes, when false is hard to notice because it's highlighted just like everything else. |
21:50:26 | dom96 | Same with "if false" |
21:50:38 | Araq | so? |
21:50:39 | dom96 | (Which I've noticed people using to comment code in JS for example) |
21:50:59 | Araq | your code can contain lots of other dead code |
21:51:17 | Araq | which is not greyed out either and you never complained about |
21:51:29 | filwit | *sigh* |
21:51:33 | filwit | nevermind dude |
21:51:59 | Araq | "when false" is not a dumb mistake |
21:52:06 | reactormonk | Araq, let's see what happens when I boot it :D |
21:52:55 | filwit | never said it was a mistake made by the person who wrote it (at least not when he wrote it) |
21:53:08 | filwit | and this isn't about dead-code removal |
21:53:21 | filwit | it's about someone looking at code, and thinking it's being executed |
21:53:27 | filwit | because they don't see the "when false:" |
21:53:30 | filwit | at the top |
21:53:37 | filwit | and compile tree times before they notice it |
21:53:40 | filwit | that is all |
21:53:51 | Araq | you know |
21:54:13 | Araq | these kind of arguments start to become convincing when they happened in real life |
21:54:34 | filwit | i don't know what you mean by that |
21:55:01 | Araq | when you looked at some piece of code written in Nimrod, scratched your head |
21:55:02 | reactormonk | Araq, assertion failed. should I iterate and see what I can fix it or is understanding beneficial? |
21:55:26 | Araq | and then noticed "ugh, it's in a when false" |
21:55:52 | reactormonk | Araq, any way to make assert as verbose as check? |
21:56:07 | Araq | reactormonk: replace with InternalAssert? |
21:56:12 | filwit | i don't need to fall into a pit before i plan to avoid it |
21:56:21 | filwit | it was just a simple argument |
21:56:36 | filwit | not like a major "Nimrod is going to die cause of this" |
21:56:49 | Araq | no, it's a very common thing people do: |
21:57:02 | Araq | "omg it's different, so it must bad: WHAT IF ... ?" |
21:57:23 | Araq | and then people come up with lots of absurdities |
21:57:24 | filwit | that would be valid if that was my actual argument |
21:57:35 | Araq | lets see: |
21:57:35 | filwit | but it isn't |
21:57:41 | filwit | and that's a straw man |
21:58:33 | Araq | "omg, you can nest if statements arbitrarily deep? what if some programmer uses 20 nested if statements? The compiler should really forbit it" |
21:58:50 | Araq | you can apply it to everything |
21:58:51 | reactormonk | Araq, nope, still no $ of either side |
21:59:19 | Araq | you can't design a language with this attitude IMO |
21:59:33 | reactormonk | Araq, sure you can, then you get C |
21:59:56 | filwit | so we should disregard all potential improvements (with valid reasoning) because it's the wrong attitude? |
22:00:04 | filwit | i never said it was a huge deal man |
22:00:12 | filwit | but i am defending a position |
22:00:17 | Araq | arbitrary restrictions are no potential improvements |
22:00:31 | filwit | that is a complete disregard of my argument |
22:00:43 | Araq | you want to forbit "when false" |
22:01:05 | filwit | i gave what i feel is valid reason for something, and you come back with "it's only convincing if someone has constantly run into it" |
22:01:45 | Araq | arbitrary restrictions are aweful |
22:01:57 | filwit | i don't care if "when false:" is forbidden man, i said "if i was designing it" which i think you took as "you did something wrong" |
22:02:10 | filwit | i understand you can't make every little feature |
22:02:13 | filwit | it's impractical |
22:02:30 | Araq | no, I'm telling you that your way of approaching language design is wrong :P |
22:02:42 | Araq | because I know you're designing one |
22:02:50 | filwit | okay, i see |
22:03:07 | filwit | well in that case, i don't think arbitrary restrictions are bad in this case |
22:03:30 | filwit | because the only purpose that syntax provides, is a duplicate of comment syntax |
22:03:42 | Araq | but it's not |
22:03:54 | Araq | deactivated code is not the same as a comment |
22:03:55 | filwit | and it does have the potential of creating hard-to-read code situations, even if that's only a minor issue |
22:04:00 | Araq | a comment is in natural language |
22:04:22 | filwit | it's not deactivated by any variable though |
22:04:27 | filwit | it's deactivated by a literal |
22:04:29 | Araq | using comments for deactivating sections of code is in fact the misfeature |
22:04:56 | filwit | okay, then that spec should be fully realized |
22:05:05 | Araq | but it is |
22:05:09 | filwit | and there should only be one way to do "deactivate" code |
22:05:13 | Araq | the code is still *parsed* in 'when false' |
22:05:28 | Araq | and yes, 'when false' is the supposed way to deactivate code |
22:05:33 | reactormonk | Araq, gotta love compiling the compiler in ~5s |
22:05:37 | filwit | of course, that is a flawed design really, since you kill two-birds-with-one-stone by just using comments, or some form of them |
22:05:44 | reactormonk | hmm, maybe 10 |
22:06:10 | Araq | filwit: you can also get rid of all control flow by introducing 'goto' |
22:06:11 | filwit | it's unrealistic to expect people to not comment out code to deactivate |
22:06:29 | dom96 | Araq: What's the advantage of the code still being parsed? Would you actually edit the code and leave it in the when false: ? |
22:06:42 | Araq | dom96: I would |
22:06:56 | filwit | all that does is slow down the compiler |
22:06:58 | Araq | I like to keep it around to say "look, you've tried that before and it didn't work" |
22:06:59 | filwit | and complicated the syntax |
22:07:21 | filwit | people are always just going to comment out code |
22:07:27 | filwit | cause one tool does both things |
22:07:35 | filwit | so they only need that single tool in their belts |
22:07:45 | Araq | filwit: 'when' is not introduced for it, 'when' has lots of other different uses |
22:07:58 | filwit | i know man, that's my point |
22:08:00 | Araq | so it doesn't complicate anything |
22:08:10 | Araq | it's always been there |
22:08:21 | filwit | that doesn't apply to the topic |
22:08:31 | filwit | when is useful for stuff, yes |
22:08:49 | filwit | that's specifically why it shouldn't be able to be used as a "comment" |
22:09:11 | filwit | and again, it presents a readability issue |
22:09:51 | filwit | when someone sees the "when" statement, it should be doing something meaningful, not duplicating what comments do (and what people will use them for) |
22:10:03 | Araq | *shrug* |
22:10:13 | Araq | it's no readability issue for me |
22:10:21 | Araq | and I have the feeling it's no for you |
22:10:30 | reactormonk | Araq, so I need to generate an nkDotExpr |
22:10:31 | filwit | it's not a huge issue |
22:10:31 | Araq | you simply don't like it because it's different |
22:10:35 | filwit | no |
22:10:51 | filwit | it's not a huge issue, but i don't just not like it cause it's different |
22:11:03 | Araq | reactormonk: hmm, no .. |
22:12:22 | Araq | filwit: one point in a higher level language is to try to encourage the programmer to write down his *intends*; this means distinguishing between ptr and ref for instance |
22:12:40 | Araq | *intents |
22:12:53 | Araq | # vs 'when false' is another example for that |
22:13:39 | filwit | sure, but i think that is much better expressed with # vs ## or @ or something |
22:14:09 | * | gradha joined #nimrod |
22:14:23 | filwit | it also doesn't address the readability issue, but like you said, you believe it's not any harder... so we're both just making arguments from experience on that point |
22:15:22 | filwit | more opinions are needed there, but I would put money on people a) using comments to block out code, and b) finding 'when false' hard to see in some cases where comments would not be |
22:15:38 | filwit | again... just an argument from authority |
22:15:45 | filwit | dont actually expect you to accept that |
22:16:04 | filwit | sorry, argument from experience |
22:17:14 | Araq | reactormonk: you need to ignore nkDotExpr in a var/let statement; just make the loop continue |
22:17:37 | dom96 | gradha: You can try increasing the poll timeout in line 858 of builder.nim. |
22:19:02 | dom96 | perhaps it's an issue with select on Mac OS X though. |
22:19:18 | gradha | the default is 500, ms? do I try 2000? |
22:19:34 | dom96 | yeah |
22:20:47 | gradha | is there any way i can patch nimbuild to actually do nothing? I mean, to test if it still consumes CPU |
22:21:04 | gradha | like putting a return before the call to git/compile/whatever |
22:22:10 | gradha | meh, let's try it first anyway |
22:22:38 | dom96 | just run it without the requestNewest set to "False" |
22:23:01 | dom96 | (it's false by default, make sure it's not set to True in the builder's ini file) |
22:23:05 | gradha | does it make any difference if nimbuild is -d:release or not? |
22:23:18 | dom96 | it shouldn't. |
22:23:35 | dom96 | well obviously it's faster, but I don't think it matters much. |
22:23:40 | dom96 | I always build a debug version |
22:24:09 | reactormonk | Araq, internal error now :-( |
22:24:25 | gradha | no signs of cpu usage for the moment, will see tomorrow |
22:24:59 | dom96 | good |
22:25:05 | reactormonk | Araq, wait. |
22:25:12 | Araq | reactormonk: yeah you need to update the JS codegen in 2-3 places to support closures |
22:25:39 | reactormonk | foo.nim(4, 16) Error: internal error: gen: unknown node type: nkClosure |
22:25:41 | reactormonk | that's better |
22:25:47 | gradha | one thing you can notice from the screenshot is that maybe the problem is with nimrod's way of doing something, notice how the CPU usage of nimbuild was very similar to kernel_task |
22:26:02 | gradha | that suggest it's some OS call that is getting blocked |
22:26:19 | reactormonk | Araq, of nkClosure: genClosure(p, n, r) I suppose |
22:26:31 | Araq | reactormonk: nice start |
22:26:36 | Araq | but I have to go now |
22:26:44 | Araq | sorry |
22:26:45 | filwit | bye Araq |
22:26:49 | reactormonk | Araq, let's see |
22:27:03 | gradha | now that nimbuild was off it seems the kernel_task cpu usage grows at a rate of half hour per day |
22:27:17 | reactormonk | internalError(n.info, "first class iterators not implemented") |
22:27:23 | gradha | since my uptime is 1 d and 10h it's a little fishy to be already at 7h |
22:27:25 | reactormonk | *ehhem* |
22:29:06 | Araq | bye |
22:41:06 | * | filwit quit (Quit: Leaving) |
23:32:56 | * | gradha quit (Quit: bbl, have youtube videos to watch) |