The Journey Outside, Gor, and Functional Programming

Fri, 11/29/2013 - 12:01 -- BlueWinds

Let's go in reverse order, actually. Check under the fold for the porny-bits.

Functional Programming: I finally "got it" earlier today. Watching a video, I finally grasped why people care - not in some abstract "it's purer" sense, but in a "I can write programs better" sense.

Basically what I realized was that I'd implemented, haltingly and uncertainly, certain aspects of functional programming in the game, and that those parts were both elegant and comprehensible at the same time. If any backers care about code, open up game/people.js, line 63. Action.choosePerson is, in a hacky sort of way, curried Game.checkConditions.

In fact, the whole checkConditions mess (it's by far the hairiest part of the game engine - see /engine/modules/classes/conditions.js) could be rewritten much more elegantly using functional programming. I doubt I'll do that, at least not immediately, but it finally clicked.

Pure functional programmers are still crazy. :P Mutable state is the way both the real world and actual computers operate.

 


Gor. Because it's somewhat famous, I sat down and read Tarnsman of Gor. As you might have guessed from my previous posts on feminism, I was not particularly impressed. It's not the women-are-sexual-objects bit I disliked - that's a perfectly fine kinky fantasy. It's the women-aren't-people part I found distasteful.

The love interest was as flat and one-dimensional as any character I've ever read, and while the male characters weren't particularly deep, they at least had traits beyond hair color / country of birth / current owner. Enslave the women in your fantasy world if you choose, but recognize that they retain minds and inner lives fully as rich and complex as the men around them (also consider if you really need gender-specific slavery, rather than generalized).

 


Related to that, I wanted to share a link to The Journey Outside. It's not dissimilar to Gor in the sorts of fantasies it portrays (brutal male power, servile/enslaved women, etc.), but it is very well written. If you enjoy that sort of thing, take a look. You can be male or female (via very quick and early gender transformation), depending on which side of the coin you prefer to explore.

Still a work in progress - every path cuts off with a promise of more to come soon, but what is there is great (if somewhat more brutal than what I usually write). Best wishes to the author as she goes through a difficult time in her life.

Comments

The_Ripped on

That was pretty much my read of Gor, too. Any opinion on people trying to do something Gorian as a full time life style? (with the standard disclaimer about every person/couple are different, of course)

Thanks for the Journey Outside link. It's a much better written piece! Not really my thing, but I can appreciate the ability of the author, and its a pleasure for me to read good prose. Bookmarked!

BlueWinds on

I'll be blunt: Gorean philosophy is sick, and people that identify with it need help.

Any time a philosophy begins to say "all people X are / should be Y", you're on dangerous ground. A woman can choose to be submissive, but it's no more "natural" than quesadillas or airplanes.

Healthy D/s relationships (and relationships in general, in fact) are based on mutual respect and on choice. Goreanism is mysogony, plain and simple.

The_Ripped on

Thank you for your bluntness :)

HypnoKitten on

Eh, Gorean isn't my thing, but I know some women and men who get turned on by that and like to participate.  Something about that whole 'Me Tarzan / Conan, you jane' thing.  At the end of the day all submission is conscent (there is police for any other form), even Gor, RACK, and 24/7 M/s relationships.  Goreans are fine as long as they keep it within their own structure, just like Old Guard - have your play, treat each other by whatever rules you've all agreed to, but if you try to order My sub around without my permission we are going to have problems.  Not like I or anyone else in the lifestyle can throw stones given how we come off to people who are not in it when they find out.  Besides, at least its not Fifty Shades or Sleeping Beauty ;)

Their consensual kink is fine even if it is not my kink

BlueWinds on

That is the difference between Gorean philosophy and a Gorean relationship. Apologies if I didn't make that clear enough: I only object to thinking that the Jane/Tarzan thing is either a truth about the world, or a moral imperative, which is what "philosophy" implies.

If you aren't proclaiming something as either morally correct or factually correct, then you aren't talking about a philosophy. I have no problem with a Gorean lifestyle.

(Actually I do have a little bit of a problem with it, but only a small one, since I consider Nationalism one of the four diseases of the modern mind, along with Racism, Sexism and Religion)

HypnoKitten on

Functional programming as in machine programming, where there is the one giant running function?  That was fun, especially in Lua, I think I even still remember some of my code for a mini-game I did in that.. it went something like this (((( (( (((((((( (((( ... and then there was more stuff after that but you get the gist. 

If you are having fun with that you should check out a book on design patterns sometime, that's what I'm getting into now and everyone at my job totally swears by - to the point where they keep refactoring all my code to fit it into those patterns (annoying, but can't argue that it always seems to improve it in some way)

BlueWinds on

Design patterns are failures of your programming language. I'm going to guess you use/deal with either Java or PHP? Interesting fact: Javascript design patterns are completely different, and far fewer than those in Java, because the language transparently handles things that you need "patterns" for in Java.

Functional programming is something a bit different than what you're talking about:

"In computer science, functional programming is a programming paradigm, a style of building the structure and elements of computer programs, that treats computation as the evaluation of mathematical functions and avoids state and mutable data. Functional programming emphasizes functions that produce results that depend only on their inputs and not on the program state - i.e. pure mathematical functions."

That's a rather dry definition, so I'll try and rephrase it:

Functional Programming is the idea that functions should return their results, rather than update values. You should be able to tell what a function does by looking only at the function - it should rely on no external information (Is the user initialized yet? What is this global variable set to? etc. are all bad questions - you have to understand where the program is right now to know how a function will behave).

Here's a link to the talk that finally made it click for me. Results/usefulness/not-dieing-of-boredom not guaranteed for anyone else.

HypnoKitten on

Thank you so much for the link, I had been very curious about how that style of programming really works out in the wild! As for design patterns, very interesting theory. At work we are currently coding applets in java, deep code in C++, and validation in c#. I am not as big an apostle of design patterns as some of the 10+ year engineers, but the main reasons they like them seems to be (a) quick readability - if we have to use a library from outside the company or our team then we know what a generator does, how it does it, and its shortcomings without having to read the code, and (b) consistency - if a wheel works we leave it alone and just focus on the kind of axle we attach it to, freeing up the mind to deal with the new design problems. For projects that have to be maintained for years and across large teams consistency is a but of a priority (though not necessarily as immediately optimal as what a more agile project could produce. Guess its just a matter of perspective, I'm still sipping at the koolaid and havent drank enough to say if I like it our not.

BlueWinds on

Let me go with a more specific example: the Factory pattern, used to create a database connection. I'm going to talk about PHP, since that's where I'm more comfortable, but it should apply pretty well to Java as well.

In PHP, I'd say "$connection = DBConnectionFactory();". DBConnFactory has some logic that looks at a configuration file, decides if I'm using MySQL or Postrges, opens a connection and returns a MySQLConnection or a PostgreConnection object.

In Javascript, I'd call "var connection = new DBConnection();". DBConnection is either MySQLConnection or PostgreSQLConnection based on the config file when the program loaded.

I still have the logic to look at the configuration file and decide which one to load, but the syntax is much more natural: "if (db == 'mysql') { var DBConnection = MySQLConnection; }" (this would be done during initialization, before any other part of the program needs a DB connection). There's no need for the factory pattern because in Javascript, classes are first class variables - that is, they can be passed around, renamed, assigned to local or global variables at-will just like a string or an integer.

Or, to phrase it a different way, the factory pattern is a way to emulate a feature from a higher level language. :D

Anonymous (not verified) on

That anyone programming in Javascript could have an aversion to FP always struck me as odd, considering Javascript's a lot more functional oriented than most languages. Anyway, my mind most recently got blown by hearing about persistent data structures for the first time. That shit is nuts.
http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey

Clojure just sounds awe-inspiring and terrifying to me now.

BlueWinds on

I'm still watching the talk, but it would be a lot easier to follow if I could see the slides. At 19:00, I think he made a fundimental mistake, repeated at 38:00:

There is no such thing as "co-located" or "concurrent" - there are only various levels of distributed. His examples of how variables fail as statu are all examples of when the assumption of co-location fails. They don't work under multi-threading because multithreading destroys the illusion of co-location within a single machine.

I think this mistake actually leads to many of the problems he describes in Clojure - it uses locks, MVCC, does a bunch of nasty stuff in the background to try and maintain the illusion of co-location for his references in a multi-threaded system.

Coordinated (as he defines it) change is expensive, finicky, fragile.