| --- Log opened Sun Mar 04 00:00:14 2012 |
| 00:04 | <@ToxicFrog> | Anyways, yeah, at this point I think the best you can hope for is for them to escape without hating programming, and perhaps knowing a bit of basic C++ |
| 00:04 | <@ToxicFrog> | I would not expect any of them to actually know how to program |
| 00:07 | < Tarinaky> | Yeah. |
| 00:08 | < Tarinaky> | I managed to avoid hurting any 17/18 year olds I had to help with the programming demonstration for open day. |
| 00:08 | < Tarinaky> | As much as one heavily acned girl struggled to understand what I meant by blocks needing to be indented. |
| 00:08 | < Tarinaky> | >.< |
| 00:08 | < Tarinaky> | I'm terrible at this teaching thing. |
| 00:09 | < Tarinaky> | (Python) |
| 00:12 | < Tarinaky> | She kept indenting the wrong lines. |
| 00:12 | < Tarinaky> | No matter how I tried to explain it. |
| 00:12 | < Tarinaky> | It was maddenning. |
| 00:12 | | Derakon[AFK] is now known as Derakon |
| 00:12 | | mode/#code [+ao Derakon Derakon] by ChanServ |
| 00:44 | | You're now known as TheWatcher[T-2] |
| 00:49 | <&McMartin> | Man. It turns out that OCaml isn't quite as bad a language as it looks |
| 00:49 | <&McMartin> | But most of that is because the toplevel repl is AWFUL |
| 00:54 | | You're now known as TheWatcher[zZzZ] |
| 00:57 | <&McMartin> | Also, argh, miss Haskell's conciseness so much, but I really need state for my prototype here. |
| 01:04 | <&McMartin> | Mrr. And one thing ML and Haskell both lack is an ability to directly say "hey, does this value match against this constructor" as a boolean expression, though it's usually both possible and desirable to work around that. |
| 01:23 | | Vash [Vash@Nightstar-a60eef95.ct.comcast.net] has joined #code |
| 01:23 | | mode/#code [+o Vash] by ChanServ |
| 01:57 | | * McMartin grumble at ML constructors, though he doesn't remember if this trick works in Haskell. |
| 02:00 | | Vash [Vash@Nightstar-a60eef95.ct.comcast.net] has quit [[NS] Quit: I lovecraft Vorn!] |
| 02:04 | | Kindamoody[zZz] is now known as Kindamoody |
| 02:48 | | Ling [rstamer@genoce.org] has quit [Ping timeout: 121 seconds] |
| 03:10 | | Vash [Vash@Nightstar-cdeba41f.wlfrct.sbcglobal.net] has joined #code |
| 03:10 | | mode/#code [+o Vash] by ChanServ |
| 03:15 | < Rhamphoryncus> | I might've figured out why I have so much trouble with version control. I think in terms of version controlled patch queues. Unfortunately such a thing does not exist. You can have either version control (which is essentially just a straight line) or you can have patch queues (which use no version control at all) |
| 03:16 | <&Derakon> | What's a patch queue? |
| 03:16 | < Rhamphoryncus> | Mechanically, it's just a series of diffs |
| 03:16 | <&Derakon> | So how is that less linear than version control? |
| 03:17 | < Rhamphoryncus> | The idea is to treat the changes as an entity, rather than the resulting version, so you can easily remove and reapply them |
| 03:18 | < Rhamphoryncus> | If you have your own patches for something but want to track upstream then a patch queue is the way to go. Much less collisions, easier to understand when you do get them |
| 03:18 | < Rhamphoryncus> | Popularized in linux kernel development |
| 03:20 | < Rhamphoryncus> | The problem.. is it's mechanically just a series of diffs. Hg has a standard extension (heh) for it, which creates a .hg/patches/ dir that contains... .diff files |
| 03:20 | | Attilla [Obsolete@Nightstar-ce4a0443.as43234.net] has quit [Ping timeout: 121 seconds] |
| 03:20 | < Rhamphoryncus> | While you can remove and reapply them easily, they don't enter version control until they stop being a diff and become a normal commit |
| 03:21 | < Rhamphoryncus> | So if you update one to resolve a collision.. and screw it up.. it's gone. |
| 03:21 | <&Derakon> | It sounds like you'd want to have to apply an entire series of diffs to a file before you'd actually have the thing you'd want to use/run/compile. |
| 03:21 | <&Derakon> | Or maybe I'm misunderstanding. |
| 03:21 | < Rhamphoryncus> | The hg extension has commands to apply them for you |
| 03:22 | <@ToxicFrog> | ...I'm not clear what the functional difference is between "version control stores patches internally, and generates finished files for you to work on" and "version control stores files internally, and generates patches for you to apply" |
| 03:23 | < Rhamphoryncus> | Merging |
| 03:23 | <@ToxicFrog> | I mean, your use case for "you have your own patches for something but want to track upstream" is exactly what git branch/fetch/merge/stash/rebase are for; I assume that Hg et all have equivalents |
| 03:23 | <@ToxicFrog> | Again, how? |
| 03:23 | < Rhamphoryncus> | rebase, yes |
| 03:24 | <@ToxicFrog> | I mean, it sounds like what you're asking for already exists in the form of 'git rebase', which basically turns history back to the branch point into a sequence of diffs and then applies them to the head. |
| 03:25 | < Rhamphoryncus> | I haven't investigated rebase thoroughly. What I've read implied it breaks things in the same way patch queues do |
| 03:25 | < Rhamphoryncus> | But that was a bit ago |
| 03:26 | <@ToxicFrog> | Er, weren't you just arguing a minute ago that the nice thing about patch queues is that they don't break things [as much as merges]? |
| 03:27 | < Rhamphoryncus> | They merge better but they lack version control. They're irreversible. |
| 03:27 | <@ToxicFrog> | um |
| 03:27 | <@ToxicFrog> | what |
| 03:27 | <@ToxicFrog> | I don't |
| 03:28 | <@ToxicFrog> | Ok, so, what rebase does is basically this: |
| 03:28 | <@ToxicFrog> | foreach commit in the branch being rebased: generate a diff |
| 03:29 | <@ToxicFrog> | foreach diff: apply it to the HEAD being rebased onto, then commit the result using the same commit message as the commit the diff was originally generated from |
| 03:29 | <@ToxicFrog> | Then repoint the branch being rebased at the latest of these new commits. |
| 03:30 | < Rhamphoryncus> | So that duplicates all the commits, rather than altering them? |
| 03:30 | <@ToxicFrog> | Yes. Commits are immutable in git. |
| 03:31 | < Rhamphoryncus> | Alright. That wasn't the impression I got before. |
| 03:31 | <@ToxicFrog> | Basically, if you have this: |
| 03:31 | <@ToxicFrog> | A-B-C-D-E <- master |
| 03:31 | <@ToxicFrog> | \ |
| 03:31 | <@ToxicFrog> | F-G-H <- feature |
| 03:31 | <@ToxicFrog> | And you rebase the 'feature' branch onto 'master', you get this: |
| 03:31 | <@ToxicFrog> | v- master |
| 03:31 | <@ToxicFrog> | A-B-C-D-E-F'-G'-H' <-feature |
| 03:31 | <@ToxicFrog> | \ |
| 03:31 | <@ToxicFrog> | F-G-H <- (anonymous branch) |
| 03:32 | < Rhamphoryncus> | yeah, that sounds right |
| 03:32 | <@ToxicFrog> | F', G' and H' are new commits created by applying the diffs generated from F, G, and H respectively. |
| 03:32 | <@Alek> | "One more 90-line SQL request, and I'll ask for my salary in cocaine." |
| 03:32 | <@ToxicFrog> | The 'feature' branch name now points to these new commits; 'master' is unchanged. |
| 03:32 | <@ToxicFrog> | The original branch is now dangling; you can give it a new name or tag if you like, or if just let it die. |
| 03:33 | <@ToxicFrog> | (commits that cannot be reached from any tag or branch will, by default, be deleted after 30 days) |
| 03:34 | < Rhamphoryncus> | So the labelling is retconned, but otherwise things are left intact |
| 03:34 | < Rhamphoryncus> | oh |
| 03:34 | <@ToxicFrog> | So, yeah. There are some commands in git that rewrite history, but this always means creating or deleting commits or changing labels around; the commits themselves are immutable once created. |
| 03:34 | < Rhamphoryncus> | That's undesirable |
| 03:34 | <@ToxicFrog> | How so? |
| 03:35 | <@ToxicFrog> | And which is "that"? |
| 03:35 | < Rhamphoryncus> | deleting after 30 days is undesirable |
| 03:35 | <@ToxicFrog> | Ok, so tag/branch the commits |
| 03:37 | <@ToxicFrog> | I'm not sure what's undesireable, as a matter of principle, about "delete commits that are no longer accessible" |
| 03:37 | <@Alek> | Q: The Chinese can show numbers of up to 10 on one hand, up to 100 using both hands. |
| 03:37 | <@Alek> | S: That's nothing, I can show numbers up to 1024 using both hands! |
| 03:37 | <@Alek> | Q: Don't be stupid, how are you going to show 132 in polite society? |
| 03:37 | < Rhamphoryncus> | They shouldn't be truly inaccessible. They're just the old version. |
| 03:37 | < Eri> | Ha |
| 03:37 | < Eri> | That's good |
| 03:37 | <@ToxicFrog> | (ok, strictly speaking they are accessible, but all the ways for doing so reliably end with "and now you have implemented git tag, except worse") |
| 03:37 | < Eri> | People get confused when I count like that |
| 03:38 | <@ToxicFrog> | Rhamphoryncus: so, you want versioning of the branch label itself? |
| 03:38 | <&Derakon> | Alek: counting in binary on your fingers really doesn't work very well. |
| 03:38 | <&Derakon> | Numerous combinations are rather hard on you. |
| 03:38 | < Eri> | Grey code is better |
| 03:38 | < Rhamphoryncus> | ToxicFrog: no, I want all the data behind it |
| 03:38 | <@ToxicFrog> | Ie, you want to be able to say "get me the commit this branch label pointed to five commits ago" (as opposed to "get me the commit five commits ago on the branch this label points to") |
| 03:38 | <@ToxicFrog> | What do you mean by "all the data behind it"? |
| 03:39 | <@Alek> | Dera: yeah. XD |
| 03:39 | <@ToxicFrog> | A branch label consists of two pieces of data*: a commit ID indicating the branch head, and a flag indicating whether it's a branch or a tag. |
| 03:39 | <@ToxicFrog> | * setting aside things like cryptographically signed tags |
| 03:40 | <@ToxicFrog> | Rhamphoryncus: the impression I get is that you want to be able to say not only "get me the branch feature", but also "get me the branch that was feature before our last rebase" |
| 03:40 | <@Alek> | but you can use them as mnemonics for your mental register, at least. :P |
| 03:40 | < Rhamphoryncus> | If I developed a change based on an old version, and I later find something isn't working, then I may need to go to the original base to track down when it appeared |
| 03:40 | < Rhamphoryncus> | yes |
| 03:40 | <@ToxicFrog> | Ok, so I have a few sources of confusion |
| 03:41 | <@ToxicFrog> | (a) the new branch, by definition, contains all of the changes of the old branch |
| 03:41 | <@ToxicFrog> | (b) by wanting to record the old branch as well you have basically reinvented merge, except worse |
| 03:41 | <@ToxicFrog> | (c) in either case, if you really need this, tag the old branch before you rebase |
| 03:42 | < Rhamphoryncus> | I only want it to be retrievable if I need it. That's the point of version control. |
| 03:42 | <@ToxicFrog> | <ToxicFrog> (c) in either case, if you really need this, tag the old branch before you rebase |
| 03:42 | < Rhamphoryncus> | So manually work around an undesirable feature |
| 03:43 | <@ToxicFrog> | I honestly cannot think of a use case where you would actually need it, but if you do, hey, you can preserve it. |
| 03:43 | < Rhamphoryncus> | I suspect I can turn off such cleaning up anyway |
| 03:43 | <@ToxicFrog> | But, again, this brings me back to (a) you have reinvented merge except worse |
| 03:43 | < Rhamphoryncus> | How so? |
| 03:43 | < Namegduf> | Yeah... if you want this, do a merge, not a rebase? |
| 03:43 | | Eri [Eri@Nightstar-3e5deec3.gv.shawcable.net] has quit [Ping timeout: 121 seconds] |
| 03:46 | < Rhamphoryncus> | All I'm asking is for a rebase that doesn't delete my history. I'm not asking for some complicated way of exposing it to me on a constant basis, just that it's there if needed. |
| 03:50 | <@ToxicFrog> | Rhamphoryncus: function git-safe-rebase() { git tag "$1-$(date)"; git rebase $@; } |
| 03:51 | <@ToxicFrog> | Or...use a merge, which is actually designed for "I want to incorporate all of the changes from two branches without rewriting history" |
| 03:53 | < Rhamphoryncus> | The problem with merge is it treats the two branches as equals. I make a 2 line change adjacent to an upstream change, when they've done 1000 other changes in that file, and I have to wade through it all |
| 03:53 | <@ToxicFrog> | ...no you don't |
| 03:54 | < Rhamphoryncus> | merge makes perfect sense if I am the upstream and they really are two parallel branches |
| 03:54 | < Rhamphoryncus> | My experience says otherwise :P |
| 03:54 | <@ToxicFrog> | Although you would if you were generating a diff set from upstream and trying to apply that~ |
| 03:54 | < Namegduf> | You've got a funny merge tool if it shows conflicts for more places in the file than you made changes. |
| 03:54 | < Rhamphoryncus> | *shrug* |
| 03:55 | < Rhamphoryncus> | I just started using meld and it does it too |
| 03:56 | < Rhamphoryncus> | I do have diffuse installed; haven't tried it yet. |
| 04:10 | < celticminstrel> | Um, since when does rebasing the feature branch onto master result in deleting the feature branch...? |
| 04:11 | < Namegduf> | Merging. |
| 04:11 | < Namegduf> | You merge a feature branch into master. |
| 04:11 | < celticminstrel> | Maybe I see it differently because I always "git pull --rebase" rather than "git rebase". |
| 04:11 | < celticminstrel> | (Unless I want to amend a commit; then it's "git rebase --interactive" and do stuff and stuff.) |
| 04:12 | | Alek [omegaboot@Nightstar-efc8dc53.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 04:13 | | Alek [omegaboot@Nightstar-efc8dc53.il.comcast.net] has joined #code |
| 04:13 | | mode/#code [+o Alek] by ChanServ |
| 04:16 | <@ToxicFrog> | celticminstrel: rebase copies the branch and the branch name now refers to the copy. |
| 04:16 | < celticminstrel> | Huh? |
| 04:16 | <@ToxicFrog> | The old version of the branch is now (unless otherwise reffed in some way) dangling and will be culled by the garbage collector once it expires. |
| 04:17 | <@ToxicFrog> | <celticminstrel> Um, since when does rebasing the feature branch onto master result in deleting the feature branch...? |
| 04:17 | < celticminstrel> | Why would it copy it? |
| 04:17 | <@ToxicFrog> | It doesn't delete the branch as such, but the commits making up the pre-rebase version of the branch are left dangling. |
| 04:17 | <@ToxicFrog> | ...because commits are immutable? |
| 04:17 | <@ToxicFrog> | Rebase doesn't edit the commits in place, it creates new commits based on the old ones and then edits the branch marker to point to the new commits. |
| 04:18 | < celticminstrel> | So you're copying the commits from the feature branch and adding them onto the master branch, I get that. |
| 04:18 | <@ToxicFrog> | This is how all history rewrites in git work, including amend and filter-branch. |
| 04:18 | < celticminstrel> | But why would that result in the old branch being touched... |
| 04:18 | <@ToxicFrog> | Because the branch name no longer refers to the old branch |
| 04:18 | <@ToxicFrog> | See my earlier diagram. |
| 04:18 | < celticminstrel> | So master and feature end up referring to the same place/ |
| 04:18 | < celticminstrel> | ? |
| 04:19 | <@ToxicFrog> | If that name was the only name referring to that branch, those commits are now unreachable. |
| 04:19 | <@ToxicFrog> | No; see the diagram, again. |
| 04:19 | < celticminstrel> | Oh, I see. |
| 04:19 | < celticminstrel> | So, "pull --rebase" is different from a straight rebase then. |
| 04:20 | < celticminstrel> | Or... wait, maybe I'm confused again... |
| 04:20 | <@ToxicFrog> | No, it's not. |
| 04:20 | <@ToxicFrog> | pull --rebase is just fetch remote branch + rebase local onto remote |
| 04:20 | <@ToxicFrog> | (and plain pull is fetch remote branch + merge remote into local) |
| 04:21 | < celticminstrel> | So, "git rebase master" is the same as "git pull --rebase . master"? |
| 04:21 | < celticminstrel> | <_< |
| 04:22 | <@ToxicFrog> | um |
| 04:22 | <@ToxicFrog> | I have no idea, I've tried using pull to operate entirely on local branches and I wouldn't recommend it |
| 04:22 | < celticminstrel> | It has never caused a problem for me... |
| 04:23 | <@ToxicFrog> | 'git rebase master' is 'rebase the current branch onto master' is 'copy the current branch onto the end of master and then repoint the branch label at the copy' |
| 04:23 | <@ToxicFrog> | Hang on |
| 04:24 | <@ToxicFrog> | That's "git pull" with . as the repository? |
| 04:24 | < celticminstrel> | Yup. |
| 04:24 | <@ToxicFrog> | ...ok, I guess that would work, but why would you ever do that? |
| 04:24 | < celticminstrel> | I think I recall trying git rebase once and something went wrong and I ended up aborting. |
| 04:24 | < celticminstrel> | I have no idea. |
| 04:25 | <@Alek> | "C++ is an absolutely hardcore language. Forget shooting yourself in the foot, you can hang yourself in an absolutely empty room." |
| 04:28 | < Rhamphoryncus> | It's so nice to see someone besides myself confused about git/hg ;) |
| 04:29 | <@ToxicFrog> | celticminstrel: I find myself unable to figure out how one can react to rebase trouble by switching to rebasing from a self pull o.O |
| 04:29 | < celticminstrel> | I don't remember the details. It was some time ago. |
| 04:31 | < celticminstrel> | Rhamphoryncus: Heh. |
| 04:31 | < celticminstrel> | Most recently was trying to figure out how to split a commit into two. |
| 04:32 | < celticminstrel> | The answer was something like "git reset HEAD^". |
| 04:32 | < celticminstrel> | (After initiating an interactive rebase which specified editing the commit in question.) |
| 04:33 | < celticminstrel> | I didn't even know that was a syntax that existed. |
| 04:33 | <@ToxicFrog> | HEAD or HEAD~1 to rewind the branch, yeah. And then you just git commit as normal, except with half the changes in each commit |
| 04:33 | <@ToxicFrog> | Er, HEAD^ or HEAD~1 |
| 04:35 | <@ToxicFrog> | 'git help revisions' contains all the details on the syntax. |
| 04:40 | | * Rhamphoryncus reviews his revision after a merge and wonders where all these changes came from |
| 04:41 | < Rhamphoryncus> | They seem to be from upstream. I can only guess they're showing up because the branch I'm working on also touched that file, and thus had to be merged. |
| 04:55 | | AnnoDomini [annodomini@A08927.B4421D.B81A91.464BAB] has joined #code |
| 04:55 | | mode/#code [+o AnnoDomini] by ChanServ |
| 04:56 | < Rhamphoryncus> | Ergh. less decided to sort my files as _2d.diff, _2.diff, _2e.diff |
| 05:03 | < Rhamphoryncus> | But the bugtracker did one better. 2e, 2f, 2g, 1, 2a, 2b, 2c, 2d |
| 05:52 | | Eri [Eri@Nightstar-3e5deec3.gv.shawcable.net] has joined #code |
| 06:06 | | Stalker [Z@2C3C9C.B2A300.F245DE.859909] has quit [Ping timeout: 121 seconds] |
| 07:00 | | Syloqs-AFH [Syloq@NetworkAdministrator.Nightstar.Net] has quit [[NS] Quit: ] |
| 07:05 | | Stalker [Z@Nightstar-3602cf5a.cust.comxnet.dk] has joined #code |
| 07:17 | | Derakon is now known as Derakon[AFK] |
| 07:34 | | Vash [Vash@Nightstar-cdeba41f.wlfrct.sbcglobal.net] has quit [[NS] Quit: I lovecraft Vorn!] |
| 07:48 | | AnnoDomini [annodomini@A08927.B4421D.B81A91.464BAB] has quit [[NS] Quit: leaving] |
| 07:49 | | Rhamphoryncus [rhamph@Nightstar-5697f7e2.abhsia.telus.net] has quit [Ping timeout: 121 seconds] |
| 07:51 | | Rhamphoryncus [rhamph@Nightstar-5697f7e2.abhsia.telus.net] has joined #code |
| 08:02 | | Rhamphoryncus [rhamph@Nightstar-5697f7e2.abhsia.telus.net] has quit [Ping timeout: 121 seconds] |
| 08:24 | | celticminstrel [celticminst@Nightstar-5d22ab1d.cable.rogers.com] has quit [[NS] Quit: Kablammo! Celticminstrel is now unavailable for comment.] |
| 08:28 | | eckse [eckse@Nightstar-7a655f1e.dsl.sentex.ca] has quit [Client closed the connection] |
| 08:55 | | Aeron is now known as EvilDarkLord |
| 09:07 | | You're now known as TheWatcher |
| 09:20 | | Kindamoody is now known as Kindamoody|out |
| 09:31 | | Alek [omegaboot@Nightstar-efc8dc53.il.comcast.net] has quit [Client closed the connection] |
| 09:32 | | Alek [omegaboot@Nightstar-efc8dc53.il.comcast.net] has joined #code |
| 09:32 | | mode/#code [+o Alek] by ChanServ |
| 09:53 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 09:53 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has joined #code |
| 09:53 | | mode/#code [+o PinkFreud] by ChanServ |
| 10:06 | <@jerith> | https://icanhascheezburger.files.wordpress.com/2008/06/funny-pictures-anteater-d ebugged-laptop.jpg |
| 10:09 | | kazrikna [kazrikna@4CA975.462904.08E9A2.992A2D] has quit [Ping timeout: 121 seconds] |
| 10:15 | | Derakon[AFK] [Derakon@Nightstar-a3b183ae.ca.comcast.net] has quit [Ping timeout: 121 seconds] |
| 10:15 | | Derakon[AFK] [Derakon@Nightstar-a3b183ae.ca.comcast.net] has joined #code |
| 10:35 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 10:42 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has joined #code |
| 10:42 | | mode/#code [+o PinkFreud] by ChanServ |
| 10:46 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 10:52 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has joined #code |
| 10:52 | | mode/#code [+o PinkFreud] by ChanServ |
| 11:21 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 11:43 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 11:47 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has joined #code |
| 11:48 | | mode/#code [+o PinkFreud] by ChanServ |
| 11:55 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code |
| 11:56 | | mode/#code [+o himi] by ChanServ |
| 12:08 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 12:14 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has joined #code |
| 12:14 | | mode/#code [+o PinkFreud] by ChanServ |
| 12:14 | | Attilla [Obsolete@Nightstar-ce4a0443.as43234.net] has joined #code |
| 14:01 | | celticminstrel [celticminst@Nightstar-5d22ab1d.cable.rogers.com] has joined #code |
| 14:19 | | maoranma [maoranma@Nightstar-d6cc5170.pools.spcsdns.net] has joined #code |
| 15:03 | | maoranma [maoranma@Nightstar-d6cc5170.pools.spcsdns.net] has quit [Ping timeout: 121 seconds] |
| 15:08 | | Syloqs_AFH [Syloq@NetworkAdministrator.Nightstar.Net] has joined #code |
| 15:08 | | mode/#code [+o Syloqs_AFH] by ChanServ |
| 15:09 | | Syloqs_AFH is now known as Syloqs-AFH |
| 15:50 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 15:50 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has joined #code |
| 15:50 | | mode/#code [+o PinkFreud] by ChanServ |
| 16:54 | | Kindamoody|out is now known as Kindamoody |
| 18:36 | | Derakon[AFK] is now known as Derakon |
| 18:36 | | mode/#code [+ao Derakon Derakon] by ChanServ |
| 19:29 | <@ToxicFrog> | automatic partial functions yesssssssssss |
| 19:30 | | * ToxicFrog rubs himself up against Scala like a cat |
| 19:32 | <@jerith> | ToxicFrog: https://gist.github.com/1406238 |
| 19:33 | <@jerith> | (Not to rain on your parade, but there's useful advice in there.) |
| 19:36 | <@ToxicFrog> | Reading that, I actually start with similar premises and come to completely opposite conclusions~ |
| 19:38 | <@ToxicFrog> | The complaints about performance are probably valid, but irrelevant to my work; ditto the build system problems with maven and ant. |
| 19:39 | | * jerith wasn't sure what you're doing, so. |
| 19:40 | | Rhamphoryncus [rhamph@Nightstar-5697f7e2.abhsia.telus.net] has joined #code |
| 19:40 | <@ToxicFrog> | However, the complaints about the language itself read as "Scala introduces a lot of concepts Java programmers are unfamiliar with, which means the Java programmers we hire can't just sit down and start work in it" |
| 19:41 | <@ToxicFrog> | To which my response is "no shit, Java is a language for getting something that works even when most of your team don't actually know how to program, perhaps you should hire actual programmers and/or allocate a training budget" |
| 19:41 | < Eri> | They had me at operator overloading |
| 19:42 | < Eri> | They don't have that in Java? |
| 19:42 | <@ToxicFrog> | (or, more generally, "the general thrust of your complaint applies to any HLL even if not all of the specifics do, thus making it either useless or insane") |
| 19:43 | <@ToxicFrog> | Eri: nope. |
| 19:43 | <@ToxicFrog> | There are some predefined classes with overloaded operators (java.lang.String, for example), but you cannot define your own. |
| 19:44 | <@ToxicFrog> | jerith: in general, as long as performance is "good enough" - which is a very generous tolerance, for me - I care a lot more about programmer performance than I do about program performance. |
| 19:44 | < Eri> | That would be really irritating, sometimes |
| 19:45 | <@ToxicFrog> | Yeah, this would run a lot faster written in Java, or C, or Go. But no-one will notice, and in the meantime I'd still be working on the SFS parser. |
| 19:45 | <@ToxicFrog> | (and I wouldn't actually be enjoying the process of writing it, either) |
| 19:45 | <@ToxicFrog> | Eri: working in Java is irritating full stop, IMO. |
| 19:46 | <@jerith> | ToxicFrog: I thought the language problems were mostly about interfacing to existing Java code, or having to write convoluted Scala because of the performance stuff. |
| 19:46 | <@jerith> | Then again, I read it a while back. |
| 19:47 | < celticminstrel> | Didn't they add very limited operator overloading in Java 7? Or is that one of the things that got deferred to Java 8? |
| 19:47 | <@ToxicFrog> | jerith: I'm specifically addressing "But it's also a very |
| 19:47 | <@ToxicFrog> | complex language. The number of concepts I had to explain to new members of our |
| 19:47 | <@ToxicFrog> | team for even the simplest usage of a collection was surprising: implicit |
| 19:47 | <@ToxicFrog> | parameters, builder typeclasses, "operator overloading", return type inference, |
| 19:47 | <@ToxicFrog> | etc. etc." |
| 19:47 | <@jerith> | Ah. |
| 19:47 | <@ToxicFrog> | [...] "If we take even the strongest of JVM engineers and rush them into |
| 19:47 | <@ToxicFrog> | writing Scala, we increase our maintenance burden with their funky code; if we |
| 19:47 | <@ToxicFrog> | invest heavily in teaching new hires Scala they won't be writing production code |
| 19:47 | <@ToxicFrog> | for a while, increasing our time-to-market. Contrast this with the default for |
| 19:47 | <@ToxicFrog> | the JVM ecosystem: if new hires write Java, they're productive as soon as we can |
| 19:47 | <@ToxicFrog> | get them a keyboard." |
| 19:48 | < celticminstrel> | Or maybe I'm just imagining things. It happens. |
| 19:49 | <@ToxicFrog> | Now, they also complain that you have to be very careful and non-idiomatic to get high throughput, and that the performance characteristics of some of the collections in particular are surprisingly bad; this is a legitimate problem if you're writing high-performance code, so I don't really see a reason to rebut that beyond "I'm not writing high-performance code, so this complaint, while valid, does not apply to me". |
| 19:50 | <@jerith> | ToxicFrog: Cool. :-) |
| 19:50 | <@ToxicFrog> | Ditto "building a mixed scala/java project without using an IDE designed for that is a pain" - I don't mix in Java code. |
| 19:51 | <@ToxicFrog> | (interfacing to existing Java libraries - which I do have cause to do - is dead easy) |
| 19:55 | < Namegduf> | All makes sense. |
| 19:55 | < Namegduf> | Java's explicitly designed to help mediocre programmers produce working systems (presuming some competent design) |
| 19:56 | < Namegduf> | The small units of isolation, the verbosity... |
| 19:56 | < Namegduf> | It's not a disadvantage of anything else so much as a legitimate advantage of Java if you really want to go that route. I'd just never want to work for them. |
| 20:13 | | Kindamoody is now known as Kindamoody[zZz] |
| 20:51 | <&McMartin> | "If we take even the strongest of JVM engineers and rush them into writing Scala..." |
| 20:51 | <&McMartin> | I'm pretty skeptical of this claim for two reasons |
| 20:52 | <&McMartin> | (1) A "JVM engineer" should be someone who writes JVMs, a task rarely done in Java - and the two teams I know who did this (one open-source, one for IBM) would be able to write Scala just fine, thanks, since they know things that aren't Java... |
| 20:52 | <&McMartin> | (2) As noted, there's a pretty solid skill grade *within* Java. |
| 20:53 | <&McMartin> | Any programmer you take on that only knows one language - or only knows a set of languages that are basically syntactic sugar for one another (say, C and Pascal) - is going to be a terrible programmer when you hand them a multiparadigm language. |
| 20:54 | <@ToxicFrog> | Yeah, I'm assuming that by "strongest of JVM engineers" he means "the strongest of our Java programmers", for the sake of having something sensible to rebut~ |
| 20:54 | <&McMartin> | The fact that they're calling Java code grinders "JVM engineers" is more revealing about *them* |
| 20:55 | <&McMartin> | I'm willing to bet that the guys writing Tomcat or JBoss are pretty solid with other HLLs too~ |
| 21:01 | < celticminstrel> | ...C and Pascal are syntactic sugar for each other? |
| 21:02 | <@jerith> | Modern Pascals, sure. |
| 21:02 | <&McMartin> | C and Delphi, less so, but C and production Pascals might as well be |
| 21:02 | <&McMartin> | There are maybe five concepts one has the other doesn't. |
| 21:02 | <@jerith> | Original Pascal had no pointers. |
| 21:02 | <&McMartin> | Standard Pascal has pointers, though disallows arithmetic on them; all actual implementations I've used allow direct assignments of int_ptr_t |
| 21:02 | <@jerith> | http://www.lysator.liu.se/c/bwk-on-pascal.html |
| 21:02 | <&McMartin> | Or its equivalent. |
| 21:02 | < celticminstrel> | I guess I never encountered original Pascal. |
| 21:03 | <&McMartin> | That's because it was designed as a teaching language, less suited for actual use than BASIC |
| 21:03 | <&McMartin> | BASIC was designed so beginning programmers could write programs that did things they needed done. |
| 21:03 | <&McMartin> | Pascal was designed to teach you recursion and linked lists. |
| 21:04 | < celticminstrel> | This reminds me, there was a game I wanted to try upgrading that uses an old Symantec/THINK GUI library. |
| 21:05 | < celticminstrel> | ...windows code apparently was Delphi. |
| 21:05 | <&McMartin> | Delphi's still very much in use. |
| 21:05 | < celticminstrel> | Other side is the Mac code. |
| 21:05 | <&McMartin> | Hell, Delphi is where C# stole most of its good ideas~ |
| 21:06 | < celticminstrel> | But that GUI library seems to be dead and buried. |
| 21:06 | <@jerith> | Was Delphi resurrected? |
| 21:06 | <&McMartin> | jerith: I know that the Game Maker programs are written in Delphi, and I vaguely recall that Delphi has some equivalent to Mono these days too |
| 21:06 | <&McMartin> | Tyrian was written in pre-Delphi Turbo Pascal |
| 21:07 | <@jerith> | I know it had been discontinued at some point, but then someon ebought the trademark and applied it to some PHP thing. |
| 21:07 | <&McMartin> | Later Turbo Pascals, Delphi, and C# all had the same designers, IIRC. |
| 21:07 | | * jerith reinvented OOP in Turbo Pascal. Shortly before discovering that it already had OOP features. |
| 21:07 | < celticminstrel> | Also doesn't help that comments and some variable names are in... I'm not sure, Dutch or something? |
| 21:12 | <@Alek> | i'm just wondering when they'll start writing programs modular enough they can update while still running. XD |
| 21:12 | | * McMartin introduces Alek to Java-based middleware, which is actually pretty good at that. |
| 21:12 | <&McMartin> | Having the class loader/unloader be part of the core library lets you do some pretty amazing things |
| 21:13 | <&McMartin> | If you *actually are* a JVM engineer instead of being called one out of pity. |
| 21:13 | <&McMartin> | Tomcat lets you load and unload applications without restarting the server, I think. That's probably the simplest case of hot update. |
| 21:13 | <&McMartin> | Since they all run in the same process space. |
| 21:14 | <@ToxicFrog> | Alek: 25 years ago, give or take? |
| 21:14 | <@ToxicFrog> | At least? |
| 21:14 | <&McMartin> | Yeah, you could also do it with overlays. |
| 21:14 | <@ToxicFrog> | I was thinking more "Erlang had this as a core feature in the 80s" |
| 21:15 | <@ToxicFrog> | $5 says that there's a Lisp dialect that predates it which you could roll your own hotswap, though~ |
| 21:16 | <&McMartin> | no bet~ |
| 21:16 | <@Alek> | ?_? |
| 21:17 | <@jerith> | You have to be very careful with that, though. |
| 21:17 | <@jerith> | It's easy to live-update to a version that misunderstands your memory structures and then barfs all over the heap. |
| 21:20 | < Rhamphoryncus> | Theoretically python can be made to unload a module and load a new one at runtime. That creates a whole new set of classes though, rather than replacing the old ones |
| 21:22 | <@jerith> | You can't do it reliably, though. |
| 21:22 | < Rhamphoryncus> | Define reliably |
| 21:23 | <@jerith> | I was under the impression that reload() didn't necessarily catch everything. |
| 21:23 | < Rhamphoryncus> | I'm not talking about reload() :) |
| 21:23 | <@jerith> | Ah. |
| 21:23 | < Rhamphoryncus> | But what I mean by a new set of classes is you essentially have two modules. It doesn't update any old objects to point to new classes |
| 21:24 | <@jerith> | Yeah. |
| 21:24 | < Rhamphoryncus> | reload() reuses the module namespace, but that's it |
| 21:25 | < Rhamphoryncus> | Underneath though, if you delete all references to a module, including objects instantiated from classes within it, it can be deleted |
| 21:25 | < Rhamphoryncus> | But.. from a language design point of view I think it's a silly idea :) |
| 21:26 | < Rhamphoryncus> | If you want to hot-swap logic then you really need a database mentality, where all the data is persistent across processes anyway |
| 21:31 | <@ToxicFrog> | The Erlang idiom is to pass main a new main function that it tail calls, which can if necessary be composed with a converter. |
| 21:33 | < Rhamphoryncus> | Yeah, but it's essentially the same thing. A database mentality. |
| 21:33 | < Rhamphoryncus> | Erlang just doesn't have any alternative for normal programming. |
| 21:33 | <&McMartin> | Actually, now that I think about it |
| 21:33 | <&McMartin> | Smalltalk gives you no choice about doing this classically |
| 21:33 | <&McMartin> | It didn't even have concepts of programs |
| 21:33 | <&McMartin> | Just differently-patched environments. |
| 21:34 | < Rhamphoryncus> | heh |
| 21:34 | <&McMartin> | I hear they've since made some concessions to the entire rest of the universe, at least in some dialects. |
| 21:34 | | * McMartin goes off to eat lunch, and then to become a Metroid. |
| 21:34 | <&McMartin> | By which I mean "learn something about Windows 8 programming" =( |
| 21:35 | < Eri> | Ah |
| 21:35 | < Eri> | I was about to ask about that term |
| 21:35 | <&McMartin> | Really, a Metroid should be a fork bomb or other resource devourer that runs in Metro >_> |
| 21:35 | <&McMartin> | I swear I will find some way to lever the term in >_> |
| 21:38 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 21:51 | | eckse [eckse@Nightstar-44ca551b.dsl.sentex.ca] has joined #code |
| 21:52 | | mode/#code [+o eckse] by ChanServ |
| 22:18 | | Vash [Vash@Nightstar-cdeba41f.wlfrct.sbcglobal.net] has joined #code |
| 22:18 | | mode/#code [+o Vash] by ChanServ |
| 22:50 | | himi [fow035@D741F1.243F35.CADC30.81D435] has joined #code |
| 22:50 | | mode/#code [+o himi] by ChanServ |
| 22:56 | | maoranma [maoranma@Nightstar-d6cc5170.pools.spcsdns.net] has joined #code |
| 23:18 | <&McMartin> | Meh |
| 23:18 | <&McMartin> | On the one hand, they're trying to simplify the application API, which is probably a good move over all. |
| 23:19 | <&McMartin> | On the other hand, this means XAML is now basically mandatory. |
| 23:20 | <@ToxicFrog> | XAML? |
| 23:24 | < maoranma> | Blah, Terraria dev just up and quit |
| 23:24 | < maoranma> | not so much *just*, that is to say, I've been wrapped up in other things |
| 23:24 | <&McMartin> | TF: XAML is basically MS's version of Glade or Qt's UI XML. |
| 23:24 | <&McMartin> | Except, being MS, it's an ugly mutation of XML =P |
| 23:25 | < maoranma> | But I was like "oh, school break time, let's go check up on Terraria...oh, it's dead, great" |
| 23:25 | <&McMartin> | Hilariously, if you use the new JS bindings to the Windows API, you can replace XAML with a subset of HTML and CSS~ |
| 23:41 | <&McMartin> | Mmm. Bleh. |
| 23:41 | <&McMartin> | This also means they're dicking over Mono, at least for looking native. |
| 23:41 | <&McMartin> | I think. |
| 23:41 | <&McMartin> | It's hard to tell, because I associate XAML with WPF, which I know Mono doesn't do, but it's also apparently tied to Silverlight, which nobody does^W^WMono does support. |
| 23:45 | < celticminstrel> | ...what's this about Terraria? |
| 23:46 | <~Vornicus> | the Terraria devs decided that the game was complete. |
| 23:46 | <~Vornicus> | I can't particularly argue with them on that point |
| 23:46 | < celticminstrel> | Oh. |
| 23:46 | < celticminstrel> | Yeah. <_< |
| 23:47 | <@ToxicFrog> | I can, since they have historically promised features (like, say, a modding API that doesn't rely on decompiling the game) which are still no in. |
| 23:47 | < celticminstrel> | Oh. |
| 23:47 | < celticminstrel> | Meh. |
| 23:55 | <~Vornicus> | That is pretty meh there though |
| --- Log closed Mon Mar 05 00:00:29 2012 |