alaricsp

I set my colleages a challenge: write porn using only prime words.

"WIDEST WOMB WOMAN WATCHED PET PERVERT WHIP BLINDFOLDED YIDDISH BITCH"

"BAREBACKED BARD RUTTED BLINDFOLDED BITCH"

"BAREBACKED BARD PULVERIZED TRUCKMAN RUTTED TORRID"

"YARDMAN WHIP UNUSED WHELP, TROLLOP SUSPECTED SILKEN RUNT. PUTOUT, PARTED, LAIN. EVALUATED FETISH,EXPENDED. DISINTEREST."

Some highlights:

"Anyone can break up a showing of an enemy propaganda film by putting two or three dozen large moths in a paper bag. Take the bag to the movies with you, put it on the floor in an empty section of the theater as you go in and leave it open. The mothts will fly out and climb into the projector beam, so that the film will be obscured by fluttering shadows"

"When possible, refer all matters to committees, for further study and consideration. Attempt to make the committees as large as large as possible - never less than five"

"Cry and sob hysterically at every occasion, especially when confronted by government clerks"

What about OneIS? It's hosted, which isn't for everyone, but it does mean one less thing to worry about. I've used it as an intranet, and it's easy to pick up: http://www.oneis.co.uk/

I couldn't watch it all the way through. It made me feel sick.

Oooh, beautiful...

That rogue-like cave generation algorithm isn't the kind of terrain I'm after, but is nonetheless quite awesome in its results. I'm now wondering if I can find an excuse to involve caverns in my game ;-)

Alas, no :-)

I'd love to find the book again... I bet it's out of print, though. It had lots of detail on modelling damage to tanks, and creating terrain, and working out things like line-of-sight in complex worlds, and I think some basic AI, but had nothing to say about snazzy graphics whatsoever; I think it made some reference to vector displays or something like that ;-)

True, I glossed over my previous research; I didn't think it'd interest people, but you're right, it's wise to show some evidence of your previous attempts before asking for tips...

My googling always just found me more and more ways of generating the height-field data - it's the roads and so on that interest me. I tried tinkering with weighted random walks (eg, given the desire to continue a road from a given point, pick an adjoining cell with a weighting that prioritises having the same altitude and being closest to continuing the existing direction), but this fails to capture things like the fact that roads tend to run along valleys and mountain passes - the hard part, it seems, is in choosing initial points. Likewise, a river can be continued by finding the most downhill adjacent cell, until you find a minimum then starting a flood-fill algorithm to create a lake, until you reach a boundary pixel that "goes downhill", whereupon you can start a new river going down from there - but this fails to realistically account for the widths of rivers (you can just make the river wider as you go down, and sum the width of rivers that meet, but that simple model looks wrong: real rivers are deeper when in narrow canyons and the like).

Perhaps I've just been unlucky ;-) This was Allied Telesyn kit IIRC.

But this is by the by! Rather than a damning indictment of STP, my real point was that having to configure all the layers of a network - physical cabling, VLANs, routing, firewalling - independently involves a load of effort that I'm not convinced is necessary. It'd be lovely to have routing functions occur in every switch, automatically routing between VLANs that are present together on the switch, and then doing MPLS-esque fast switching of frames across the network to destination switches if not - merging the switching and routing layers of the stack would just simplify things; why should we need the complex techniques we have to make networks resilient to failure?

Sorry about the bad grammar :-)

Ok, the deal with STP and VLANs is thus: STP works at the level of the actual Ethernet cables in the system, rather than the VLANs.

Imagine you have four switches, A B C and D. Say vlan 1 exists on A and B; vlan 2 on C and D, and vlan 3 on all four, and physical cables (carrying tagged VLANs) run from A-B (vlans 1 and 3), A-C (just vlan 3), B-D (just vlan 3), and C-D (vlans 2 and 3); eg, they're in a square. And you enable STP.

STP will cause the switches (ignoring VLANs) to choose one of those four cables to disable, to remove the cycle in the network. It's as likely to disable the A-B or C-D cables, which will then split vlan 1 or 3 in half.

The solution is to make all VLANs present on all switches and (tagged) on all inter-switch trunks, so that any cable can be disabled and connectivity continues; there are extensions to STP that are aware of VLANs (such as the Cisco proprietary per-VLAN spanning tree); there's the recent (2003?) Multiple Spanning Tree Protocol (MSTP), but that's not supported by the switches I've been playing with, so useless to me at least :-)

This issue is dear to my heart, too, as a hobbyist programming language designer myself ;-)

I've never seen it as a route to income in itself - but it can do so indirectly. My project, ARGON (http://www.argon.org.uk/) is all about reinventing the platform we build software on - OS, programming language, libraries, file system, network protocol - purely because the current technologies we use are hampered by backward compatibility and poorly integrated; I think it'd be a good thing for the world to start again from scratch (and deal with compatibility at a higher level).

So I've thought more about how I might possibly make my hobby pay for itself. I think that an entire platform might well be successful as an embedded platform, as there's much less motivation for compatibility and a familiar programming environment in that market. In the workstation and server worlds, however, I think such a platform pretty much has to be open source, or it'll never be adopted by hackers who want something to play with. Then the usual open-source tricks will apply: selling boxed sets with manuals and 'enterprise tools' in, support contracts, commercial redistribution licenses, etc.

Getting rich by writing a book and general fame/glory leading to speaking engagements, however, is right out ;-)

The best introduction to real computer science that I know is the book "Structure and Interpretation of Computer Programs". It teaches programming in terms of Lisp, but don't be put off - it's just because Lisp is a good vehicle for exploring different approaches. The lessons therein have stuck with me no matter what language I'm using.

Beyond that sort of thing, you need to specialise in the kind of areas you want to work in - if you want to program to earn money, then learning SQL, HTML, and web app development in your favourite platform is a good idea. If you go for the Unix route, I'd recommend you learn Python before Perl/PHP, but then learn the latter two because there's money in it. If you go the Microsoft route, I'm sure there's plenty of good books on C# and ASP.net. Java's pretty useful, too.

It's a good idea to learn C, not so much to learn the language itself as to learn about the processor's memory model, which C somewhat ruthlessly exposes you to; if you master C, you'll indirectly learn how software performance works, in ways that'll indirectly help you write faster code in higher-level languages. And, of course, C is useful in its own right if you want to get into embedded, systems, or games programming.

Personally, I think C++ isn't a good language to get involved in; if you want to anyway, either because you disagree with me or because you're after a job doing C++, make sure you've read Structure and Interpretation of Computer Programs, played with C, and tried at least one object-oriented language first; C++ is complex, and having a strong background in the basics behind it will help you a lot; trying to dive straight in might lead to a rather painful learning experience.

Perhaps most importantly, find a programming project you are excited about, and do it. When you're done, you'll have realised you'll have made lots of mistakes - but you'll never make those mistakes again, and the next project you do (perhaps one you'll be paid for) will be a lot better. Practice makes perfect! And have fun!

Now I'm wondering if they count as design patterns or not...

Other than JIT recompilation in VMs of various kinds (which is only indirectly related), no, not that I know of...

That is indeed a most potent collection of detailed arguments!

Now, let's just wait for my colleague to start ribbing me for keeping our project written in C again... ;-)

I think it's a knee-jerk reaction to how the more zealotous members of the design patterns community have had knee-jerk reactions to people questioning the scripture status of the Design Patterns book.

Once a bunch of people get religious, another bunch of people will crop up to get religious against them in turn.

I think design patterns are useful and valid; but I think they should be evaluated individually within the context of a given programming language, not necessarily considered global.

Yes... sort of.

SRFI-4 (http://srfi.schemers.org/srfi-4/srfi-4.html) provides a standard interface for dealing with 'homogenous vectors' (eg, arrays of unboxed integers or floats), which is great for shuffling bytes.

For bits, there's the usual bitwise-or and all that.

However, both could be improved somewhat; what the Factor folks have done with their struct arrays is IMHO superier.

Yeah! Synthesis is quite excellent. I've been interested in exploring using the FORTH model of easily-accessible-runtime-compiler in that sort of context...

I've not seen anything like the dynamic-dispatch optimisations the Self team came up with in the 1990s done in C++, nor problem-domain optimisations expressed as macros as is often done in Lisps, nor the aggressive constant-propagation of closures and their eventual inlining that Factor does.

Perhaps some of them could be applied, but a highly complicated base language with extensive mutation semantics (including pointer aliasing) probably mean they'll be so limited in their applicable scope, and so difficult to implement, that it's not an attractive activity for C++ compiler writers...

FWIW, I'm working in C for my day job (and resisting calls to move up to C++), as my day job involves shuffling bytes around rather than particularly complex code; it's ~20KLOC. Then we build the tools to manage it in Python with a bit of shell scripting here and there. However, I code Scheme in my spare time, and would do the lot in that if I didn't then have to justify training new developers in Scheme! C's the right tradeoff for commercially developing a high-performance database kernel, IMHO.

I've done plenty of C++ in past jobs... which is why my day job is in C :-)

That day may not be too far off... I hope ;-)

Nowt wrong with skimming a surface, sometimes you can get more impact with a one-page summary than a long essay :-)

I agree with some points and disagree with others here.

I think I see three underlying problems:

1) Mutable state has consequences, and OO happens to highlight some of them

2) The author would probably prefer generic functions, the "other way" to do OO IMHO, as they give you polymorphism while leaving the encapsulation issue to other mechansism, such as modules, as they mention.

3) OO examples are just terrible. Who on Earth writes a Bike class? I've seen whole arguments about whether Car should inherit from Vehicle and all this rubbish, all because people are taking vague and non-realistic examples, then getting tangled when they try and realise them. This is a road sure to lead to meaningless discussions and confusion on the parts of students. Instead, let's think about real software objects, such as files, windows, threads, and connections; and problem-domain objects such as users, orders and so on (as long as one is gently aware of the subtle issue that a 'user' is a person while the 'user' in the system is an object that models a person). OO can work well for modelling such objects.

Nice!

I wonder how well the moving contacts to bring the power from the live and neutral to the power cable will survive, though - they may become worn and intermittent with time.

Do we really need the fold-out wings? Could we not just rotate the live and neutral pins into place, then plug it in? Or do the standards require a certain outline to keep fingers from the plugging-in bits?

Hmmm, IPSec. I've always found IPSec to have a nice feature list, but to be implemented in a painful way when it comes to working with NATs!

A nice feature of n2n is that, when you want to send to a node that's behind NAT, the supernode can be asked to relay the packet in for you over the existing session from that node to the supernode.

I run an edge node on my laptop, and whenever I come online, its attempts to send keepalives to the supernode suddenly get through, and the supernode re-registers me in my new location; and if I move from behind NAT to out in the open or back, everything adjusts correctly and automatically.

IPSec handles the encryption side, at the cost of tripping over firewalls and NATs more than n2n's straight UDP, but it doesn't really cover the IP mobility side...

Quite possibly! I need to go and re-learn Haskell's typeclasses - I found them quite elegant when I looked at them years ago, but have forgotten it all since :-( Ah, the penalties of age...