The availability of components that do a myriad of tasks could lead programmer complacency
Look around. There are many software development components. Do you need to write a program that displays HTML? There is an HTML-displaying component. Do you need to write a program that plays a MIDI file? There is a MIDI-file-playing component. Do you need to write a program that uses a stack, queue or other classic data structure? There are data structure components. Indeed, many of the programming challenges that used to take hours, or days or weeks to write are now available as components.
It is certainly true that components have some very good properties. Software developers can save substantial amounts of time by using previously-written components. Also, as Joshua Bloch pointed out in "Effective Java," these components probably consist of high quality code written by professionals .
On the other hand, components might come with an undesireable side-effect. The availability of components that can do such a myriad of typical tasks could lead us programmers to a place of complacency where we do not know how the code in the components was written.
Perhaps the ability to rewrite component code from the ground up is not something that will be of much importance in day-to-day software engineering. Provided that someone, somewhere, will write components for whatever languages we will be using in the future, then we can continue to use the components. There is something to be said, though, for what programmers learn by way of writing such code for themselves.
In college, I sharpened my programming skills by, more than once, writing code for routine things such as linked lists. I was not doing any groundbreaking data structure research, and probably whatever linked list component came with our programming system would have worked just as well as, if not better than, what I wrote. But I still gained valuable knowledge and experience just by going through the motions of writing this code.
Imagine what we could learn, then, by writing our own HTML format and display code? Or our own MIDI file-playing code? Of course, not every programmer should necessarily attempt to implement every sort of existing component. But, from time to time, if a certain task seems interesting, it could be worth the effort just for the educational benefit. And, perhaps more importantly, by doing so we will not lose track of how all of the parts that we use were built.
If you're mainly interested in getting the job done fast and correctly, then by all means, reach for the components. That's what they are there for. If you have some spare time and want to spend it writing code, then you could consider rewriting a component. You may end up finding a better way of doing things than the writer of the component did. Or, if nothing else, you may simply gain algorithmic insight and become better equipped for future programming tasks. After all, it's good for us to know how we got here, and to be prepared to explore someplace new.
 Bloch, Josuha. Effective Java Programming Language Guide. Published by Addision-Wesley, 2001.
A Ubiquity symposium is an organized debate around a proposition or point of view. It is a means to explore a complex issue from multiple perspectives. An early example of a symposium on teaching computer science appeared in Communications of the ACM (December 1989).
To organize a symposium, please read our guidelines.
Ubiquity Symposium: Big Data
- Big Data, Digitization, and Social Change (Opening Statement) by Jeffrey Johnson, Peter Denning, David Sousa-Rodrigues, Kemal A. Delic
- Big Data and the Attention Economy by Bernardo A. Huberman
- Big Data for Social Science Research by Mark Birkin
- Technology and Business Challenges of Big Data in the Digital Economy by Dave Penkler
- High Performance Synthetic Information Environments: An integrating architecture in the age of pervasive data and computing By Christopher L. Barrett, Jeffery Johnson, and Madhav Marathe
- Developing an Open Source "Big Data" Cognitive Computing Platform by Michael Kowolenko and Mladen Vouk
- When Good Machine Learning Leads to Bad Cyber Security by Tegjyot Singh Sethi and Mehmed Kantardzic
- Corporate Security is a Big Data Problem by Louisa Saunier and Kemal Delic
- Big Data: Business, technology, education, and science by Jeffrey Johnson, Luca Tesei, Marco Piangerelli, Emanuela Merelli, Riccardo Paci, Nenad Stojanovic, Paulo Leitão, José Barbosa, and Marco Amador
- Big Data or Big Brother? That is the question now (Closing Statement) by Jeffrey Johnson, Peter Denning, David Sousa-Rodrigues, Kemal A. Delic