Software bloat (Larkin was right)
in [Design]
|
Prev: OrCad/ question
Next: Capture hierarchy
From: Phil Hobbs on 21 May 2010 12:08 On 5/21/2010 3:26 AM, D Yuniskis wrote: > Hi John, > > John Larkin wrote: >>>>> E.g., how would I even *begin* to assign part numbers to each >>>>> of the software modules I create? >>>> I'm talking about electronic parts, not software modules. We use a >>>> "telephone number", like 123-4567. The first three digits are the >>>> class (103- is the class for 0603 ceramic caps for example) and the >>>> last 4 digits are the specific part. 103-1300 is the 10 pF one. >>>> >>>> We have rules for *everything*. >>>> >>>> The best way to control software modules is to not have them: use one >>>> monolithic source file for a given project. We do assign a part number >>>> and a revision letter to a piece of software, just like any other >>>> engineering drawing. >>> I reuse modules often. It allows me to make "inexpensive" >>> solutions (instead of having to reinvent the wheel each time). >> >> I have an editor with advanced "cut" and "paste" features. > > Sure. But why cut and paste stuff when it already works "as is"? > It's documented, there is a test suite for it, etc. > >>> It would be quite hard for me to edit 5-50MB source files! >> >> YIKES! Nothing, not even an OS, should be that big! > > <grin> Products require an OS + application(s). I work > on *big* projects! :> > > But, if you think about it, it is not difficult to have > 10MB for a small-ish assembly language program. Assume a line > of code generates 1.5 bytes (most generate at least *one* > byte of code :> ). Most ASM opcodes are 3 or 4 chars. > Put a tab on each side of it gives us 5 or 6. Put some > arguments after it (register list, symbolic address of an > operand, etc.) probably adds at least 10 chars. One or more > tabs out to a "comment column" followed by 30 or 40 characters > of commentary (?) I.e., it's easy to have 50 characters > on that line for that 1.5 bytes of generated code. > > So, 100KB of code is ~3.5MB (note that we haven't included > any other overhead -- like EXTERNs, etc. -- nore any paragraphs > of pure commentary). > > I just looked at an old Z180 project that I did. Almost 9MB of > sources. Looks like it compiled to about 200K. So, that would > be 4.5MB/100KB code (roughly in line with my shirtsleeve estimate > above). > > My TCP/IP stack is over 100 files and a couple of megabytes of > source (C with a tiny mix of ASM). > > A quick peek at the NetBSD sources show ~20,000 files and > 100MB > for just the kernel (i.e., the equivalent of "Linux" -- without > any of the other OS utilities or applications). > > My multimedia OS is about a third of that -- but, it doesn't have > to run on 30 different architectures, support umpteen gazillion > different I/O boards, etc. > > No, it's just not practical to deal with any decent size product > as "one file"... > >> :> >>> And, incredibly inefficient having to compile all of that in one >>> piece. (besides the drawback of polluting the namespace therein) >> >> My PowerBasic programs rarely take a full second to compile. > > Building my entire OS from scratch ("make clean all") takes > several minutes on a 3G machine. Some of this would be sped > up if everything was in one giant file (less thrashing around > in the filesystem). > > But, since I rarely work on more than two files at a time, > I can do a typical incremental build in just a few seconds: > compile the two files that have changes, link and done. > >> What's a namespace? > > If you glue all of your modules together into one giant file, > then you have to ensure that nothing from any different > modules has the same name as something in *another* file > > E.g., if I have a (private/static) scrap routine called "copy()" > that is used in "window.c" to perhaps make a copy of a "window". > Now assume I want similar functionality for *menus*. So, > in "menu.c" I create a (private) routine called "copy()". > > Nothing outside of menu.c ever references the "copy()" that is > inside menu.c. Likewise, nothing outside of window.c ever > references the copy that is inside window.c. I.e., each "copy" > is private to the module in which it is defined. > > Now, if I glue all of window.c and all of menu.c together into > one big file, there will be *two* "copy()" routines. Two > identical names in the single file-scope namespace. (i.e., each > name within the file has to be unique). > > (you can actually work around this -- but, why work around > something when it just gives you a less desirable result? > Namely, an oversized source file?) > > Sort of like having two variables each called "X" and expecting > them to have different values and be accessed uniquely. Revision control software is a big help for this, and you can archive each release (and every change leading up to it). I use git, which I've become very fond of. My clusterized EM simulator is nearly 5 MB of .cpp and .h files, not to mention a 500 kB front end script! Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal ElectroOptical Innovations 55 Orchard Rd Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net
From: D Yuniskis on 21 May 2010 12:40 Hi Phil, Phil Hobbs wrote: > On 5/20/2010 2:03 PM, D Yuniskis wrote: >> This, I think, is an outgrowth of the same sort of >> ridiculous mindset that people initially bring to >> *organizing* data. E.g., how many part numbering systems >> have data embedded *in* the part number that tries to >> describe the item? (isn't that the role of the *description* >> tied to the P/N??) People impose structure on things >> unnecessarily instead of letting the machine do that on >> their behalf. >> >> E.g., when I started preparing documents, standards, etc. >> here, I used a much more commonsense approach: I started >> with *1* :> (instead of something artificial like >> 1985-SPEC-SFW-001.1 -- the ".1" being a revision level, etc.) >> Then, moved on to "2". >> >> Data should largely be free-form -- except where it *can't* :> >> This applies to part numbers, object (file) names, etc. Once >> you start imposing artificial structure, you start forcing >> things to be "done your way" -- which, typically, exposes >> some *flaw* in "your way", later (once you are *very* pregnant!) >> >> Put smarts in the system to be able to *understand* the data. > > It's sort of nice to be able to look at a part number and see whether > it's a capacitor or a BNC connector, though. That doesn't have to have > descriptions embedded in the part number, but it does need a bit of > thought, e.g. numbers starting with '0' are subassemblies, '1', > resistors, '2', capacitors, and so forth. Takes an extra couple of > digits but makes life a lot easier. I don't think it works, in the long run. And, I think the effort spent trying to figure out *how* to do this (and codifying it and ensuring everyone uses the same rules) is better used getting better descriptions, better search capabilities, etc. I don't understand the false security that comes from putting information like that in a "name" for an object. E.g., I likewise don't understand "hungarian notation" for naming variables. I'm sure glad my parents didn't name me: boy_son_eldest_Don! I see this sort of behavior in many places. People seem afraid to "let go" of data and trust something else to keep it handy (and safe!) for them! I see people building "databases" in spreadsheets simply because they fear "not seeing ALL the data". (and I mean *huge* spreadsheets -- hundreds of columns, thousands of rows) When shown how to get the same results with a database, they cringe because "it's magic" -- the numbers "just appear" instead of being displayed in front of them (static) all the time. I ask them, "How does seeing all of these numbers help you understand them? Do you know, for a fact, that *this* number HERE is correct? Are you sure the formula in this cell hasn't been changed in JUST this cell? Do you regularly examine the formulae? (glassy-eyed stare) Computers are good for two things: doing lots of things fast and remembering stuff. They've got me beat on both counts and I'd be foolish to try to compete with them :>
From: Joel Koltner on 21 May 2010 12:45 "D Yuniskis" <not.going.to.be(a)seen.com> wrote in message news:ht6cl3$jc8$1(a)speranza.aioe.org... > I don't understand the false security that comes from > putting information like that in a "name" for an object. > E.g., I likewise don't understand "hungarian notation" > for naming variables. I think there was a certain time period when software was getting pretty big and complex but the tools hadn't caught up yet when hungarian notation saved enough time in having to look up, "ok, now what type of object is this again?" could -- for some people -- outweigh the minor hassle of using it in the first place... although I never personally felt the benefit was enough to bother. These days development tools have so much "intellisense" built-in that I don't think there's much point anymore and (happily) you do see less and less of it. And to a certain extent, if you choose your variable and method names descriptively and write the interfaces well, people shouldn't have to worry about the exact type of your object anyway -- if you have a variable that's of type, e.g., "EmployeeName," it should be safe to assume it can act like a string. > I'm sure glad my parents didn't name me: boy_son_eldest_Don! I try to convine people that if you have a schematic sitting in, e.g., c:\Schematics\Top Secret Projects\NSA Spy Satellite\RF Transmitter, it's kinda silly ot make the file name "Top Secret NSA Spy Satellite RF Transmitter Schematic.SCH," but not everyone buys into this. (Granted, I'm exaggerating, but you get the idea -- I really do see a lot of "Project Name Functional Name Schematic.SCH" files...) ---Joel
From: John Larkin on 21 May 2010 13:30 On Fri, 21 May 2010 09:40:00 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >Hi Phil, > >Phil Hobbs wrote: >> On 5/20/2010 2:03 PM, D Yuniskis wrote: >>> This, I think, is an outgrowth of the same sort of >>> ridiculous mindset that people initially bring to >>> *organizing* data. E.g., how many part numbering systems >>> have data embedded *in* the part number that tries to >>> describe the item? (isn't that the role of the *description* >>> tied to the P/N??) People impose structure on things >>> unnecessarily instead of letting the machine do that on >>> their behalf. >>> >>> E.g., when I started preparing documents, standards, etc. >>> here, I used a much more commonsense approach: I started >>> with *1* :> (instead of something artificial like >>> 1985-SPEC-SFW-001.1 -- the ".1" being a revision level, etc.) >>> Then, moved on to "2". >>> >>> Data should largely be free-form -- except where it *can't* :> >>> This applies to part numbers, object (file) names, etc. Once >>> you start imposing artificial structure, you start forcing >>> things to be "done your way" -- which, typically, exposes >>> some *flaw* in "your way", later (once you are *very* pregnant!) >>> >>> Put smarts in the system to be able to *understand* the data. >> >> It's sort of nice to be able to look at a part number and see whether >> it's a capacitor or a BNC connector, though. That doesn't have to have >> descriptions embedded in the part number, but it does need a bit of >> thought, e.g. numbers starting with '0' are subassemblies, '1', >> resistors, '2', capacitors, and so forth. Takes an extra couple of >> digits but makes life a lot easier. > >I don't think it works, in the long run. And, I think >the effort spent trying to figure out *how* to do this >(and codifying it and ensuring everyone uses the same >rules) is better used getting better descriptions, better >search capabilities, etc. It is convenient to have all the 0805 resistors in the same part of the stockroom, and not mixed randomly with transformers and sheet metal and shrink tubing. Even more convenient to have them in order by resistance. > >I don't understand the false security that comes from >putting information like that in a "name" for an object. >E.g., I likewise don't understand "hungarian notation" >for naming variables. > >I'm sure glad my parents didn't name me: boy_son_eldest_Don! Be more grateful it wasn't boy_son_eldest_Susan. After all, names don't mean anything, so any random choice is as good as any other. John
From: John Larkin on 21 May 2010 13:31
On Thu, 20 May 2010 21:40:17 -0400, "Michael A. Terrell" <mike.terrell(a)earthlink.net> wrote: > >John Larkin wrote: >> >> On Thu, 20 May 2010 10:02:00 -0700, D Yuniskis >> <not.going.to.be(a)seen.com> wrote: >> >> >Hi John, >> > >> >John Larkin wrote: >> >>> For a lean, poor man's "GUI", consider using a manu system >> >>> atop curses. *Very* fast (even over a serial link!) and >> >>> has all the "feel" of a GUI without the G. >> >> >> >> Here's our parts thing, home page. It's all single-letter keystroke >> >> commands and prompts. It a blast to drive. >> >> >> >> ftp://jjlarkin.lmi.net/MAX.jpg >> >> >> >> You can look at all parts, do searches, do where-used, browse parts >> >> lists, see datasheets/photos/links/engineering notes. Parts selected >> >> in one context are carried over into others... you can prowl a parts >> >> list, highlight a part, escape out, and the part is featured on the >> >> home page. Then do where-used, or open the part data file, or enter >> >> the total parts report at that point. >> > >> >You developed this in-house? Why not use something off-the-shelf? >> >(OTOH, most OTS solutions force you to do business "their way") >> >> We tested some commercial packages and didn't like them. They clearly >> didn't understand the electronics business, were slow (usually sat on >> top of a general-purpose database manager, a hazard in itself) and >> often had silly per-seat-per-year license rules. >> >> I wrote the skeleton of this myself and we hired a contract guy to do >> the detail coding. The biggest part wasn't the code, it was inventing >> and documenting a new part numbering system, re-describing all the >> parts in stock (close to 5000 of them) and moving/relabeling all the >> bins. It was worth it, and now we own the source code. >> >> The Brat bird-dogged the project to completion, including browbeating >> the programmer into doing good work and forcing the engineers to go >> through those 5000 part records one at a time. I was impressed. > > > Did she use a whip and a chair, or a pistol? ;-) Force of personality, plus lots of pizza. John |