A Well-Documented Piece of....*bleep*
-
[rant] Here's the setup of an "unidentified" application: For some reason, the developer didn't want to code in the language to which he was assigned, so the first thing that he did was create an entire generator that allowed him to generate the "other" language so that he could continue to program in the language of his choice. The resulting application is so "objectified" that the object model is several layers deep, and in order to find a "Save" command, I have to wade through 20+ pages of documentation describing his monolithic object model. The irony of it all is that it's nicely structured, it has all of its unit tests, and it also has plenty of documentation. In all, I'd say the codebase is about 30k lines, which isn't too terribly large. There is, however, just one problem: I did the same project in less than 2k lines of code! It's a bloated masterpiece! [/rant] Has anyone else ever run into this scenario?
-
[rant] Here's the setup of an "unidentified" application: For some reason, the developer didn't want to code in the language to which he was assigned, so the first thing that he did was create an entire generator that allowed him to generate the "other" language so that he could continue to program in the language of his choice. The resulting application is so "objectified" that the object model is several layers deep, and in order to find a "Save" command, I have to wade through 20+ pages of documentation describing his monolithic object model. The irony of it all is that it's nicely structured, it has all of its unit tests, and it also has plenty of documentation. In all, I'd say the codebase is about 30k lines, which isn't too terribly large. There is, however, just one problem: I did the same project in less than 2k lines of code! It's a bloated masterpiece! [/rant] Has anyone else ever run into this scenario?
Philip Laureano wrote:
Has anyone else ever run into this scenario?
MFC?
-
Philip Laureano wrote:
Has anyone else ever run into this scenario?
MFC?
J2SE? I kid, I kid! :laugh:
Please don't bother me... I'm hacking right now. Don't look at me like that - doesn't anybody remember what "hacking" really means? :sigh:
-
[rant] Here's the setup of an "unidentified" application: For some reason, the developer didn't want to code in the language to which he was assigned, so the first thing that he did was create an entire generator that allowed him to generate the "other" language so that he could continue to program in the language of his choice. The resulting application is so "objectified" that the object model is several layers deep, and in order to find a "Save" command, I have to wade through 20+ pages of documentation describing his monolithic object model. The irony of it all is that it's nicely structured, it has all of its unit tests, and it also has plenty of documentation. In all, I'd say the codebase is about 30k lines, which isn't too terribly large. There is, however, just one problem: I did the same project in less than 2k lines of code! It's a bloated masterpiece! [/rant] Has anyone else ever run into this scenario?
Nope! But my first professional programming job was to write an application in less than 2 weeks, because the previous programmer, who was writing it in assembly over a 6 month period, left the company along with all the code. I brought in my libraries, QuickC compiler, and wrote it in C, it worked well given the time frame. I occasionally write code generators, but only when it is required to eliminate wasting my time by having to hand code something that can be automated. Point, click, verify, and generate. That way a non-programmer can handle the creation, and I only have to verify it, before and after the code generation.
INTP "Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
-
Philip Laureano wrote:
Has anyone else ever run into this scenario?
MFC?
Naw, he mentioned "nicely structured".
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! VCF Blog
-
Philip Laureano wrote:
Has anyone else ever run into this scenario?
MFC?
STL? ATL? COM? DCOM? ... :~
-
[rant] Here's the setup of an "unidentified" application: For some reason, the developer didn't want to code in the language to which he was assigned, so the first thing that he did was create an entire generator that allowed him to generate the "other" language so that he could continue to program in the language of his choice. The resulting application is so "objectified" that the object model is several layers deep, and in order to find a "Save" command, I have to wade through 20+ pages of documentation describing his monolithic object model. The irony of it all is that it's nicely structured, it has all of its unit tests, and it also has plenty of documentation. In all, I'd say the codebase is about 30k lines, which isn't too terribly large. There is, however, just one problem: I did the same project in less than 2k lines of code! It's a bloated masterpiece! [/rant] Has anyone else ever run into this scenario?
Actually, yes! In my college days, I was taking an AI class and one of my fellow students got around a language requirement for one assignment by writing a LISP interpreter in Prolog just so he could do the actual assignment in LISP (or maybe the other way around, I don't remember -- that was almost 20 years ago)
-
[rant] Here's the setup of an "unidentified" application: For some reason, the developer didn't want to code in the language to which he was assigned, so the first thing that he did was create an entire generator that allowed him to generate the "other" language so that he could continue to program in the language of his choice. The resulting application is so "objectified" that the object model is several layers deep, and in order to find a "Save" command, I have to wade through 20+ pages of documentation describing his monolithic object model. The irony of it all is that it's nicely structured, it has all of its unit tests, and it also has plenty of documentation. In all, I'd say the codebase is about 30k lines, which isn't too terribly large. There is, however, just one problem: I did the same project in less than 2k lines of code! It's a bloated masterpiece! [/rant] Has anyone else ever run into this scenario?
Reminds me of a job I did MANY years ago (when I was a fresh out of college 'grammer). Of course, my reasons were actually legitimate. We were using Turbo Pascal (TP3 I think, but not sure, circa 1986) to develop the project and I discovered that TPs keyboard interrupt routine would occassionally drop characters if you typed fast enough. So, I wrote a new keyboard interrupt routine in 8086 assembler, hand assembled it, and put it in as inline binary code (TP had a way to do that). Worked like a charm.
-
Reminds me of a job I did MANY years ago (when I was a fresh out of college 'grammer). Of course, my reasons were actually legitimate. We were using Turbo Pascal (TP3 I think, but not sure, circa 1986) to develop the project and I discovered that TPs keyboard interrupt routine would occassionally drop characters if you typed fast enough. So, I wrote a new keyboard interrupt routine in 8086 assembler, hand assembled it, and put it in as inline binary code (TP had a way to do that). Worked like a charm.
the handler used by the IDE or the one used by applications it built? I used TP6/7 in HS during the mid/late 90s. I never noticed a problem in the IDE, and IIRC apps built in it used the DOS handler by default. OTOH I'd replaced the one for DOS with a 255 char buffer instead of the paltry dozenish MSes used. For most of my larger apps I used a custom handler that supported multiple simultaneous key presses. I grabbed the ASM for both off the web though instead of writing my own.
-- If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
-
the handler used by the IDE or the one used by applications it built? I used TP6/7 in HS during the mid/late 90s. I never noticed a problem in the IDE, and IIRC apps built in it used the DOS handler by default. OTOH I'd replaced the one for DOS with a 255 char buffer instead of the paltry dozenish MSes used. For most of my larger apps I used a custom handler that supported multiple simultaneous key presses. I grabbed the ASM for both off the web though instead of writing my own.
-- If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
The one used by the apps it built... And the buffer was the problem. Boy is thi staking me back to that project 20+ years ago... I was a new developer and just knew that I needed to rapidly catch the keystrokes for processing. There weren't any standard "input" type fields on the application as it was a real time graphing system for statistical process control that processed data coming in through the keyboard buffer from various data-collection devices. Being a public/purchased application, we couldn't guarantee the devices would be configured with 40ms delays between simulated keystrokes. This was in the day when user's who bought the software put requirements on the software, not the other way around. There were several modules to the application. One was the device interface which would capture the input and push it into the keyboard buffer. The requirement was that the floor users had to be able to upload this data as fast as possible as well as be able to do near real-time input from the collection devices. The second module also ran in the background and collected that data from the keyboard buffer and wrote it to the datastore (a custom designed fixed-length flat file system with a unique indexing algorithm written by the senior developer). He was having a hard time with the buffer overflowing on large uploads and losing data, so he asked me to research alternatives. I came up with a cheap custome keyboard handler with a large (8K I think) buffer which would hold everything the largest device we supported at the time. At the same time, it sped up the processing of the data as the TP-based keyboard handler would type into a text field at a very slow paste. I could type 70 WPM at the time and I could make the simplest input field drop characters. The third and final part would continually update the various control graphs from the flat files. I did plenty with that eventually as well, but that's another topic. This was 1986 and the PC/AT was the latest and greatest thing. Windows 286 wasn't even dreamed of (much less 3.0, 3.1, Workgroups, or the future OSs) and the Mac was viewed as a "toy" for graphics designers and the like, not a serious machine for floor production systems. Instead, factory floors had ultradurable (and super-expensive for their day) PC or XT 8086/8088 based computers from Compaq or IBM. In short, creative "get it done" solutions that could do things quicker and with little overhead were the best. I think the assembler code took less than 1K so the whole thi
-
The one used by the apps it built... And the buffer was the problem. Boy is thi staking me back to that project 20+ years ago... I was a new developer and just knew that I needed to rapidly catch the keystrokes for processing. There weren't any standard "input" type fields on the application as it was a real time graphing system for statistical process control that processed data coming in through the keyboard buffer from various data-collection devices. Being a public/purchased application, we couldn't guarantee the devices would be configured with 40ms delays between simulated keystrokes. This was in the day when user's who bought the software put requirements on the software, not the other way around. There were several modules to the application. One was the device interface which would capture the input and push it into the keyboard buffer. The requirement was that the floor users had to be able to upload this data as fast as possible as well as be able to do near real-time input from the collection devices. The second module also ran in the background and collected that data from the keyboard buffer and wrote it to the datastore (a custom designed fixed-length flat file system with a unique indexing algorithm written by the senior developer). He was having a hard time with the buffer overflowing on large uploads and losing data, so he asked me to research alternatives. I came up with a cheap custome keyboard handler with a large (8K I think) buffer which would hold everything the largest device we supported at the time. At the same time, it sped up the processing of the data as the TP-based keyboard handler would type into a text field at a very slow paste. I could type 70 WPM at the time and I could make the simplest input field drop characters. The third and final part would continually update the various control graphs from the flat files. I did plenty with that eventually as well, but that's another topic. This was 1986 and the PC/AT was the latest and greatest thing. Windows 286 wasn't even dreamed of (much less 3.0, 3.1, Workgroups, or the future OSs) and the Mac was viewed as a "toy" for graphics designers and the like, not a serious machine for floor production systems. Instead, factory floors had ultradurable (and super-expensive for their day) PC or XT 8086/8088 based computers from Compaq or IBM. In short, creative "get it done" solutions that could do things quicker and with little overhead were the best. I think the assembler code took less than 1K so the whole thi
Draugnar wrote:
I think the assembler code took less than 1K so the whole thing was under 9K and our entire package could run on a 512K XT very reliably.
The handler or the application? IIRC the big buffer handler I'd used took less than 1k ram. I actually have the HD from my 486 sitting around somewhere, unless it suffered bitrot over the last few years I could probably still boot it if I actually wanted to.
-- If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
-
Draugnar wrote:
I think the assembler code took less than 1K so the whole thing was under 9K and our entire package could run on a 512K XT very reliably.
The handler or the application? IIRC the big buffer handler I'd used took less than 1k ram. I actually have the HD from my 486 sitting around somewhere, unless it suffered bitrot over the last few years I could probably still boot it if I actually wanted to.
-- If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
The handler module took 1K on disc and 9K in memory (adding in the 8K for the buffer). The whole application took significantly more (it's been 20+ years and my memory fades now that I'm in my 40s), but still ran on the 512K XTs that had been spec'd by our beta client (who got the final app at a greatly reduced price over the later retail clients). -Draugnar
-
Draugnar wrote:
I think the assembler code took less than 1K so the whole thing was under 9K and our entire package could run on a 512K XT very reliably.
The handler or the application? IIRC the big buffer handler I'd used took less than 1k ram. I actually have the HD from my 486 sitting around somewhere, unless it suffered bitrot over the last few years I could probably still boot it if I actually wanted to.
-- If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
The most interesting part of the project was the hand assembling. The Microsoft assembler put in header info for the linker that I didn't want as it was going in as inline binary, so I sat down with the 8086 Assembly manual and hand assembled it so I had just the code used by the routine. Having taken C+ (not C++) and 360/370 Assembler in college sure made that job a lot easier.
-
Actually, yes! In my college days, I was taking an AI class and one of my fellow students got around a language requirement for one assignment by writing a LISP interpreter in Prolog just so he could do the actual assignment in LISP (or maybe the other way around, I don't remember -- that was almost 20 years ago)
Probably PROLOG interpreter for LISP: the reverse would be extremely difficult. A number of these have been made. The best Common LISP implementation around is AllegroCL (still among the most powerful platforms, esp. with its unmatched AllegroCache). AllegroCL has an extension called AllegroPROLOG, which is implemented on top of AllegroCL in such a way that the programmer can mix LISP and PROLOG code freely, while the PROLOG code is compiled into LISP code and integrated properly. Pretty nice for certain applications, notably Artificial Intelligence, for which AllegroCL is probably best. -Nick P.