| --- Log opened Fri Nov 06 00:00:12 2009 |
| --- Day changed Fri Nov 06 2009 |
| 00:00 | < McMartin> | I would like to see Seb go Guano-a-Guano with Vlad. |
| 00:00 | < Derakon[work]> | Which Vlad? |
| 00:00 | < McMartin> | The 18/0 guy mentioned in here previously. |
| 00:01 | < Derakon[work]> | Ahh. |
| 00:13 | | Derakon[work] [Derakon@Nightstar-d44d635e.ucsf.edu] has quit [[NS] Quit: Leaving] |
| 00:36 | < simon`> | hm |
| 00:37 | < simon`> | there's a guest lecture monday about writing server processes in erlang using anonymous functions and self-reference as recursion instead of using named processes. I have no idea what the benefit of that is. |
| 00:39 | < simon`> | I'm thinking it's either smarty-pantsy or it provides some kind of security in an erlang context because server environments might be susceptible to more manipulation if one can actually refer to a server by function/process name. |
| 00:52 | | Attilla [The.Attilla@FBC920.0A905B.8E5905.BA3BAF] has quit [Connection reset by peer] |
| 01:04 | < McMartin> | It's nice to see developers respecting the community they work with. http://www.slproweb.com/products/Win32OpenSSL.html |
| 01:07 | < Vornicus> | uh-huh |
| 01:07 | < simon`> | no way to respect utter idiots than by addressing them explicitly! :-) |
| 01:08 | < McMartin> | "I want access to archival versions" is not utter idiocy no matter how many <font color="red"> tags you use. |
| 01:09 | < Namegduf> | What's the use case? |
| 01:09 | < McMartin> | Developers doing Win32 development involving OpenSSL. |
| 01:10 | | AbuDhabi [farkoff@Nightstar-0bac1eaf.adsl.tpnet.pl] has quit [[NS] Quit: Also, Power Dome A is now the roost of a truly ancient Deep Crow.] |
| 01:10 | < Namegduf> | Why do they need to develop against old versions? |
| 01:10 | < McMartin> | If I had to guess, incompatible API changes. |
| 01:10 | < Namegduf> | I mean, if the old versions are legitimately insecure, that seems like grounds to update, regardless of any cost to development efforts. |
| 01:11 | < Namegduf> | If security wasn't an issue... you shouldn't be using SSL in the first place. |
| 01:11 | < McMartin> | Astonishingly, there are a lot of people who would prefer to have a program actually continue to run, while using other mechanisms as a broader defense. |
| 01:12 | < McMartin> | Tell that to autoconf |
| 01:12 | < Namegduf> | I have numerous bigger issues with autoconf |
| 01:12 | < Namegduf> | Like the whole piece of crap thing |
| 01:12 | < McMartin> | So, say you need to compile some third-party tool that uses autoconf. |
| 01:12 | < Namegduf> | Autotools in general is a horrible mess that was developed because whoever was working on adding the newest piece apparantly: |
| 01:12 | < McMartin> | Like, you know, 95% of them. |
| 01:12 | < Namegduf> | A) Couldn't write in anything but shellscript |
| 01:13 | < Namegduf> | B) Had a severe phobia of refactoring |
| 01:13 | < Namegduf> | But, okay, let's look at the end user scenario. |
| 01:13 | < Namegduf> | I'm using Autoconf. |
| 01:13 | < Namegduf> | Therefore, I'm not on Windows, therefore, whatever the guy does is irrelevant to me |
| 01:14 | < Namegduf> | If I could see your end point, I could maybe try to understand if it ported even though the reasoning doesn't. |
| 01:14 | < McMartin> | My end point is that is it is bad form to suggest to other developers that they punch themselves in the face when one is the top-listed platform port for a major piece of software, mainly. |
| 01:16 | < McMartin> | As in, you go to openssl.org, click through to the "precompiled downloads" page, and that's the only link. |
| 01:16 | < McMartin> | So yeah, there's a certain degree of professionalism I expect from software that core, and he's not even close to meeting it. |
| 01:16 | < Namegduf> | To be fair, the greater criticism is the OpenSSL guys not making their own compile. |
| 01:16 | < Vornicus> | Among other things: regression testing, revival of systems from backup... |
| 01:17 | < McMartin> | I will grant that one. |
| 01:17 | < Namegduf> | And instead referring to some random unprofessional unassociated guy who's just doing them at whim, apparantly. |
| 01:17 | < McMartin> | In fact, sufficiently unimpressed that I think I'll be doing a MinGW compile from source, myself. |
| 01:17 | < Namegduf> | Have fun |
| 01:18 | < McMartin> | No doubt. |
| 01:18 | < McMartin> | Actually, no, that's plan B |
| 01:18 | < McMartin> | plan A is to ensure that the thing I'm *trying* to compile actually needs it in the first place. |
| 01:18 | < McMartin> | Since the part I suspect needs it is going to be a part I don't have to actually use, and I may be able to config-flag it out. |
| 01:20 | < Pinkhair> | McMartin- the tone of the message suggests that he has a massive amount of people (possibly)requesting and (probably)rudely demanding older versions |
| 01:21 | < Namegduf> | It's best to assume that if Windows users are requesting something, they're doing it rudely. |
| 01:22 | < Namegduf> | Which reminds me of the hilarious time a guy turned up in a crossplatform support channel I helped with, proclaimed himself a representative of all Windows users, and insisted that if software was offered on Windows, it work "out of the box". How cruel to force people to "setup a properly working configuration for their system/naming" before it'll run. |
| 01:22 | < Namegduf> | They later made a forum post. |
| 01:23 | < Namegduf> | But, yeah, that kind of tone is bleh, but if people are being terribly rude... |
| 01:23 | < McMartin> | Yeah, see, this developer appears to actually be that guy. |
| 01:23 | < Namegduf> | Haha, fair point. |
| 01:52 | | Derakon[AFK] is now known as Derakon |
| 02:06 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has quit [Killed (Vornicus (Kitty on the keyboard!))] |
| 02:14 | | Attilla [The.Attilla@FBC920.480E8C.4A3EE6.AB1516] has joined #code |
| 02:14 | | mode/#code [+o Attilla] by ChanServ |
| 02:21 | | Reivles [reaverta@ServerAdministrator.Nightstar.Net] has joined #code |
| 02:29 | < Vornicus> | THe worst bit about being a programmer with ADD is that the ocmputer is the single most effective tool for magnifying ADD, ever. |
| 02:37 | <@Derakon> | Speaking of distractions, did you see my query earlier? |
| 02:37 | < Vornicus> | Yes I did. |
| 02:38 | < Vornicus> | I determined it to be a little bit harder than I could pull off in a few minutes. |
| 02:38 | | * Derakon nods. |
| 02:48 | < Vornicus> | obviously on a 1 we're looking at 3.5; on a 2 it's... 3.5 + 7 + 10.5 + 14 + 17.5 + 21 = 12.75 |
| 03:04 | < Pinkhair> | vorn |
| 03:04 | < Pinkhair> | your tile list is a bit unhelpful |
| 03:05 | < Pinkhair> | needs some sort of either tile file organization or(if using tilesheets) a temlte would work |
| 03:05 | < Pinkhair> | *template |
| 03:09 | < Vornicus> | Yeah, it doesn't describe very well. I have a folder full of shapes, I can probably shove it all together into an image... |
| 03:10 | <@Derakon> | convert's append option is your friend. |
| 03:10 | <@Derakon> | If all the images are of the same size, you can use "convert -append 1.png 2.png 3.png out.png" to jam them together into rows, and "convert +append 4.png 5.png 6.png out2.png" to jam them together into columns. |
| 03:10 | <@Derakon> | Or maybe it's the other way around, I forget. |
| 03:28 | | Attilla [The.Attilla@FBC920.480E8C.4A3EE6.AB1516] has quit [Connection reset by peer] |
| 04:27 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving] |
| 04:29 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 04:38 | < Rhamphoryncus> | nothing says fun like semirandomly frobbing an algorithm and hoping to get better results >.< |
| 04:56 | | * Vornicus patpats Rham |
| 04:58 | | * McMartin hacks an Ultima IV savegame. |
| 05:02 | | * ToxicFrog ponders X-COM: TFTD |
| 05:03 | < SmithKurosaki> | o.0 |
| 05:03 | <@Derakon> | Incidentally, Vorn, I wrote a quick Monte Carlo simulator for the dice problem. Came out with an answer of 464 quadrillion over 1 million samples. |
| 05:03 | < Rhamphoryncus> | I think I need something more precise than a floating average |
| 05:05 | | Syloqs-AFH [Syloq@NetworkAdministrator.Nightstar.Net] has quit [Connection reset by peer] |
| 05:06 | < Rhamphoryncus> | Or maybe my expectations are wrong. A few delays will increase the average interval, and on clean runs that means waiting at the ends |
| 05:10 | < Rhamphoryncus> | Not the result I want, but it is the result I asked for |
| 07:02 | | Derakon is now known as Derakon[AFK] |
| 08:51 | | AnnoDomini [farkoff@Nightstar-0bac1eaf.adsl.tpnet.pl] has joined #code |
| 08:59 | | Rhamphoryncus [rhamph@Nightstar-a62bd960.abhsia.telus.net] has quit [Client exited] |
| 09:36 | | You're now known as TheWatcher |
| 10:24 | < MyCatVerbs> | Reivles: If semirandomly frobbing it is a reasonable approach then it's more likely a heuristic, not an algorithm. ;P |
| 10:25 | < MyCatVerbs> | Er, Rhamphoryncus, except that I didn't notice that they'd dropped. |
| 11:11 | | AnnoDomini [farkoff@Nightstar-0bac1eaf.adsl.tpnet.pl] has quit [Ping timeout: 121 seconds] |
| 11:15 | | AnnoDomini [farkoff@Nightstar-ba7f0025.adsl.tpnet.pl] has joined #code |
| 11:25 | | Attilla [The.Attilla@FBC920.480E8C.4A3EE6.AB1516] has joined #code |
| 11:25 | | mode/#code [+o Attilla] by ChanServ |
| 14:37 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has joined #code |
| 16:07 | | Syloqs_AFH [Syloq@NetworkAdministrator.Nightstar.Net] has joined #code |
| 16:08 | | Syloqs_AFH is now known as Syloqs-AFH |
| 16:40 | | Tarinaky [Tarinaky@Nightstar-aa7b13ae.adsl.virginmedia.net] has quit [Ping timeout: 121 seconds] |
| 16:54 | | Tarinaky [Tarinaky@Nightstar-b4b74c4b.adsl.virginmedia.net] has joined #code |
| 17:01 | | Rhamphoryncus [rhamph@Nightstar-a62bd960.abhsia.telus.net] has joined #code |
| 18:29 | | You're now known as TheWatcher[afk] |
| 18:35 | | Derakon [Derakon@Nightstar-d44d635e.ucsf.edu] has joined #code |
| 18:35 | | Derakon is now known as Derakon[work] |
| 18:36 | | * Derakon[work] mutters at Visual Studio and wxPython. |
| 18:36 | < Derakon[work]> | I just need to get wxPython.h so I can build the damned application! |
| 18:36 | < Derakon[work]> | But this file seemingly does not exist! |
| 18:52 | | * Derakon[work] mutters, heads back in. |
| 18:52 | | Derakon[work] [Derakon@Nightstar-d44d635e.ucsf.edu] has quit [[NS] Quit: Leaving] |
| 19:30 | < McMartin> | wx D: |
| 20:32 | | You're now known as TheWatcher |
| 20:34 | < ToxicFrog> | Visual Studio :/ |
| 21:07 | | Netsplit *.net <-> *.split quits: @Attilla, dmlandrum, @Derakon[AFK], AnnoDomini, Vornicus, Orthia, simon`, crem, KazWork, Kazriko, (+7 more, use /NETSPLIT to show all of them) |
| 21:08 | | Netsplit over, joins: jerith, MyCatVerbs, Rhamphoryncus, Pinkhair, AnnoDomini, gnolam, Reivles, Orthia |
| 21:08 | | Orthianz [Orthianz@Nightstar-364aee13.xnet.co.nz] has joined #code |
| 21:08 | | Netsplit over, joins: Kazriko |
| 21:08 | | Orthia [Orthianz@Nightstar-364aee13.xnet.co.nz] has quit [Client closed the connection] |
| 21:09 | | 459AAADR2 [rhamph@Nightstar-a62bd960.abhsia.telus.net] has joined #code |
| 21:09 | | KazWork [kazrikna@Nightstar-55f6a2b4.xen.prgmr.com] has joined #code |
| 21:09 | | crem [moo@Nightstar-8ca3eea7.adsl.mgts.by] has joined #code |
| 21:09 | | Alek [omegaboot@Nightstar-02457fcc.emhril.sbcglobal.net] has joined #code |
| 21:09 | | Derakon[AFK] [Derakon@Nightstar-5abd3ac9.ca.comcast.net] has joined #code |
| 21:09 | | Attilla [The.Attilla@FBC920.480E8C.4A3EE6.AB1516] has joined #code |
| 21:09 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 21:09 | | dmlandrum [dmlandrum__@8E7DA3.838E9A.6CA65A.A8EF5A] has joined #code |
| 21:09 | | simon` [simon@Nightstar-a12ff716.gjk.dk] has joined #code |
| 21:09 | | ServerMode/#code [+oo Derakon[AFK] Attilla] by *.Nightstar.Net |
| 21:09 | | Pinkhair [none@Nightstar-a7d2ccfd.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
| 21:11 | | Rhamphoryncus [rhamph@Nightstar-a62bd960.abhsia.telus.net] has quit [Ping timeout: 121 seconds] |
| 21:13 | | Rhamphoryncus_ [rhamph@Nightstar-a62bd960.abhsia.telus.net] has joined #code |
| 21:16 | | 459AAADR2 [rhamph@Nightstar-a62bd960.abhsia.telus.net] has quit [Ping timeout: 121 seconds] |
| 21:19 | | Netsplit *.net <-> *.split quits: gnolam, Kazriko, Rhamphoryncus_, MyCatVerbs, Orthianz, Reivles, AnnoDomini, jerith |
| 21:19 | | Netsplit over, joins: jerith, MyCatVerbs, AnnoDomini, Orthianz, gnolam, Reivles, Kazriko, Rhamphoryncus_ |
| 21:19 | | Rhamphoryncus__ [rhamph@Nightstar-a62bd960.abhsia.telus.net] has joined #code |
| 21:22 | | Rhamphoryncus_ [rhamph@Nightstar-a62bd960.abhsia.telus.net] has quit [Ping timeout: 121 seconds] |
| 21:22 | | MyCatVerbs [mycatverbs@Nightstar-492e7e67.co.uk] has quit [Ping timeout: 121 seconds] |
| 21:24 | | MyCatVerbs [mycatverbs@Nightstar-492e7e67.co.uk] has joined #code |
| 21:24 | | Derakon[work] [Derakon@Nightstar-d44d635e.ucsf.edu] has joined #code |
| 21:25 | < Derakon[work]> | Y'know, I think the part I hate most about software development is dependency resolution. |
| 21:25 | < Derakon[work]> | I don't think I've ever encountered a language/IDE that didn't have some massive failing in that area. |
| 21:32 | < Rhamphoryncus__> | yeah |
| 21:34 | < Derakon[work]> | I think ideally I'd download a program (and/or write some source), and when I tried to run it, I'd get a message saying "Oh, you're depending on X. Let me go look up what you need for that...ah, here's the link to the package repository, now download that and put it in this directory and we're good to go." |
| 21:34 | < Derakon[work]> | (Of course, without a Net connection you couldn't do the lookup, but the rest would be the same) |
| 21:44 | < Rhamphoryncus__> | I mostly agree, but I want something more complicated ;) |
| 21:44 | < Derakon[work]> | Heh. |
| 21:44 | < Derakon[work]> | Complicated is baaaaaad. |
| 21:45 | < Rhamphoryncus__> | My concern is based on multiple sources for software. It invalidates the idea that there is canonical naming and versioning |
| 21:46 | < Derakon[work]> | As a matter of practicality, the vast majority of the time you're resolving dependencies you'll want the same version everyone else is using. |
| 21:46 | < Derakon[work]> | If you want a different version, you can always just ignore what the auto-recommender says. |
| 21:47 | < Derakon[work]> | But mostly what I'm after is not having to muck about with include paths, header files, dll files, and all that shit. |
| 21:47 | < Rhamphoryncus__> | So I'm leaning towards having distinct naming/versioning authorities, with explicit mixing between them, and then redesign the packaging architecture to keep things as isolated as possible. Allow multiple parallel installs |
| 21:49 | < Rhamphoryncus__> | There's redundancy between the system installer and the language installer. Two different goals of course. Need something that handles both goals just fine |
| 21:49 | < Derakon[work]> | I don't care how it works. More importantly, I don't want to have to care how it works. |
| 21:49 | < Rhamphoryncus__> | aye, that too |
| 21:50 | < Derakon[work]> | As it stands, every language/IDE I've worked with has assumed that, if you're a programmer, you're willing to get your hands dirty with compilers and paths and crap. |
| 21:50 | < Rhamphoryncus__> | All the serious projects I've seen have their own bodged-together build systems.. completely ignoring the tools in the IDE (which don't work anyway) |
| 21:51 | <@TheWatcher> | Indeed. |
| 21:51 | < Rhamphoryncus__> | openttd's is almost good. Much less verbose, only printing out each file it's compiling, rather than the full line every time |
| 21:52 | < Rhamphoryncus__> | However, it's slow, taking several seconds (5-10? feels like) for a no-op, and doesn't have proper diagnostics when it has missing dependencies |
| 21:53 | < Rhamphoryncus__> | hmm. 4 seconds for a no-op, 11.8 to recompile one file and relink |
| 21:54 | <@TheWatcher> | Ouch |
| 21:57 | < Vornicus> | Der: I think Java solves that problem forever. |
| 21:59 | < Derakon[work]> | Oh? |
| 22:01 | < Vornicus> | Yeah - there is a standard naming system. |
| 22:01 | < Vornicus> | If you're Amazon and you've released the foo library: com.amazon.foo |
| 22:01 | < Derakon[work]> | Oh, you're talking about the naming conflicts Rhamph was discussing. |
| 22:01 | < Rhamphoryncus__> | so, my patched version of amazon's foo library is named...? |
| 22:02 | < Vornicus> | I don't know, but I'm sure they've covered that ground in the docs somewhere |
| 22:02 | < Rhamphoryncus__> | doubt it :) |
| 22:03 | < Derakon[work]> | com.rhamphoryncus.patchedfoo |
| 22:03 | < Rhamphoryncus__> | So, in ubuntu every library would become com.ubuntu.patchedfoo? |
| 22:03 | < Derakon[work]> | Depends on if they're patching the libs or using the canonical versions. |
| 22:04 | <@TheWatcher> | It's still A Fucking Mess |
| 22:04 | < Derakon[work]> | Does every lib have to be modified before being included in the Ubuntu repo? |
| 22:04 | < Rhamphoryncus__> | Enough things have patches that you might as well make it policy to assume they're patched in the naming scheme |
| 22:06 | < Rhamphoryncus__> | Now for an app to use those it'd have to have something like trylibrary('com.ubuntu.patchedfoo', 'com.debian.patchedfoo', 'com.redhat.patchedfoo', 'com.amazon.foo'), which is really no better than just import("foo") and letting it grab one for you |
| 22:08 | < Rhamphoryncus__> | Not to mention that my patch is really just a one-line bug fix I'm going to send upstream. I should have to modify the application (which then require more renaming!) just to try it out |
| 22:10 | < Rhamphoryncus__> | What I want for a packaging system is basically like a per-app fakeroot. You run Bar and it loads the foo library. It doesn't ask for a specific version, that's the packaging system's job to provide in advance |
| 22:11 | < Rhamphoryncus__> | The packaging system decides who sees what, of what versions. The naming is just one of many attributes it can use, limited only in that a single app's fakeroot cannot have conflicted names |
| 22:12 | < Rhamphoryncus__> | You could (hypothetically) setup ubuntu and redhat along side, in the same system |
| 22:13 | <@TheWatcher> | Which requires some way of specifying a library signature so it gives you version X which has the features you require as opposed to version Y... |
| 22:13 | < Derakon[work]> | You could easily examine the signatures of functions exported by a library and turn that into an overall library signature, then match what you need against the available signatures. |
| 22:14 | < Derakon[work]> | (But doing that transparently might be a bad idea) |
| 22:15 | < Rhamphoryncus__> | I'd prefer to avoid heuristics. Better to have "namespace: redhat\npackage: foo" and let it only use redhat with redhat unless told otherwise |
| 22:19 | < Derakon[work]> | Of course, your actual source code shouldn't have to care what namespace it's in unless it's code for that namespace. |
| 22:20 | < Derakon[work]> | I.e. I should be able to write Python code that works on all systems without my users having to go "Dammit, he's using the RedHat version and I only have the OSX Leopard version" |
| 22:29 | < Derakon[work]> | In other news, I estimate I've eliminated about 3500 lines of dead code and useless comments from the codebase since I started working on it two months ago. |
| 22:36 | < Rhamphoryncus__> | Right. Ideally there'd be no significant differences and it would happily default to whatever's available |
| 22:36 | | Thant [Thant@Nightstar-63cb80a6.cable.ntl.com] has joined #code |
| 22:37 | < Rhamphoryncus__> | In fact your app wouldn't be distributed under the redhat namespace anyway, unless they provide it. You'd be the upstream under its own namespace |
| 22:37 | < Thant> | evenin all |
| 22:37 | < Thant> | quick question for anyone who knows much about C++, in a cout statement, you put like cout " bla bla bla" << variabletobereadoutlol << " bla bla bla" |
| 22:37 | < Thant> | right? |
| 22:37 | < Thant> | but why do you need the << bit? |
| 22:38 | < Rhamphoryncus__> | Thant: because C++ is on crack |
| 22:38 | < McMartin> | Because << is the operator for "and then output" |
| 22:38 | < Rhamphoryncus__> | Well, more of a failed experiment in language design |
| 22:38 | < McMartin> | What were you expecting to see there? |
| 22:38 | < McMartin> | I mean, that's like asking "why do I need the = in x = 2 + 3" |
| 22:39 | < Derakon[work]> | The plus, more likely. |
| 22:39 | < Rhamphoryncus__> | I can't recall, is there any practical difference between that and (if it were provided) cout.print("blah").print("blah")? Just returning self each time? |
| 22:39 | < Thant> | well i'm not really that fluent in C++, in fact im learning it and i spotted it alot in the book im using, and in the openGL work i've been doing, and it was never really explain |
| 22:39 | <@TheWatcher> | Thant: http://www.cplusplus.com/reference/iostream/ostream/operator%3C%3C/ |
| 22:39 | < Rhamphoryncus__> | Maybe it's easier to do multiple dispatch this way |
| 22:39 | < Derakon[work]> | It's basically just C++'s print paradigm. |
| 22:39 | < McMartin> | If you're asking "why is the bit shift operator being repurposed for this", because they wanted to allow chained expressions and they don't allow the creation of arbitrary infix operators. |
| 22:39 | < Thant> | thanks Watcher |
| 22:40 | < Derakon[work]> | Just like in Python it's 'print "bla bla bla", variabletobeprinted, "bla bla bla"' (unless you're using Python 3) |
| 22:40 | < McMartin> | (And because it kind of looks like an arrow pointing at the output) |
| 22:40 | < Thant> | ah, that explains it well Derakon, thanks |
| 22:40 | < Thant> | in other news, how are you all today |
| 22:41 | < Vornicus> | Py3k you use a, uh. How do you call it. "varargs" thing. |
| 22:41 | < Vornicus> | print("bla bla bla", variabletobeprinted, "bla bla bla") |
| 22:41 | < Derakon[work]> | Vorn: ahh, yes, arbitrary-length argument listst. <3 |
| 22:41 | < Vornicus> | WHich I wish they would have done for C++, but. |
| 22:41 | < Rhamphoryncus__> | python 3 does it as print("blah", someothervariable, "blah"). Would C++ even allow that sort of upcasting with a variable-argument function? |
| 22:41 | < Vornicus> | also I <3 string.format |
| 22:41 | < Derakon[work]> | Vorn: well, printf supports it. |
| 22:42 | < McMartin> | That would involve using C's version, given its design space, and C's varargs mechanism is the worst possible thing ever invented. |
| 22:42 | < McMartin> | because it has no terminator. |
| 22:42 | < Rhamphoryncus__> | bah not reading further comments once I started typing |
| 22:42 | < Derakon[work]> | McM: ...so how does it recognize the last argument? |
| 22:42 | < Derakon[work]> | Check if the next arg is null? |
| 22:42 | < McMartin> | Derakon[work]: it doesn't. Provide too few arguments to printf and it will cheerfully pop your autos or your return address. |
| 22:43 | <@TheWatcher> | You either need to include an explicit end, or some kind of count (printf's format string is an implicit arg count, for example) |
| 22:43 | < Derakon[work]> | Oh, by examining the format string. Gotcha. |
| 22:43 | < Derakon[work]> | Wonderbar. |
| 22:43 | < McMartin> | If it's %n, which takes a pointer that's written to, it will cheerfully stomp your return address. |
| 22:43 | < McMartin> | This is the "format string attack" that was owning the shit out of programs everywhere a few years back. |
| 22:43 | < Derakon[work]> | Why would you even have a print argument that writes to memory? |
| 22:44 | < McMartin> | IIRC, %n is "number of characters printed so far" |
| 22:44 | < Rhamphoryncus__> | weee recompile/test/debug cycle. Leaves so much time for kibitzing on IRC! |
| 22:45 | <@TheWatcher> | yep, "n The number of characters written so far is stored into the integer indicated by the int * (or variant) pointer argument. No argument is converted." |
| 22:45 | < McMartin> | And because if you couldn't use every single statement to produce a privilege escalation attack, it just wouldn't be C. |
| 22:45 | < Derakon[work]> | Har. |
| 22:46 | < Rhamphoryncus__> | in C, you can use signed integer overflow as part of an attack |
| 22:46 | < McMartin> | I mean, the standard library has functions clearly documented as "NEVER USE THIS FUNCTION" that are supported anyway. |
| 22:46 | < McMartin> | gets() exists for the sole and express purpose of smashing the stack. |
| 22:47 | <@TheWatcher> | (scanf likewise) |
| 22:47 | < McMartin> | (scanf can theoretically be used in ways that won't.) |
| 22:47 | < Rhamphoryncus__> | ... gets() is included for pedantic reasons, but I seriously think they should delete it, claim standard complain anyway, and say "fuck you" to anybody that argues |
| 22:47 | < McMartin> | (Like, only scanning %d) |
| 22:47 | <@TheWatcher> | ('theoretically' yes ¬¬) |
| 22:48 | < McMartin> | (gets() can't in any conceivable universe) |
| 22:48 | < McMartin> | (a fine but nevertheless real distinction) |
| 22:49 | < Rhamphoryncus__> | I thought scanf had lots of valid uses |
| 22:49 | < McMartin> | I think the one you want is, um... snscanf or something like that? |
| 22:50 | < McMartin> | ISTR there being one where %s isn't "now do gets() in all its comploetely helpless glory" |
| 22:51 | < McMartin> | But yes, C's string library is such that it constitutes a valid reason to suggest Visual Leeging Basic over C for some problem domains. |
| 22:51 | < Rhamphoryncus__> | that's %s. There's around a dozen different options |
| 22:51 | < Rhamphoryncus__> | C could use an array type |
| 22:51 | < Rhamphoryncus__> | But I suppose I shouldn't start that conversation |
| 22:52 | < McMartin> | std::vector<>, awaaaaaaay |
| 22:52 | < McMartin> | Conversation ended~ |
| 22:52 | | * TheWatcher chuckles |
| 22:53 | < McMartin> | You need a few wacky idioms, like &x[0] instead of just 'x', but if you do that, then code written to use C arrays functions identically when you secretly replace x with a std::vector. |
| 22:53 | < Namegduf> | Is it guaranteed that's safe? |
| 22:53 | < Namegduf> | To assume vectors are contiguous. |
| 22:53 | < McMartin> | Yes |
| 22:53 | < Rhamphoryncus__> | heh. C++ is like the star wars prequels. I'm so used to ignoring it that I sometimes forget it when I consider how to improve the original |
| 22:53 | < McMartin> | STL absolutely guarantees vector contiguity. |
| 22:54 | < McMartin> | (This is one reason why push_front is O(n); it can't just make a new prequel block like std::deque can) |
| 22:54 | < McMartin> | STL is full of horrors but the container types largely aren't them. |
| 22:55 | < McMartin> | STL + boost turns C++ into an actually usable language. |
| 22:55 | < Namegduf> | C++ is perfectly usable |
| 22:55 | < McMartin> | ("largely" aren't because std::map still has all kinds of ugly surprises in it) |
| 22:55 | < Derakon[work]> | ...heh. 15 of the last 25 checkins to my Mercurial repo include the phrase "More dead code removal". |
| 22:55 | < Thant> | C++ seems fine to me |
| 22:56 | < Derakon[work]> | Thant: how much have you used high-level languages? |
| 22:56 | | * Rhamphoryncus__ notes that openttd is C++, but he's using printf for his debugging |
| 22:56 | < Namegduf> | It's not great, but it's absolutely usable. |
| 22:56 | < McMartin> | It's still possible to do C stuff in C++ which means it inherits all the flaws therein |
| 22:56 | < McMartin> | I'm also not a fan of its inheritance mechanics. |
| 22:56 | < Thant> | only languages i've used are VB and C# and C++ (<-- games computing uni student, i just use what the lecturers tell me to ) |
| 22:56 | < Derakon[work]> | Ahh. |
| 22:56 | < Namegduf> | s/flaws/ability to actually see what the hardware is like instead of programming in some abstract universe/ |
| 22:56 | < Thant> | most of my C++ has been using the openGL libraries to do graphics stuff though |
| 22:56 | <@TheWatcher> | Derakon[work]: I think you might be making the mistake of confusing c++ with a high-level language~ |
| 22:57 | < Namegduf> | Yeah, that. |
| 22:57 | < McMartin> | Namegduf: As long as you're programming a 386~ |
| 22:57 | < Namegduf> | McMartin: Or, you know, anything else. |
| 22:57 | < Derakon[work]> | TW: er, no, I was finding out if Thant had any experience with actual high-level languages. |
| 22:57 | < McMartin> | You can't target 8086 without non-portable language extensions. |
| 22:57 | < Derakon[work]> | Because after using Python for a while, C++ is really grating. ?.? |
| 22:57 | < Namegduf> | McMartin: Erm, yes, yes you can. |
| 22:57 | | * McMartin still remembers far pointers. |
| 22:57 | < McMartin> | If you aren't explicitly marking near/far pointers in your memory model - which is a hardware-specific vendor extension - you're abstracting the hardware even in C. |
| 22:58 | < Namegduf> | There's a level of abstraction, it's just really low. |
| 22:58 | < Thant> | you wouldn't say C++ is high level? |
| 22:58 | < McMartin> | C++ is not high level the way C# is. |
| 22:58 | < Namegduf> | C++ is only high level by the definition that makes C high level |
| 22:58 | < Derakon[work]> | Not compared to more modern languages. |
| 22:58 | < McMartin> | What Namegduf said. |
| 22:58 | < Namegduf> | That is, "everything but assembly is high evel" |
| 22:58 | < Derakon[work]> | As time passes, we continue to make programming more abstract. |
| 22:58 | < Namegduf> | And slower. |
| 22:58 | < Namegduf> | (Curious that0 |
| 22:58 | < Thant> | i was under the impression that high level = relitevely close to coherent speech, as in really far away from say asembly etc |
| 22:58 | < Derakon[work]> | No, programming is faster. |
| 22:58 | < Derakon[work]> | Execution is slower. |
| 22:59 | < Namegduf> | Which is what I said and quite obviously meant. |
| 22:59 | < McMartin> | Except when it's not; handcoded MIPS assembler tends to be slower than what a good C or FORTRAN compiler will produce. |
| 22:59 | < Derakon[work]> | Thant: there's no hard-and-fast distinction. |
| 22:59 | < Thant> | fair enough |
| 22:59 | < Namegduf> | McMartin: Right, then everything past that point got orders of magnitudes worse. |
| 22:59 | < Derakon[work]> | And for 99% of applications, it doesn't matter. |
| 22:59 | < McMartin> | This has not in fact been my experience with Python or Haskell anyway. |
| 22:59 | < Thant> | this room is fairly awesome, i can idle and learn about as much as i do in a lecturer |
| 23:00 | < Thant> | lecture** |
| 23:00 | < Namegduf> | Derakon[work]: Why don't you go use VB if all you want is an application developed yesterday? |
| 23:00 | < Derakon[work]> | I wouldn't recommend spending time in lecturers. :) |
| 23:00 | < Thant> | hahaa |
| 23:00 | <@TheWatcher> | Well, depends if they're cute. |
| 23:00 | < Derakon[work]> | Namegduf: because I'd rather use Python? |
| 23:00 | < McMartin> | Namegduf: Because Python is a superior language by evrey measure? |
| 23:00 | < Thant> | my hands are cold, so i make a few mistakes ;w; |
| 23:00 | < Vornicus> | Because VB, while it is quite impressive at GUI construction, blows hot electric goats as a language. |
| 23:00 | < McMartin> | Code size, ease of development, speed of result, and portability, Python wins. |
| 23:00 | < Namegduf> | My point is that "development speed, make it work in five minutes" is not the be all and end all. |
| 23:00 | < Namegduf> | Vornicus: Yes, it does. |
| 23:00 | < Derakon[work]> | You're making a false dichotomy here. |
| 23:01 | < McMartin> | Actually, the question is generally "I need the answer in two days" |
| 23:01 | < Namegduf> | I'm not making a dichotomy. There's two points here: |
| 23:01 | < McMartin> | Write in five minutes, run for one day > write for a day and a half, run in five minutes. |
| 23:01 | < Derakon[work]> | "Make it fast" and "make it soon" are not mutually exclusive, since "fast" actually means "fast enough" in most situations. |
| 23:01 | < Namegduf> | 1) If languages which used to be "usable" but now aren't "usable", as opposed to simply being replaced by new alternatives, programmers are getting stupider. |
| 23:01 | < Derakon[work]> | And I can make a fast-enough program, and debug it, in Python one hell of a lot faster than I can make a fast-enough program in C++, and debug it. |
| 23:02 | < Derakon[work]> | ... |
| 23:02 | < Namegduf> | Everything which was usable, is still usable |
| 23:02 | < Derakon[work]> | Maybe they're getting pickier instead? |
| 23:02 | < McMartin> | Problems are also getting more complex. |
| 23:02 | < Derakon[work]> | When you're trying to improve the UI, you don't want to waste your time mucking about with buffer overflows. |
| 23:02 | < Namegduf> | McMartin: It's a pity we've not invented methods of abstraction as early as procedural programming that allows that to be managed. |
| 23:02 | < McMartin> | Also, legacy software issues more or less prove that the languages weren't usable then either, we just lived with it. |
| 23:02 | < Namegduf> | Actually, I think it proves their developers didn't know how to program. |
| 23:02 | < McMartin> | Namegduf: And we've learned nothing else since? |
| 23:03 | < McMartin> | I mean, you can argue this |
| 23:03 | < Namegduf> | McMartin: No, it's just that the problems were perfectly DOABLE. |
| 23:03 | < Derakon[work]> | Let me be the first to say that I know what it looks like when a developer doesn't know how to program. |
| 23:03 | <@TheWatcher> | Painfully so~ |
| 23:03 | < Thant> | what it seems to me |
| 23:03 | < Namegduf> | And that new languages aren't needed to tackle more complex problems, because that's what models of abstraction are for. |
| 23:03 | < Thant> | and i know im not an expert or something |
| 23:03 | < Derakon[work]> | And it's entirely different from what you get when your languages aren't as high-level as the problems you're trying to solve. |
| 23:03 | < Thant> | is that programmers dont really care about efficiency so much |
| 23:03 | < Thant> | like it used to be programmers were mega efficient cause they didnt have much space, and needed to squeeze as much as possible |
| 23:04 | < Thant> | but now they arent as constraining, nobody seems to care as much |
| 23:04 | < McMartin> | Also, squeezing a program tends to make it slower. |
| 23:04 | < McMartin> | time/space tradeoffs are still alive and well. |
| 23:04 | < Thant> | really, packing as much as possible in a small space makes it run slower compared to a bloated code? |
| 23:04 | < Namegduf> | Time/space tradeoffs are entirely ignored, as is elegance, efficiency, and complexity, in the name of whatever can be done in two minutes, in far too many places. |
| 23:04 | < Derakon[work]> | Thant: sure. |
| 23:05 | < Derakon[work]> | Compare procedural textures to textures stored as images. |
| 23:05 | < Derakon[work]> | Loading a texture is fast. Calculating one is slow. |
| 23:05 | < Thant> | yeah thats a fair point |
| 23:05 | < McMartin> | Complexity means it won't scale, which means that systems will care abou tit. |
| 23:05 | < Thant> | i agree with namegduf though in that people dont really seem to care so much about good programming practice |
| 23:05 | < Derakon[work]> | Namegduf: sounds like you're just bemoaning the lack of craftsmanship in modern programming. |
| 23:05 | < Thant> | from what i've seen anyhow |
| 23:06 | < Derakon[work]> | Which I suspect is a similar complaint as "Kids these days got no respect". |
| 23:06 | < Rhamphoryncus__> | That efficiency also has a developer time cost. It's quite evident in openttd, which has lots of bit packing |
| 23:06 | < McMartin> | As for efficiency, "the first rule of optimizing is don't do it" goes back to the fucking 1960s. |
| 23:06 | < Derakon[work]> | I.e. it's been being made as long as programming has been a profession. |
| 23:06 | < Thant> | <Derakon[work]> Which I suspect is a similar complaint as "Kids these days got no respect". |
| 23:06 | < Thant> | i laughed pretty hard at that |
| 23:07 | < Derakon[work]> | Glad to help. |
| 23:07 | < Derakon[work]> | Anyway, Namegduf, just because I use Python instead of C++ doesn't mean that I don't care about efficiency and good design. |
| 23:07 | < McMartin> | That said, I'm pretty comfortable saying that most university-level client/server network applications these days were beyond the skills of well over 90% of programmers 25 years ago. |
| 23:07 | < Derakon[work]> | It just means that I don't care about the parts that Python abstracts away for me. |
| 23:07 | < Namegduf> | I'm not trying to make any point beyond that, as someone who *started* with C/C++, the idea of programmers describe what I've found quite easy to manage and develop as "unusable" disturbing, not because they're difering, but because far too many people agree with them. |
| 23:07 | < McMartin> | While now I would only put them beyond, say, 40%. |
| 23:07 | < Rhamphoryncus__> | McMartin: don't forget that the Knuth quote refers to *small*, constant optimizations. NOT to larger algorithmic complexity optimizations. They should be done upfront. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." |
| 23:08 | < McMartin> | Right. |
| 23:08 | < Namegduf> | Memory management is absolutely trivial if you spend as little as *five minutes* planning out a design/procedure for ensuring it happens. |
| 23:08 | < McMartin> | Language choice is a "small efficiency." |
| 23:08 | < Thant> | knuth quote? |
| 23:08 | < Namegduf> | Whether it's RAII or similar techniques. |
| 23:08 | < Derakon[work]> | (Quick note: the vast majority of programs that were written 30 years ago have long since crumbled to dust, and we don't know about them any more. The ones that survived had good design. That doesn't mean that all programmers back then cared about good design.) |
| 23:08 | < McMartin> | Namegduf: I've found that working with syntax trees is effectively impossible to do without an ugly monolithic design unless you're using some kind of mark-and-sweep system. |
| 23:09 | < Derakon[work]> | Namegduf: I take issue with calling something "absolutely trivial" when legions of perfectly skillful programmers still manage to muck it up accidentally, even when they make the effort to do it write. |
| 23:09 | < Rhamphoryncus__> | Thant: "premature optimization is the root of all evil". See my previous comment for the longer version |
| 23:09 | < Namegduf> | Derakon[work]: I've never seen someone making an effort complain about issues. |
| 23:09 | <@TheWatcher> | Thant: http://en.wikipedia.org/wiki/Donald_Knuth - very highly respected computer scientist |
| 23:09 | < McMartin> | So if the choice is (a) write a mark-and-sweep system myself or (b) write in a language that takes advantage of the 20 years of research in being better than mark-and-sweep with the same effect, yeah, (b) is a no-brainer to the point of (a) being a non-started. |
| 23:09 | < McMartin> | nonstarter, rather. |
| 23:10 | < Derakon[work]> | Namegduf: okay, your experience is wildly different from mine then. |
| 23:10 | < Namegduf> | Derakon[work]: I've seen plenty of people charge in, hack something together, and then whine about difficulties |
| 23:10 | < McMartin> | And if "using X is now a non-starter" holds, that means it's "unusable". |
| 23:10 | < Thant> | thanks |
| 23:10 | < McMartin> | It wouldn't have been 20 years ago, but it is now... |
| 23:10 | < McMartin> | ... much as a system where I have to hand-draw triangles for a 3D display would be presentaly unusable because, you know, OpenGL exists. |
| 23:10 | < Derakon[work]> | I fully expect that in twenty years, people will wonder how in blazes anyone could stand to write in Python. |
| 23:10 | < Namegduf> | That's not what "unusable" means. "unusable" means "One/I can't use it." |
| 23:10 | < Derakon[work]> | And you know what? They'll be justified in thinking so! |
| 23:11 | < McMartin> | Derakon: people think that now because of whitespace issues~ |
| 23:11 | < Derakon[work]> | :p |
| 23:11 | <@TheWatcher> | Damned right ¬¬ |
| 23:11 | < Namegduf> | Perhaps, but if they say "We're not capable of writing in Python", they've gotten less intelligent to a disturbing degree |
| 23:11 | | * Derakon[work] drops some line noise on TW. |
| 23:11 | < McMartin> | Well |
| 23:11 | < Kazriko> | Eh, I find myself wishing other languages would enforce whitespace... |
| 23:11 | < McMartin> | I'm not capable of writing in Fortran. |
| 23:11 | < Namegduf> | There's a difference between "It's inefficient" and "One cannot" |
| 23:11 | <@TheWatcher> | (but then, I use perl, so I have no bloody room to talk...) |
| 23:11 | < Rhamphoryncus__> | McMartin: yeah, then we dare them to write C without whitespace ;) |
| 23:11 | < McMartin> | That doesn't mean it's beyond me. |
| 23:12 | < McMartin> | It means I've never been arsed to learn because I have no reason to ever do so. |
| 23:12 | < Namegduf> | Right. |
| 23:12 | < Derakon[work]> | There's a difference between having the capability to use a lower-level language, and that language having any relevance to your day-to-day work. |
| 23:12 | < Namegduf> | "unusable" means its beyond everyone, or at least them. |
| 23:12 | < McMartin> | (And I wouldn't learn Fortran III because I like my recursive functions, even though I *can* write recursive algorithms without having the language support them.) |
| 23:12 | < Namegduf> | As in, "It's not usable.", as in "It's not possible to use." |
| 23:12 | < McMartin> | (That latter skill is largely lost, and good riddance.) |
| 23:12 | | * Kazriko has drawn triangles by hand before, has no desire to continue doing so. :p |
| 23:12 | < Derakon[work]> | I think you're being too strict with your (English) language there, Namegduf. |
| 23:13 | < Thant> | (has to draw cubes by hand in openGL, fustrating) |
| 23:13 | < Derakon[work]> | When someone says "X is unusable", generally they're hyperbolizing. |
| 23:13 | < Namegduf> | Derakon[work]: Well, see, it seems to be consensus. |
| 23:13 | < Derakon[work]> | What they actually mean is "X is impractical" |
| 23:13 | < McMartin> | I read "unusable" as "is such a bad idea that it should not be done." |
| 23:13 | < McMartin> | Yeah. |
| 23:13 | < Derakon[work]> | And why shouldn't the consensus be "C++ is impractical for most applications"? |
| 23:13 | < Namegduf> | Aside that it isn't... |
| 23:14 | < Kazriko> | C++ is impractical for all of the applications i've done except one of my most recent... |
| 23:14 | < Derakon[work]> | Compared to other more abstracted languages, it's certainly less practical. |
| 23:14 | < McMartin> | And honestly, given that buffer overflows were the reigning security exploit on every computer system and every operating system for 30 years until the Internet revolution made SQL injection beat it out... |
| 23:14 | < McMartin> | The prosecution at least has a colorable case. |
| 23:15 | < Derakon[work]> | You asked me earlier why I don't use VB if all I want to do is hack out a job as quickly as possible. I ask you why, if you're so concerned about craftsmanship, you don't bone up on assembly optimization and hand-craft your own assembly code? |
| 23:15 | < Derakon[work]> | The two stances are equally absurd. |
| 23:15 | < Namegduf> | Because that's not an improvement in craftsmanship. |
| 23:15 | < Rhamphoryncus__> | mental note: floating averages do not work when you use the average itself as the minimum value for the next round |
| 23:15 | < McMartin> | Post-standardization - which I remind you has been less than a decade - C++ is much easier to use in a restricted fashion where you can largely ensure that it's being used right. |
| 23:15 | < Namegduf> | McMartin: Precisely. |
| 23:15 | < McMartin> | However, when you do this, your code is largely indistinguishable from C# or Java. |
| 23:15 | < McMartin> | And JIT technology has gotten extremely good; MSIL's JITs in particular can rival most STL implementations. |
| 23:16 | < Namegduf> | Except ridiculously faster and without the horrible memory usage and weight of Java. |
| 23:16 | < Namegduf> | Java doesn't scale down very well |
| 23:16 | < McMartin> | Yes |
| 23:16 | < McMartin> | Beat me to it |
| 23:16 | < McMartin> | JIT effectively is a burden on link-loading time. |
| 23:16 | | * Namegduf has 128MB RAM servers. Java is not acceptable as a solution there. Python is, and is used in a few places. |
| 23:16 | < Vornicus> | Hell, a great many video games - long the prime land of C/C++ - use languages like Lua (WoW, Aquaria, Supreme Commander) or Python (Civ4) for literally everything they can get away with. |
| 23:16 | < Kazriko> | The memory usage of java was important back when we were using 128mb and smaller servers, like yours. :p |
| 23:17 | < McMartin> | There are a lot of applications where nobody gives a shit about link-loading time, but some applications (like gmake!) assume link-loading time is effectiveloy zero. |
| 23:17 | < Namegduf> | Kazriko: So basically in any case where RAM matters. |
| 23:17 | < Kazriko> | Ruby, btw, is a poor choice in those environments too. |
| 23:17 | < Vornicus> | Which is a shitton. |
| 23:17 | < McMartin> | No, RAM can matter at any phase. |
| 23:17 | < Namegduf> | Yeah, I understand Ruby is. |
| 23:17 | < Kazriko> | I had a server that worked perfectly on Python and zope for years... |
| 23:17 | < McMartin> | My usual operating environment is one where the target is 1GB RAM and care is required to not blow into 2GB-level requirements. |
| 23:18 | < Kazriko> | tried to install redmine for ruby on it... took it down completely. |
| 23:18 | < Namegduf> | Yeah, that'll happen. |
| 23:18 | < Namegduf> | But it doesn't matter if it can save a programmer five minutes |
| 23:18 | < McMartin> | I rather suspect that RAM will matter based on dataset. |
| 23:18 | < Derakon[work]> | You're hyperbolizing, Namegduf. |
| 23:18 | < McMartin> | Bringing down the dev machine costs the dev time and enrages them and their IT departments~ |
| 23:18 | < Namegduf> | Derakon[work]: Only a little. That does tend to be the prevailing attitude, or the end result of entirely ignoring efficiency. |
| 23:18 | < Derakon[work]> | The difference in worktime for a complicated task, in C++ vs. a high-level language, can be huge. |
| 23:19 | < McMartin> | Derakon: make that C and I'll agree |
| 23:19 | < Namegduf> | Derakon[work]: It really heavily depends on what you're doing. I write in C++ and Python intermixed of late |
| 23:19 | < McMartin> | If safety is not a concern, the C++/Python difference is merely "noticable"~ |
| 23:19 | < Derakon[work]> | Heh. |
| 23:19 | < McMartin> | Python scales down better than C++. |
| 23:19 | < Namegduf> | C++ scales down like C |
| 23:20 | < McMartin> | Sssort of. |
| 23:20 | < Namegduf> | Aside the cost of having the runtime aronud. |
| 23:20 | < Namegduf> | Because it has a "pay for it if you use it" approach (which I *like* as nice language features go) |
| 23:20 | < Derakon[work]> | Jetblade works nicely by starting in Python, and then converting time-critical bits to C (well, Cython) as-needed. |
| 23:20 | | * Kazriko has programmed far more C code over the years than C++... |
| 23:20 | < McMartin> | I'm thinking for scaling down to the point where Python starts looking like shell. |
| 23:20 | < McMartin> | At which point "small super-shell script" is easier than "small compiled program" |
| 23:20 | < Namegduf> | Oh, I see. |
| 23:20 | < Namegduf> | Yes, that's true. |
| 23:20 | < Rhamphoryncus__> | I want to make python scale down like a hand-tuned assembly app. Without the runtime library even |
| 23:21 | < Derakon[work]> | "import for" |
| 23:21 | < Namegduf> | See, what's really ugly and annoys me is that high level languages SHOULD be capable of doing that. |
| 23:21 | < McMartin> | As for "pay for it if you use it" C++ takes it to extremes I occasionally find offensive, but that's absolutely going to depend on problem domain and architecture paradigm. |
| 23:21 | < Namegduf> | The big limiting factor in C/C++ optimisation is how much the compiler can safely assume about what you're doing. |
| 23:21 | < Rhamphoryncus__> | Namegduf: so support my compiler ;) |
| 23:21 | < McMartin> | Right |
| 23:22 | < Namegduf> | High level languages should make it easier, but they instead make things vastly more expensive. |
| 23:22 | < McMartin> | Lack of arbitrary pointer arithmetic allows for huge gains. |
| 23:22 | < Namegduf> | I'll skip the rant about dynamic typing |
| 23:22 | < McMartin> | C++'s implementations of RTTI and exceptions are quite plausibly the worst implementations worthy of the name, and its RTTI may not even be worthy of being called it. |
| 23:22 | < Namegduf> | Which I find both increasing development times to write *good* software (because I now have to ensure my variables contain what I want them to contain) AND execution times. |
| 23:23 | < Namegduf> | But... it really is a good example. |
| 23:23 | | Thant [Thant@Nightstar-63cb80a6.cable.ntl.com] has quit [[NS] Quit: ] |
| 23:23 | < Namegduf> | In deciding whether to have it, it seriously would appear that efficiency never even entered the discussion. |
| 23:23 | < McMartin> | Well, it did, but it came in as "how can we make it vanish utterly without trace?" |
| 23:23 | < McMartin> | Which costs a lot. |
| 23:24 | < Derakon[work]> | Make what vanish utterly? |
| 23:24 | < Derakon[work]> | Pronoun trouble~ |
| 23:24 | < McMartin> | it: the feature, when unused. |
| 23:24 | < McMartin> | Which is to say, it has to have zero overhead if dynamic_cast<> is never called by it nor by anything that could conceivably ever link against it. |
| 23:25 | < McMartin> | Which means that, among other things, tagging the data with its type Isn't Allowed. |
| 23:25 | < Derakon[work]> | Oh, you're talking about C++ here. |
| 23:25 | < McMartin> | IIRC, the standard implementation is to do pointer-compare with vtables, which interacts in well-specified but very surprising ways with multiple inheritance and structs. |
| 23:25 | < Derakon[work]> | I was on a separate branch. |
| 23:25 | < Namegduf> | But, yeah, working with both |
| 23:25 | < Namegduf> | I find C++ and Python roughly identical in terms of difficulty to code. |
| 23:26 | < Derakon[work]> | Quick question: how often do you have to deal with other peoples' code? |
| 23:26 | < Namegduf> | C++ has some initial overhead in starting new tasks and involves finding the API you're going to use, and has some uglier APIs. |
| 23:26 | < Derakon[work]> | I'm mostly just curious. |
| 23:26 | < McMartin> | The closest I've seen to a "good" RTTI system that's also fast is Objective-C, and it's got holes in it that make it questionable as a whole |
| 23:26 | < Namegduf> | Python... hmm, only in one of the things I've touched, and it was Bad Code. |
| 23:26 | < Namegduf> | As in, entirely uncommented. |
| 23:26 | < Derakon[work]> | Hah. |
| 23:26 | < McMartin> | Bad Python Code is really the best |
| 23:26 | < Derakon[work]> | Man, I have you so beat. |
| 23:26 | <@TheWatcher> | snrk |
| 23:26 | | * Kazriko finds it equally fast to write one line of C++ code as one line of Python, but can get 3x as much done with one line of python as one line of C++. ehh |
| 23:26 | < McMartin> | And the guys that had to work with Vlad beat you~ |
| 23:27 | < Derakon[work]> | Point. |
| 23:27 | < McMartin> | I have since concluded that Python is the best possible language for Bda Code |
| 23:27 | < Derakon[work]> | But yeah, in the past two months, I have stripped out 3500 lines of code from this application, all in Python. |
| 23:27 | < Namegduf> | C++, latest thing was to write a module for another piece of software |
| 23:27 | < McMartin> | because The Badness is so flagrantly evident and nonobscured. |
| 23:27 | < Derakon[work]> | But I would hate to think what it'd be like if this were all C++ instead. |
| 23:27 | < Namegduf> | So I'd consider it as pretty heavily using other people's code. |
| 23:28 | < Derakon[work]> | Namegduf: er, I meant "how much do you have to maintain, modify, debug, etc. other peoples' code" |
| 23:28 | < Derakon[work]> | Not just having your code interacting with their code. |
| 23:28 | < Namegduf> | Debug, occasionally, but rarely. |
| 23:29 | < Namegduf> | Maintain, not really. There's other contributors to what I maintain, but in small amounts. |
| 23:30 | < Derakon[work]> | Nothing like "My team is responsible for this component in this program, and we all work together on it"? |
| 23:31 | < Namegduf> | Nothing on that level. There's a team, but the number contributing is small, and I'm by a wide margin the main contributor. Hobbyist stuff there. |
| 23:34 | < Namegduf> | You're saying C++ is a lot harder to manage? |
| 23:34 | < Derakon[work]> | I'm saying that I'd much rather maintain someone's bad Python code than their bad C++ code. |
| 23:34 | < Derakon[work]> | It's a lot harder to hide gotchas in Python than in C++. |
| 23:35 | < Derakon[work]> | (Whether intentionally or accidentally) |
| 23:35 | < Namegduf> | That's true. |
| 23:35 | < Namegduf> | Although dynamic typing hurts for that in some cases. |
| 23:36 | < Derakon[work]> | Maybe...but generally I can track down the invokers of a given piece of code and look at what they're using. |
| 23:38 | | Netsplit *.net <-> *.split quits: jerith, gnolam, Kazriko, MyCatVerbs, Orthianz, Reivles, AnnoDomini |
| 23:40 | | Netsplit over, joins: MyCatVerbs |
| 23:40 | < McMartin> | The issue with Python is that you have to trigger the problem at run-time, while ObjC (for instance) has a vague idea of it and can at least warn about more suspicious cases. |
| 23:40 | < McMartin> | Intrinsically not perfect, of course. |
| 23:41 | < McMartin> | In actual code news, is there a way in Perl to do string interpolation inside of here documents? |
| 23:41 | < Derakon[work]> | "Inside of here documents"? |
| 23:42 | < McMartin> | "Here documents" is the Perl equivalent of Python's """ strings. |
| 23:42 | < Derakon[work]> | Oh, like "print <<EndOfString"? |
| 23:42 | < Derakon[work]> | Yeah, you can do string interpolation in those. |
| 23:43 | < Derakon[work]> | Like so: http://paste.ubuntu.com/311945/ |
| 23:43 | <@TheWatcher> | In fact, I believe it interpolates by default unless you surround the keyword in quotes (print <<'EndOFString';) |
| 23:44 | < McMartin> | Aha |
| 23:44 | | * McMartin >_<s at this. |
| 23:44 | < McMartin> | Speaking of Wrong Language for the Task. |
| 23:44 | < McMartin> | Using Perl to autogenerate NSIS. |
| 23:44 | <@TheWatcher> | ... yeah |
| 23:44 | | * McMartin adds "recode all this in Python" to The List Of Stuff. |
| 23:45 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has joined #code |
| 23:46 | < McMartin> | On the other hand, mixing <<'EOS' with <<EOS makes it hurt a *little* less. |
| 23:47 | < McMartin> | So thanks for that. |
| 23:47 | | Reivles [reaverta@ServerAdministrator.Nightstar.Net] has joined #code |
| 23:47 | < Derakon[work]> | Glad to help. |
| 23:49 | | AnnoDomini [farkoff@Nightstar-ba7f0025.adsl.tpnet.pl] has joined #code |
| --- Log closed Sat Nov 07 00:00:02 2009 |