Please enter verification code
Confirm
The Cognitive Programming Paradigm the Next Programming Struture
American Journal of Software Engineering and Applications
Volume 2, Issue 2, April 2013, Pages: 54-67
Received: Mar. 25, 2013; Published: Apr. 2, 2013
Views 3527      Downloads 247
Author
Benjamin Odei Bempong, Information and Communication Technology/Mathematics Department Presbyterian University College, Ghana. Abetifi-Kwahu, Eastern Region
Article Tools
PDF
Follow on us
Abstract
The development of computer programming started with the development of the switching logic, because, the computer hardware is made up of millions of digital switches. The activation and deactivation of these switches are through codified instructions – (program) which trigger the switches to function. The computer programming languages have gone through a revolution, from the machine code language, through assembly mnemonics to the high level programming languages like FORTRAN, ALGOL, COBOL, LISP, BASIC, ADA and C/C++. It is a fact that, these programming languages are not the exact codes that microprocessors do understand and work with, because through compiler and interpreter programs, these high level programming languages that are easily understood by people are converted to machine code languages for the microprocessor to understand and do the work human knowledge has instructed it to do. The various programming languages stem from the difficulties man has in using one programming language to solve different problems on the computer. Hence, for mathematical and trigonometrically problems, FORTRAN is the best, for business problems, COBOL is the right language, whilst for computer games and designs, BASIC language is the solution. The trend of using individual programming languages to solve specific problems by single processor computers have changed drastically, from single core processors to present day dual and multi-core processors. The main target of engineers and scientists is to reach a stage that the computer can think like the human brain. The human brain contains many cognitive (thinking) modules that work in parallel to produce a unique result. With the presence of multi-core processors, why should computers continue to draw summaries from stored databases, and allow us to sit hours to analyse these results to find solutions to problems? The subject of ‘Cognitive Programming Paradigm’, analyses the various programming structures and came out that these programming structures are performing similar tasks of processing stored databases and producing summarized information. These summarized information are not final, business managers and Executives have to sit hours to deliberate on what strategic decisions to take. Again, present day computers cannot solve problems holistically, as normally appear to human beings. Hence, there’s the need for these programming structures be grouped together to solve human problems holistically, like the human brains processing complex problems holistically. With the presence of multi-core processors, its possible to structure programming such that these programming structures could be run in parallel to solve a specific problem completely, i.e. be able to analyse which programming structure will be suitable for a particular problem solving or be able to store first solution and compare with new solutions of a problem to arrive at a strategic decision than its being done at present. This approach could lift the burden on Managers and Executives in deliberating further on results of a processed business problem.
Keywords
Programming; Structure; Cognitive; Paradigm
To cite this article
Benjamin Odei Bempong, The Cognitive Programming Paradigm the Next Programming Struture, American Journal of Software Engineering and Applications. Vol. 2, No. 2, 2013, pp. 54-67. doi: 10.11648/j.ajsea.20130202.15
References
[1]
Edsger Dijkstra, Notes on Structured Programming, pg. 6
[2]
Böhm, C. and Jacopini, G.: Flow diagrams, Turing machines and languages with only two formation rules, CACM 9(5), 1966.
[3]
Michael A. Jackson, Principles of Program Design, Academic Press, London, 1975.
[4]
O.-J. Dahl, E. W. Dijkstra, C. A. R. Hoare Structured Pro-gramming, Academic Press, London, 1972 ISBN 0-12-200550-3
[5]
Edsger Dijkstra (March 1968). "Go To Statement Considered Harmful" (PDF). Communications of the ACM 11 (3): 147–148.
[6]
Jacobs, B. (2006-08-27). "Object Oriented Programming Oversold". Archived from the original on 2006-10-15. http://web.archive.org/web/20061015181417/http://www.geocities.com/tablizer/oopbad.htm.
[7]
Shelly, Asaf (2008-08-22). "Flaws of Object Oriented Mod-eling". Intel® Software Network. http://software.intel.com/en-us/blogs/2008/08/22/flaws-of-object-oriented-modeling/. Retrieved 2010-07-04.
[8]
Yegge, Steve (2006-03-30). "Execution in the Kingdom of Nouns". steve-yegge.blogspot.com. http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html. Retrieved 2010-07-03.
[9]
"The Jargon File v4.4.7: "syntactic sugar"". http://www.retrologic.com/jargon/S/syntactic-sugar.html.
[10]
The True Cost of Calls. wordpress.com. 2008-12-30. http://hbfs.wordpress.com/2008/12/30/the-true-cost-of-calls/.
[11]
http://en.wikibooks.org/wiki/X86_Disassembly/Functions_and_Stack_Frames
[12]
Roberts, Eric S. (2008). "Art and Science of Java; Chapter 7: Objects and Memory". Stanford University. http://www-cs-facul-ty.stanford.edu/~eroberts/books/ArtAndScienceOfJava/slides/07-ObjectsAndMemory.ppt.
[13]
Roberts, Eric S. (2008). Art and Science of Java. Addison-Wesley. ISBN 978-0321486127. http://www-cs-facul-ty.stanford.edu/~eroberts/books/ArtAndScienceOfJava/slides/07-ObjectsAndMemory.ppt.
[14]
Guy Lewis Steele, Jr. "Debunking the 'Expensive Procedure Call' Myth, or, Procedure Call Implementations Considered Harmful, or, Lambda: The Ultimate GOTO". MIT AI Lab. AI Lab Memo AIM-443. October 1977. [1][2][3]
[15]
David Detlefs and Al Dosser and Benjamin Zorn (1994-06). "Memory Allocation Costs in Large C and C++ Programs; Page 532" (PDF). SOFTWARE—PRACTICE AND EXPE-RIENCE 24 (6): 527–542. )
[16]
Krishnan, Murali R. (1999-02). "Heap: Pleasures and pains". microsoft.com. http://msdn.microsoft.com/en-us/library/ms810466%28v=MSDN.10%29.aspx.
[17]
http://microallocator.googlecode.com/svn/trunk/MicroAllocator.cpp
[18]
Jeffrey Dean, David Grove, and Craig Chambers. Optimiza-tion of Object-Oriented Programs Using Static Class Hie-rarchy Analysis. University of Washington. doi:10.1.1.117.2420. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117.2420&rep=rep1&type=pdf.
[19]
Teaching FP to Freshmen, from Harper's blog about teaching introductory computer science.
[20]
M.Trofimov, OOOP - The Third "O" Solution: Open OOP. First Class, OMG, 1993, Vol. 3, issue 3, p.14.
[21]
21.Yegge, Steve (2006-03-30). "Execution in the Kingdom of Nouns". steve-yegge.blogspot.com. http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html. Retrieved 2010-07-03.
[22]
22. Boronczyk, Timothy (2009-06-11). "What's Wrong with OOP". zaemis.blogspot.com. http://zaemis.blogspot.com/2009/06/whats-wrong-with-oop.html. Retrieved 2010-07-03.
[23]
Ambler, Scott (1998-01-01). "A Realistic Look at Object-Oriented Reuse". www.drdobbs.com. http://www.drdobbs.com/184415594. Retrieved 2010-07-04.
[24]
Shelly, Asaf (2008-08-22). "Flaws of Object Oriented Mod-eling". Intel® Software Network. http://software.intel.com/en-us/blogs/2008/08/22/flaws-of-object-oriented-modeling/. Retrieved 2010-07-04.
[25]
James, Justin (2007-10-01). "Multithreading is a verb not a noun". techrepublic.com. http://blogs.techrepublic.com.com/programming-and-development/?p=518. Retrieved 2010-07-04.
[26]
Shelly, Asaf (2008-08-22). "HOW TO: Multicore Program-ming (Multiprocessing) Visual C++ Class Design Guidelines, Member Functions". support.microsoft.com. http://support.microsoft.com/?scid=kb%3Ben-us%3B558117. Retrieved 2010-07-04.
[27]
Robert Harper (2011-04-17). "Some thoughts on teaching FP". Existential Type Blog. http://existentialtype.wordpress.com/2011/04/17/some-advice-on-teaching-fp/. Retrieved 2011-12-05.
[28]
Cardelli, Luca (1996). "Bad Engineering Properties of Ob-ject-Oriented Languages". ACM Comput. Surv. (ACM) 28 (4es): 150. doi:10.1145/242224.242415. ISSN 0360-0300. http://lucacardelli.name/Papers/BadPropertiesOfOO.html. Retrieved 2010-04-21.
[29]
Stallman, Richard (1995-01-16). "Mode inheritance, cloning, hooks & OOP". Google Groups Discussion. http://groups.google.com/group/comp.emacs.xemacs/browse_thread/thread/d0af257a2837640c/37f251537fafbb03?lnk=st&q=%22Richard+Stallman%22+oop&rnum=5&hl=en#37f251537fafbb03. Retrieved 2008-06-21.
[30]
Potok, Thomas; Mladen Vouk, Andy Rindos (1999). "Prod-uctivity Analysis of Object-Oriented Software Developed in a Commercial Environment". Software – Practice and Expe-rience 29 (10): 833–847. doi:10.1002/(SICI)1097-024X(199908)29:10<833::AID-SPE258>3.0.CO;2-P. http://www.csm.ornl.gov/~v8q/Homepage/Papers%20Old/spetep-%20printable.pdf. Retrieved 2010-04-21.
[31]
C. J. Date, Introduction to Database Systems, 6th-ed., Page 650
[32]
C. J. Date, Hugh Darwen. Foundation for Future Database Systems: The Third Manifesto (2nd Edition)
[33]
Stepanov, Alexander. "STLport: An Interview with A. Ste-panov". http://www.stlport.org/resources/StepanovUSA.html. Retrieved 2010-04-21.
[34]
Graham, Paul. "Why ARC isn't especially Object–Oriented.". PaulGraham.com. http://www.paulgraham.com/noop.html. Retrieved 13 November 2009.
[35]
Armstrong, Joe. In Coders at Work: Reflections on the Craft of Programming. Peter Seibel, ed. Codersatwork.com, Ac-cessed 13 November 2009.
[36]
Mansfield, Richard. "Has OOP Failed?" 2005. Available at 4JS.com, Accessed 13 November 2009.
[37]
Mansfield, Richard. "OOP Is Much Better in Theory Than in Practice" 2005. Available at Devx.com Accessed 7 January 2010.
[38]
Stevey's Blog Rants
[39]
Rich Hickey, JVM Languages Summit 2009 keynote, Are We There Yet? November 2009.
[40]
Teaching FP to Freshmen, from Harper's blog about teaching introductory computer science.
[41]
[http://en.wikipedia.org/wiki/cognition].
ADDRESS
Science Publishing Group
1 Rockefeller Plaza,
10th and 11th Floors,
New York, NY 10020
U.S.A.
Tel: (001)347-983-5186