On 12/26/2012 12:05 PM, George Currie wrote: Uh-huh, in the perversion called HFT where a share of stock is owned on the average for a period of what, 2 seconds? That is laughingly called "investment"? HFT would probably disappear if a per-share trading tax were imposed--right now, it only exists because trades and back-outs can be done for free. There could be worse things in this world were HFT to suddenly go away. That being said, there's nothing intrinsically wrong with COBOL--but little effort is being spent on writing good compilers for it. After all, it's just a programming language. --Chuck

On 12/26/2012 01:19 PM, Dave wrote: Most of my field experience was supporting the COBOL compiler and runtime. I remember Grace Hopper and the Navy Audit Tests for COBOL 74. (Now *there's* and acronym that few people remember: FCCTS - Federal COBOL Compiler Testing Service). It always seemed to me that the resolution of about half the PSRs submitted by users could be solved by quoting chapter and verse from the CODASYL spec--"I'm aware that you think it SHOULD work that way, but it doesn't"). Still, for its time, until the rise (and fall) of PL/I, COBOL had a lot of interesting features that other languages didn't have--the ability to specify the precision of a calculation; MOVE CORRESPONDING, ISAM as an integral part of the language, incredible variety of the PERFORM verb. Statements like EXAMINE/INSPECT, TALLYING or REPLACING.... A lot of the Y2K work on COBOL stuff was done by shall we say, "senior" programmers for good wages at the time==$50/hour was not unusual for COBOL contract work in 1998. It's fun introducing a young 'un who knows C or Java to the intricacies of COBOL... :) --Chuck

Dave wrote: Where things really count (embedded, real-time systems) those practices are still maintained. Although I will say that recent CS grads with their "extreme programming" and all of that happy horse sh*t are harder to bring on board these days. Consequently, we're hiring fewer and fewer "young" programmers these days... let them get their lumps on someone else's dime, we'll take the older more experienced guys that have learned why good practices are important. Bill S.

In article <50DB55D9.3010709 at sydex.com>, Chuck Guzis <cclist at sydex.com> writes: Maybe you haven't looked at C++ in a while. Modern C++ is a single language that can encompass many programming styles. The situation described in the article cited has nothing to do with the programming language and everything to do with code development that leave out automated regression testing. If you have automated regression tests on the code base, then you can make improvements to the code base knowing that you didn't make things worse instead of better. Without it, you tend to make the minimally invasive change that is localized as much as possible. This results in the accumulated detritis described in the article as time passes. What was initially a nice clean design eventually becomes a giant stove-pipe engineered solution. Again, none of this has anything to do with the language chosen for the software, although some languages make it easier to create automated unit tests and automated regression tests that give you the confidence that your changes have made things better, not worse. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

On Sun, 30 Dec 2012 02:22:59 -0500 Toby Thain <toby at telegraphics.com.au> wrote: I am very thankfull that C++ doesn't impose garbage collection on me, but gives me the choice to use it where apropriate. It is very disturbing to me that I can't use the RAII idiom in Java and have to work around this with try-catch-finally. So you get automatic memory management, but you have to manage your resources manualy. Thats awkward und cumbersome. And I surely don't want a garbage collector when programming C++ on a 8 bit microcontroler with a few dozen bytes of RAM... As allways: One size does not fit all. Different jobs need different tools. -- \end{Jochen} \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}

On Sun, 30 Dec 2012 14:13:59 -0500 Toby Thain <toby at telegraphics.com.au> wrote: Sure. But there are languages that don't leave this decision to the programmer. C++ does. Scheme is new to me. But I know of Java, JavaScript and Lua implementations, all garbage collected, for micorcontolers. Though, most of them are to big for many 8-bitters. \begin{advocatus diaboli} So C++ is no higher level language and is not appropriate for general problems? ;-) \end{advocatus diaboli} I use closures / lambdas in C++11 extensively - without garbage collection and without memory management problems. I just use simple RAII to manage memory, i.e. "smart pointers". Though, you can call smart pointers a primitive and crude way of garbage collection. ;-) -- \end{Jochen} \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}

On 12/30/2012 03:38 PM, Richard wrote: ...and that's saying something! Yes. "I'm a MODERN programmer! We don't have to worry about stuff like managing our own memory anymore!" Morons. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

sbrk() or GTFO -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- LDA #<TXT:LDY #>TXT:JMP $AB1E:TXT .asc "just another c64 hacker":.byt 0d00 -

On 30/12/12 7:12 PM, Dave McGuire wrote: Give me the right abstraction or give me death. :D --T

On 12/31/2012 02:13 PM, Fred Cisin wrote: I maintain that this is exactly "control of the machine". Yes, most definitely! -Dave -- Dave McGuire, AK4HZ New Kensington, PA

On Mon, 31 Dec 2012, Toby Thain wrote: Which shows how meaningless "high level language" can be.

On 12/31/2012 01:45 PM, Alexandre Souza - Listas wrote: Absolutely. :-) -Dave -- Dave McGuire, AK4HZ New Kensington, PA

Dave McGuire wrote: Exactly. The "key phrase" that I encounter is "I don't want to have to think about...". If someone I'm interviewing says that, the interview tends to end fairly quickly. Bill S.

On 31/12/12 12:04 AM, Richard wrote: Where I work we use Gerrit (a Google tool well integrated with Git). Code review is pretty thorough and most commits are seen by all team members. I highly recommend the practice for any team. --Toby

In article <alpine.LFD.2.02.1212310929540.32632 at sidewinder.deltasoft.com>, geneb <geneb at deltasoft.com> writes: Agreed, but even so, I'm not seeing 3x cost for maintainable code. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

--- On Sun, 12/30/12, Richard <legalize at xmission.com> wrote: my guess if you never wrote reuseable code http://agile.dzone.com/news/reuse-myth-can-you-afford reuseable code is define as code that can be used without any code changes across many different unrelated applications, code that implements floating point algorithm is an example. Digital filters that can handle fixed point inputs (with different word sizes), floating point inputs, as well as arrays is another example of reuseable code. The 3x cost has to deal with not just writing the code but testing it (all the various paths in different applications). You can't just write code, have a code review, and then test in one application and magically call it "reuseable". To test reuseability to have to test the code's ability to be reused. Code that just can be used in the same application, with just minor updates is not what is known as reuseable in the software industry. Although some refer to it as vertically reuseable as opposed to horitizally reuseable, but that is just to satisfy naive managers.

Actually, for some purposes throwaway shit _is_ well-engineered code. Good engineering is about building it suitably for its use, not about building it to some sort of idealized "all code should be like this" target. When the purpose of the code is to, for example, verify that your understanding of some aspect of the language is correct, or when you need to compute a constant that will go into the final code as a constant, or some such, then the code _is_ throwaway, so making it anything else is wasted effort. (Unfortunately its author rather ruins the effect by making one of the most annoying (to my eye) rudimentary English blunders on the net today, namely, using "loose" as if it meant "lose".) Yes and no, I'd say. The page you cite touches on this when it says One of the reasons developers want to "design for reuse" is not so much because the code will be reused but rather because they desire a set of properties (modularity, high cohesion, low coupling, etc.) which are desirable engineering properties but sound a bit abstract. Designing for reuse and designing for maintainability, while hardly identical, do overlap heavily. In particular... ...I consider this a dangerous idea. There is certainly some truth in it, but I think it is dangerous because designing code without any thought of reuse has a nasty tendency to result in code that is extremely hard to reuse, often needing a complete discard and rewrite. Designing code with reuse in mind, while not necessarily resulting in reuse-ready code, does produce code that is much easier to reuse later. Someone upthread wrote that "reuseable code is define as code that can be used without any code changes across many different unrelated applications"[sic]. I disagree with this definition; I see reusability as a spectrum, not an absolute, running from what that quote describes through code that needs a few minor tweaks and code that needs major tweaks all the way to stuff that is best scrapped and rewritten rather than reused at all. So, I would say, don't make it fully reuse-ready; that is wasted effort. But write it with reuse in mind. Do this because that produces more maintainable code in general. And, in many cases, it is actually the cheaper option. If we let the chance of needing to reuse the code be R, the cost to build it without even thinking of reusability P1, the cost to build it with reuse in mind P2, the cost to overhaul it for reuse (in extreme cases, this means scrap and rewrite) P3, and the cost to update it for reuse when built the second way is P4, then, if P1+(R*P3) > P2+(R*P4), you're better off building for reusability, as in, writing it with reuse in mind even if you don't actually make it reuse-ready. And, at least in my limited experience, that inequality is often true. 0xa0 is the 8859-1 non-break space character. This is probably an artifact of a MUA that's been "improved" to the point where it's too stupid to comprehend the concept that quotes should be a literal quote of what was written, rather than what was massaged into some other form to get it past display code that's also been "improved" to the point where subtrefuge has to be used to display straightforward text. The message-ID in your In-reply-to: and References: is <1357143740.29987.YahooMailClassic at web120004.mail.ne1.yahoo.com>, which makes it look as though this was written by someone using Yahoo's webmail interface, in which case none of this misbehaviour is any surprise at all to me. Webmailers generally do not understand email, instead trying to shorehorn it into their "everything is the Web and the Web is everything" mindset, leading to damage like that. (That's hardly the only damage; I went back and looked up the message in question and found it (a) added spurious linebreaks to text it quoted and (b) used paragraph-length lines for its new text.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

In article <1357228405.84897.YahooMailClassic at web120003.mail.ne1.yahoo.com>, steve <gkicomputers at yahoo.com> writes: I would say that the libraries in boost qualify as a good example of reusable code for C++. <http://boost.org> Due to the intersection between members of the C++ standars committee and members of the boost community, many things have migrated from boost to the C++ standard, if not in literal API, then certainly in terms of concepts and strategies. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

On 01/01/2013 11:32 AM, Alexander Schreiber wrote: I once wrote a text editor as a throw-away code project in order to learn the operation of some of the more arcane instructions of a particular machine. It was full of odd vector instructions and satisfied me that I could understand the descriptions of the instructions detailed in the hardware manual. Shortly after that, I moved on to another venture. Imagine my surprise when I discovered fully 10 years later, that my little learning project was still being used as the standard editor! The instruction set of the architecture had changed, with many of the instructions that I had used being tossed on the scrap heap. Someone had very carefully replaced them with subroutines that did the equivalent thing. I was dumbfounded and horrified. Moral: If you write throw-away code, keep it to yourself and don't let another breathing human being see it. They might try to use it. --Chuck

On Tue, 1 Jan 2013, Chuck Guzis wrote: In 1970, I objected to using 2 digit decimal year numbers, but I was ordered to do it. "None of this will still be around." "Wait, and put comments in AFTER the program is complete." "Why are you wasting time adding comments to a program that is done? We need you to get to work on the next project." I was assigned to several man years to convert graphing packages from CalComp to SC/SD Datagraphics. Instead of rewriting them, I intercepted the lowest level calls (N/S/E/W/up/down?) and re-directed them to low level calls in the Sc/SD routines. Finished in 2 weeks. Got chewed-out for not using the entire time that had been contracted for. We did enough things right (such as that) during that year that the guvmint contract gave us a bonus that averaged $2K per person, for the company to distribute as they saw fit. I received a gift certificate for a supermarket frozen turkey. Because of "man on the moon day", we "ran out" of holidays, and were told to use vacation time for X-Mas. I called in sick. In 1999, when I was contacted to help "repair" my code, I refused.

In article <50E342F8.5020607 at sydex.com>, Chuck Guzis <cclist at sydex.com> writes: Moral: it is not throw-away code, if you don't actually throw it away. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

On Tue, Jan 01, 2013 at 09:01:18PM -0800, Chuck Guzis wrote: That's the sign of a good coder. There is no disposable code. I don't have that problem. All the instructions I have used are still in the current version. We do things differently now but the old stuff still works. People will go to almost any length to cut and paste or hack something together so they can proudly say to management they haven't reinvented the wheel. Usually, it's much smarter, cheaper, and even faster to engineer and deploy a new wheel. I've thrown out a lot of other people's code against managements' wishes, threats, etc. I have never regretted it and sometimes the brass even thanks me for doing it afterwards. But never beforehand! -- _ _ ._ _ _ <_> ___ _ _ ___ ___ ___ _| | ___ | ' ' || |/ | '| '_>/ . \/ | '/ . \/ . |/ ._> |_|_|_||_|\_|_.|_| \___/\_|_.\___/\___|\___.

There is a time you NEED to start from scratch. The code is so badly-patched and full of layers that you need to take all the fat out and make it leaner.

In article <CAMTenCEaFSd2-5A-2tgj3meO9BRaVxeLqGUAoQR1tshoyz=E4g at mail.gmail.com>, Liam Proven <lproven at gmail.com> writes: Contrast with: <http://www.joelonsoftware.com/articles/fog0000000069.html> This was an interesting read, thanks. I always wondered why Netscape 4 was such a POS and now I know. I had heard stories from contractors who worked at netscape on how horrible the code was and at this time I don't know if they were referring to either the "duct tape code" or the rewrite code, but either way it sounds like the code was pretty shitty. I'm with Joel on rewrite vs. refactor (which is to say: don't rewrite, but do refactor incrementally with automated tests). This is also touched on by Brian Foote in his google tech talk "Big Ball of Mud" which I linked to earlier on this thread. Ugly code that has been debugged, tested and is working in the field is to be favored over new, pretty code that has not been debugged, tested and survived in the field. However, we should not delude ourself that the choice is only between ugly time-tested code and pretty untested code. The one can be transformed into the other by judicious application of automated regression tests (so you know that changes are indeed improvements and not making things worse or introducing bugs) and guided refactoring. Over the past 10 years, I have done this many times and the single biggest weapon in combatting shitty code is automated regression tests. Otherwise, you really don't know if you're making things better or not. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

On Tue, 1 Jan 2013, Chuck Guzis wrote: Sometimes, it is easier, and much less intimidating to modify something existing into what you want, rather than face the daunting task of designing from scratch. It takes time, and experience, to build the confidence to know that you CAN start from scratch. You probably gave some "developing" programmer much needed practice and experience. But, let's hope that now he can build from scratch! -- Grumpy Ol' Fred cisin at xenosoft.com

On Wed, 02 Jan 2013 10:54:28 +0100 Bert Thomas <bthomas at brothom.nl> wrote: Depends. By adding that "overkill" that programmer solved the problem once and for all. If he had it done as a constant, the customer may wanted that constant to become a variable in a furure release. That woud cause additional efforts. The code would need to be touched again. But if it is already a variable read from a database, its just a matter of adding e.g. a GUI knob for the variable. Been there, done that. Many times. ;-( -- \end{Jochen} \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}

On Wed, 02 Jan 2013 10:17:34 -0700 Richard <legalize at xmission.com> wrote: Which is false when applied in an absolute manner. Most (all?) things go wrong when taken to an absolute extreme. Proper real world engineering is allways a question of optimizing, balanceing and finding a pragmatic way in the middle. The Middle Way is no new concept. It is one of the fundamental wisdoms of Buddhism. Something that has proven to be true by many generations of humans for now well over 2500 years weights more to me then the ideas of some Extreme Programming Guru. ;-) You can apply YAGNI in an absolute manner in your Extreme Programming monastery up there on top of the ivory tower. But you are doomed to fail sooner or later when you are in the real world. Even if you do it right and you are right in doing it right, you may get fired by a suit who has a different opinion about what is right... ;-( -- \end{Jochen} \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}

On 1/2/2013 3:43 PM, Richard wrote: I got yelled at because I was not breaking up my assignment to do a firmware for a mouse like device in "extreme" mode, nor did it seem to be useful to do it in "agile" mode. Hard to break down a task to take mouse input and send it to a usb port into "phases" that can be tested individually. Either it is a fricking mouse, or it is a pile of useless C code. I never did get it thru management's head that there wasn't much in between. BTW, it did succeed in turning about 1 1/2 weeks of work which could have been completed in a straight line into about 4 weeks on their schedule with some sort of excuse in their scrum meetings why it wasn't done, or where I was.

It was thus said that the Great Mouse once stated: But it's an awfully small "there". I'm thankful we don't have to deal with Agile where I work as I feel the concept is meaningless with respect to the coding we do. My job here is to test several coponents of a much larger product; each component (and there are six we're responsible for) are independent programs that all communicate amongst themselves. Each program is conceptually simple. For instance, one component waits for two particular SS7 [1] messages, does some data lookups and sends a request to another piece over IP; it then waits for a reply on the IP side before responding to the SS7 network. The second component receives the message (from the SS7 component), does some data lookup, and it might in fact send a DNS query [5], send a message to a cell phone [6] and wait for the cell phone to query back to the component before replying to the SS7 component. Perhaps I'm not imaginative enough, but I personally have a hard time seeing how Agile, scrum meetings and test-driven design [3] applies to the project. Heck, it's hard enough testing the fully written components (especially the SS7 component [7]), much less unit testing on individual routines (each component is a "unit"---I can't see any further decomposition going on). It doesn't help that the components are written in C *and* C++ (with respect to unit testing). I best stop before I go into full-on-rant mode. -spc (Running a regression test takes at least a half-hour to set up and that's if everything is running smoothly ... [8]) [1] Signaling System 7---a telelphony network stack [2] [2] and the stack we use *SUCKS* but I've been advised that the SS7 stack we use is, in fact, *BEST OF BREED*, which doesn't bode well for SS7 stacks in general. [9] [3] Okay, I can't tell if the following article series is satire or a genuine attempt at test-driven design: http://xprogramming.com/xpmag/OkSudoku http://xprogramming.com/xpmag/Sudoku2 http://xprogramming.com/xpmag/SudokuMusings http://xprogramming.com/xpmag/Sudoku4 http://xprogramming.com/xpmag/sudoku5 I mean, it's Ron Jefferies, who I understand is a cheerleader for Agile development, but then, he says stuff like: def square_indexes(square_number) result = [] first_row = square_number / 3 first_column = (square_number % 3) * 3 first_row.upto(first_row+2) do | row | first_column.upto(first_column+2) do | col | cell_number = row * 9 + col result.push(cell_number) end end result end That?s a lot of code, and I?m afraid it won?t work. When did 14 lines of code become "a lot"? Is he serious? [4] [4] Please tell me he was writing satire. [5] Caller ID internally is done using DNS records. NAPTR records in fact. Surprising, but on retrospect, it's not a bad match. [6] SMS or proprietary protocol, depending on how fast the SMS network for the vendor is. [7] "One does not simply 'walk' into Mordor," was the response I got when I asked about SS7 networks. [8] Two years and only just last month did I learn that once I open up an SS7 endpoint, I *may* have to wait up to 30 seconds for it to "register" with the network, else sending messages will fail. Did I mention that the SS7 stack we use *SUCKS*? [9] For instance, it maintains static data behind your back. And error conditions? Yeah, you have to crawl into memory *past* a structure to get the actual reason for the error. Seriously. It *SUCKS*.

In article <20130103104200.675d850af00571b58e6df393 at unixag-kl.fh-kl.de>, Jochen Kunz <jkunz at unixag-kl.fh-kl.de> writes: Then I don't see how that makes you qualified to proclaim things about it when you don't know what it is. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

In article <20130104111716.af40f485841b265accf281c0 at unixag-kl.fh-kl.de>, Jochen Kunz <jkunz at unixag-kl.fh-kl.de> writes: Non sequitur. Because all software methodologies are methodologies does not qualify you to make claims about a methodology you know nothing about. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>