That is indeed a very different market within which to work.

Quote from: Phillip;863562Ha, Java seems to me just a headache; I think code reuse is perhaps more practical within a project than across them, anyhow and OOP is often more overhead than it's worth. (I'd prefer Smalltalk if we must go all OO all the time)

The secret of Object Orient Programming isn't in code reuse but rather in implementing interfaces so objects can talk to each in standard ways. For example I write and maintain a CAD/CAM program for HVAC Ductwork. I have an object called a Fitting that interfaces with a Fitting Program that actually produces the part's geometry. I have about a 100 Fitting Programs in the software but to the Fitting Object they look the same because they all use the Fitting Program Interface.

Now the advantage over the older method of using standard function in libraries is that the if you miss implementing a function or a property it will throw a compile error and highlight exactly what went missing. While libraries generally only show up as a runtime error.

But when it comes to the traditional teaching of OOP I want to take the book and slap the author's head a few time if they start out with the example of a cat inherits from mammal which inherits from animal. I have a several hundred thousand line program and I can count the number times I have on one hand code reuse through inheritance. But I have hundreds of interfaces for various purposes. Most of the code reuse is done through traditional libraries of routines and function.

Quote from: Phillip;863562I have an old-fashioned appreciation for requirement specifications (treated as the documentation for the program I'm writing), but find that actual programming tends to turn around and go bottom up. 'Agile' to me means a good environment for experimentation: preferably an interpreted language, though nowadays a combination of editor and fast compiler can come pretty close.

Unit Testing is the way go. It have improved my productivity immensely because because most unintended bugs get caught in the automated tests. If they don't get caught just write another unit test and add it to the test library. The unit tests also serve well as a backup of the original code requirements.

The only downside that it takes a lot of time to ramp up if you have an existing project that didn't have unit testing from the get go.

Quote from: Phillip;863562I like having a small set of simple tools for building more, even if fancy pre-built libraries are also available. There's a similar deal in game rules, where one way the 'code' speaks for itself, while the other way I need to pore through documentation just to get the necessary vocabulary.

My experience with Unit Tests grew hand in hand with my appreciation of developing rules through actual play.

Quote from: BedrockBrendan;863641I wasn't around then, but compared to when I started gaming in the 80s and 90s, I think D&D, or some version of it, is now more ubiquitous. In the 90s especially I recall there being some serious alternatives to D&D and most of the people in my area seemed a lot more open to playing them.

Imaginative play where you pretend to be a character doing something fun and interesting is one of the biggest forms of entertainment on the planet Earth. However in the form of setting around a table with pen & paper and a human referee has declined from it's 80s and 90s height.

For example circa 1980 if you wanted to run and bash monsters and take their shit the only choices was Dungeons & Dragons or a similar RPG. However by 2000, you could fire up Diablo and get the same experience.

Quote from: estar;863676The secret of Object Orient Programming isn't in code reuse but rather in implementing interfaces so objects can talk to each in standard ways.

Agreed.

Quote from: estar;863676But when it comes to the traditional teaching of OOP I want to take the book and slap the author's head a few time if they start out with the example of a cat inherits from mammal which inherits from animal.

Slapping's too good for 'em.

Quote from: estar;863676Unit Testing is the way go. It have improved my productivity immensely because because most unintended bugs get caught in the automated tests. If they don't get caught just write another unit test and add it to the test library. The unit tests also serve well as a backup of the original code requirements.

Agreed 100%

Quote from: estar;863676The only downside that it takes a lot of time to ramp up if you have an existing project that didn't have unit testing from the get go.

Aarggh! Tell me about it...

Quote from: estar;863676My experience with Unit Tests grew hand in hand with my appreciation of developing rules through actual play.

Huh? Are you my long lost twin?

Quote from: estar;863676But when it comes to the traditional teaching of OOP I want to take the book and slap the author's head a few time if they start out with the example of a cat inherits from mammal which inherits from animal. I have a several hundred thousand line program and I can count the number times I have on one hand code reuse through inheritance. But I have hundreds of interfaces for various purposes. Most of the code reuse is done through traditional libraries of routines and function.

I guess it depends on the software you write. Almost everything I do is via inheritance. Basically, as I find chunks of logic that different areas have in common (methylation 450 and methylation 27 both have the same kind of probes and data that gets processed the same way) the common logic and attributes get pulled into an ancestor, which gets passed specifics (such as, the list of platform specific probes and their genomic coordinates).

So I have a root converter mixin (animal) that is inherited by the methylation mixin (mammal) and by the methylation 450 (dog) and methylation 27 (cat) classes.

Quote from: JoeNuttall;863686Huh? Are you my long lost twin?

LOL Probably not but perhaps we have similiar pressures at work. My situation is that my company deals in manufacturing metal cutting machine. Our edge is the fact we write and support our own CAD/CAM software. Since it is a vertical market focused on particular industries (like HVAC) we get bombarded with specialty request all the time for software.

So rather bitch about it, I kept with current practices and designed a few of my own to make adding features, and redesigning features very easy with our software. We have a half-dozen distinct software packages to support different machines but they all use the same set of libraries with only the two top levels different. Those levels control the looks and feel of the UI.

And this experience had a big part in shaping my attitude to using different rules to for the various campaigns I run in the Majestic Wilderlands. I just don't attach the importance that some people do to using a set of rules to set the feel of a campaign. I understand the point especially Vreeg's point about how the setting with come to fit the rules. But I designed an "interface" within my Majestic Wilderlands that allows me to slot in completely different sets of rules with minimal work. Note it minimal work not no work.

Right now the latest set of rules to get the treatment is Fantasy Age by Green Ronin. To date it has included AD&D 1st, Harnmaster, Fantasy Hero, GURPS 2nd, 3rd, and 4th editions, D&D 3.X, Runequest 2nd, Mongoose Runequest, D&D 4th, D&D 5th, Fudge/Fate*, and OD&D (which got turned into a published supplement).

*My Fudge/Fate attempt can be downloaded from here.
http://www.batintheattic.com/downloads/MajesticRealmsRPG_Fudge_Rev%2017.zip
It floundered on the fact that +1 or -1 is too much of a big deal.

Quote from: estar;863685For example circa 1980 if you wanted to run and bash monsters and take their shit the only choices was Dungeons & Dragons or a similar RPG. However by 2000, you could fire up Diablo and get the same experience.

Not even remotely the same unless you were a purely hack-n-slash player uninterested in anything but combat. Even the old SSI Gold boxes offered vastly more than Diablo. The whole "PC games offer the same experience as a real RPG!" gag has been shot down in flames since the 80s.

Quote from: Tod13;863759I guess it depends on the software you write. Almost everything I do is via inheritance.

I do all that by composition with interfaces. That is you create the animal class passing into its constructor a concrete implementation of the behaviour interface. Then you can unit test the animal class and the two behaviour classes  entirely separately.

Then you go home and fight some orcs.

Quote from: Tod13;863759I guess it depends on the software you write. Almost everything I do is via inheritance. Basically, as I find chunks of logic that different areas have in common (methylation 450 and methylation 27 both have the same kind of probes and data that gets processed the same way) the common logic and attributes get pulled into an ancestor, which gets passed specifics (such as, the list of platform specific probes and their genomic coordinates).

Sounds reasonable. The lowest levels of my software also uses inheritance as well in what I call utility classes like the standard lists that manage collections of objects. Since this involves replicating a set of standard behaviors I use inheritance.

You should look up the Design Pattern called Strategy. If you don't know what they are design patterns are like algorithims. Algorithms tell you how to use functions and data structure to do something useful. While Design Patterns tell you how to combine different objects to do something useful.

The strategy pattern is where you make a strategy object that has a standard interface. It then gets attached to the objects that need to use that particular strategy (or logic).

The advantage of this approach over is inheritance if the strategy/logic for one object out of a group changes slightly you can create a new strategy object assign it to just that object. While inheritance cascades down the chain. While inheritance allows methods (and thus the logic) to change in the child object my opinion it is not as clear as the assignment of an explicit strategy.

Then again my particular issue that I have to support my software over decades over multiple OSes and hardware generation. Some of my code dates back to 1985 when it was running on a HP Workstation using Rocky Mountain BASIC, a language designed to control and monitor science equipment. Which made it ideal for motion control of a metal cutting machine.

Quote from: Tod13;863759So I have a root converter mixin (animal) that is inherited by the methylation mixin (mammal) and by the methylation 450 (dog) and methylation 27 (cat) classes.

I wish my language (VB6/VB.NET/C#) supported mixins, that would help me with a particular class of design problems. When the problem is a variation on a common set of behaviors then inheritance may be the better fit.

Quote from: Omega;863764Not even remotely the same unless you were a purely hack-n-slash player uninterested in anything but combat. Even the old SSI Gold boxes offered vastly more than Diablo. The whole "PC games offer the same experience as a real RPG!" gag has been shot down in flames since the 80s.

Agreed. Even something as open ended as Morrowind still lacked what a p&p rpg has. The only way computers can hope to match that is by having an AI that can respond dynamically to anything you throw at it.

Quote from: JoeNuttall;863765I do all that by composition with interfaces. That is you create the animal class passing into its constructor a concrete implementation of the behaviour interface. Then you can unit test the animal class and the two behaviour classes  entirely separately.

Then you go home and fight some orcs.

LOL. Or play some orcs. "Work. Work". -Orcs

Unless your mixin (parent class) is abstract, you can still unit test it separate from the inheritors. Even if it is abstract, there are ways around that.

A more likely problem is that, you probably can't usefully unit test it separately from the inheritors, since it needs data from them to be useful. Toy data helps, but in some cases, I can't get the PhD who really understands their obtuse (to me) statistics to help me build toy data.

Quote from: Omega;863764Not even remotely the same unless you were a purely hack-n-slash player uninterested in anything but combat.

I think that's estar's point. Back in the 80s, people who wanted that generally had to use D&D for it. Nowadays, they have superior alternatives for getting that experience and so don't need D&D. Hence, some of the shrinking of the TTRPG market.

Quote from: Omega;863764Not even remotely the same unless you were a purely hack-n-slash player uninterested in anything but combat. Even the old SSI Gold boxes offered vastly more than Diablo. The whole "PC games offer the same experience as a real RPG!" gag has been shot down in flames since the 80s.

You not getting my point. You are right, tabletop is a different experience. But you miss my point that those gamers were not looking for the tabletop RPG experience in the first place.

Those gamers were looking for the experience offered by PC Games. Except it is 1980 and those computer games don't exist, hell for gamers at the they didn't imagine it could even exist.

However what they do know that circa 1980 they like to play AD&D because they get to bash monsters (or each other all day). This isn't theoretical. I seen and played with this type of gamer in my hometown in northwest Pennsylvania in the early 80s. Frankly they were a bit of a pain in the ass to those of us who wanted to get on with doing more with our characters.

Then when the computer games started hitting they started disappearing from tabletop and started playing Rogue-likes, and later Diablo for their fun.

So for them the PC Game was the better experience than tabletop RPG with all the world building and roleplaying with NPCs "bullshit" pushed to the wayside.

And why PC games became dominate is because on one hand they are more accessible in terms of time and availability and on the other hand they eventually began to look spectacular.

Quote from: estar;863685Imaginative play where you pretend to be a character doing something fun and interesting is one of the biggest forms of entertainment on the planet Earth. However in the form of setting around a table with pen & paper and a human referee has declined from it's 80s and 90s height.

For example circa 1980 if you wanted to run and bash monsters and take their shit the only choices was Dungeons & Dragons or a similar RPG. However by 2000, you could fire up Diablo and get the same experience.

Yes, I do think a considerable chunk of the audience for table top RPGs has been eaten up by video games and online RPGs. But I meant ubiquitous as in, within the current block of table top gamers, a smaller percentage seem to be playing alternatives to D&D* itself in my local area. I've always assumed this had to do mainly with the d20 boom we had following 3E. Before that people always made a new system for a new game. Once d20 opened up like that, I think it became the standard operating system for most gamers. I don't think this is bad or good, but I do think the reality that needs to be accepted by anyone creating alternatives to that (myself included).

My experience in the 90s was very different, where you had huge swaths of table top gamers playing things like white wolf and other games. Back then if I wanted to find a group playing GURPS or Rolemaster, it was pretty easy, not it seems a bit harder to find. Not impossible, just more difficult.  

*By D&D I just mean D&D and Pathfinder, as well as any D&D-like d20 system.

RE: Patterns. I know patterns. I mentioned earlier how one place I worked, patterns was "the thing". You just had to be able to identify the pattern you were using for management to accept the code. You didn't have to be able to explain why it was the correct pattern to use.

I use the strategy pattern in one or two places, but even then, the strategy instance is usually part of an inheritance hierarchy.

Quote from: estar;863768I wish my language (VB6/VB.NET/C#) supported mixins, that would help me with a particular class of design problems. When the problem is a variation on a common set of behaviors then inheritance may be the better fit.

Sorry. I used "mixin" simply as "parent class intended to be inherited" rather than the LISP-CLOS mixin of "mixing in via inheritance functionality from outside the hierarchy". I miss multiple inheritance too. In this case, I'm working in Java.

For the second half of your comment, that's exactly what I'm doing. This particular problem is converting from one overly complex data format (same "format" but implemented differently each time--I know that doesn't make sense, but I didn't get consulted by the NCI/NIH when they did it) into a simpler data format that is implemented the same. So it's often smaller variations of "what do I use as the gene-name equivalent for this platform" or "which column is THAT in for this institution's data files".