• (cs) in reply to Not Bob
    Not Bob:
    The GEDCOM standard is so outdated that no program can implement only GEDCOM and supprt the features that users want and that genealogists need.

    It's roughly the equivalent of using only static HTML 4 for a website. Everyone can understand it, but everyone wants more.

    There's something of a turf war going on right now with several different groups actively trying to define the next GEDCOM replacement.

    That process has been going on since - when? late in the last century. Somebody starts a forum or a mailing list demanding something to happen, which generates a heated debate that dies off after a few weeks. Rinse and repeat.

    The dirty little secret is that most vendors of commercial genealogy programs don't want an efficient and reliable data exchange method. They want their users locked into their proprietary turfs.

    "Dinosaur Bob" has been the one decent exception to this rule, but now it's been a long time since I saw him participate in an open discussion. Maybe it's me who haven't been to the right places. I don't care much anymore, neither; I'm rather content with my own project Yggdrasil which doesn't even try to be "GEDCOM-compatible".

  • Me (unregistered) in reply to Neil Morrison
    Neil Morrison:
    Weinberg's Law again?

    (If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization).

    I think that's moire a reflection on the complexity of the task, and the inability of IT Management to realise this complexity.
    To build a building we have teams of engineers, labourers (of varying specialities) and technicians. To write software we bundle a handful of graduates together, add a sprinkling of hobbyists who have heard Java and XML in the same sentence and insist they revolutionise the world. Doesn't help that somewhere in there we let the Programmers make business decisions, and the managers make technical decisions and we have a recipe for disaster.

    Probably also doesn't help that people seem to think that we can make generic programs, or standardise processes for everything we do. The reality is that the planning involved in software is often not done well - though I'm not sure how it can be improved. How can you estimate effort, without putting in similar effort to actually complete the task (that is, to reduce everything to such a low level that you can reasonably estimate it, you've probably created a prototype - which not only takes time, but then reduces the effort required)? Experience? Not always helpful, especially where each piece of work you do is significantly different, has different technology limitations and will probably involve significantly different hurdle to the last one. I worked with someone who used to get angry when managers wanted percentages on how complete a particular task - in his way of thinking (and I can sort of relate to it, I must admit) the work was either finished or it wasn't - the percentage complete could not be quantified until after the fact (that is, afterward we can say "on the 23rd July it was 50% complete but we didn't actually know that on the 23rd of July).

    I used to be amazed at how estimates evolve. A seemingly simple task is estimated at 1 day by a developer who (rather arrogantly, perhaps) thinks they can knock it off in about an hour. Their Team Leader doubles that to introduce a safety net, and the Project Lead doubles it again. Even with 6 layers of management (none of whom want their head in the chopping block) this "trivial" task is estimated at 32 days - plus management overhead and testing. I can't help but think that a lot of it (as has been discussed/argued/fought over here squillions of times is the lack of interest from Techs in management, and the lack of understanding in management of technical areas (even at a reasonably high level). It bothers me that I've had managers who (even at a simplistic level) do not understand that WebMethods is different to C - or (worse still) that a Unix Server is not a Mainframe ("Yeap...we'll get them to do it on the Solaris Mainframe..." - and no, we don't use IBM System z). Unfortunately (and perhaps ironically), managers with technical backgrounds often struggle at the other extreme - to let go of the technical - and invest too much in projects - micromanaging and dictating technical specifics.

    Basically a Manager should have a view that is neither too high (so high that everything is a black box) nor too low (so low that they feel personally responsible for every code path). It is a difficult balance, and I'd like to think erring by having too low a level view is probably less harmful than too high - although both can be very dangerous.

  • (cs) in reply to Me
    Me:
    I worked with someone who used to get angry when managers wanted percentages on how complete a particular task - in his way of thinking (and I can sort of relate to it, I must admit) the work was either finished or it wasn't - the percentage complete could not be quantified until after the fact (that is, afterward we can say "on the 23rd July it was 50% complete but we didn't actually know that on the 23rd of July).

    That is an excellent example of management not understanding the Pareto principle (the 80/20 rule), which applied to programming implies that 80 % of the functionality will be achieved by doing 20 % percent of the work. In the end, to make perfect software covering all corner cases and guarding against every effect of user idiocy, the cost in terms of developer hours will rise asymptotically.

  • Dave (unregistered)

    This looks a lot like a surrealist animal-classification system that some well-known (but not well-known enough for me to remember his name right now) philosopher once proposed, which went something like:

    • Animals with fur
    • Animals whose names begin with a 'p'
    • Animals who are not cats
    • Animals who have just knocked the flowerpot off the mantlepiece
    • [etc]
  • (cs) in reply to Dave
    Dave:
    This looks a lot like a surrealist animal-classification system that some well-known (but not well-known enough for me to remember his name right now) philosopher once proposed, which went something like:
    • Animals with fur
    • Animals whose names begin with a 'p'
    • Animals who are not cats
    • Animals who have just knocked the flowerpot off the mantlepiece
    • [etc]

    Jorge Luis Borges, in “The Analytical Language of John Wilkins”, perhaps?

    These ambiguities, redundancies, and deficiencies recall those attributed by Dr. Franz Kuhn to a certain Chinese encyclopaedia entitled Celestial Emporium of Benevolent Knowledge. On those remote pages it is written that animals are divided into (a) those that belong to the Emperor, (b) embalmed ones, (c) those that are trained, (d) suckling pigs, (e) mermaids, (f) fabulous ones, (g) stray dogs, (h) those that are included in this classification, (i) those that tremble as if they were mad, (j) innumerable ones, (k) those drawn with a very fine camel's-hair brush, (l) others, (m) those that have just broken a flower vase, (n) those that resemble flies from a distance.
  • Dave Clarke (unregistered)

    I swear I've worked with this guys 'output' before. I worked with a small ISP startup at the begining of my career and I think this chap was brought in to do the company DB and billing system. He was an ex-civil engineer who "knew a thing or two" about computers and was quite heaviliy into his genealogy. The billing system was a MS Access database and a similar gem of software development best practice. Would the author of the post care to share the initials of the SDK author?

  • (cs) in reply to Marnen Laibow-Koser
    Marnen Laibow-Koser:
    I think so. I don't know anything about FoxPro, but I *do* know a thing or two about genealogy software. I assume TMG is The Master Genealogist, which was indeed built on top of FoxPro.

    MvADD: Error writing to 'Merchant2/00000001/DEN_TINYCART/recent.dbf': Runtime error in /Merchant2/4.24/modules/util/DEN_TINYCART.mvc @ [00000054:000000be]: Line 1666: MvADD: Error writing to 'Merchant2/00000001/DEN_TINYCART/recent.dbf': Runtime error in /Merchant2/4.24/modules/util/DEN_TINYCART.mvc @ [00000054:000000be]: Line 1666: MvADD: Error writing to 'Merchant2/00000001/DEN_TINYCART/recent.dbf':

    Masterful! dBase hilarity ensues.

  • (cs) in reply to Leif
    Leif:
    Me:
    I worked with someone who used to get angry when managers wanted percentages on how complete a particular task - in his way of thinking (and I can sort of relate to it, I must admit) the work was either finished or it wasn't - the percentage complete could not be quantified until after the fact (that is, afterward we can say "on the 23rd July it was 50% complete but we didn't actually know that on the 23rd of July).

    That is an excellent example of management not understanding the Pareto principle (the 80/20 rule), which applied to programming implies that 80 % of the functionality will be achieved by doing 20 % percent of the work. In the end, to make perfect software covering all corner cases and guarding against every effect of user idiocy, the cost in terms of developer hours will rise asymptotically.

    So the costs will approach zero? If I was a manager, I would love that analysis.

  • Dimitry Sapajev (unregistered)

    I know a guy who wrote foxpro app in '90 and maintains it till this day. By now source is over 2MB, split into two files. New features are added, dead code is left alone, several if cases based on hardcoded customer variable (even for menu structure). Source control: what's that? Global variable slots are used up long time ago, instead db is used to hold runtime variables. Dbf table string fields are split to several sub-fields, length only known in source. We tried to convert it to latest fox but failed epicly. Complete rewrite would be in order.

    captcha: opto - I opto out of memories of foxpro.

  • (cs) in reply to frits
    frits:
    Leif:
    Me:
    I worked with someone who used to get angry when managers wanted percentages on how complete a particular task - in his way of thinking (and I can sort of relate to it, I must admit) the work was either finished or it wasn't - the percentage complete could not be quantified until after the fact (that is, afterward we can say "on the 23rd July it was 50% complete but we didn't actually know that on the 23rd of July).

    That is an excellent example of management not understanding the Pareto principle (the 80/20 rule), which applied to programming implies that 80 % of the functionality will be achieved by doing 20 % percent of the work. In the end, to make perfect software covering all corner cases and guarding against every effect of user idiocy, the cost in terms of developer hours will rise asymptotically.

    So the costs will approach zero? If I was a manager, I would love that analysis.

    No. They will approach infinity.

  • Neil (unregistered) in reply to Shinobu
    Shinobu:
    I have to say though, that I don't share the hatred for Dispatch. Given what it needs to do and the state of compilers when it was designed, I can't imagine how it could have been any simpler.
    Well, it could simply have never existed, and the existing marshalling system that was used to invoke methods across threads (or even processes!) could have easily been adapted to cope with dynamic invocations, such as is done with Gecko's XPConnect module. (Indeed Gecko is dropping its inter-thread marshalling and now only uses typelibs for dynamic dispatch.)

    CAPTCHA: iusto (use typelibs for inter-thread marshalling but now I only use them for dynamic dispatch.)

  • (cs) in reply to Dimitry Sapajev
    Dimitry Sapajev:
    I know a guy who wrote foxpro app in '90 and maintains it till this day. By now source is over 2MB, split into two files. New features are added, dead code is left alone, several if cases based on hardcoded customer variable (even for menu structure). Source control: what's that? Global variable slots are used up long time ago, instead db is used to hold runtime variables. Dbf table string fields are split to several sub-fields, length only known in source. We tried to convert it to latest fox but failed epicly. Complete rewrite would be in order.

    captcha: opto - I opto out of memories of foxpro.

    Our smart client rewrite all FoxPro apps to java based apps. Good business decision I think. What you say?

  • (cs) in reply to Mick
    Mick:
    Did I miss something?

    Why would you use a Software Development Kit to read files? Or does SDK mean something different in the world of genealogy?

    Because genealogy file formats are extremely complex and varied, a fact apparently unknown to the flippant commentators here.

    The database specs are confidential and not shared by the respective developers. To wit: Legacy (Access), Personal Ancestral File (home-grown), Roots Magic (formerly CodeBase, now SQLite), Family Tree Maker (formerly Windows Compound File, now VistaDB, no relation to Windows Vista), etc. etc. If you try to just "read a file", you are in for a world of hurt.

    GEDCOM does not accurately capture the various data models, hence the need for GenBridge.

  • (cs)

    I think we are missing the real issue here, which is how does a small, one-man shop balance the day-to-day exigencies of supporting customers, fixing bugs and rolling out new features on one hand, versus taking a year (or two) off to completely rewrite one's app?

    It's easy to dismiss the design decision to choose FoxPro twenty years ago. Back then, it was a very effective way to get an app out quickly, running on a 386 (as has been pointed out). But we don't all have the luxury of stopping the business and go code in our lair full-time.

    "Genealogy software" should not be dismissed derisively. The genealogy data model of relationships, sources and citations is complex. Genealogy is probably the only pursuit where mutually contradictory assertions must be preserved and entertained, sometimes forever, as neither can be conclusively disproven because evidence is lost to the passage of time. Would you have guessed that you need to store multiple birth and death dates, and multiple sets of parents? Only your Mom knows who's your Daddy for sure.

    I know TMG and Dinosaur Bob. Despite its shortcomings, his software is highly regarded by his customers as the only genealogy program to accurately capture the complexities and intricacies of the craft. He has focused on implementing features, for the benefit of his grateful customers. Most of them don't give a hoot what he writes in (except of course when they bump up against Unicode).

    I'd love to hear from any self-employed developers here, who have successfully rewritten half a million lines of code and stopped being paid for a couple of years.

  • Dave (unregistered) in reply to Watson
    Watson:
    Dave:
    This looks a lot like a surrealist animal-classification system that some well-known (but not well-known enough for me to remember his name right now) philosopher once proposed, which went something like:
    • Animals with fur
    • Animals whose names begin with a 'p'
    • Animals who are not cats
    • Animals who have just knocked the flowerpot off the mantlepiece
    • [etc]

    Jorge Luis Borges, in “The Analytical Language of John Wilkins”, perhaps?

    These ambiguities, redundancies, and deficiencies recall those attributed by Dr. Franz Kuhn to a certain Chinese encyclopaedia entitled Celestial Emporium of Benevolent Knowledge. On those remote pages it is written that animals are divided into (a) those that belong to the Emperor, (b) embalmed ones, (c) those that are trained, (d) suckling pigs, (e) mermaids, (f) fabulous ones, (g) stray dogs, (h) those that are included in this classification, (i) those that tremble as if they were mad, (j) innumerable ones, (k) those drawn with a very fine camel's-hair brush, (l) others, (m) those that have just broken a flower vase, (n) those that resemble flies from a distance.

    Yup, that's the one.

  • Dave (unregistered) in reply to Nagesh
    Nagesh:
    Dimitry Sapajev:
    I know a guy who wrote foxpro app in '90 and maintains it till this day. By now source is over 2MB, split into two files. New features are added, dead code is left alone, several if cases based on hardcoded customer variable (even for menu structure). Source control: what's that? Global variable slots are used up long time ago, instead db is used to hold runtime variables. Dbf table string fields are split to several sub-fields, length only known in source. We tried to convert it to latest fox but failed epicly. Complete rewrite would be in order.

    captcha: opto - I opto out of memories of foxpro.

    Our smart client rewrite all FoxPro apps to java based apps. Good business decision I think. What you say?

    You have no chance to survive make your time. Ha Ha Ha Ha ...

  • L. (unregistered) in reply to sprezzatura
    sprezzatura:
    Mick:
    Did I miss something?

    Why would you use a Software Development Kit to read files? Or does SDK mean something different in the world of genealogy?

    Because genealogy file formats are extremely complex and varied, a fact apparently unknown to the flippant commentators here.

    The database specs are confidential and not shared by the respective developers. To wit: Legacy (Access), Personal Ancestral File (home-grown), Roots Magic (formerly CodeBase, now SQLite), Family Tree Maker (formerly Windows Compound File, now VistaDB, no relation to Windows Vista), etc. etc. If you try to just "read a file", you are in for a world of hurt.

    GEDCOM does not accurately capture the various data models, hence the need for GenBridge.

    Wonderful ... commentators here have a hard time realizing how f'ing retarded some crappy programmers can be - as in expeting them to even think anyone would want to steal their useless disgusting code ...

    Meh.

    Like seriously ... 'A Software for Genealogy' .

    Lol ? you sure you don't want a specific software to do explorer tasks for images only, and another for text files only ?

  • L. (unregistered) in reply to sprezzatura
    sprezzatura:
    I think we are missing the real issue here, which is how does a small, one-man shop balance the day-to-day exigencies of supporting customers, fixing bugs and rolling out new features on one hand, versus taking a year (or two) off to completely rewrite one's app?

    It's easy to dismiss the design decision to choose FoxPro twenty years ago. Back then, it was a very effective way to get an app out quickly, running on a 386 (as has been pointed out). But we don't all have the luxury of stopping the business and go code in our lair full-time.

    "Genealogy software" should not be dismissed derisively. The genealogy data model of relationships, sources and citations is complex. Genealogy is probably the only pursuit where mutually contradictory assertions must be preserved and entertained, sometimes forever, as neither can be conclusively disproven because evidence is lost to the passage of time. Would you have guessed that you need to store multiple birth and death dates, and multiple sets of parents? Only your Mom knows who's your Daddy for sure.

    I know TMG and Dinosaur Bob. Despite its shortcomings, his software is highly regarded by his customers as the only genealogy program to accurately capture the complexities and intricacies of the craft. He has focused on implementing features, for the benefit of his grateful customers. Most of them don't give a hoot what he writes in (except of course when they bump up against Unicode).

    I'd love to hear from any self-employed developers here, who have successfully rewritten half a million lines of code and stopped being paid for a couple of years.

    Dude . lol . One or two years to rewrite a genealogy app . Return to cleaning up the desks thx.

    HALF A MILLION LINES OF CODE !!!! ZOMG 1101011110101111 !!!

    Right . when you code crap, Mloc is probably a good performance measure.

    After all it can be directly related to HDD space required and thus perceived duration of install time . brilliant.

  • roy (unregistered) in reply to frits

    Façade design pattern, no?

  • lollancf37 (unregistered)

    I am laughing so hard right now.

  • (cs) in reply to Steve The Cynic
    Steve The Cynic:
    dgvid:
    Reminds me of Microsoft's IDispatch. Did they ever catch the guy who created that? Or is it a "cold case"?
    IDispatch is a solution to the specific problem of how to call COM interfaces from a live-interpreted scripting language like VBScript.
    It's really a solution to how you construct a receiver for any message (which is what a COM call maps to, either conceptually or literally when using DCOM or one of its derivatives). The very concept of having a generic message receiver is pretty much alien to the C++ model of the world where you start from the definition of the message types, but there are other languages where handling this sort of thing makes sense. Because it's alien to C++, the way it is mapped there is naturally going to be horrible — that's what you'd naturally expect — but it really isn't true for everything; it would map nicely into Lisp or Perl or Python or Ruby or …

    Programmers of “static” languages accuse dynamic code of being untyped and unchecked mush. Programmers of “dynamic” languages accuse static code of being sclerotic, myopic and inflexible. There's some truth in both, but much misunderstanding too.

  • (cs) in reply to Ol Bob
    Ol Bob:
    FoxPro anyone..?
    This.

    And I would InstaQuit that job. I'd rather panhandle or whore myself out at the truck stop.

  • (cs) in reply to dkf
    dkf:
    Programmers of “static” languages accuse dynamic code of being untyped and unchecked mush. Programmers of “dynamic” languages accuse static code of being sclerotic, myopic and inflexible. There's some truth in both, but much misunderstanding too.
    C# 4.0 FTW.
  • Luiz Felipe (unregistered) in reply to hoodaticus
    hoodaticus:
    dkf:
    Programmers of “static” languages accuse dynamic code of being untyped and unchecked mush. Programmers of “dynamic” languages accuse static code of being sclerotic, myopic and inflexible. There's some truth in both, but much misunderstanding too.
    C# 4.0 FTW.

    Static and dynamic must coexist. I love C#4 for it.

  • Former Mac OS dev (unregistered) in reply to Luiz Felipe

    C#? Objective C has been managing mixed static and dynamic typing since 1990.

  • (cs) in reply to Former Mac OS dev
    Former Mac OS dev:
    C#? Objective C has been managing mixed static and dynamic typing since 1990.
    So has Visual Basic. So there.
  • Robert Gascoyne-Cecil, 3rd Marquess of Salisbury (unregistered) in reply to MadX
    MadX:
    Aves:
    Bob's my uncle.

    Uncle Bob's my father.

    Well son, Viscomte Cranborne, you died in 1947 and know squat about programming. Stay down!

  • Phil (unregistered) in reply to dgvid

    IDispatch is root of all evil, being COM! Even better, XPCOM (the component system used by Mozilla) is a horrible reimplementation of this dreck. The one thing going for COM and XPCOM is that they do not need three different classes to expose a single class to RPC like J2EE. Thankfully I've never had to use CORBA to see how bad it can get.

  • Tim (unregistered) in reply to L.
    L.:
    Like seriously ... 'A Software for Genealogy' .

    Lol ? you sure you don't want a specific software to do explorer tasks for images only, and another for text files only ?

    You mean like, say, Adobe Illustrator and Microsoft Word? Just wondering.

  • ccj (unregistered)

    women whose given name contains liz.flp

    ...get added to Bob's little black book, because he has a Liz fetish. Seriously, what utility could this actually provide? And WTF is with the whitespace in a filename?! Forbidden!!!

Leave a comment on “S(adistic)DK”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article