It isn't bloat, until it makes an executable fat... which is generally only the result of using *many* specializations of a template or templates. Using the template construct && STL wisely (like programming sensibly in general) will result in code of respectible size. General misnomers need not apply;P
Remember, the designers of the STL selected templates knowing full that template instantination results in 'duplicate' code (a.k.a. specialized code). Their reasoning (from memory) was soley for performance and policy issolation. Had they selected the ABC approach (base class) people would whine about performance.
Comming from requirements in the C world (the same one that spawned most of the early C++ adopters), using templates is the obvious best choice. Read (or reread) 'The C++ programming language' and 'Design and evolution of the C++ language' by Stroustrup... the design choices, and implied costs/reasons to use are well documented.
lol... from fud surrounding one topic to another. the STL is no more bloated than my mother-in-law. err, hmmm... wait... no more bloated than a canned ham. what do you mean by bloat anyway? unqualified mud-slinging is no where near as fun.
I disagree. C++ is intended to solve systems in the language of the domain - which is one of the central purposes of the language (see Design and Evolution of C++ by Stroustrup). Some of the strongest uses of C++ I've seen today are well abstracted matrix libraries for advanced signal processing (Blitz++)... not too far from what the question is asking about.
i remember bumping into a russian s/f collection at a public library when i was in grade school (from the 70s)... and have never found a good collection since. i found, then, that russian s/f was different - but quite cool. much of that particular collection was dark, but well concieved... strange enough that it left me then wanting more (not far from some of the warped orson scott card short s/f). our puny little local library system, though, didn't have any other russian s/f - and since i've not seen many translated works around. *most* excellent.
I've been using PACE/ACE for a number of years now for manufacturing control systems. The libraries are solid, and well tested... and provide good portability to a dozen platforms. Ace provides some great high-level C++ abstractions, and PACE is a solid set of C interfaces to common OS stuff. I have a few systems based on Ace/Pace that have uptimes > 1 year... and ramp up to the library was short. I would stay away from their container classes, and use STLPort instead.
I've installed Redhat7.1 on a dozen machines at work (server class and desktop) and only one took more than an hour... and that was because of a machine mis-configuration. The developers using the desktop machines had their development environments set up in a matter of minutes, and were productive before eating lunch. Win2k is an easy install as well, but takes several reboots (assuming a high-driver-karma day).
For me, I just prefer the Freedom of Gnu/Linux... and detest the draconic nature of Microsoft - though their systems are usable. I love the quality of the Free software I use, and the fact that most of it is free is cool as well.
Recently we switched from Dell to building our own machines here, as Dell service in Canada is terrible. We have had to wait weeks for new hard drives, only to have to return them... memory replacements have all been with refurbished memory that was non-functional... and phone support is painful. Additionally, we have found Dell hardware is completly mediocre, with at least one edge component (HD, CDRom, floppy, monitors) failing within a year... and performance is below average as the machines tend to be behind technologically (slower busses, etc.). For the premium price, you get marginal support, hardware, and performance.
We used to buy Micron laptops where I work, and they were wonderful machines -- and well supported. I dropped one of my laptops due to the zipper of the laptop case tearing, and they replaced it in 24 hours. Unfortunatly, our company decided to go with another vendor... which has been problematic since.
I am a young software architect, promoted a few years ago (when I was 26). The transition from lead developer was difficult, mostly because I resisted the fact that 'architect' is really quasi-management. It is a role that requires gobs of communication, documentation, and strong leadership skills.
The key, I find, is to somehow remember your passion for the role of desinging and preaching systems to a group on a regular basis. I look for things that remind me why I like coding, design, and bringing good sense to the people I serve. And remember, you serve the entire company; your role is to make decisions that will enable the business, and be within the abilities of the developmers and testers.
Ignore the fact that you are younger, it will only undermine your authority. Remember to excercise your authority when it is important, and to let the little things go. And, humility will buy you loads of respect.
Most of all, dream constantly about software design, etc.... as innovation is the product of passion, and borderline insanity. And, never stop learning. Don't let a month go by without reading a dozen books and implementing at least a handful of things based on what you learn.
Will you stop coding? Only if you want to. You are now a leader, so if coding is essential, then you direct your copmany to allow for your position to code. I set asside 10-20% research time (coding/reading), and I prototype around many of the new technologies we add to our product regularly. And, you are Free to contribute to the GNU project in your spare time;P
the power of cli apps is the fact that both the programatic interface to the component model and the user interface are the same thing! the user interface mecanism provides a 'quasi' natural language interface (which can be quite productive), and the programatic interface provides a convinient way of putting components together for solving problems.
what i don't get is how gui-centric ppl can't see the simple advantage of cli (at least for server/backend components). the same interface gives you a programatic interface (in all languages), and a simple user interface. what a bonus... you learn the user interface, and you know the programatic interface. few component models are so easy to interact with.
are clis the end-all of user interfaces? of course not... but they are a useful tool, and a powerful paradigm for componentizing software.
a few systems have good solutions for dll/so madness... though good design really reduces the problem. for example, nextstep and apple's os-x use resource maps/app packages so the shared objects are mapped properly in the application package, and can be stored there or in the system packages. tru64 uses a filesystm/kernal.so versioning scheme... that allows multiple versions of libraries to exist and be served somewhat sensible. and i am sure there are others. luckily, linux has the potential to improve the library hell...
so when i paint a new picture in real life, where do i put it? do i put it on the shelf in the den, or do i file it in the basement with my college art? real life models in many places where things need places to exist... what computers may be able to do for us is improve/automate the process. hiding the fact that things go places may not actually help.
good pt. about learning applications. repeating the same tasks over time should not take a linear cost in human interaction... but rather the cost should start to drop over time. one thing that i think important in featutures like this (application learning) is that the implementation needs to be shared, and not propietary to each tool. ie., a learning library could be part of a window manager, toolkit, or even os... but hopefully not unique to each tool.
I won't hire developers who lack passion either... there is little value in the productivity of a drone - slow, forward, unmotivated movement is rarely the best thing for a product. Dispassionate developers result in adequate output at best, and not the sort of thing that has incredible quality (or other attributes).
Developers without passion generally stagnate in their learning (only learning the least amount required), they are not as committed to quality, they don't think about product problems endlessly... their cranial output is limited. Software is rarly akin to industrial production, and more often a sort of craftmanship (there are exceptions, but in the general case) - a craftsperson needs to strongly desire to learn/do more... it is part of who they are.
| Oh, I have my criticisms of C++: A new standard
| is a mistake when no on produces a fully-ISO
| compliant compiler today. The STL is an ugly
| mess designed by committee; I'd like to see
| restricted template arguments, inheritable
| enums, and a few other new ideas.
the stl wasn't designed by committee, but by stepanov... and is one of the most brilliant designs i've seen to date.
Proprietary data files (and interfaces to those files) are the limiting factor between different 'suites' of applications, and not the suites themselves. Microsoft, for example, has deliberately hoarded the specifications of their file formats... which results in a lack of easy operability outside of their binaries. The result of this is the requirement for Microsoft's proprietary embeddable COMponents or binary viewers, as viewing/editing/access of those files requires a proprietary binary to be used.
Imagine an open format for the hoarded MS office suite formats (or any suite)... where there could be any number of viewers/interfaces/tools - which solve for different uses of the files (like a command line viewer, text mode viewer, browser viewer, summary viewer, etc., etc.). Things like embedded COM (for the purpose of displaying a proprietary document) become less important as the source for many viewers would be available. The choice to COMponentize would be a separate issue, and a system would not *have* to rely on COMponents or even a COMponent system for that purpose. COMponent systems can be a good thing, but access to data should *never* be limited to one platform/vendor/library/etc. That is just evil.
The best case, in my opinion, are strong standards in the data formats and simple, open data access libraries and/or COMponents. Viewing, editing, reporting, or otherwise can have as many implementations, platforms, paradigms as a user base will support. Limiting the high level functionality to one group, vendor or open 'suite' is not far from proprietary... and does not serve the users well.
In the end, leaders in an open system are naturally selected - and can change over time, whether sources are open or not. In a closed standards system (a la microslop or otherwise) leaders are selected naturally initially (and even then sometimes selected by oem agreements and similar)... but from that point the competition is obstructed. The obstruction of competition not only results in fewer user choices, but also the lasting future of the data encloesd in the propietary formats... and use of that data in as many ways as could be useful.
Propietary standards are evil. Closed data interface libraries, or user access to that data (via 'suites') is evil as well. The data needs to be free, access to the data needs to be free, extending the possible uses of the data needs to be free as well. There may be room for propietary extensions of use, but not in exclusion... and not in a way that comprimises the freedoms of the user. The key is to provide the users with the greatest freedoms possible.
we did something very similar to this a few years back with poor performance on inter-process data transit with com... implemented a work-around as MS took their sweet time even returning calls.
there's more to it, and more than just personal stuff to post. for me, i use my blogs as a place to store design thoughts, geek links, bad prose, and thoughts on my current oss projects. personal life? i suppose, but also a way to record my cranium from a few locations, share it with a few people - gaining the ability to read it 2 weeks later.
and the macro-personal blogs are cool too, a window into another being... sometimes funny, sometimes boring, sometimes stupid. who cares?! if you are interested in seeing inside peoples heads - even if it is filtered through ego, html, and prose... blogs rock.
except that MS provides two models for scripting that are not at ALL related, and the OLE version lacks the interactive command interface (past the gui system). sepparating the command line from ole interfaces is a terrible waste... which also results in the inability to use the ole interfaces interactively from a command line. bringing those two together would be a better thing for the fragmented OS.
having any assumption about interface as a fundamentally part of the os is a BAD THING. most unixes do it right by issolating all user services from the core of things... this is the beauty of it.
the problem with windows wasn't only that it was built on dos, more that dos had the cli integrated with its own core... and windows made the same mistake holding shell.dll so close to its own testicles. bad sepparation and assumptions about the user groups has brought about an operating system barely useful for everyday use... and butt-ass-useless for server applications. mac OS-9 and less have similar problems... a poor core, with a tightly integrated gui system... no sepparation, no flexibility.
why should something like tar need to implement anything to do with a gui? that is the reason tools on other platforms are *so* bad... the gui is the focus, and takes away from the principle of simplicity. the basic concept of having a gui that can give information about the status of a tool like tar isn't flawed, but thinking that tar should have anything to do with the implementation is. simplicity in the basic tools is one of the foundations of the unix philosophy.
if a gui on tar is needed, then the best route to it is to provide an easy way for the functionality to exist for free... like a console window, or a wrapper that takes the stdout/err and displays progress. don't fsk with the good stuff;P... the componentisation of unix is what makes it so good. that and stability, power, and the many freedoms it can provide.
that's actually a good point, that corel's aim was one of control - not that of community contribution. they failed to make money not because there isn't a market in adding value to Free things, but because they were unable to figure it out for themselves. they didn't add much value by introducing a crappy, visionless distro. not that they add much value to the software market with their crappy, visionless products.
i'd agree that pair programming is a crock. frequent reviews of requirements, specs, design, implementations and aggressive refactoring are much more effective in every situation i have seen (and those i've read about). pair programming seems to result in a quick path to a loss of focus... which can occur in any shaped development. focus is really one of the keys, along with vision and raw fsking ability (too many lame developers out there).
refactoring, in a group of people that don't understand how to do it well, can be an evil thing indeed. i have found that it can take a group years to get the sense of community required to be able to refactor the shared code in a way that is natural and forward moving. the problem? a shared sense of direction. overdesign is not a problem, as some have mentioned... shared vision is what is needed for group refactoring to happen happily. if a group of people are not focused on what something should (or could) be, then the efforts of refactoring will be pulling the product in *MANY* different directions. non-XP programming wins out in a shop with a lack of focus, as the focus is generated by a select few (often a few select twits)... where XP, or group enabled development relies of a focus shared by many people, which can be an incredible thing - when it works.
trolls were sparse on most boards, because membership required peer (board) review. twits were kicked+banned, and that was that. and, many boards were payforuse, which probably added to the troll filter.
as for offtopic conversations, some interesting stuff comes out of that... i like offtopic, but can't stand the trolling twits.
Slashdot Mirror
It isn't bloat, until it makes an executable fat ... which is generally only the result of using *many* specializations of a template or templates. Using the template construct && STL wisely (like programming sensibly in general) will result in code of respectible size. General misnomers need not apply ;P
... the design choices, and implied costs/reasons to use are well documented.
Remember, the designers of the STL selected templates knowing full that template instantination results in 'duplicate' code (a.k.a. specialized code). Their reasoning (from memory) was soley for performance and policy issolation. Had they selected the ABC approach (base class) people would whine about performance.
Comming from requirements in the C world (the same one that spawned most of the early C++ adopters), using templates is the obvious best choice. Read (or reread) 'The C++ programming language' and 'Design and evolution of the C++ language' by Stroustrup
lol ... from fud surrounding one topic to another. the STL is no more bloated than my mother-in-law. err, hmmm ... wait ... no more bloated than a canned ham. what do you mean by bloat anyway? unqualified mud-slinging is no where near as fun.
I disagree. C++ is intended to solve systems in the language of the domain - which is one of the central purposes of the language (see Design and Evolution of C++ by Stroustrup). Some of the strongest uses of C++ I've seen today are well abstracted matrix libraries for advanced signal processing (Blitz++) ... not too far from what the question is asking about.
i remember bumping into a russian s/f collection at a public library when i was in grade school (from the 70s) ... and have never found a good collection since. i found, then, that russian s/f was different - but quite cool. much of that particular collection was dark, but well concieved ... strange enough that it left me then wanting more (not far from some of the warped orson scott card short s/f). our puny little local library system, though, didn't have any other russian s/f - and since i've not seen many translated works around. *most* excellent.
I've been using PACE/ACE for a number of years now for manufacturing control systems. The libraries are solid, and well tested ... and provide good portability to a dozen platforms. Ace provides some great high-level C++ abstractions, and PACE is a solid set of C interfaces to common OS stuff. I have a few systems based on Ace/Pace that have uptimes > 1 year ... and ramp up to the library was short. I would stay away from their container classes, and use STLPort instead.
I've installed Redhat7.1 on a dozen machines at work (server class and desktop) and only one took more than an hour ... and that was because of a machine mis-configuration. The developers using the desktop machines had their development environments set up in a matter of minutes, and were productive before eating lunch. Win2k is an easy install as well, but takes several reboots (assuming a high-driver-karma day).
For me, I just prefer the Freedom of Gnu/Linux ... and detest the draconic nature of Microsoft - though their systems are usable. I love the quality of the Free software I use, and the fact that most of it is free is cool as well.
Recently we switched from Dell to building our own machines here, as Dell service in Canada is terrible. We have had to wait weeks for new hard drives, only to have to return them ... memory replacements have all been with refurbished memory that was non-functional ... and phone support is painful. Additionally, we have found Dell hardware is completly mediocre, with at least one edge component (HD, CDRom, floppy, monitors) failing within a year ... and performance is below average as the machines tend to be behind technologically (slower busses, etc.). For the premium price, you get marginal support, hardware, and performance.
We used to buy Micron laptops where I work, and they were wonderful machines -- and well supported. I dropped one of my laptops due to the zipper of the laptop case tearing, and they replaced it in 24 hours. Unfortunatly, our company decided to go with another vendor ... which has been problematic since.
I am a young software architect, promoted a few years ago (when I was 26). The transition from lead developer was difficult, mostly because I resisted the fact that 'architect' is really quasi-management. It is a role that requires gobs of communication, documentation, and strong leadership skills.
The key, I find, is to somehow remember your passion for the role of desinging and preaching systems to a group on a regular basis. I look for things that remind me why I like coding, design, and bringing good sense to the people I serve. And remember, you serve the entire company; your role is to make decisions that will enable the business, and be within the abilities of the developmers and testers.
Ignore the fact that you are younger, it will only undermine your authority. Remember to excercise your authority when it is important, and to let the little things go. And, humility will buy you loads of respect.
Most of all, dream constantly about software design, etc. ... as innovation is the product of passion, and borderline insanity. And, never stop learning. Don't let a month go by without reading a dozen books and implementing at least a handful of things based on what you learn.
Will you stop coding? Only if you want to. You are now a leader, so if coding is essential, then you direct your copmany to allow for your position to code. I set asside 10-20% research time (coding/reading), and I prototype around many of the new technologies we add to our product regularly. And, you are Free to contribute to the GNU project in your spare time ;P
cli apps provide two basic constructs:
the power of cli apps is the fact that both the programatic interface to the component model and the user interface are the same thing! the user interface mecanism provides a 'quasi' natural language interface (which can be quite productive), and the programatic interface provides a convinient way of putting components together for solving problems.
what i don't get is how gui-centric ppl can't see the simple advantage of cli (at least for server/backend components). the same interface gives you a programatic interface (in all languages), and a simple user interface. what a bonus ... you learn the user interface, and you know the programatic interface. few component models are so easy to interact with.
are clis the end-all of user interfaces? of course not ... but they are a useful tool, and a powerful paradigm for componentizing software.
a few systems have good solutions for dll/so madness ... though good design really reduces the problem. for example, nextstep and apple's os-x use resource maps/app packages so the shared objects are mapped properly in the application package, and can be stored there or in the system packages. tru64 uses a filesystm/kernal .so versioning scheme ... that allows multiple versions of libraries to exist and be served somewhat sensible. and i am sure there are others. luckily, linux has the potential to improve the library hell ...
so when i paint a new picture in real life, where do i put it? do i put it on the shelf in the den, or do i file it in the basement with my college art? real life models in many places where things need places to exist ... what computers may be able to do for us is improve/automate the process. hiding the fact that things go places may not actually help.
good pt. about learning applications. repeating the same tasks over time should not take a linear cost in human interaction ... but rather the cost should start to drop over time. one thing that i think important in featutures like this (application learning) is that the implementation needs to be shared, and not propietary to each tool. ie., a learning library could be part of a window manager, toolkit, or even os ... but hopefully not unique to each tool.
I won't hire developers who lack passion either ... there is little value in the productivity of a drone - slow, forward, unmotivated movement is rarely the best thing for a product. Dispassionate developers result in adequate output at best, and not the sort of thing that has incredible quality (or other attributes).
... their cranial output is limited. Software is rarly akin to industrial production, and more often a sort of craftmanship (there are exceptions, but in the general case) - a craftsperson needs to strongly desire to learn/do more ... it is part of who they are.
Developers without passion generally stagnate in their learning (only learning the least amount required), they are not as committed to quality, they don't think about product problems endlessly
| Oh, I have my criticisms of C++: A new standard
... and is one of the most brilliant designs i've seen to date.
| is a mistake when no on produces a fully-ISO
| compliant compiler today. The STL is an ugly
| mess designed by committee; I'd like to see
| restricted template arguments, inheritable
| enums, and a few other new ideas.
the stl wasn't designed by committee, but by stepanov
Proprietary data files (and interfaces to those files) are the limiting factor between different 'suites' of applications, and not the suites themselves. Microsoft, for example, has deliberately hoarded the specifications of their file formats ... which results in a lack of easy operability outside of their binaries. The result of this is the requirement for Microsoft's proprietary embeddable COMponents or binary viewers, as viewing /editing /access of those files requires a proprietary binary to be used.
... where there could be any number of viewers/interfaces/tools - which solve for different uses of the files (like a command line viewer, text mode viewer, browser viewer, summary viewer, etc., etc.). Things like embedded COM (for the purpose of displaying a proprietary document) become less important as the source for many viewers would be available. The choice to COMponentize would be a separate issue, and a system would not *have* to rely on COMponents or even a COMponent system for that purpose. COMponent systems can be a good thing, but access to data should *never* be limited to one platform/vendor/library/etc. That is just evil.
... and does not serve the users well.
... but from that point the competition is obstructed. The obstruction of competition not only results in fewer user choices, but also the lasting future of the data encloesd in the propietary formats ... and use of that data in as many ways as could be useful.
... and not in a way that comprimises the freedoms of the user. The key is to provide the users with the greatest freedoms possible.
Imagine an open format for the hoarded MS office suite formats (or any suite)
The best case, in my opinion, are strong standards in the data formats and simple, open data access libraries and/or COMponents. Viewing, editing, reporting, or otherwise can have as many implementations, platforms, paradigms as a user base will support. Limiting the high level functionality to one group, vendor or open 'suite' is not far from proprietary
In the end, leaders in an open system are naturally selected - and can change over time, whether sources are open or not. In a closed standards system (a la microslop or otherwise) leaders are selected naturally initially (and even then sometimes selected by oem agreements and similar)
Propietary standards are evil. Closed data interface libraries, or user access to that data (via 'suites') is evil as well. The data needs to be free, access to the data needs to be free, extending the possible uses of the data needs to be free as well. There may be room for propietary extensions of use, but not in exclusion
support, my ass!
there's more to it, and more than just personal stuff to post. for me, i use my blogs as a place to store design thoughts, geek links, bad prose, and thoughts on my current oss projects. personal life? i suppose, but also a way to record my cranium from a few locations, share it with a few people - gaining the ability to read it 2 weeks later.
... sometimes funny, sometimes boring, sometimes stupid. who cares?! if you are interested in seeing inside peoples heads - even if it is filtered through ego, html, and prose ... blogs rock.
and the macro-personal blogs are cool too, a window into another being
except that MS provides two models for scripting that are not at ALL related, and the OLE version lacks the interactive command interface (past the gui system). sepparating the command line from ole interfaces is a terrible waste ... which also results in the inability to use the ole interfaces interactively from a command line. bringing those two together would be a better thing for the fragmented OS.
having any assumption about interface as a fundamentally part of the os is a BAD THING. most unixes do it right by issolating all user services from the core of things ... this is the beauty of it.
... and windows made the same mistake holding shell.dll so close to its own testicles. bad sepparation and assumptions about the user groups has brought about an operating system barely useful for everyday use ... and butt-ass-useless for server applications. mac OS-9 and less have similar problems ... a poor core, with a tightly integrated gui system ... no sepparation, no flexibility.
the problem with windows wasn't only that it was built on dos, more that dos had the cli integrated with its own core
why should something like tar need to implement anything to do with a gui? that is the reason tools on other platforms are *so* bad ... the gui is the focus, and takes away from the principle of simplicity. the basic concept of having a gui that can give information about the status of a tool like tar isn't flawed, but thinking that tar should have anything to do with the implementation is. simplicity in the basic tools is one of the foundations of the unix philosophy.
... like a console window, or a wrapper that takes the stdout/err and displays progress. don't fsk with the good stuff ;P ... the componentisation of unix is what makes it so good. that and stability, power, and the many freedoms it can provide.
if a gui on tar is needed, then the best route to it is to provide an easy way for the functionality to exist for free
that's actually a good point, that corel's aim was one of control - not that of community contribution. they failed to make money not because there isn't a market in adding value to Free things, but because they were unable to figure it out for themselves. they didn't add much value by introducing a crappy, visionless distro. not that they add much value to the software market with their crappy, visionless products.
i'd agree that pair programming is a crock. frequent reviews of requirements, specs, design, implementations and aggressive refactoring are much more effective in every situation i have seen (and those i've read about). pair programming seems to result in a quick path to a loss of focus ... which can occur in any shaped development. focus is really one of the keys, along with vision and raw fsking ability (too many lame developers out there).
refactoring, in a group of people that don't understand how to do it well, can be an evil thing indeed. i have found that it can take a group years to get the sense of community required to be able to refactor the shared code in a way that is natural and forward moving. the problem? a shared sense of direction. overdesign is not a problem, as some have mentioned ... shared vision is what is needed for group refactoring to happen happily. if a group of people are not focused on what something should (or could) be, then the efforts of refactoring will be pulling the product in *MANY* different directions. non-XP programming wins out in a shop with a lack of focus, as the focus is generated by a select few (often a few select twits) ... where XP, or group enabled development relies of a focus shared by many people, which can be an incredible thing - when it works.
trolls were sparse on most boards, because membership required peer (board) review. twits were kicked+banned, and that was that. and, many boards were payforuse, which probably added to the troll filter.
... i like offtopic, but can't stand the trolling twits.
as for offtopic conversations, some interesting stuff comes out of that