=== AStorm [n=astralst@host-81-190-179-124.gorzow.mm.pl] has joined #upstart | ||
=== Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart | ||
=== Md [i=md@freenode/staff/md] has joined #upstart | ||
=== Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart | ||
=== Keybuk [n=scott@quest.netsplit.com] has joined #upstart | ||
_ion | Sigh, doing anything in a virtual machine is simply too slow on this computer. | 01:44 |
---|---|---|
_ion | It probably takes a minute just to finish the initramfs script. :-) | 01:44 |
_ion | I guess i'll have to hack on replacement-initscripts on this computer directly. | 01:45 |
Keybuk | heh | 01:59 |
=== Keybuk just hacks directly | ||
=== AStorm [n=astralst@host-81-190-179-124.gorzow.mm.pl] has joined #upstart | ||
=== j_ack [n=rudi@p508DBB02.dip0.t-ipconnect.de] has joined #upstart | ||
_ion | (offtopic: http://johan.kiviniemi.name/blag/2007/02/16/monitorcalc/) | 04:19 |
Keybuk | you really do like ruby, don't you? :p | 04:58 |
=== mbiebl [n=michael@e180072138.adsl.alicedsl.de] has joined #upstart | ||
_ion | It's not perfect, but i haven't found any better ones yet. :-) | 06:07 |
=== AStorm [n=astralst@host-81-190-179-124.gorzow.mm.pl] has joined #upstart | ||
Keybuk | what for though? | 06:25 |
Keybuk | a language can never be perfect for everything | 06:26 |
Keybuk | only perfect for something | 06:26 |
Keybuk | what is ruby's task? | 06:26 |
AStorm | Theoretically, network programming and Perl's place | 06:27 |
AStorm | Ruby = better Perl | 06:27 |
Keybuk | so ruby has regular expressions as a first class object? | 06:27 |
AStorm | As a language construct, you meant? Yes. | 06:28 |
AStorm | And an object too. | 06:28 |
AStorm | but then, it isn't all that useful :P | 06:28 |
Keybuk | what does a ruby program that returns all lines from a file matching a regular expression look like? | 06:28 |
AStorm | Beats me. I don't program in Ruby. | 06:28 |
Keybuk | it would surprise me if it's as good at parsing as Perl is | 06:28 |
AStorm | Why not? | 06:29 |
Keybuk | since Perl does that so well, at the expense of other langauge niceties | 06:29 |
AStorm | Anything is as good at parsing as perl. | 06:29 |
Keybuk | eh? | 06:29 |
AStorm | Though the syntax might be bulkier a bit. | 06:29 |
Keybuk | the syntax is everything | 06:29 |
Keybuk | and the speed at which it can do it | 06:29 |
AStorm | Nothing at all. | 06:29 |
AStorm | Speed, yes, that matters. | 06:29 |
Keybuk | you could write a program to extract data from files and generate a report in C... | 06:29 |
Keybuk | ...you just wouldn't | 06:29 |
Keybuk | you would always use Perl | 06:29 |
AStorm | No, because it doesn't have any good regexp library. | 06:30 |
AStorm | I would use Python personally. | 06:30 |
Keybuk | of course it does | 06:30 |
Keybuk | Python isn't good at this kind of thing | 06:30 |
AStorm | pcre you mean | 06:30 |
AStorm | It is _very_ good | 06:30 |
Keybuk | no, it's quite bad | 06:30 |
AStorm | if you don't mind re.match("WHATEVER") | 06:30 |
AStorm | Instead of ~= | 06:30 |
Md | which tends to suck, yes | 06:30 |
AStorm | It has splitting and other things too. | 06:30 |
Keybuk | while (<>) { | 06:31 |
Keybuk | print $1 if /[a-z] ([0-9] +)/gi; | 06:31 |
Keybuk | } | 06:31 |
Keybuk | -- | 06:31 |
Keybuk | what's the Python equivalent of that? | 06:31 |
AStorm | for line in stdin: ... | 06:31 |
Keybuk | no, | 06:31 |
Keybuk | not stdin | 06:31 |
AStorm | for line in stdin: x = re.match("[a-z] ([0-9+)"); if x: print x.groups(1) | 06:32 |
Keybuk | BZZT | 06:32 |
AStorm | What is that <> thingy? | 06:32 |
AStorm | Some variable? | 06:32 |
Keybuk | doesn't parse filenames given on the command line in preference to stdin | 06:32 |
Keybuk | doesn't print each number on the line | 06:32 |
Keybuk | and you've tried to bunch it up into one line, which is very bad Python | 06:32 |
AStorm | Yep | 06:32 |
AStorm | It's IRCy Python | 06:32 |
AStorm | :P | 06:32 |
AStorm | It would probably take 5 lines to do exact the same thing as in Perl. | 06:33 |
AStorm | Which I don't know. | 06:33 |
Keybuk | I've reached 30 lines so far ... | 06:33 |
AStorm | :P | 06:33 |
AStorm | What does that thing means actually? | 06:33 |
AStorm | *mean | 06:33 |
=== Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart | ||
Keybuk | whatever you want it to mean | 06:33 |
AStorm | That <> | 06:34 |
Keybuk | the point is that Perl is *VERY* good at extracting information out of files and generating data sets from it | 06:34 |
Keybuk | extraordinarly good | 06:34 |
AStorm | Well, yep. | 06:34 |
Keybuk | <> is "each line for each file listed on the command line, or stdin" | 06:34 |
AStorm | Aha. | 06:34 |
AStorm | That'll be 7 lines of Python | 06:34 |
AStorm | :P | 06:34 |
AStorm | One for more | 06:34 |
Keybuk | no, it's still not 7 lines of python | 06:34 |
AStorm | and two imports | 06:34 |
AStorm | Ok, 8, miscalculated. | 06:34 |
AStorm | :P | 06:35 |
Keybuk | two imports? | 06:35 |
AStorm | Yep. | 06:35 |
Keybuk | oh, right, re | 06:35 |
AStorm | Heh, one less even. | 06:36 |
AStorm | http://docs.python.org/lib/module-fileinput.html | 06:36 |
AStorm | :P | 06:36 |
AStorm | That's what Perl does with that <>, isn't it? | 06:36 |
Keybuk | yes | 06:37 |
Keybuk | you still can't get anything legible | 06:37 |
AStorm | You can do even better with Python 2.5 | 06:37 |
AStorm | print x.groups(1) if x | 06:37 |
AStorm | s/if/when/ | 06:38 |
AStorm | print x.groups(1) when x | 06:38 |
AStorm | or even.. in older Python... | 06:38 |
Keybuk | still not x.groups(1) I'm afraid | 06:38 |
AStorm | It is. | 06:38 |
Keybuk | no | 06:38 |
Keybuk | Perl will print all matches in the line | 06:38 |
Keybuk | because I used /g | 06:38 |
AStorm | x is an instance of a matchobjects. | 06:38 |
AStorm | Aha, one missing flag. | 06:39 |
Keybuk | (python doesn't have this flag <g>) | 06:39 |
AStorm | re.GLOBAL | 06:39 |
Keybuk | AttributeError: 'module' object has no attribute 'GLOBAL' | 06:39 |
AStorm | Oh yes it does :P | 06:39 |
AStorm | re.findall | 06:39 |
Keybuk | no | 06:39 |
AStorm | re.finditer | 06:39 |
Keybuk | right, that's not a flag | 06:39 |
Keybuk | import re | 06:40 |
Keybuk | import fileinput | 06:40 |
Keybuk | RE = re.compile(r'[a-z] ([0-9] +)', re.IGNORECASE) | 06:40 |
Keybuk | if __name__ == "__main__": | 06:40 |
Keybuk | for line in fileinput.input() | 06:40 |
Keybuk | for number in line.findall(): | 06:40 |
Keybuk | print number | 06:40 |
Keybuk | is the equivalent Python | 06:40 |
AStorm | Yep. | 06:40 |
Keybuk | which is infintely less useful than the Perl | 06:40 |
Keybuk | ergo. at parsing, Perl wins | 06:40 |
AStorm | But you don't have to compile :P | 06:40 |
Keybuk | you do bloody well have to compile | 06:40 |
Keybuk | this file is 2GB! | 06:40 |
AStorm | No, you don't. | 06:40 |
Keybuk | compiling that regexp every time will run slow as a dog | 06:40 |
AStorm | 100 latest matches are buffered. | 06:40 |
AStorm | NO. | 06:40 |
Keybuk | actually | 06:40 |
Keybuk | heh | 06:40 |
AStorm | Python won't compile it every time. | 06:40 |
Keybuk | Python can't parse that file | 06:40 |
Keybuk | it ENOMEM'd :p | 06:40 |
Keybuk | Perl took under a second | 06:41 |
Keybuk | and used only a few 100K | 06:41 |
AStorm | Because you used findall | 06:41 |
AStorm | and not finditer | 06:41 |
AStorm | :P | 06:41 |
Keybuk | ok | 06:41 |
Keybuk | finditer still running | 06:41 |
wasabi | Heh. And here I am, a C# user. | 06:41 |
wasabi | The bane of all of you! | 06:41 |
Keybuk | finditer still running | 06:41 |
=== Keybuk kills it | ||
Keybuk | Perl wins | 06:41 |
Keybuk | I'm not saying Python is bad, Python is very good at certain things | 06:42 |
Keybuk | it just does emphatically not beat Perl at being a parsing/extraction language | 06:42 |
AStorm | Why? My 2GB file took actually... like 10s | 06:42 |
AStorm | Probably not :P | 06:42 |
Keybuk | 10s is well over 10 times longer than Perl | 06:42 |
AStorm | It's a general purpose language, hell. | 06:42 |
Keybuk | there's no such thing | 06:42 |
Keybuk | no language is ever general purpose | 06:42 |
AStorm | Eh... | 06:43 |
Keybuk | every single one ends up specialising in being able to do one thing well | 06:43 |
Keybuk | whether deliberately or not | 06:43 |
AStorm | It's a language with no special purpose in mind | 06:43 |
AStorm | other than being easily embedded | 06:43 |
Keybuk | easily embedded => Lua | 06:43 |
Keybuk | so Python loses there | 06:43 |
AStorm | Yep. | 06:43 |
AStorm | actually, I know why it did regexp so slow | 06:44 |
Keybuk | one of my major, deep-seated, proto-religious hates is people who use one language for every single task | 06:44 |
AStorm | Object lookups :P | 06:44 |
Keybuk | especially if that language is PHP :p | 06:44 |
Keybuk | but it applies to any | 06:44 |
AStorm | PHP is evil, yep. | 06:44 |
AStorm | Especially due to unreadability :P | 06:44 |
Keybuk | you do not write applications with user interfaces in Perl | 06:44 |
Keybuk | you do not write data parsing and report generation apps in Python | 06:45 |
AStorm | Oh, right, Python isn't too good at threading too. | 06:45 |
AlexExtreme | well, PHP is kinda sucky. especially at GUIs | 06:45 |
AStorm | Well, I do. But then, anyway :P | 06:45 |
AStorm | But these need a bit of special care in tight loops. | 06:45 |
AlexExtreme | would you beleive that the package manager in KateOS (a linux distro) is written in PHP | 06:45 |
AlexExtreme | with PHP-GTK2 | 06:45 |
AStorm | Esp. putting object lookups outside of them. | 06:45 |
AStorm | OMFG! | 06:45 |
Keybuk | you don't write *anything* in Java, C++ or PHP | 06:45 |
AStorm | I'd write it in Haskell, blah :P | 06:46 |
AStorm | C++ is good if you have a requirement on it. | 06:46 |
Keybuk | AStorm: haskell is good for mathmetical or functional data sets | 06:46 |
AlexExtreme | I hate C++ :) | 06:46 |
AStorm | Or have to write low-level code. | 06:46 |
Keybuk | C++ is never good | 06:46 |
Keybuk | C++ is useless for low-level code | 06:46 |
Keybuk | and terrible for object oriented code | 06:46 |
AStorm | No, it isn't :P | 06:46 |
AlexExtreme | Java... ugh, bloat. | 06:46 |
Keybuk | low-level => C | 06:46 |
Keybuk | object-oriented => C# or Python | 06:46 |
AStorm | C++ is good enough for low-level semi-OO code. | 06:46 |
Keybuk | I bet you any low-level C++ code you find is really C mangled by a C++ compiler | 06:46 |
AStorm | Thought C can do still. | 06:47 |
AStorm | *though | 06:47 |
AStorm | Keybuk, uh... tell that to guys liking templates :P | 06:47 |
Keybuk | why the hell would you need templates for low-level code?! :p | 06:47 |
AStorm | C# requires mono runtime, which is ugh. | 06:47 |
Keybuk | one ioport looks much like another | 06:47 |
Keybuk | C++ requires C++ runtime, which is ugh ugh ugh | 06:47 |
AStorm | That's why :P | 06:47 |
AStorm | No, it doesn't. | 06:48 |
AlexExtreme | yes it does | 06:48 |
AStorm | It's statically compilable. | 06:48 |
AlexExtreme | libstdc++ | 06:48 |
AStorm | ^ | 06:48 |
AlexExtreme | well | 06:48 |
AlexExtreme | it is | 06:48 |
AlexExtreme | but | 06:48 |
Keybuk | you can build the mono runtime into the binary | 06:48 |
AlexExtreme | that makes your application unnecessarily massive | 06:48 |
AStorm | Keybuk, yep? Tell me about it. | 06:48 |
AStorm | AlexExtreme, not that much. | 06:48 |
AStorm | Linkers are quite smart nowadays. | 06:48 |
wasabi | mono is statically compilable too heh | 06:48 |
wasabi | apples to apples | 06:48 |
AStorm | wasabi, yes, it is | 06:48 |
AStorm | But it's a large runtime :P | 06:49 |
Keybuk | Linkers are dump | 06:49 |
Keybuk | uh, dumb | 06:49 |
wasabi | it's not that large... | 06:49 |
AStorm | Not GNU ld :P | 06:49 |
Keybuk | AStorm: have you *looked* at the size of libstdc++ ?! :p | 06:49 |
AStorm | Yep. 3MB | 06:49 |
Keybuk | AStorm: GNU ld is dump; it does exactly what you tell it | 06:49 |
Keybuk | AStorm: and the size of mono? :p | 06:49 |
Keybuk | (tip: it's about the same size) | 06:49 |
AStorm | 36MB runtime | 06:49 |
AStorm | (count libs in!) | 06:49 |
wasabi | It's not a 36MB runtime heh. | 06:49 |
wasabi | You have to only count USED libs heh | 06:49 |
Keybuk | AStorm: no, mono libs include a lot more than libstdc++ | 06:49 |
Keybuk | I can include glibc and gtk+, etc. into the stdc++ calculation, if you like | 06:50 |
Keybuk | it wouldn't win :p | 06:50 |
AStorm | glibc can't be | 06:50 |
AStorm | mono uses it too | 06:50 |
AStorm | :P | 06:50 |
wasabi | -rw-r--r-- 1 root root 2.4M 2007-02-07 16:57 /usr/lib/libmono.so.0.0.0 | 06:50 |
AStorm | Unless it's implemented in asm | 06:50 |
wasabi | So, basic VM is 2.4 MB. | 06:50 |
AlexExtreme | bbl | 06:50 |
AStorm | Basic VM is nothing. | 06:50 |
wasabi | So, count the classes you use. | 06:50 |
AStorm | wasabi, a lot more | 06:50 |
wasabi | Which I can't do for you since I don't have a program in bind. | 06:50 |
=== Keybuk wonders how big Python is | ||
AStorm | all system classes | 06:51 |
wasabi | Not all system classes. | 06:51 |
AStorm | Keybuk, exactly... 2.5MB dll | 06:51 |
wasabi | If you don't use System.Windows.Forms.dll, you don't need it. | 06:51 |
AStorm | wasabi, ok, most of them :P | 06:51 |
Keybuk | AStorm: compared to a 3MB so? :p | 06:51 |
wasabi | Harldy. | 06:51 |
wasabi | System.Web | 06:51 |
Keybuk | Mono is smaller then | 06:51 |
wasabi | System.Runtime.Remoting | 06:51 |
wasabi | System.Security, System.Xml | 06:51 |
wasabi | System.Data, System.Design | 06:51 |
AStorm | wasabi, ok, anyway. | 06:51 |
wasabi | Mono.HalfABillion | 06:51 |
AStorm | the problem is the mono requirement :P | 06:51 |
Keybuk | what's wrong with Mono? | 06:51 |
wasabi | Why, again? :0 | 06:51 |
AStorm | That's why Haskell wins :P | 06:52 |
=== Keybuk likes C# - it's a nice language | ||
wasabi | haha | 06:52 |
Keybuk | with a good hereditary too | 06:52 |
AStorm | Compilable to straight machine code. | 06:52 |
AStorm | Yes, C# is nice | 06:52 |
Keybuk | you can compile any language straight to machine code | 06:52 |
AStorm | though from .NET I prefer Nemerle. | 06:52 |
Keybuk | admittedly, some of the higher-level ones like Python are damned tricky to do | 06:52 |
AStorm | Keybuk, to _standalone_ code (semi-standalone) | 06:52 |
AStorm | Yep. | 06:52 |
Keybuk | but it's possible | 06:52 |
AStorm | Haskell compiles to C-- | 06:53 |
wasabi | But it's *pointless* | 06:53 |
Keybuk | simply because if you couldn't express the language as machine code, you could never run the damned thing | 06:53 |
AStorm | or optionally to C | 06:53 |
AStorm | Keybuk, JIT != full static compilation | 06:53 |
Keybuk | a runtime is just pre-packaged machine code for language constructs, after all | 06:53 |
AStorm | And a JIT :P | 06:53 |
Keybuk | AStorm: I'm not talking about JIT | 06:53 |
wasabi | Every program we write relies on other services. | 06:53 |
AStorm | Mono uses JITting a lot | 06:53 |
wasabi | Mono can pre-JIT. | 06:53 |
AStorm | wasabi, well, some do more, some less | 06:53 |
Keybuk | if a language can be interpreted, on the fly, then it can be compiled to machine code in advance | 06:53 |
wasabi | If you really give a shit. | 06:53 |
AStorm | wasabi, yep, somewhat | 06:54 |
AStorm | But not NET 2.0 | 06:54 |
wasabi | Hmm. MS 2.0 can pre-JIT. Don't know about Mono. | 06:54 |
AStorm | Keybuk, of course. | 06:54 |
Keybuk | if a language cannot be compiled, then ergo, it cannot be interpreted | 06:54 |
Keybuk | you could define a language that was literally impossible to compile | 06:54 |
AStorm | But writing such a compiler is another matter. | 06:54 |
Keybuk | but then you would also not be able to interpret it | 06:54 |
AStorm | Heck, you can even compile a subset of special Python | 06:54 |
AStorm | RPython | 06:55 |
Keybuk | simply because the only way to define an un-compilable language is to design a language that requires the machine to do things that it cannot do | 06:55 |
AStorm | with the use of PyPy toolchain | 06:55 |
Keybuk | you can compile all of Python | 06:55 |
Keybuk | Python is written in C | 06:55 |
Keybuk | C is compiled | 06:55 |
wasabi | This argument has no goal anymore. | 06:55 |
AStorm | Keybuk, gah | 06:55 |
Keybuk | ergo all Python constructs can be expressed as machine code | 06:55 |
Keybuk | so all the compiler need to is take the machine code constructs compiled from the C, and chain them together appropriately | 06:55 |
AStorm | Yeah right. | 06:55 |
AStorm | Do that and see the app fail like hell :P | 06:55 |
wasabi | C# is a valuable language. It does work so I don't have to. It makes my software easier to program. It's pretty elegant as it goes for languages. | 06:55 |
Keybuk | why would it fail? | 06:55 |
wasabi | Hence. YAY. | 06:55 |
AStorm | Notice import statement. | 06:56 |
Keybuk | notice that import frequently loads C .so files | 06:56 |
AStorm | C# is ok for me. | 06:56 |
AStorm | Keybuk, some, most not :P | 06:56 |
Keybuk | so? | 06:56 |
AStorm | Anyway, please write the compiler :D | 06:56 |
AStorm | I'd be grateful. | 06:56 |
Keybuk | I don't want to write the compiler | 06:56 |
AStorm | There's no compiler, because it's a "damn hard" problem | 06:56 |
Keybuk | if the speed that machine code provides were a requirement, I probably wouldn't write it in Python to start with | 06:56 |
Keybuk | note that hard != impossible | 06:57 |
AStorm | Yep. | 06:57 |
AStorm | It's already done for restricted python | 06:57 |
Keybuk | actually, I shouldn't imagine it's even that hard | 06:57 |
AStorm | (not too restricted) | 06:57 |
Keybuk | there are one or two python constructs that would require some exotic games in machine code | 06:57 |
Keybuk | but nothing too untoward | 06:57 |
AStorm | wasabi, still, I love some constructs of Nemerle more than C# | 06:57 |
Keybuk | you'd end up with more than a few jumping-point routines | 06:58 |
wasabi | Yeah. I like that you can use them side by side. ;) | 06:58 |
AStorm | Well. RPython compiles to straight nice C :P | 06:58 |
wasabi | I'm really excited by a lot of C# features. | 06:58 |
wasabi | I think LINQ just totally rocks. | 06:59 |
AStorm | wasabi, examples, because I'm not completely sold on it | 06:59 |
wasabi | LINQ: language integrated queries. | 06:59 |
wasabi | For instance: | 06:59 |
wasabi | ISet<string> strings = new ISet<string>(); /* add a bunch of strings to strings */ | 06:59 |
Keybuk | Python is just a wannabe-Lisp anyway :p | 06:59 |
AStorm | wasabi, ahha, nice :P | 06:59 |
AStorm | Keybuk, indeed, OO Lisp | 06:59 |
Keybuk | eh? | 07:00 |
wasabi | foreach (string s in (from strings as string where string.StartsWith("f")) { do stuff with s; } | 07:00 |
Keybuk | there's no such thing as OO Lisp or non-OO Lisp | 07:00 |
AStorm | Object-oriented Lisp | 07:00 |
Keybuk | Lisp is Lisp | 07:00 |
wasabi | You can use the syntax "from" to apply constraints to enumerations in code. | 07:00 |
AStorm | I was talking about Python :P | 07:00 |
AStorm | I still prefer Haskell syntax to Scheme one :P | 07:00 |
AStorm | Only thing missing is . for accessing "members" of a class | 07:00 |
AStorm | It's currently used for function composition. | 07:01 |
Keybuk | err? Lisp is even more insanely "everything is a first class object" than Python is | 07:01 |
AStorm | Haskell' (Prime) will resolve this problem. | 07:01 |
AStorm | Yep, most of the time. | 07:01 |
AStorm | Except (define ...) | 07:01 |
Keybuk | to the degree that any lisp expression can either be lisp code to evalulate that expression, or a value | 07:01 |
AStorm | I know. Been there, done Lisp :P | 07:02 |
Keybuk | (define ...) is just def in Python | 07:02 |
AStorm | Nope. | 07:02 |
AStorm | def is defun | 07:03 |
AStorm | define is more powerful | 07:03 |
AStorm | No equivalent Python construct. | 07:03 |
Keybuk | maybe I'm confused there, it's been a while since I did any serious lisp | 07:03 |
wasabi | Okay, lets say you have a collection of Person objects... and you wanted to find Person objects with a given age and first name: | 07:03 |
wasabi | var q = from persons as p where p.Name.FirstName == "Bob" and p.Age = 123; | 07:03 |
wasabi | foreach (Person p in q) { do stuff with them } | 07:03 |
AStorm | wasabi, nice sugar :P | 07:04 |
wasabi | Yup. It turns into a AST, which a ORM tool can implement. | 07:04 |
AStorm | Not entirely necessary anyway. | 07:04 |
wasabi | Or it becomes a simple loop. | 07:04 |
wasabi | Either way, your code looks clear and concise. | 07:04 |
wasabi | Instead of programatic. | 07:05 |
AStorm | I don't know if it's entirely clear :P | 07:05 |
AStorm | Looks like a SQL query. | 07:05 |
wasabi | Yeah, it is the same idea. YOu are filtering a batch of data. | 07:06 |
wasabi | But it's completely type safe. | 07:06 |
AStorm | Well, I actually prefer Haskell :P | 07:06 |
wasabi | And IDEs can do pop up completion and fun stuff on it. ;) | 07:06 |
AStorm | filter (\x -> x.Name.FirstName == "Bob" and p.Age == 123) thedb | 07:06 |
AStorm | That's assuming H' | 07:07 |
AStorm | not H98 | 07:07 |
=== j_ack [n=rudi@p508DBB02.dip0.t-ipconnect.de] has joined #upstart | ||
wasabi | How is that implemented? | 07:08 |
wasabi | Can that be translated at runtime to a SQL statement? | 07:08 |
AStorm | Probably :P | 07:08 |
AStorm | Depends on what x is | 07:09 |
AStorm | if x is an SQL-alike object | 07:09 |
AStorm | Of course, it's no syntactic sugar :P | 07:09 |
AStorm | it depends on the qualities of the p element | 07:10 |
AStorm | Esp. on its class and implementation of == and . operator | 07:10 |
wasabi | Ahh. | 07:11 |
wasabi | So the p class could be a class which completely changes the dynamics of the == and . | 07:11 |
AStorm | Yes. | 07:11 |
wasabi | Inorder to formulate one query that can be turned into one SQL statement. | 07:11 |
AStorm | Another boon is it can be used everywhere :P | 07:11 |
AStorm | You get an OODB gratis. | 07:12 |
wasabi | Yeah. | 07:12 |
AStorm | Ah, wrong | 07:12 |
wasabi | Python has a 'yield' statement, right? | 07:12 |
AStorm | this can't be done in this way | 07:12 |
wasabi | ? | 07:12 |
AStorm | p would have to be a Monad :P | 07:12 |
AStorm | wasabi, yes, it does | 07:12 |
wasabi | Monad? | 07:12 |
wasabi | I like yield. ;) | 07:13 |
wasabi | One of my favorite new C# features. | 07:13 |
AStorm | wasabi, yes, a wrapper around interactions with outside world | 07:13 |
AStorm | Signifying mostly "this is not a function" | 07:13 |
wasabi | hmm | 07:13 |
AStorm | Because it's not :P | 07:13 |
AStorm | So, it'd have to be written more like x <- (p->Something->SomethingElse); x==blah | 07:15 |
AStorm | but that can be also "undone" | 07:15 |
AStorm | Because it's actually a syntactic sugar for some >>= operators | 07:15 |
AStorm | Which work like a pipe in Linux. | 07:15 |
AStorm | Etc. etc. | 07:16 |
wasabi | Yeah. All of the stuff in C# is delayed evaluation too. | 07:16 |
wasabi | It never actually runs until it's used. | 07:16 |
wasabi | var q = from whatever; just returns an instance of some class that could potentially do the filter. | 07:16 |
AStorm | Unfortunately not lazy, just delayed :P | 07:17 |
wasabi | Could be lazy. If it's not SQL. | 07:17 |
AStorm | Nemerle does have some lazy eval constructs. | 07:17 |
wasabi | Default implementation is lazy... it finds the NEXT element, and stops. | 07:17 |
wasabi | SQL implementation could implement that by streaming results. | 07:17 |
AStorm | Aha. Ok. | 07:17 |
AStorm | But generally, C# is strict, right? Is there a method to disable that strictness locally easily? | 07:18 |
wasabi | No. It is always strict. | 07:18 |
AStorm | Generators? | 07:18 |
wasabi | Don't understand the reference. | 07:19 |
wasabi | Explain. | 07:19 |
AStorm | I think it supports them. | 07:20 |
AStorm | You can iterate using .next and .previous, but the objects get accessed only then | 07:20 |
AStorm | not earlier | 07:20 |
wasabi | Oh. Yeah. IEnumerable contains .MoveNext() | 07:20 |
wasabi | yield returns implementations of IEnumerable which access a method statemachine | 07:21 |
wasabi | And the query stuff does too | 07:21 |
AStorm | Aha, just what I though. Like Python iterator. | 07:21 |
wasabi | Yeah. | 07:21 |
AStorm | A bit of laziness in a strict language. | 07:21 |
wasabi | Hmm. By strict you mean? It's still completely typesafe. | 07:21 |
wasabi | What it generates must still be of the declared type. | 07:21 |
wasabi | IEnumerable<T> | 07:22 |
wasabi | Basically, using yield looks like. | 07:22 |
wasabi | public IEnumerable<string> GetString() { yield return "string1"; yield return "string2"; } | 07:22 |
wasabi | foreach (string s in GetString()) { operate on s; } | 07:23 |
AStorm | wasabi, strict == not lazy | 07:23 |
wasabi | The foreach construct basically uses MoveNext() and Current() on the IEnumerable instance. | 07:23 |
AStorm | Not dynamic. | 07:23 |
AStorm | lazy != dynamic | 07:23 |
AStorm | Are there any nice operators/functions to access an Nth object of an IEnumerable? | 07:23 |
wasabi | No. It's not an IEnumerable then. | 07:24 |
wasabi | IList<T> contains an indexor. | 07:24 |
wasabi | IList<T> : IEnumerable<T> | 07:24 |
wasabi | You could certainly implement an IList<T> which worked on a backing IEnumerable by advancing. | 07:25 |
AStorm | Aha, correct :P | 07:25 |
wasabi | But you would prefer not to i'd imagine. | 07:25 |
AStorm | :> | 07:25 |
wasabi | As you'd lose the benefits of the delayed evaluation. | 07:26 |
AStorm | Depends for what. E.g. memoisation | 07:26 |
wasabi | Simply calling List.Count would force teh entire thing to be evaluated. | 07:26 |
wasabi | public IEnumerable<Foo> GetFoos() { for (int i = 0; i < 5; i++) return Foo(); } <--- generator? | 07:28 |
wasabi | public IEnumerable<Foo> GetFoos() { for (int i = 0; i < 5; i++) yield return Foo(); } <--- generator? | 07:28 |
wasabi | bah. I meant "new Foo()" | 07:29 |
AStorm | wasabi, sure | 07:35 |
AStorm | Because counting is non-lazy always | 07:36 |
AStorm | You could have CountAlreadyDone | 07:36 |
wasabi | Sure. | 08:23 |
=== Md [i=md@freenode/staff/md] has joined #upstart | ||
=== j_ack [n=rudi@p508DBB02.dip0.t-ipconnect.de] has joined #upstart |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!