| 00:05:37 | xilo | what does "programmable statically typed languages" supposed to mean |
| 00:09:07 | xilo | >mfw hello world example is named "hallo.nim" |
| 00:09:41 | * | DAddYE_ quit (Remote host closed the connection) |
| 00:19:30 | * | DAddYE joined #nimrod |
| 00:25:35 | EXetoC | BitPuffin: fun |
| 00:25:54 | BitPuffin | EXetoC: no :( |
| 00:26:04 | EXetoC | I know right |
| 00:27:24 | EXetoC | xilo: that you can modify the language as a user |
| 00:28:45 | xilo | ah |
| 00:28:47 | xilo | gotcha |
| 00:41:49 | reactormonk | xilo, editor? |
| 00:42:49 | xilo | reactormonk: what? |
| 00:43:33 | reactormonk | xilo, which editor are you using for nimrod? |
| 00:43:52 | xilo | oh, i haven't done anything. just reading on language |
| 00:44:03 | xilo | but i use vim for everything that isn't c#/c++/java |
| 00:44:20 | reactormonk | there's a plugin from zahary |
| 00:44:31 | xilo | yeah i found it |
| 00:45:03 | reactormonk | good |
| 00:46:52 | xilo | sadly i do more reading on programming languages then actually programming or learning |
| 00:46:54 | xilo | :[ |
| 00:51:12 | EXetoC | just get on with it :> |
| 00:52:17 | xilo | i has no ideaz. so i just read lol |
| 00:53:58 | EXetoC | been there |
| 00:54:17 | * | DAddYE quit (Remote host closed the connection) |
| 00:54:31 | BitPuffin | xilo: why aren't you using vim for C++? Install YouCompleteMe and fix that right away |
| 00:55:02 | BitPuffin | Gonna sleep! |
| 00:55:14 | BitPuffin | night y'all |
| 00:55:14 | xilo | BitPuffin: i don't use c++ anymore :3 |
| 00:55:16 | xilo | g'night |
| 00:55:24 | BitPuffin | xilo: ah, me neither! |
| 00:55:27 | BitPuffin | only when I have to |
| 00:55:28 | xilo | good show! |
| 00:55:31 | BitPuffin | night! |
| 00:55:33 | EXetoC | but now I'm writing awesome code that will make everyone want to use Nimrod. I suggest that you do the same :> |
| 00:55:40 | xilo | what are you writing |
| 00:55:42 | BitPuffin | (still YouCompleteMe is still worth installing) |
| 00:55:43 | EXetoC | BitPuffin: good luck mate |
| 00:55:55 | BitPuffin | EXetoC: thanks, you too! |
| 00:56:02 | EXetoC | c(:) |
| 00:56:59 | xilo | eh |
| 00:58:17 | xilo | what ist hat |
| 00:58:31 | EXetoC | xilo: just some OpenGL code |
| 00:58:36 | xilo | oh |
| 00:58:37 | EXetoC | xilo: a dude with a hat.. thing |
| 00:58:42 | xilo | got a github? |
| 00:58:49 | EXetoC | c(:)-< |
| 01:00:16 | EXetoC | xilo: https://github.com/EXetoC |
| 01:00:44 | * | BitPuffin quit (Ping timeout: 268 seconds) |
| 01:01:20 | EXetoC | those libs aren't there yet, because they are unusable atm, but they will be some time before 2014, so stay tuned my friend! |
| 01:01:23 | xilo | enums can have multiple values in nimrod? |
| 01:01:39 | EXetoC | xilo: enum types? if so then yes |
| 01:01:47 | xilo | neato |
| 01:02:09 | EXetoC | if that's what you mean, then the answer is almost always yes c(:) |
| 01:02:15 | xilo | yes |
| 01:02:39 | xilo | looks like nimrod has a nice FFI |
| 01:03:24 | EXetoC | they are not strictly values though, but rather members, or enumerators </nitpick> |
| 01:03:37 | EXetoC | yes, a great interface |
| 01:03:57 | xilo | what libs are missing? |
| 01:04:24 | EXetoC | in general? |
| 01:04:33 | xilo | from what you said earlier |
| 01:04:39 | xilo | XetoC : those libs aren't there yet, because they are unusable atm, |
| 01:05:12 | EXetoC | that 2D engine |
| 01:06:56 | xilo | ooh |
| 01:07:14 | xilo | so gfwl is just for setting up window/context/handling input/etc. not the rendering and such |
| 01:07:26 | EXetoC | right |
| 01:08:00 | xilo | gotcha |
| 01:08:02 | xilo | neat |
| 01:08:05 | xilo | better than using sdl to do that |
| 01:08:18 | xilo | (which i see people do) |
| 01:08:46 | xilo | are strings utf8 in nimrod |
| 01:11:10 | EXetoC | "Per convention, all strings are UTF-8 strings, but this is not enforced. For example, when reading strings from binary files, they are merely a sequence of bytes. The index operation s[i] means the i-th char of s, not the i-th unichar. The iterator runes from the unicode module can be used for iteration over all Unicode characters." |
| 01:12:50 | xilo | that's expected |
| 01:13:13 | xilo | but i mean strings and char types support utf8 |
| 01:15:42 | comex | in what way does that not answer the question? |
| 01:16:04 | EXetoC | support how? consider this: "åäö".len == 6 |
| 01:16:59 | xilo | oh |
| 01:17:50 | xilo | but can you do char foo = 'ä' |
| 01:18:42 | xilo | kinda silly on that len bit |
| 01:20:59 | comex | https://github.com/Araq/Nimrod/issues/400 |
| 01:21:14 | comex | (I disagree, by the way - I think Python (3) is probably doing it right) |
| 01:22:58 | EXetoC | maybe he was referring to py2 |
| 01:26:35 | xilo | c# does it by displayed character |
| 01:33:09 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 02:16:13 | * | q66 quit (Quit: Leaving) |
| 02:33:36 | * | EXetoC joined #nimrod |
| 02:51:56 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 03:04:43 | * | DAddYE joined #nimrod |
| 04:22:57 | * | OrionPK quit (Read error: Connection reset by peer) |
| 04:56:07 | * | xilo quit (Ping timeout: 260 seconds) |
| 06:00:42 | DAddYE | hi thereeeeeeeeee |
| 07:33:48 | * | Araq_ joined #nimrod |
| 07:43:04 | Araq_ | comex: python 3 has b"byte strings" because it simply does not work |
| 07:56:47 | Araq_ | http://lucumr.pocoo.org/2010/1/7/pros-and-cons-about-python-3/ |
| 07:57:23 | * | DAddYE quit (Remote host closed the connection) |
| 08:25:54 | * | DAddYE joined #nimrod |
| 08:28:27 | DAddYE | Hi there! |
| 08:28:50 | DAddYE | Araq: is it possible that a cstring is subjected to be GC'd super uber fast? |
| 08:42:49 | Araq_ | DAddYE: yes. the GC is aggressive and when you convert string->cstring you need to keep the original string alive |
| 08:43:03 | Araq_ | for as long as it's used as cstring |
| 08:44:09 | DAddYE | thanks a lot |
| 08:44:11 | DAddYE | will double check better tomorrow |
| 08:44:15 | DAddYE | 1.44 am in San Francisco :D |
| 08:44:21 | DAddYE | better go bed |
| 08:44:22 | DAddYE | :D |
| 08:44:26 | * | BitPuffin[Mobile joined #nimrod |
| 08:47:38 | * | BitPuffin[Mobile quit (Client Quit) |
| 09:11:36 | * | Araq_ quit (Quit: ChatZilla 0.9.90 [Firefox 22.0/20130618035212]) |
| 09:14:21 | * | BitPuffin joined #nimrod |
| 09:15:25 | BitPuffin | Oi! |
| 09:15:39 | BitPuffin | Araq: I think I'll make the vectors (and matrices) an array type and add the temporary swizzling once [] is fixed, or add {} and later make [] an alias and later make .xyz an alias too |
| 09:17:06 | BitPuffin | so people can use whatever they think looks the best :) |
| 09:21:32 | BitPuffin | It even indexes from 0 now! https://github.com/BitPuffin/linagl/blob/master/src/linagl/vector.nim |
| 09:21:46 | * | Araq_ joined #nimrod |
| 09:40:29 | * | DAddYE quit (Remote host closed the connection) |
| 09:47:12 | BitPuffin | Isn't there a to the power of operator? |
| 09:52:12 | BitPuffin | Seems like pow can't raise ints :/ |
| 09:52:33 | BitPuffin | shouldn't the compiler implicitly convert ints to float in this case? |
| 09:56:07 | * | Araq_ quit (Read error: Connection timed out) |
| 09:56:27 | BitPuffin | erf, why do I have to battle this xD ints numbers! |
| 09:56:29 | BitPuffin | it's* |
| 09:56:54 | * | Araq_ joined #nimrod |
| 10:03:39 | Araq_ | BitPuffin: feel free to add ^ as expontential operator |
| 10:03:50 | Araq_ | it even got the right assoc now |
| 10:04:07 | BitPuffin | Araq_: I might, for now I'll use my when T is int workaround and use toFloat |
| 10:04:26 | BitPuffin | assoc? |
| 10:05:34 | BitPuffin | Araq_: is "mag" a fitting name for the magnitude proc? |
| 10:06:14 | Araq_ | I like "mag" |
| 10:06:20 | BitPuffin | good |
| 10:06:26 | BitPuffin | then I bet others will too |
| 10:06:47 | BitPuffin | currently have addition, subtraction, negation and magnitude in there hehe |
| 10:11:24 | BitPuffin | am I missing something when I've added dot and cross? |
| 10:11:45 | BitPuffin | Araq_: is there a way to make dot and cross operators so that you can write a dot b |
| 10:30:44 | BitPuffin | Hmm, I wonder how to code the cross product of arbitrary dimension |
| 10:31:38 | BitPuffin | or actually, it seems like it only applies to 3 dimensional and 7 dimensional vectors |
| 10:31:49 | BitPuffin | and we don't really need 7 dimensional vectors in an opengl library |
| 10:38:21 | * | q66 joined #nimrod |
| 10:40:21 | Araq_ | you can write a.dot(b) and a.cross(b); however I'd like the unicode versions of them |
| 10:40:55 | Araq_ | oh well just use *. adn *+ |
| 10:41:12 | * | DAddYE joined #nimrod |
| 10:45:07 | BitPuffin | Araq_: hmm, yeah actually a.dot(b) is pretty nice, but I might add the others as aliases! |
| 10:45:24 | BitPuffin | Wow this error message was not helpful |
| 10:46:28 | BitPuffin | https://gist.github.com/BitPuffin/ede667675c79eb20fc8d gee thanks compiler |
| 10:46:44 | * | Araq_ quit (Read error: Connection timed out) |
| 10:48:55 | * | Araq_ joined #nimrod |
| 10:49:06 | BitPuffin | welcome back Araq_! |
| 10:49:26 | BitPuffin | I don't know if you saw the gist before you got disconnected |
| 10:51:40 | BitPuffin | oh, so it's the len(a) != 3 |
| 10:51:49 | BitPuffin | then why didn't it just tell me that! |
| 10:52:30 | BitPuffin | Is there a len like operator that works on ranges? |
| 10:53:26 | BitPuffin | err, max(R) - min(R) perhaps? |
| 10:54:06 | BitPuffin | actually max(R) - min(R+1) |
| 10:54:14 | BitPuffin | -1* |
| 10:54:41 | * | EXetoC joined #nimrod |
| 10:55:44 | BitPuffin | Hey EXetoC! |
| 10:55:50 | BitPuffin | Vectors are almost complete :D |
| 10:59:16 | * | nihathrael quit (*.net *.split) |
| 10:59:16 | * | silven quit (*.net *.split) |
| 10:59:17 | * | Zor quit (*.net *.split) |
| 10:59:18 | * | JStoker quit (*.net *.split) |
| 10:59:18 | * | Araq quit (*.net *.split) |
| 10:59:35 | * | Araq_bnc joined #nimrod |
| 10:59:35 | * | nihathrael joined #nimrod |
| 10:59:50 | * | Zor joined #nimrod |
| 10:59:52 | BitPuffin | hmm ` Error: type mismatch: got (typedesc[range 0..2(int)]) but expected 'typedesc[range 0..2(int)]' ` for max(I) |
| 11:00:39 | * | silven joined #nimrod |
| 11:00:56 | * | JStoker joined #nimrod |
| 11:05:54 | BitPuffin | Hmm, why isn't there any simple way to check the length of an interval :( |
| 11:06:01 | BitPuffin | of a range* |
| 11:08:31 | Araq_ | len(a) should work ... |
| 11:08:56 | BitPuffin | Araq_: Doesn't seem like it does |
| 11:09:32 | BitPuffin | Araq_: it's not even in system source so |
| 11:09:58 | BitPuffin | Araq_: http://hastebin.com/jepehayole.pl that's what happens with len on a range |
| 11:10:16 | Araq_ | yeah |
| 11:10:24 | Araq_ | but it should work for arrays |
| 11:10:40 | BitPuffin | Araq_: Well it says it expects a constant expression :s |
| 11:12:49 | Araq_ | bug report |
| 11:13:40 | BitPuffin | Araq_: I guess, the problem is that len(a) works, but that doesn't work with != because len(a) != 3 is not a constant expression |
| 11:13:49 | BitPuffin | Araq_: can you think of any workaround for now? |
| 11:15:03 | Araq_ | len(a) != 3 IS a constant expression |
| 11:15:06 | * | DAddYE quit (Ping timeout: 264 seconds) |
| 11:15:12 | Araq_ | uncomment I'll fix it tonight |
| 11:15:17 | Araq_ | *do comment it out |
| 11:15:45 | BitPuffin | Araq_: No since a is dependent on what's passed through, although that is known because I will be known |
| 11:15:58 | BitPuffin | Araq_: So I don't need to open a github issue then? |
| 11:17:41 | Araq_ | a is always an array so it's known at instantiation time |
| 11:18:04 | Araq_ | make a github issue please so that progress is monitored |
| 11:18:36 | BitPuffin | Araq_: Okay sure, but is the issue with len or != here? (useful for the bug report) |
| 11:22:42 | Araq_ | len of course; the compiler knows how to evaluate != |
| 11:23:57 | BitPuffin | okay :) |
| 11:26:35 | BitPuffin | Is this good? https://github.com/Araq/Nimrod/issues/544 |
| 11:28:48 | EXetoC | BitPuffin: great |
| 11:28:49 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 11:29:09 | Araq_ | BitPuffin: it's excellent |
| 11:29:18 | BitPuffin | Goodie! |
| 11:29:32 | BitPuffin | I'll go ahead and add a dist proc in the mean time |
| 11:30:05 | * | EXetoC joined #nimrod |
| 11:33:30 | BitPuffin | welcome back EXetoC |
| 11:33:50 | EXetoC | TNX |
| 11:34:28 | BitPuffin | Okay so I've added vector addition, subtraction, negation, magnitude, distance, dot product and cross product, am I missing something? |
| 11:35:24 | BitPuffin | wait |
| 11:35:27 | BitPuffin | scalar multiplication |
| 11:36:59 | BitPuffin | now how will I make that work properly, hmm |
| 11:37:09 | BitPuffin | is there a base type for numbers? |
| 11:37:18 | BitPuffin | no that won't work |
| 11:37:25 | EXetoC | no? |
| 11:38:38 | BitPuffin | Perhaps this?: |
| 11:38:39 | BitPuffin | proc `*`[T, T1, I](a: T1, b: TVector[T, I): TVector[T1, I] = |
| 11:39:13 | BitPuffin | No damn that doesn't work either... |
| 11:39:26 | EXetoC | there are type classes. check system.nim |
| 11:39:50 | BitPuffin | Because if the elements of the vector are floats, and you pass in an int, then it doesn't become int |
| 11:40:06 | Araq_ | proc `*`[T, I](a: T, b: TVector[T, I]): TVector[T, I] |
| 11:40:21 | Araq_ | --> just use the unification algorithm of overloading |
| 11:40:30 | BitPuffin | Araq_: but then a and the vector has to be the same type |
| 11:40:39 | Araq_ | that's a feature |
| 11:40:44 | BitPuffin | like int scalars with int stuff |
| 11:40:59 | Araq_ | I like it this way |
| 11:41:01 | BitPuffin | you should be able to do float scaling on an int vector and get back a float vector |
| 11:41:10 | Araq_ | meh |
| 11:41:20 | BitPuffin | no mehs |
| 11:41:29 | Araq_ | IMO that should not be supported |
| 11:41:34 | BitPuffin | for realz and shizzles |
| 11:41:37 | BitPuffin | Why not? |
| 11:41:55 | Araq_ | because if the user can't decice on his types, it's not your problem |
| 11:42:21 | BitPuffin | not sure if I agree |
| 11:42:28 | EXetoC | I don't care much for it, but you can perform type conversions inside the function if you want |
| 11:42:31 | BitPuffin | the user might have use of the vector being ints at first |
| 11:43:08 | BitPuffin | but then when it comes to the time of scaling it could be useful that you get a float back |
| 11:43:19 | BitPuffin | EXetoC: there doesn't seem to be a number type class |
| 11:43:28 | EXetoC | TNumber |
| 11:43:56 | BitPuffin | actually yeah |
| 11:44:54 | Araq_ | implicit conversions and generics do not really mix |
| 11:44:57 | BitPuffin | that should work |
| 11:45:10 | Araq_ | it's things like these which turn C++ into a clusterfuck |
| 11:45:18 | Araq_ | just say no |
| 11:45:43 | BitPuffin | proc `*`[I](a: TNumber, b: TVector[TNumber, I): TVector[TNumber, I] = |
| 11:45:44 | BitPuffin | ? |
| 11:49:07 | EXetoC | it looks correct. just add the missing ].. and you probably want to export it as well (*) |
| 11:50:33 | BitPuffin | yeah |
| 11:50:34 | BitPuffin | hmm |
| 11:50:57 | EXetoC | but in this case, all instances of TNumber might be different, but I don't know if you're going to ignore his suggestions |
| 11:51:39 | BitPuffin | Gotta go! |
| 11:51:51 | BitPuffin | We'll fix this later |
| 11:51:53 | BitPuffin | cheers |
| 11:52:39 | EXetoC | bye |
| 11:54:00 | Araq_ | same here, bye |
| 11:54:12 | * | Araq_ quit (Quit: ChatZilla 0.9.90 [Firefox 22.0/20130618035212]) |
| 11:56:06 | * | BitPuffin quit (Ping timeout: 246 seconds) |
| 12:11:20 | * | DAddYE joined #nimrod |
| 12:23:37 | EXetoC | I'm constantly reminded of how bad D's tuples are. too much template magic |
| 12:23:47 | EXetoC | and of course an awful syntax as a result |
| 12:23:54 | * | Araq joined #nimrod |
| 12:23:56 | EXetoC | </hate> later :-) |
| 12:33:45 | * | Araq quit (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]) |
| 12:44:53 | * | DAddYE quit (Ping timeout: 248 seconds) |
| 12:48:27 | * | Araq joined #nimrod |
| 12:50:29 | * | Araq quit (Client Quit) |
| 13:25:29 | * | xilo joined #nimrod |
| 13:41:20 | * | DAddYE joined #nimrod |
| 14:15:16 | * | DAddYE quit (Ping timeout: 276 seconds) |
| 15:11:10 | * | DAddYE joined #nimrod |
| 15:15:40 | * | DAddYE quit (Ping timeout: 256 seconds) |
| 15:48:17 | EXetoC | some of my generic functions depend on other generic functions that I don't necessarily want to export. I wonder if that can be made to work somehow |
| 15:49:34 | EXetoC | might be a little hacky though. hm, term rewriting macros to the rescue maybe |
| 16:11:14 | * | Mat2 joined #nimrod |
| 16:11:21 | Mat2 | hello |
| 16:12:48 | * | DAddYE joined #nimrod |
| 16:46:42 | * | DAddYE quit (Ping timeout: 268 seconds) |
| 16:52:47 | EXetoC | I'm also making a vector lib. I was pushing the compiler to its limits again, so I decided to just keep it simple by disallowing `*`(vec, scalar). "v2(x, y) * v2(z)" is fine imo |
| 16:53:19 | EXetoC | but only because of the short names. I try not to overdo it though |
| 17:25:16 | dom96 | yo yo |
| 17:25:18 | * | DAddYE joined #nimrod |
| 17:25:45 | Mat2 | hi DAddYE and EXetoC |
| 17:25:56 | EXetoC | hello there, human|bot|alien |
| 17:26:00 | dom96 | no hi for me? :( |
| 17:26:18 | Mat2 | hi dom96 |
| 17:26:46 | Mat2 | hi all |
| 17:26:51 | Mat2 | :) |
| 17:26:51 | dom96 | So i tried advertising nimrod in here, care to give me some support? https://news.ycombinator.com/item?id=6090549 |
| 17:30:00 | dom96 | Maybe I should just start replying "Use Nimrod" to everyone. |
| 17:30:43 | * | Mat2 just reading the comments and article? |
| 17:31:43 | * | DAddYE quit (Ping timeout: 268 seconds) |
| 17:31:50 | dom96 | EXetoC: are both you and bitpuffin working on vectors? |
| 17:32:15 | * | Araq_bnc is now known as Araq |
| 17:32:21 | Mat2 | hi Araq |
| 17:32:32 | EXetoC | dom96: actually, this is not a standalone lib. I'm aware of how many people are working on vector stuff |
| 17:33:32 | Mat2 | so why don't all of you don't work together ? |
| 17:33:48 | Mat2 | soryy, so why all of you don't work together |
| 17:33:53 | Mat2 | ^sorry |
| 17:34:19 | dom96 | indeed, good question. |
| 17:38:18 | * | DAddYE joined #nimrod |
| 17:39:32 | EXetoC | I'm sure the others will figure out what needs to be done. BitPuffin is just having some issues with the generic part of it since he's new, and he doesn't even have a repo yet |
| 17:41:44 | Mat2 | if someone of you have troubles with CPU dependent aspects (like utilizing SSE or other SIMD extensions) I can help out |
| 18:10:28 | Mat2 | dom96: What are your arguments for Nimrod as reaction to the article you linked ? It describes mostly subjective preferences of style |
| 18:10:45 | Mat2 | not functionality |
| 18:12:08 | dom96 | I think it's pretty hard for people to give an unbiased review of a programming language after they spent so much time rewriting a big part of their own (or the companie's they are a part of) infrastructure in that language. |
| 18:12:24 | dom96 | *company's |
| 18:14:40 | Mat2 | in these case one can simply remark something like: "use Nimrod, it's new and sexy, its the future, get part of its fashion, have fun" |
| 18:15:26 | dom96 | I haven't actually given Go a proper try because I don't see any reasons why I should. |
| 18:17:20 | Mat2 | I have some (non impressive) experiences with the language |
| 18:20:30 | Mat2 | as otherwise noted in the comments, its type-system is not consequent, only limited extensible and far to restrictive for system-programming puposes |
| 18:20:59 | Mat2 | ^purposes |
| 18:23:21 | Mat2 | the coroutine concept is simple and elegant on the other side |
| 18:24:29 | Araq | the goroutine concept is in fact very broken |
| 18:25:14 | Araq | it doesn't prevent capturing variables, in fact it encourages it |
| 18:25:30 | Mat2 | I think your ar right |
| 18:25:34 | Araq | but captured variables are a recipe for data races |
| 18:26:02 | Araq | you pay the price of potentially concurrent code everywhere when in fact the concurrency is quite limited |
| 18:26:17 | Araq | because you only have N CPUs where N is usually a small number |
| 18:27:44 | Mat2 | that's true but Go was build for parallel processing inside large MIMD systems (like Google's server farms) |
| 18:28:40 | Araq | *shrug* for many CPUs its GC technology doesn't scale anyway and it will be tough to make it scale |
| 18:29:04 | Araq | in practice they will use multiple processes like everyone else does |
| 18:29:40 | Mat2 | it's even not granted that goroutines shedule on different cores, anyhow |
| 18:31:05 | Mat2 | but its a simple concept |
| 18:31:28 | Araq | threads and locks are also simple |
| 18:32:07 | Araq | it's hard to ensure correctness with them, but then goroutines are not much better at that problem |
| 18:36:37 | Mat2 | see, much programmers I know at work which came from university have problems understanding locks, mutexes and semaphores like all stuff of concurrent programming. I think the designers of Go just choosen an approach which offers utilisation for peoples which did not want to gain deep undertanding of the material |
| 18:37:32 | Mat2 | (it doesn't mean to think of there solution as effective in terms of energeing) |
| 18:38:22 | Mat2 | however, go had seem to work out good enough for the infrastucture of Google for sure |
| 18:39:20 | Araq | I dunno; most of their services are in other languages and I can't see them rewrite them in Go |
| 18:40:38 | Araq | also I can't see the language appeal to the average Google developer who is a smart guy after all and surely can deal with generics and the like |
| 18:41:12 | Mat2 | there won't. Go is used more like a scripting-language with ambitions for future usage in system-programming |
| 18:41:50 | Mat2 | I can envision a Go compiler for small, embedded boards like the Maximite or Arduino class boards |
| 18:41:56 | comex | Araq: and yet Google doesn't use any fancy modern languages, but usually C++ and Java |
| 18:42:05 | comex | and they make crap like Dart |
| 18:43:12 | comex | my impression has always been that Google wants their languages to be as boring and unobtrusive as possible, encouraging straightforward, unclever code |
| 18:43:44 | comex | (however, i was only on the inside very briefly, so take that with a grain of salt) |
| 18:44:45 | Araq | comex: I know |
| 18:45:07 | comex | anyway, it doesn't seem like they'd terribly mind making custom container types annoying, why are you using those in the first place |
| 18:45:36 | comex | then again, Go is radical in other ways, with no classes and goroutines and stuff |
| 18:45:39 | comex | that's what I like it for |
| 18:45:46 | comex | and the syntax is pretty good |
| 18:45:57 | Araq | I find it insulting |
| 18:46:16 | Araq | it's always been "type identifier" or "identifier: type" |
| 18:46:30 | comex | I like "identifier type" |
| 18:46:35 | comex | my language will do it that way |
| 18:46:41 | Araq | lol |
| 18:46:52 | Mat2 | were discussing likeness of style |
| 18:47:10 | comex | except there will be a colon anyway |
| 18:47:12 | comex | :foo int = 5; |
| 18:47:23 | EXetoC | eh |
| 18:47:24 | comex | but normally omitted, so :foo = 5; |
| 18:47:29 | Mat2 | I think the coroutine concept and its limitations are an important feature of Go |
| 18:47:46 | Araq | sure it's an important feature of Go, Mat2 |
| 18:48:03 | dom96 | comex: nooo, no semicolons! |
| 18:48:08 | Mat2 | personally, I generally do not like to read C style languages |
| 18:48:28 | Araq | semicolon insertion rules... seriously? |
| 18:48:43 | Araq | expr/stmt split ... seriously? (Nimrod evolved :P ) |
| 18:48:57 | Araq | atoi wtf? |
| 18:49:06 | comex | lol |
| 18:49:09 | Araq | yeah ... "Nice" syntax |
| 18:49:18 | Araq | amateurs ... |
| 18:49:40 | comex | dom96: I feel like it's best to either go full Python or stick with semicolons |
| 18:50:22 | comex | anyway, I'm doing semicolons like Rust |
| 18:50:46 | dom96 | perhaps. I really like Python's syntax, which is the reason why I like Nimrod so much. |
| 18:51:36 | comex | statements are expressions, semicolon evaluates the first and returns the second (or void if there is nothing after it) |
| 18:51:58 | comex | so a function body { 5 } returns 5, but { 5; } returns void |
| 18:52:01 | Mat2 | my point is: There is a demand for languages which handles parallel-processing without expected knowledge sidens the programmer, and Go seem to be designed for this audience |
| 18:52:13 | Araq | comex: you don't need semicolons for that feature ;-) |
| 18:52:32 | comex | it makes it more elegant :p |
| 18:53:25 | comex | anyway, my language is meant to feel familiar from C, so semicolons are a must :) |
| 18:56:35 | comex | my language will also have no classes, no automatic vtable generation... but templates and extremely powerful macros |
| 18:56:38 | comex | and it doesn't exist :p |
| 18:56:41 | comex | but it will... |
| 18:58:17 | Mat2 | comex: Have you take a look at Rust ? |
| 18:58:38 | Mat2 | or better ATS ? |
| 18:59:06 | comex | Mat2: i've been meaning to look at ATS properly but it's extremely far from what I want |
| 18:59:30 | comex | Rust is very nice, but I want my own take on things :p |
| 19:01:53 | Mat2 | I also do not understand what's the advantage to depend a language on semicolons as sequence terminator because these 'feature' was originally intendend as compromise for easier parsing. It has nothing to do at all with syntax and semantic reasons of a programming-language |
| 19:03:04 | Araq | whether an expression yields a type or void is a semantic question, semicolons have nothing to do with it |
| 19:04:18 | comex | in particular, my language does not care about safety like rust, will have a minimal and optional standard library - you are encouraged to use C libraries - and will make it very easy to use C libraries |
| 19:05:04 | Mat2 | so you want a C++ without the complexibility |
| 19:05:13 | comex | sort of |
| 19:05:36 | comex | Araq: sure, but they make it unambiguous whether a particular line is supposed to return a value or void |
| 19:05:50 | Mat2 | ??? |
| 19:05:57 | comex | semicolons |
| 19:06:09 | Araq | comex: use 'discard' to discard a value instead :P |
| 19:06:29 | comex | then you would have to write 'discard' everywhere |
| 19:06:40 | comex | well. not necessarily |
| 19:09:16 | Mat2 | hmm, no granted type-safety, Algol ispired syntax with lot of curly-braces, template support - choose B ! |
| 19:09:50 | comex | sure :p |
| 19:10:05 | comex | since when does B have template support? |
| 19:11:06 | Mat2 | MULTICS had featured a very advanced preprocessor for source-code out-of-the box |
| 19:11:29 | * | Smaehtin joined #nimrod |
| 19:11:43 | Araq | for the people who don't know: Multics = Unix with error checking |
| 19:13:02 | comex | (i want macros to be at least as powerful as Nimrod's, but hopefully nicer) |
| 19:13:24 | Araq | hey nimrod's macros are getting nicer all the time |
| 19:13:29 | Mat2 | the later Unix version of B lost these possibility |
| 19:13:32 | comex | i believe you :) |
| 19:13:39 | dom96 | comex: save yourself lots of work and just fork Nimrod ;) |
| 19:13:42 | Araq | and if you do make them even more powerful |
| 19:13:54 | Araq | then you get into serious trouble IMHO |
| 19:13:57 | * | alexandrus joined #nimrod |
| 19:14:02 | comex | what kind of trouble? |
| 19:14:12 | Araq | because then you can't reason about any piece of code at all |
| 19:14:22 | comex | yep, that's the goal |
| 19:14:26 | comex | no, really |
| 19:14:27 | Araq | as the macro could go UP the ast |
| 19:14:35 | Araq | and transform the whole module |
| 19:14:51 | comex | yet, on the other hand, I hate how implicit and confusing C++ code can be |
| 19:14:59 | comex | so in theory, the rule will be: |
| 19:15:10 | comex | as powerful as you need when you need them, don't bloody use them unless it's life or death |
| 19:15:36 | comex | kind of schizophrenic! |
| 19:16:51 | comex | of course, nimrod's are quite powerful already |
| 19:16:56 | comex | probably it won't make much difference |
| 19:17:15 | comex | but really what's more important is "nice" |
| 19:18:29 | comex | so, for example, it will be possible to evaluate the type or value of an AST node |
| 19:19:12 | comex | it will also be possible to create a type which does your macro thing whenever it's used in any way |
| 19:22:43 | Mat2 | you will get in serious trouble with this approach because there can exist situations where the value is constant but its type depends on access |
| 19:23:04 | Mat2 | I think of unions for example which references the same address |
| 19:23:33 | Mat2 | ^adress |
| 19:24:33 | Araq | it's "address" |
| 19:24:49 | Mat2 | thanks |
| 19:25:18 | EXetoC | the actual union is a type too |
| 19:25:29 | EXetoC | so it just depends on how much you can query as a user |
| 19:27:50 | Mat2 | typedef union {uin64_t word; uint8_t bytes[7];} suCell; |
| 19:28:54 | Mat2 | <- value constant, access dependent of referencing word or bytes[n] independent of the structure type |
| 19:34:50 | Mat2 | what these union determinize is the implicit type conversation, not type of its references memory location |
| 19:35:14 | Mat2 | ^referenced |
| 19:36:41 | Mat2 | its content can be of any type possible (for example per priour pointer access) |
| 19:38:29 | Mat2 | so how can a statical compiler evaluate the value inside such a construct without reinterpretation of the AST ? |
| 19:38:41 | Mat2 | I think that's not possible |
| 19:45:06 | * | gradha joined #nimrod |
| 19:49:48 | EXetoC | YES |
| 19:49:58 | EXetoC | don't you just love it when you manage to tame OpenGL? |
| 19:50:11 | EXetoC | gradha: hello friend. are you done watching cat videos? |
| 19:50:42 | gradha | the internet keeps producing them, there's no end to them |
| 19:51:03 | Mat2 | suCell test; test.word = (float) 42.14; uint8_t erg = test.bytes[0]; // gcc compiles without type checking or error |
| 19:51:08 | gradha | I don't watch cat videos though, I hate cats |
| 19:51:20 | EXetoC | lol rly. ok :p |
| 19:56:06 | EXetoC | Mat2: but AST is usually only a compile-time concept isn't it? I don't think he was referring to the runtime value. I don't know what he meant to be honest |
| 19:56:56 | EXetoC | literals maybe |
| 19:58:24 | Mat2 | I had interpretated his goal as evaluating or better estimate the run-time characteristics of values though AST parsing |
| 20:00:46 | Mat2 | I mean static parsing and not its run-time interpretation |
| 20:05:51 | Mat2 | in my opinion his goal can only be reached if the type of all referenced memory-locations is known at compile-time and that means some kind of interpretation is needed |
| 20:06:21 | Mat2 | within a JIT compiler, that's possible for example |
| 20:13:00 | EXetoC | comex: is that what you were referring to? ^ |
| 20:19:13 | EXetoC | gradha: do you like squirrels? |
| 20:24:08 | gradha | I like most animals well cooked |
| 20:27:40 | EXetoC | ic |
| 20:31:18 | * | alexandrus quit () |
| 20:57:29 | comex | Mat2: in the case of a field in a union, then the callback will only get invoked if you actually access that field |
| 20:57:53 | comex | it's not intended to magically protect against you ever accessing that memory, but simply a way to control the semantics of a type |
| 20:59:30 | comex | similar to C operator overloading, but more powerful |
| 20:59:33 | comex | er, C++ |
| 21:01:42 | Mat2 | hmm, can you explain your idea more in depth please |
| 21:02:40 | Mat2 | accessing a callback by referencing a variable reads like dynamic-type casting for me |
| 21:04:24 | comex | the callback would be part of the variable's type |
| 21:04:33 | comex | or otherwise statically registered for that particular variable |
| 21:04:40 | Smaehtin | Is there a way in Nimrod to get the parameter types of a proc inside a template? |
| 21:04:55 | comex | in most cases this isn't particularly needed - or doesn't get you more than a regular macro |
| 21:12:33 | comex | one example where it might be useful is a type that lazily represents a value - say, a future |
| 21:12:58 | Araq | Smaehtin: currently not |
| 21:13:47 | comex | or heck, a pure lazy type like in haskell, you could do that |
| 21:14:00 | Smaehtin | Araq: Alright, I see, thanks |
| 21:15:50 | comex | if a was a lazy int, overload any instances where a is used to force strictness - that much can be done in C++ (albeit in an ugly fashion, you would have to overload every operator to delegate to the underlying type), but then you can say that if it was already forced statically earlier in a function, then the code to check if it's lazy need not be generated |
| 21:16:57 | comex | something that wouldn't require the full power but still can't done in Nimrod - I think - is making a type that can be swizzled like in GLSL, as mentioned before |
| 21:17:41 | comex | or making an object that runs code when it goes out of scope, but again without having to make a wrapper class that overloads every operator to delegate, and with the ability to still use & to make a pointer to the underlying object |
| 21:18:21 | Araq | comex: swizzling will be possible via overloading of '.' and nimrod got destructors |
| 21:19:05 | comex | but can you do it without manually specifying every possible swizzle combination? i.e. is it integrated with the macro system |
| 21:19:22 | Araq | yes |
| 21:19:30 | comex | well, that's nice :p |
| 21:19:34 | comex | how does it work? |
| 21:19:55 | EXetoC | people really like swizzling :> |
| 21:19:57 | Araq | macro `.`(x: typeHere, y: expr): typeHere = # macros participate in overloading resolution now |
| 21:20:09 | comex | oh, that's fun |
| 21:20:13 | Mat2 | EXetoC: *g* |
| 21:20:44 | Mat2 | ExetoC: specially in Norway |
| 21:21:06 | comex | mine won't look like that because it doesn't do overloading (at all) |
| 21:21:13 | EXetoC | aha |
| 21:21:37 | comex | but ok, I'm wrong, that's pretty close to what I want to be able to do |
| 21:22:20 | * | EXetoC quit (Read error: Connection reset by peer) |
| 21:25:48 | comex | hmm, is there anything else interesting about my language idea |
| 21:26:39 | comex | i want only first class iterators, like Rust - there is no reason you shouldn't be able to say enumerate(zip(rlist_each(a), rlist_each(b))) and have it be just as efficient as doing it manually |
| 21:27:00 | comex | *yawn* |
| 21:30:19 | Mat2 | do you also prefer polymorphism ? |
| 21:33:40 | comex | which kind? |
| 21:34:16 | Mat2 | the 'most-wanted' one as in C++ |
| 21:34:22 | comex | i think operator overloading, function overloading, and probably virtual methods are evil and should be avoided at all costs |
| 21:34:36 | Araq | lol |
| 21:34:38 | comex | like, people just don't know where to stop |
| 21:34:53 | Araq | virtual functions are evil but operator overloading is only some sugar |
| 21:35:03 | comex | is it nice to be able to implement + on vec3? yes. is it nice that LLVM use iterators have like three different ways to convert to user? no. |
| 21:35:15 | comex | or maybe some of them go to use |
| 21:35:25 | comex | but there's at least one magic * operator there |
| 21:35:26 | comex | it's evil |
| 21:35:36 | Mat2 | LLVM is a bad example by design |
| 21:35:39 | Araq | it's irrelevant when you have the proper tools |
| 21:35:46 | comex | what are proper tools? |
| 21:35:56 | Araq | oooh I need to move my mouse cursor over it to see where it comes from |
| 21:36:02 | Araq | big deal :rolleyes: |
| 21:36:12 | comex | first of all, i don't have such tools |
| 21:36:19 | Araq | well that's your problem then |
| 21:36:22 | comex | second of all, i don't want to move my mouse cursor over every word in the program to see what it does |
| 21:36:28 | Araq | coding without proper tools is foolish |
| 21:36:42 | comex | or if it's a patch or on github's code viewer, what do i do then? |
| 21:37:01 | Araq | despair I guess |
| 21:37:08 | comex | I don't even like C++ overloading [] for map and vector |
| 21:37:37 | comex | well, vector's okay (it can be confused with C arrays, but you shouldn't use those anyway), but map is confusing, because |
| 21:38:03 | Mat2 | cout << "overloading can be fun in case of the right namespace" << "\n"; |
| 21:38:04 | comex | reading a particular bit of code that does things[unchecked index] = thing |
| 21:38:24 | comex | it's not clear whether it's an unsafe vector or array operation, or a perfectly fine map one |
| 21:38:44 | * | EXetoC joined #nimrod |
| 21:38:46 | comex | (this can be helped by naming 'things' better as 'thingMap' or whatever, but that's not always done) |
| 21:38:59 | comex | and i've seen someone other than me get tripped up by this |
| 21:39:27 | comex | of course it's not the end of the world, people spend lots of time reading C++ without too much trouble |
| 21:39:36 | comex | but it's just a stumbling point, which should be avoided. |
| 21:40:28 | comex | like linus, I dislike obj.method() for similar reasons |
| 21:40:40 | comex | as it loses context |
| 21:41:07 | comex | so I prefer sometype_method(obj) even if it's more typing (if you have such a good IDE, surely it will also be able to autocomplete this for you, so who cares?) |
| 21:41:45 | Mat2 | comex: I do not know a single person who reads C++ code under free will (except the ones which get paid to do so) |
| 21:41:47 | EXetoC | I prefer the former, Nimrod style |
| 21:41:51 | Araq | it's not about the typing, comex |
| 21:41:53 | comex | function overloading, for its part, is okay if you don't have implicit type conversions, but with those, like in C++, it's awful |
| 21:41:59 | Araq | I don't want to read that overly verbose shit |
| 21:42:16 | Mat2 | agree |
| 21:42:40 | comex | I do, it's not that long and makes it clear what I'm dealing with - again, without having to roll over things in an IDE I don't have |
| 21:42:57 | Araq | I don't want to code for dinosaurs who never used a working IDE nor can imagine such a thing |
| 21:43:00 | comex | it would sure be nice in something like chrome where there are like 5 levels of delegation to sub-objects for everything |
| 21:43:12 | Araq | and yet use VIM with plugins which pretty much is an IDE anyway |
| 21:43:29 | comex | and the same members have different types in different objects, but they implement the same methods |
| 21:43:32 | comex | really confusing |
| 21:43:47 | comex | as for vim, I don't mind editor power, but it's a fact that there is no good C++ navigation tool for vim :p |
| 21:43:55 | * | Associat0r joined #nimrod |
| 21:43:55 | * | Associat0r quit (Changing host) |
| 21:43:55 | * | Associat0r joined #nimrod |
| 21:44:22 | Mat2 | Araq: I use VIM for coding in Nimrod at current *g* |
| 21:45:10 | comex | nor emacs, I think |
| 21:45:59 | * | gradha quit (Quit: bbl, need to watch https://www.youtube.com/watch?v=1ZZC82dgJr8 again) |
| 21:46:16 | comex | (again, LLVM is a primary example of how horrible C++ can be when it comes to function overloading) |
| 21:47:09 | Araq | I'm sick and tired of people complaining about overloading (100% compiletime feature) and then don't care about what the ordinary scripting language does |
| 21:47:26 | Mat2 | Emacs is fine; It is an OS featuring an embedded text editor ;) |
| 21:47:45 | comex | Araq: scripting languages typically have no overloading |
| 21:47:57 | Araq | which is delegating everything to runtime so you have no chance but pray nobody actually modified the "builtin" == operator or something |
| 21:48:13 | comex | well, i mean function overloading |
| 21:48:18 | Araq | comex: indeed they are doing something much worse instead |
| 21:48:34 | Araq | and yet nobody even realizes |
| 21:48:53 | comex | i don't even know what it would mean to "modify the builtin == operator" |
| 21:49:02 | comex | you can overload == in most scripting languages, sure... |
| 21:49:15 | Araq | monkey patching? dynamic binding? |
| 21:49:45 | comex | they're like abortion |
| 21:49:45 | * | Associat0r quit (Quit: Associat0r) |
| 21:49:50 | comex | they should be safe, legal, and rare ;p |
| 21:49:51 | * | OrionPK joined #nimrod |
| 21:50:49 | comex | which, incidentally, means that I do not like JS, Ruby, and Objective-C's habits of monkey patching built-in objects to add random stuff |
| 21:52:04 | comex | but depending on the situation, that isn't that much better with an overloading-based dot operator either, you could still get a duplicate tohex(string) |
| 21:52:12 | comex | but the fault is of the dot operator! |
| 21:52:36 | comex | if you don't have a dot operator, it's not cleaner looking to use a short, ambiguous name |
| 21:52:38 | Mat2 | a scripting-level is a patchwork environment for gluing applications. I can not think of a meaningful example where overloading features would make sense for it |
| 21:53:01 | Mat2 | ^language |
| 21:53:02 | comex | Mat2: scripting languages are very often used to write large applications, you know that perfectly well ;p |
| 21:54:01 | Mat2 | that's why the world went wrong... |
| 21:54:14 | comex | i like scripting languages |
| 21:54:28 | Araq | I never use them anymore unless I can't avoid it |
| 21:54:29 | comex | i'm a little schizophrenic on this matter too |
| 21:54:44 | comex | typing types makes code easier to understand... yet not doing it makes code easier to read |
| 21:54:58 | Araq | no |
| 21:55:07 | Araq | that's just ... wrong on so many levels |
| 21:55:09 | comex | er, s/read/write |
| 21:55:10 | comex | sorry |
| 21:55:19 | comex | what i said is certainly wrong :) |
| 21:55:26 | Araq | I see |
| 21:55:32 | comex | admittedly, scripting versus compiled languages isn't just that - part of the difference would be made up with more powerful macros |
| 21:55:49 | comex | like, there is no reason I shouldn't be able to do Python metaclass crap in a compiled language |
| 21:56:14 | Araq | there should be a reason to do metaclass crap in Python |
| 21:56:18 | Araq | *shouldn't |
| 21:56:24 | comex | yet sometimes there is |
| 21:56:48 | comex | although they're often used as poor man's macros :/ |
| 21:57:10 | comex | for example |
| 21:57:22 | comex | RPC |
| 21:57:27 | comex | trivial in every dynamic language |
| 21:57:37 | comex | pain in the ass in (almost) every static one, you need an external code generator |
| 21:58:05 | comex | and usually you need a definition file for your methods, separate from the normal code defining the object |
| 21:58:22 | comex | but there is no reason it shouldn't be easy in a static language too |
| 21:58:40 | comex | (although you should always be careful with RPC - but that doesn't mean there should be pointless barriers) |
| 21:58:54 | Araq | you know, C# does it easily |
| 21:59:25 | Smaehtin | Do the constraints in Nimrod not work on objects yet? like type TMyObject[T: int] = object ... |
| 21:59:38 | comex | I don't know much about C#, but I bet it takes advantage of reflection and crap |
| 22:00:00 | comex | which is nice, but not applicable to native code languages |
| 22:00:00 | Araq | they have issues, Smaehtin but your example looks just fine |
| 22:01:14 | Smaehtin | Araq: I can still declare a var value = TMyObject[string]() even though the constraint is int though |
| 22:01:34 | Smaehtin | Araq: I'm guessing that's just a bug then? |
| 22:01:57 | Araq | yeah |
| 22:02:45 | Mat2 | get some slep, ciao |
| 22:03:05 | * | Mat2 quit (Quit: Verlassend) |
| 22:03:20 | Smaehtin | Araq: Alright. Still though, damn you did a good job with Nimrod. I can't believe I haven't heard of it before |
| 22:03:26 | Smaehtin | Araq: How long has it been in development? |
| 22:04:30 | Araq | dunno 6 years |
| 22:04:54 | Smaehtin | Holy shit |
| 22:09:32 | Araq | yeah but I can only work on it in my spare time |
| 22:12:02 | Smaehtin | Shame |
| 22:29:12 | * | Smaehtin quit (Quit: Page closed) |
| 23:02:48 | * | xilo quit (Read error: Connection reset by peer) |
| 23:04:13 | * | xilo joined #nimrod |
| 23:40:58 | EXetoC | woot |