Re: [FRIAM] speculative Q
Glen writes: But, again, you're being very binary. Practically, each member will be a member in part because they're aligned ideologically, in part because they contribute to the mission, and in part for promotional/egotistical reasons. Those sets aren't disjoint, regardless of what the participants think about themselves. Sure, ideological and technical preferences and selfish motivators can be correlated and causality can be hard to pin down. I'm claiming in my case low correlation, but not no correlation. Suppose individual preferences are represented by universal bit strings. The bit strings can encode floating point numbers or yes/no, or triples to say yes/no/don't care, or programs or whatever.Then there are other bit strings representing something global like Hackage, or the Library of Congress, a software company's intellectual property, or what's on Food Network.Couple all the individual preferences to the global bit strings as an Ising system with random weights. A clever marketing department (or a politician) figures out what bits matter and directs resources to select/change their bits to change frustration in the system to make their bits more crucial -- to be towards the center of the network.They can only have so many bits, so they have to choose the right ones.User-facing tools are an instance of those bits that happen to be strongly correlated to a lot of other individuals' bits. It's arbitrary what the semantics are for the bits. It's just history and a popularity contest. But investment will occur in controlling the state of an evolving set of owned bits so as to maximize influence the evolution of other bits. Meanwhile, preference bits of an individual have broader connectivity to other preferences (and their own) and global state bits. Different communities would be seen from the user-facing software vendor as isolated graphs given some minimum cutoff for what is a connection, and their cutoff would be relatively h igh compared to a free software developer. My claim is that free software developers, and GPL developers in particular, have a preference for exploring this broader type of connectivity, and are especially interested in the frustration of the interconnections amongst the global bits than in the relationship between individual preference bits or the relationship between the individual and global bits. Any slice or subset of bits might not be interesting by itself, but the concept of growing and compressing the totality of global bits is a core value. If FOO and BAR represent different kinds of strong technical preferences then that could explain why cooperation around multi-aspect software is harder. There's too much to fight about. But then consider loose cooperative efforts like Hackage, or CTAN, CPAN, CRAN, etc. each representing millions of lines of code. To say these aren't multi-aspect is absurd. They are very, very high dimensional, interdependent, and open-ended. Yes, but it would be a stretch to think of things like CPAN as user-facing tools. They are more middle-ware or back-end. At best, you can only think of the front-end script that accesses the databases as the front-end part. And that's certainly not multi-aspect. That /usr/bin/cpan script has a very narrow focus in handling the packages. I don't mean the script or the tool to manage the collection, I mean the collection. These collective efforts are more like federations than applications. And federations are methodological approaches to handling large sets of opinionated members ... like the EU or the US. They are explicitly _designed_ to handle the extremists and their _splat_ of opinions on everything under the sun, because they allow even the extremists a way to focus in on the minimal agreement required to cooperate. This goes back to the Cathedral vs. the Bazaar. Large commercial organizations aren't automatically cathedrals just because they assert a mission. A plan needs to be identified and socialized over and over. That negotiation acts more like a Bazaar -- figuring who can do what, who they can work with, and how to reward and control them. A small organization of like-minded people can take the cathedral approach straight away but will be limited by available manpower. (Assuming there is in fact a distinction between conceptual work and detail work at all.) Large hierarchical organizations of the kind that make most user-facing software have some small group of people making executive decisions. They are just people though and not _that_ much better than the people on the leaves of the tree. So they cannot take on fundamentally _harder_ problems, they can only keep throwing human resources at it, provided they can keep their story straight about what problem they are solving. A hard problem is one that takes more intelligence to solve and that will be limited
Re: [FRIAM] speculative Q
On 07/17/2015 09:44 PM, Russell Standish wrote: I do know about emacs. It survives, because it is bloody good at being a text editor, particular for programming. I suppose vi is the same - I've seen some people make vi stand up and sing, but for me, its behaviour when interacting with vt100 style terminals has always put me off. I agree (that both emacs and vi) are good text editors. But emacs, at least, is much more than just a text editor. I've used emacs as a window manager, spreadsheet, IDE, file manager, database, etc. It definitely has multiple and diverse aspects. But Marcus is right that it doesn't field the morons (or pander to users). The same is perhaps even more true of vi. You have to be a particular type of person to use the tool. But I think I disagree slightly with Marcus. Although it doesn't _pander_ to users, it provides a very navigable (damn near user-friendly, actually) exception system. You don't have to be a rocket scientist to figure out what went wrong when you do something stupid. You just have to be a little persistent. Such an exception system is always necessary for a tool with such a diverse set of functions. And that is in contrast to the sharply focused tools that dominate open source software. Mess up the configuration of, say, postfix, and you could spend a long while trying to figure out what you did wrong. So emacs is much more like libreoffice than it may seem at first glance. FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] speculative Q
On 07/17/2015 11:22 PM, Marcus Daniels wrote: My claim is that free software developers, and GPL developers in particular, have a preference for exploring this broader type of connectivity, and are especially interested in the frustration of the interconnections amongst the global bits than in the relationship between individual preference bits or the relationship between the individual and global bits. Any slice or subset of bits might not be interesting by itself, but the concept of growing and compressing the totality of global bits is a core value. OK. Yes, I agree for the most part. Free developers will usually have a more synoptic view of software and more ... cumulative (for lack of a better term) goals. But the point I was trying to make with those 3 articles still stands: that people who join communities for community's sake are not necessarily only drags on, disrupters of the system. They provide something like a dampening baffle that traps and eliminates the noise of the extremists, the purposeful missionaries. In fact, without _enough_ of that sort of middling or joiner, a project is more at risk when/if extremists fail to cohere. And I think this is true in open source projects as well as proprietary ones. A hard problem is one that takes more intelligence to solve and that will be limited by individual human ability, not just orderly communication and a command and control apparatus. I'm still not convinced. 8^) I think there are some hard problems that succumb to the wisdom of crowds and brute force ... but then again, I've spent the overwhelming majority of my career writing simulations, which are numerical solutions to problems I'm not smart enough to solve analytically. So, of course, I'd have that bias, eh? FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] speculative Q
But the point I was trying to make with those 3 articles still stands: that people who join communities for community's sake are not necessarily only drags on, disrupters of the system. They provide something like a dampening baffle that traps and eliminates the noise of the extremists, the purposeful missionaries. In fact, without _enough_ of that sort of middling or joiner, a project is more at risk when/if extremists fail to cohere. And I think this is true in open source projects as well as proprietary ones. Right, but from the missionary's point of view, the truth is out there, and if one project dies another will fill its place.. It is the truth that matters. Marcus FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
[FRIAM] How Text Editing is like Riding a Bike, was: speculative Q
Text Editing Nostagia Conflated with Bicycle Riding: I learned to ride on paper tape and punch cards... kind of like one of those toddler's early walker toys that looked like a flying saucer maybe? It had bumpers all around, a built in rattle, didn't move too fast, and the sling-like seat was easy to clean. Then I graduated to a tricycle with timesharing and line-oriented text editors... maybe one of the precursors to VI like ED or EX... it was a big step up, especially when I got onto a CRT based terminal rather than a line-printer or thermal style where there was a full record of your mistakes and lots of paper to toss or recycle after a few hours of intense editing. My paper-tape/card experience made me very thoughtful and careful about my work, but still... one could generate a lot of paper. It was interesting sometimes to have a record of your revisions (a roll of yellow paper with every line of typing and every line of replacement insert or substitute commands... especially as I typed all my creative writing papers in this mode... thought my CR teacher didn't care for the line-printer style paper I submitted on she liked it better than my lousy handwriting, and she fortunately liked the content of my work. When VI came along it was like my first Schwinn two-wheeler. The ability to go back to EX commands on demand for things like global pattern replaces was like training wheels... I could always revert to what I knew to get things done. I *still* ride my first Schwinn. My road racing friends call it a clunker bike but it gets me around. Most of you under 50 were screaming down the streets in those Plastic Big Wheels you got for Xmas that year! When Emacs came out, I wanted desperately to be a hipster and use it. By then VI had some syntax directed editing features, but for the most part, Emacs just felt like climbing on a fancy english racing bike after my comfy beach-cruiser style VI... the seat was high and hard, the handlebars were slung for aerodynamics, not comfort, and the gears were mostly just confounding... VI with syntax-coloring and brace matching, etc. was like adding a 3 speed hub to my Schwin... a little more range for low grinding hills and high speed whe! down the highway, but what do you do with those other 7 gears? And don't you dare get off the smooth pavement! I now use whatever IDE is appropriate for a project (I feel I can ride/drive pretty much anything with wheels, skis, tracks, or pontoons) but when the going gets tough, I revert to my trustly VI (Schwinn Cruiser with 3 speed hub, ape-hanger bars and well sprung fat gel seat, and extra fat knobby tires for gravel, not for speed) and my array of Unix Text processing tools like SED (cushman mini-bike) and Awk (go-cart) and PERL (high-displacement dual-sport motorcycle with a full complement of spare parts in the panniers, barkbusters on the handgrips, electric and kick start, and flat-proof tires. Really, text editing is just like riding a bike... you don't forget what that first real bike feels like, and it IS fun to wipe the dust off of it and cruise down the boardwalk ogling the young and the reckless with their toned tans, but from one old fart to the rest of you, don't forget the ape-hangers, the gel seat, and the three speed hub.Nothing beats a global pattern replace or building a chain of complex macros to get you from here to there in comfort and ease! Like Curious George, I can VI with both hands behind my back, doing a wheelie while whistling dixie even though I only dust it off once every few months or more! - Steve On 07/17/2015 09:44 PM, Russell Standish wrote: I do know about emacs. It survives, because it is bloody good at being a text editor, particular for programming. I suppose vi is the same - I've seen some people make vi stand up and sing, but for me, its behaviour when interacting with vt100 style terminals has always put me off. I agree (that both emacs and vi) are good text editors. But emacs, at least, is much more than just a text editor. I've used emacs as a window manager, spreadsheet, IDE, file manager, database, etc. It definitely has multiple and diverse aspects. But Marcus is right that it doesn't field the morons (or pander to users). The same is perhaps even more true of vi. You have to be a particular type of person to use the tool. But I think I disagree slightly with Marcus. Although it doesn't _pander_ to users, it provides a very navigable (damn near user-friendly, actually) exception system. You don't have to be a rocket scientist to figure out what went wrong when you do something stupid. You just have to be a little persistent. Such an exception system is always necessary for a tool with such a diverse set of functions. And that is in contrast to the sharply focused tools that dominate open source software. Mess up the configuration of, say, postfix, and you could
Re: [FRIAM] How Text Editing is like Riding a Bike, was: speculative Q
Steve writes: Really, text editing is just like riding a bike... you don't forget what that first real bike feels like, and it IS fun to wipe the dust off of it and cruise down the boardwalk ogling the young and the reckless with their toned tans, but from one old fart to the rest of you, don't forget the ape-hangers, the gel seat, and the three speed hub. I still have the motors skills for ed and sometimes still use it when an internet connection is slow. The motor skills amount to using regular expression ranges instead of scrolling around, and making changes with what amount to using tiny context dependent programs to make the edits. It does require one be very facile with tagged regular expressions.It's not a crazy way to program, actually. If one can't formulate the code change they want to make with code, it may well not even make sense. And programs are just grammar constrained graphs, after all. Marcus FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] [WedTech] 'Playing' Versioned Source Repositories
Look at gitk, unless you're actually looking for an animation of the tree of files and directories over time. Though tk might be a good choice for doing that, too, if Ben Bederson's Pad++ is still working. -- rec -- On Sat, Jul 18, 2015 at 8:52 PM, Arlo Barnes arlo.bar...@gmail.com wrote: So Etherpad http://etherpad.org/ (that collaborative editing web-app that was closed source, got real popular at one point, closed shop, was cloned into 'PiratePad', then the original acquired and open-sourced by Apache) has this feature called 'Timeslider', which allows one to watch the progression of the document edit-by-edit from inception to the current state. Is there a way to do this for Git (for example, through Github) or other source control softwares? Of course, instead of 'document' it would be 'repository'. -Arlo James Barnes ___ Wedtech mailing list wedt...@redfish.com http://redfish.com/mailman/listinfo/wedtech_redfish.com FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] 'Playing' Versioned Source Repositories
Magit for Emacs should come close to this. It can control git to apply patch sets, e.g. in time order. Of course, most developers will commit working code changes, not all the details of their edits. The deltas will be batch edits, not keystroke by keystroke, or line by line. But it will highlight the diffs in context. http://magit.vc/screenshotshttp://magit.vc/screenshots/ Magit! A Git Porcelain inside Emacs Magit is an Emacs interace to it Git Read more...http://magit.vc/screenshots/ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
[FRIAM] 'Playing' Versioned Source Repositories
So Etherpad http://etherpad.org/ (that collaborative editing web-app that was closed source, got real popular at one point, closed shop, was cloned into 'PiratePad', then the original acquired and open-sourced by Apache) has this feature called 'Timeslider', which allows one to watch the progression of the document edit-by-edit from inception to the current state. Is there a way to do this for Git (for example, through Github) or other source control softwares? Of course, instead of 'document' it would be 'repository'. -Arlo James Barnes FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
