The Full Wiki

Programming: Wikis

  
  
  

Note: Many of our articles have direct quotes from sources you can cite, within the Wikipedia article! This article doesn't yet, but we're working on it! See more info or our list of citable articles.

Did you know ...


More interesting facts on Programming

Include this on your site/blog:

Encyclopedia

(Redirected to Computer programming article)

From Wikipedia, the free encyclopedia

Software development process
Activities and steps
Requirements · Specification
Architecture · Design
Implementation · Testing
Deployment · Maintenance
Models
Agile · Cleanroom · DSDM
Iterative · RAD  · RUP  · Spiral
Waterfall · XP · Scrum  · Lean
V-Model  · FDD  · TDD
Supporting disciplines
Configuration management
Documentation
Quality assurance (SQA)
Project management
User experience design
Tools
Compiler  · Debugger  · Profiler
GUI designer
Integrated development environment

Computer programming (often shortened to programming or coding) is the process of writing, testing, debugging/troubleshooting, and maintaining the source code of computer programs. This source code is written in a programming language. The code may be a modification of an existing source or something completely new. The purpose of programming is to create a program that exhibits a certain desired behaviour (customization). The process of writing source code often requires expertise in many different subjects, including knowledge of the application domain, specialized algorithms and formal logic.

Contents

Overview

Within software engineering, programming (the implementation) is regarded as one phase in a software development process.

There is an ongoing debate on the extent to which the writing of programs is an art, a craft or an engineering discipline.[1] In general, good programming is considered to be the measured application of all three, with the goal of producing an efficient and evolvable software solution (the criteria for "efficient" and "evolvable" vary considerably). The discipline differs from many other technical professions in that programmers, in general, do not need to be licensed or pass any standardized (or governmentally regulated) certification tests in order to call themselves "programmers" or even "software engineers." However, representing oneself as a "Professional Software Engineer" without a license from an accredited institution is illegal in many parts of the world.[citation needed] However, because the discipline covers many areas, which may or may not include critical applications, it is debatable whether licensing is required for the profession as a whole. In most cases, the discipline is self-governed by the entities which require the programming, and sometimes very strict environments are defined (e.g. United States Air Force use of AdaCore and security clearance).

Another ongoing debate is the extent to which the programming language used in writing computer programs affects the form that the final program takes. This debate is analogous to that surrounding the Sapir-Whorf hypothesis [2] in linguistics, that postulates that a particular language's nature influences the habitual thought of its speakers. Different language patterns yield different patterns of thought. This idea challenges the possibility of representing the world perfectly with language, because it acknowledges that the mechanisms of any language condition the thoughts of its speaker community.

Said another way, programming is the craft of transforming requirements into something that a computer can execute.

History of programming

Wired plug board for an IBM 402 Accounting Machine.

The concept of devices that operate following a pre-defined set of instructions traces back to Greek Mythology, notably Hephaestus and his mechanical slaves.[3] The Antikythera mechanism was a calculator utilizing gears of various sizes and configuration to determine its operation. The earliest known programmable machines (machines whose behavior can be controlled and predicted with a set of instructions) were Al-Jazari's programmable Automata in 1206.[4] One of Al-Jazari's robots was originally a boat with four automatic musicians that floated on a lake to entertain guests at royal drinking parties. Programming this mechanism's behavior meant placing pegs and cams into a wooden drum at specific locations. These would then bump into little levers that operate a percussion instrument. The output of this device was a small drummer playing various rhythms and drum patterns.[5][6] Another sophisticated programmable machine by Al-Jazari was the castle clock, notable for its concept of variables, which the operator could manipulate as necessary (i.e., the length of day and night). The Jacquard Loom, which Joseph Marie Jacquard developed in 1801, uses a series of pasteboard cards with holes punched in them. The hole pattern represented the pattern that the loom had to follow in weaving cloth. The loom could produce entirely different weaves using different sets of cards. Charles Babbage adopted the use of punched cards around 1830 to control his Analytical Engine. The synthesis of numerical calculation, predetermined operation and output, along with a way to organize and input instructions in a manner relatively easy for humans to conceive and produce, led to the modern development of computer programming. Development of computer programming accelerated through the Industrial Revolution.

In the late 1880s, Herman Hollerith invented the recording of data on a medium that could then be read by a machine. Prior uses of machine readable media, above, had been for control, not data. "After some initial trials with paper tape, he settled on punched cards..."[7] To process these punched cards, first known as "Hollerith cards" he invented the tabulator, and the key punch machines. These three inventions were the foundation of the modern information processing industry. In 1896 he founded the Tabulating Machine Company (which later became the core of IBM). The addition of a control panel to his 1906 Type I Tabulator allowed it to do different jobs without having to be physically rebuilt. By the late 1940s, there were a variety of plug-board programmable machines, called unit record equipment, to perform data-processing tasks (card reading). Early computer programmers used plug-boards for the variety of complex calculations requested of the newly invented machines.

Data and instructions could be stored on external punch cards, which were kept in order and arranged in program decks.

The invention of the Von Neumann architecture allowed computer programs to be stored in computer memory. Early programs had to be painstakingly crafted using the instructions of the particular machine, often in binary notation. Every model of computer would be likely to need different instructions to do the same task. Later assembly languages were developed that let the programmer specify each instruction in a text format, entering abbreviations for each operation code instead of a number and specifying addresses in symbolic form (e.g., ADD X, TOTAL). In 1954 Fortran was invented, being the first high level programming language to have a functional implementation.[8][9] It allowed programmers to specify calculations by entering a formula directly (e.g. Y = X*2 + 5*X + 9). The program text, or source, is converted into machine instructions using a special program called a compiler. Many other languages were developed, including some for commercial programming, such as COBOL. Programs were mostly still entered using punch cards or paper tape. (See computer programming in the punch card era). By the late 1960s, data storage devices and computer terminals became inexpensive enough so programs could be created by typing directly into the computers. Text editors were developed that allowed changes and corrections to be made much more easily than with punch cards.

As time has progressed, computers have made giant leaps in the area of processing power. This has brought about newer programming languages that are more abstracted from the underlying hardware. Although these high-level languages usually incur greater overhead, the increase in speed of modern computers has made the use of these languages much more practical than in the past. These increasingly abstracted languages typically are easier to learn and allow the programmer to develop applications much more efficiently and with less code. However, high-level languages are still impractical for a few programs, such as those where low-level hardware control is necessary or where processing speed is at a premium.

Throughout the second half of the twentieth century, programming was an attractive career in most developed countries. Some forms of programming have been increasingly subject to offshore outsourcing (importing software and services from other countries, usually at a lower wage), making programming career decisions in developed countries more complicated, while increasing economic opportunities in less developed areas. It is unclear how far this trend will continue and how deeply it will impact programmer wages and opportunities.

Modern programming

Quality requirements

Whatever the approach to software development may be, the final program must satisfy some fundamental properties. The following properties are among the most relevant:

  • Efficiency/performance: the amount of system resources a program consumes (processor time, memory space, slow devices such as disks, network bandwidth and to some extent even user interaction): the less, the better. This also includes correct disposal of some resources, such as cleaning up temporary files and lack of memory leaks.
  • Reliability: how often the results of a program are correct. This depends on conceptual correctness of algorithms, and minimization of programming mistakes, such as mistakes in resource management (e.g., buffer overflows and race conditions) and logic errors (such as division by zero).
  • Robustness: how well a program anticipates problems not due to programmer error. This includes situations such as incorrect, inappropriate or corrupt data, unavailability of needed resources such as memory, operating system services and network connections, and user error.
  • Usability: the ergonomics of a program: the ease with which a person can use the program for its intended purpose, or in some cases even unanticipated purposes. Such issues can make or break its success even regardless of other issues. This involves a wide range of textual, graphical and sometimes hardware elements that improve the clarity, intuitiveness, cohesiveness and completeness of a program's user interface.
  • Portability: the range of computer hardware and operating system platforms on which the source code of a program can be compiled/interpreted and run. This depends on differences in the programming facilities provided by the different platforms, including hardware and operating system resources, expected behaviour of the hardware and operating system, and availability of platform specific compilers (and sometimes libraries) for the language of the source code.
  • Maintainability: the ease with which a program can be modified by its present or future developers in order to make improvements or customizations, fix bugs and security holes, or adapt it to new environments. Good practices during initial development make the difference in this regard. This quality may not be directly apparent to the end user but it can significantly affect the fate of a program over the long term.

Algorithmic complexity

The academic field and the engineering practice of computer programming are both largely concerned with discovering and implementing the most efficient algorithms for a given class of problem. For this purpose, algorithms are classified into orders using so-called Big O notation, O(n), which expresses resource use, such as execution time or memory consumption, in terms of the size of an input. Expert programmers are familiar with a variety of well-established algorithms and their respective complexities and use this knowledge to choose algorithms that are best suited to the circumstances.

Methodologies

The first step in most formal software development projects is requirements analysis, followed by testing to determine value modeling, implementation, and failure elimination (debugging). There exist a lot of differing approaches for each of those tasks. One approach popular for requirements analysis is Use Case analysis.

Popular modeling techniques include Object-Oriented Analysis and Design (OOAD) and Model-Driven Architecture (MDA). The Unified Modeling Language (UML) is a notation used for both the OOAD and MDA.

A similar technique used for database design is Entity-Relationship Modeling (ER Modeling).

Implementation techniques include imperative languages (object-oriented or procedural), functional languages, and logic languages.

Measuring language usage

It is very difficult to determine what are the most popular of modern programming languages. Some languages are very popular for particular kinds of applications (e.g., COBOL is still strong in the corporate data center, often on large mainframes, FORTRAN in engineering applications, scripting languages in web development, and C in embedded applications), while some languages are regularly used to write many different kinds of applications.

Methods of measuring programming language popularity include: counting the number of job advertisements that mention the language,[10] the number of books teaching the language that are sold (this overestimates the importance of newer languages), and estimates of the number of existing lines of code written in the language (this underestimates the number of users of business languages such as COBOL).

Debugging

A bug, which was debugged in 1947.

Debugging is a very important task in the software development process, because an incorrect program can have significant consequences for its users. Some languages are more prone to some kinds of faults because their specification does not require compilers to perform as much checking as other languages. Use of a static analysis tool can help detect some possible problems.

Debugging is often done with IDEs like Visual Studio, NetBeans, and Eclipse. Standalone debuggers like gdb are also used, and these often provide less of a visual environment, usually using a command line.

Programming languages

Different programming languages support different styles of programming (called programming paradigms). The choice of language used is subject to many considerations, such as company policy, suitability to task, availability of third-party packages, or individual preference. Ideally, the programming language best suited for the task at hand will be selected. Trade-offs from this ideal involve finding enough programmers who know the language to build a team, the availability of compilers for that language, and the efficiency with which programs written in a given language execute.

Allen Downey, in his book How To Think Like A Computer Scientist, writes:

The details look different in different languages, but a few basic instructions appear in just about every language:
  • input: Get data from the keyboard, a file, or some other device.
  • output: Display data on the screen or send data to a file or other device.
  • arithmetic: Perform basic arithmetical operations like addition and multiplication.
  • conditional execution: Check for certain conditions and execute the appropriate sequence of statements.
  • repetition: Perform some action repeatedly, usually with some variation.

Many computer languages provide a mechanism to call functions provided by libraries. Provided the functions in a library follow the appropriate runtime conventions (eg, method of passing arguments), then these functions may be written in any other language.

Programmers

Computer programmers are those who write computer software. Their jobs usually involve:

See also

References

  1. ^ Paul Graham (2003). Hackers and Painters. http://www.paulgraham.com/hp.html. Retrieved 2006-08-22. 
  2. ^ Kenneth E. Iverson, the originator of the APL programming language, believed that the Sapir–Whorf hypothesis applied to computer languages (without actually mentioning the hypothesis by name). His Turing award lecture, "Notation as a tool of thought", was devoted to this theme, arguing that more powerful notations aided thinking about computer algorithms. Iverson K.E.,"Notation as a tool of thought", Communications of the ACM, 23: 444-465 (August 1980).
  3. ^ New World Encyclopedia Online Edition New World Encyclopedia
  4. ^ Al-Jazari - the Mechanical Genius, MuslimHeritage.com
  5. ^ A 13th Century Programmable Robot, University of Sheffield
  6. ^ Fowler, Charles B. (October 1967), "The Museum of Music: A History of Mechanical Instruments", Music Educators Journal 54 (2): 45–49, doi:10.2307/3391092 
  7. ^ Columbia University Computing History - Herman Hollerith
  8. ^ [1]
  9. ^ [2]
  10. ^ Survey of Job advertisements mentioning a given language>

Further reading

  • Weinberg, Gerald M., The Psychology of Computer Programming, New York: Van Nostrand Reinhold, 1971

External links


Quotes

Up to date as of January 14, 2010

From Wikiquote

Computer programming (often simply programming or coding) is the craft of writing a set of commands or instructions that can later be compiled and/or interpreted and then inherently transformed to an executable that an electronic machine can execute or "run".

Contents

Computer Programming

  • On two occasions I have been asked,—"Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
    • Charles Babbage, Passages from the Life of a Philosopher (1864), ch. 5: "Difference Engine No. 1"
  • Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to build bigger and better idiots. So far, the universe is winning.
    • Rick Cook (or Rich Cook?) [citation needed]
  • Computers are man's attempt at designing a cat: It does whatever it wants, whenever it wants, and rarely ever at the right time.
    • EMCIC, Keenspot Elf Life Forum, 2001-Apr-26 [specific citation needed]
  • If you lie to the computer, it will get you.
    • Perry Farrar [citation needed]
  • There is no programming language, no matter how structured, that will prevent programmers from making bad programs.
    • Larry Flon [citation needed]
  • No matter how slick the demo is in rehearsal, when you do it in front of a live audience the probability of a flawless presentation is inversely proportional to the number of people watching, raised to the power of the amount of money involved.
  • [This] reminds me of a quotation from somebody that, whenever he tried to explain the logical structure of a programming language to a programmer, it was like a cat trying to explain to a fish what it feels like to be wet.
  • To me programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge.
    • Grace Hopper, quoted in Management and the Computer of the Future (1962) by Sloan School of Management, p. 277
  • Programming: when the ideas turn into the real things.
    • Maciej Kaczmarek [citation needed]
  • Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.
    • Alan Kay [citation needed]
  • Premature optimization is the root of all evil.
    • Donald Knuth, "Structured Programming with Goto Statements". Computing Surveys 6:4 (December 1974), pp. 261–301, §1.
    • Premature optimization is the root of all evil (or at least most of it) in programming.
    • Knuth refers to this as "Hoare's Dictum" 15 years later in "The Errors of Tex", Software—Practice & Experience 19:7 (July 1989), pp. 607–685. However, the attribution to C. A. R. Hoare is doubtful.[2]
      • All three of these papers are reprinted in Knuth, Literate Programming, 1992, Center for the Study of Language and Information ISBN 0937073806
  • The most important thing in a programming language is the name. A language will not succeed without a good name. I have recently invented a very good name and now I am looking for a suitable language.
    • Donald E. Knuth (1938-...) [citation needed]
  • Computers are good at following instructions, but not at reading your mind.
    • Donald Knuth [citation needed]
  • One in a million is next Tuesday.
  • He who hasn't hacked assembly language as a youth has no heart. He who does as an adult has no brain.
    • John Moore [citation needed], playing on the French saying that "He who is not a Socialist at 20 has no heart. He who at 40 is a Socialist has no brain."
  • Computer programming is tremendous fun. Like music, it is a skill that derives from an unknown blend of innate talent and constant practice. Like drawing, it can be shaped to a variety of ends – commercial, artistic, and pure entertainment. Programmers have a well-deserved reputation for working long hours but are rarely credited with being driven by creative fevers. Programmers talk about software development on weekends, vacations, and over meals not because they lack imagination, but because their imagination reveals worlds that others cannot see.
    • Larry O'Brien and Bruce Eckel in Thinking in C#
  • The best book on programming for the layman is "Alice in Wonderland", but that's because it's the best book on anything for the layman.
  • Computer Science is embarrassed by the computer.
    • Alan Perlis, "Epigrams on Programming"
  • Prolonged contact with the computer turns mathematicians into clerks and vice versa.
    • Alan Perlis, "Epigrams on Programming"
  • Structured Programming supports the law of the excluded muddle.
    • Alan Perlis, "Epigrams on Programming"
  • There are two ways to write error-free programs; only the third one works.
    • Alan Perlis, "Epigrams on Programming"
  • Software and cathedrals are much the same – first we build them, then we pray.
    • Sam Redwine [Proceedings of the 4th International Software Process Workshop, Moretonhampstead, Devon, U.K., 11-13 May 1988, IEEE Computer Society]
  • Why bother with subroutines when you can type fast?
    • Vaughn Rokosz [citation needed]
  • A Netscape engineer who shan't be named once passed a pointer to JavaScript, stored it as a string and later passed it back to C, killing 30.
  • Real Programmers always confuse Christmas and Halloween because Oct31 == Dec25.
    • Andrew Rutherford [citation needed]
  • Don't get suckered in by the comments...They can be terribly misleading.
    • Dave Storer [citation needed]
  • The three chief virtues of a programmer are: Laziness, Impatience and Hubris.
    • Larry Wall [citation needed]
  • Zawinski's Law: Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
    • Jamie Zawinski (who called it the "Law of Software Envelopment") [citation needed]

Anonymous/Unattributed

  • 43rd Law of Computing: Anything that can go wr Seek Error reading Drive C: Abort, Retry, Ignore, Fail?
  • Any sufficiently advanced magic is indistinguishable from a rigged demonstration.
    • Restatement of Murphy's reformulation of Clarke's Third Law
  • The attention span of a computer is only as long as its electrical cord.
  • Beware of programmers that carry screwdrivers.
  • Computer programmers never die, they just become lost in the processing.
  • Computers can never replace human stupidity.
  • Computers Unite! You have nothing to lose but your operators.
  • Eagleson's Law of Programming: Any code of your own that you haven't looked at for six or more months, might as well have been written by someone else.
  • Gilb's First Law of Unreliability: Computers are unreliable but humans are even more unreliable.
  • Good programming is 99% sweat and 1% coffee.
  • If God had intended man to have computers, he would have given him 16 fingers.
  • In computing, turning the obvious into the useful is a living definition of the word "frustration".
  • Is a computer language with goto's totally Wirth-less?
  • Laws of Computer Programming:
    1. Any given program, when running, is obsolete.
    2. Any given program costs more and takes longer.
    3. If a program is useful, it will have to be changed.
    4. If a program is useless, it will have to be documented.
    5. Any given program will expand to fill all available memory.
    6. The value of a program is proportional to the weight of its output.
    7. Program complexity grows until it exceeds the capability of the programmer who must maintain it.
  • Managers know it must be good because the programmers hate it so much.
  • On a clear disk you can seek forever.
  • Programmer (n): An organism that can turn caffeine into code.
  • Programmers get overlaid.
  • Programming Department: Mistakes made while you wait.
  • Programming is an art form that fights back.
  • Programming would be so much easier without all the users.
  • The problem about all graphical programming languages is that when your project becomes complex, not only will you have spaghetti code, but it will actually look like spaghetti too.
  • Small programs are for small minds.
  • Software and cathedrals are much the same - first we build them, then we pray. Sam Redwine (This is a quote from Samuel T. Redwine, Jr. made at 4th International Software Process Workshop and published in Proceedings of the 4th International Software Process Workshop, Moretonhampstead, Devon, U.K., 11-13 May 1988, IEEE Computer Society.)
  • There are 10 types of people in this world, those who understand binary and those who do not.
  • To err is human. To blame it on a computer is even more so.
  • Troutman's First Programming Postulate: If a test installation functions perfectly, all subsequent systems will malfunction.
  • Troutman's Second Programming Postulate: The most harmful error will not be discovered until a program has been in production for at least six months.
  • Troutman's Third Programming Postulate: Job control cards that positively cannot be arranged in improper order will be.
  • Troutman's Fourth Programming Postulate: Interchangeable tapes won't.
  • Troutman's Fifth Programming Postulate: If the input editor has been designed to reject all bad input, an ingenious idiot will discover a method to get bad data past it.
  • Troutman's Sixth Programming Postulate: Profanity is the one language all programmers know best.
  • We don't really understand it, so we'll give it to the programmers.
  • Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.
  • Whom computers would destroy, they must first drive insane.
  • Writing it is easy, understanding it is hard.
  • Your program is sick! Shoot it and put it out of its memory.
  • Your Zip file is open.

Debugging

  • Even perfect program verification can only establish that a program meets its specification. [...] Much of the essence of building a program is in fact the debugging of the specification.
    • Fred Brooks (1986), "No Silver Bullet", Information Processing 1986, the Proceedings of the IFIP Tenth World Computing Conference, H. K. Kugler, ed., Elsevier Science, 1986, p. 1069 ff.
    • Reprinted in the IEEE magazine Computer 20 (4), (April 1987), p. 43 ff.; and in The Mythical Man-Month Anniversary Edition (1995), ISBN 0-201-83595-9
  • Much to the surprise of the builders of the first digital computers, programs written for them usually did not work.
    • Rodney Brooks, Programming in Common Lisp, Wiley, 1985, p. 94
  • bug, n: An elusive creature living in a program that makes it incorrect. The activity of "debugging", or removing bugs from a program, ends when people get tired of doing it, not when the bugs are removed.
    • Datamation, January 15, 1984[specific citation needed]
  • If debugging is the process of removing bugs, then programming must be the process of putting them in.
  • Testing can only prove the presence of bugs, not their absence.
  • silver bullet (SIL-vuhr BOOL-it) noun: A quick solution to a thorny problem. [From the belief that werewolves could be killed when shot with silver bullets.] "Writing code, he (Stuart Feldman) explains, is like writing poetry: every word, each placement counts. Except that software is harder, because digital poems can have millions of lines which are all somehow interconnected. Try fixing programming errors, known as bugs, and you often introduce new ones. So far, he laments, nobody has found a silver bullet to kill the beast of complexity."
    • Survey: The Beast of Complexity; The Economist (London, UK); Apr 14, 2001.
  • From then on, when anything went wrong with a computer, we said it had bugs in it.
    • RADM Grace Hopper, on the removal of a 2-inch-long moth from the Harvard Mark I experimental computer at Harvard in August 1945, as quoted in Time (16 April 1984)
  • The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.
  • Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
    • Brian Kernighan, "The Elements of Programming Style", 2nd edition, chapter 2
  • Beware of bugs in the above code; I have only proved it correct, not tried it.
  • A documented bug is not a bug; it is a feature.
    • James P. MacLennan[citation needed] (Probably not original)
  • A known bug is better than an unknown feature.
    • Manoj Sati [citation needed]
  • As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.
    • Maurice Wilkes discovers debugging, 1949 [specific citation needed]

Anonymous/Unattributed

  • Law 1: Every program can be optimised to be smaller. Law 2: There's always one more bug. Corollary: Every program can be reduced to a one-line bug.
  • Lubarsky's Law of Cybernetic Entomology: There's always one more bug.
  • The paradox of software testing: In theory, testing software for correctness is impossible. In practice, it is given to freshmen because it's the least demanding task available.

Unrelated/off-topic

Merge-arrow.svg
It has been suggested that this article or section be merged into Computers. (Discuss)
  • The cheapest, fastest and most reliable components of a computer system are those that aren't there.
    • Gordon Bell, Encore Computer Corp [citation needed]
  • If computers take over (which seems to be their natural tendency), it will serve us right.
    • Alfred Alistair Cooke (1908-...) [citation needed]
  • Gilder's Law: Bandwidth grows at least three times faster than computer power.
    • George F. Gilder, Telecosm: How Infinite Bandwidth Will Revolutionize Our World, The Free Press, NY, 2000 [specific citation needed]
  • The best way to predict the future is to implement it.
    • Alan Kay [citation needed]
  • As the trials of life continue to take their toll, remember that there is always a future in Computer Maintenance.
    • National Lampoon[specific citation needed]

See also

External links

Wikipedia
Wikipedia has an article about:
Wiktionary-logo-en.png
Look up programming in Wiktionary, the free dictionary

Study guide

Up to date as of January 14, 2010
(Redirected to Topic:Computer programming article)

From Wikiversity

CP logo.png
Part of the School of Computer Science

Computer Programming is a field that involves the methodology behind the programming, software abstraction, algorithms, data structures, design, testing, and maintenance of computer software.

Contents

Division news

  • May 14, 2007 - New programming language added (D) and lesson numbers for programming languages updated.
  • September 16, 2006 - Department upgraded to division
  • August 20, 2006 - Department founded!......

Recommended course of study

General topics

Applied topics

Computer Programming Languages

Available

Planned

Specialized programming environments

Learning materials and learning projects

Portal:Learning Materials
Portal:Learning Projects

Wikiversity has adopted the "learning by doing" model for education. Lessons should center on learning activities for Wikiversity participants. Learning materials and learning projects can be used by multiple departments. Cooperate with other departments that use the same learning resource.

Learning materials and learning projects are located in the main Wikiversity namespace. Simply make a link to the name of the lesson (lessons are independent pages in the main namespace) and start writing!

Textbooks

Exercise collections

Literature on programming exercises

  • Exercise design for introductory programming : "Learn-by-Doing" basic O-O-concepts using Inverted Curriculum Marcel Kessler. Master thesis, ETH Zürich, 2004; ETH, Eidgenössische Technische Hochschule Zürich, Department of Computer Science, Chair of Software Engineering, 2004 [1]

Learning projects

  • MediaWiki Project - from introductory HTML to advanced MediaWiki hacking.... participants develop new MediaWiki features for the Wikiversity community.
  • ACM SIGCSE (Special Interest Group Computer Science Education) Link list on Programming: [2]
  • CisLunarFreighter (Game Development Project).

Active participants

The histories of Wikiversity pages indicate who the active participants are. If you are an active participant in this department, you can list your name here (this can help small departments grow and the participants communicate better; for large departments a list of active participants is not needed).

  • JordanP (Beginer: CSS, HTML, XHTML, Python, PHP, Flash, Java)
  • Aepex (Computer Science)
  • AmiDaniel -- VB6, Java, various others
  • CQuinton (talk) (Perl, PHP, Python... help with Intro to Programming and Computer science in general)
  • Crossbow9
  • Devourer09 (Computer Science)
  • Donald McLean -- Introduction to Programming and the companion course Introduction to Programming in Java
  • Draicone (talk) (PHP, C, C++, Javascript, Pascal, Python, Perl, RoR, General OO, Intro to Programming)
  • Girish Pandit(Java, J2EE, SOA, Data Structures, Design Patterns,Database, PHP)
  • Hillgentleman--interested to learn PHP
  • JaK81600 (Computer Science)
  • Mark Roberts (Computer Science)
  • Michael Billington (talk • contribs) (VB6, C, and apparently PHP)
  • NickSentowski (talk)
  • OMouse (D programming language, general proof-reading and filling in the gaps)
  • Pedro Gonnet (talk)
  • Punk Boi 8
  • Quasar (talk)(C Programming, C++, Data Structures, Java)
  • raghunandanan 05:05, 9 May 2007 (UTC) a beginner
  • Richard2me (Computer Science)
  • Xlbnushk -- (X)HTML, CSS, JavaScript, PHP, MySQL, MSSQL
  • Cslashb HTML, CSS & Visual Basic, learning Java, C# & C++
  • Charles Mwiyeretsi ( SQL, Java, PHP, C, CSS...)
  • Gadaba ( SQL, Java, PHP, C, CSS...,Game Design)
  • Josh Sandlin (Linux Programming)
  • Prototype (Visual Basic, HTML, PHP + SQL)
  • Peter Rawsthorne (LAMP beginner)
  • Mathieu (LAMP, C, Java, HTML, CSS beginner)
  • Jekrox (QB, HTML, Visual Basic)
  • AFriedman
  • Rbhagwandin 16:34, 8 May 2009 (UTC)

Resources

External links

Sciences humaines.svg Educational level: this is a tertiary (university) resource.
Crystal Clear Sharemanager.png Resource type: this resource is a course.
Nuvola apps kcmsystem.svg Subject classification: this is an engineering resource .
Nuvola apps kcontrol.gif Completion status: this resource is well on its way to completion, but there may still be work to do.

Gaming

Up to date as of February 01, 2010

This article uses material from the "Programming" article on the Gaming wiki at Wikia and is licensed under the Creative Commons Attribution-Share Alike License.







Got something to say? Make a comment.
Your name
Your email address
Message