What is a programming language, and do developers write all the code themselves?

What is a programming language?

A programming language is the set of words and rules a developer writes instructions in. The code you saw in the last lesson was written in one. Python, Java, JavaScript, and Go are among the most common, and every file in a codebase is written in one language or another.

The word "language" invites the wrong picture. It suggests French versus Spanish: years of study, fluency as identity, a switch costing everything. The truer picture is trades. A carpenter and an electrician both build houses, hold most of their skill in common, and differ mainly in the materials they work with daily. A Python developer and a Java developer are that close. The language names the material. The developer names the skill.

The second half of this lesson answers a question the first half raises. If developers write instructions, do they write all of them? They do not, and the numbers are stark. Most of a modern application is code the team never wrote: prewritten parts, chosen and connected. The sections below cover what a language is, why languages multiply, and how that assembly model works.

Why are there so many of them?

Languages multiply because they are tools with trade-offs, and no single set of trade-offs fits every job. One language runs fast but takes longer to write. Another is quick to write but slower to run. One catches mistakes before the program starts, another lets developers move loosely and pay for it later. Some are welded to a platform: apps for iPhones are mostly written in Swift because Apple built Swift for exactly that.

So a team's language choice usually reflects the product and the era, and much less often a strong belief. JavaScript dominates websites because browsers run it natively. Python dominates data and AI work because that community built its tools there. Java runs a large share of banking and enterprise systems because those systems were started when Java was the safe choice, and they still work.

This is why a language on a resume reads best as a record of environments. "Eight years of Java" describes eight years inside a certain kind of company and system as much as it describes the language itself. The full sorting of languages against every other technology name comes later in the course, in the module on sorting the nouns.

How long does it take to learn another one?

Weeks, for an experienced developer. Useful code in a new language within two or three weeks, comfortable within a few months. That estimate surprises people outside the field, and the reason it holds is worth having precisely.

Most languages in mainstream use share their core ideas. The concepts transfer whole; what changes is spelling and habit. The knowledge that took years sits elsewhere: how to structure a system so it survives growth, how to find the cause of a failure, how to read someone else's code, how to weigh a shortcut against its future cost. All of that travels with the developer into any language.

The transfer has limits worth knowing. Moving between nearby languages is the fast case. Moving into a language with a genuinely different model, or into the deep end of a specialized domain, takes longer, because there the language is entangled with years of domain knowledge. Depth in one language also has its own meaning: it signals long exposure to that language's world, its systems, and its community.

What is a framework, and what is a library?

A framework is a large body of prewritten code that supplies the shape of an application. A library is a smaller piece of prewritten code that does one job well. Both exist so that developers stop re-solving solved problems.

Every application needs the same foundations: responding to clicks, talking over the network, showing pages, handling logins. A framework provides those foundations plus a structure to build within, and the developer fills in what makes this product different from every other one. React, Django, and Rails are frameworks you will see constantly on resumes, and each belongs to a language: React to JavaScript, Django to Python, Rails to Ruby.

A library is narrower. One library draws charts. Another handles dates and time zones. Another processes payments. A developer pulls in a library at the moment they need its one job done.

The standard way engineers separate the two is direction of control. With a library, the developer's code is in charge and calls the library when needed. With a framework, the framework is in charge: it runs the show and calls the developer's code at the right moments. That is why a framework shapes how a whole team works and why teams choose one so carefully. Choosing a framework means accepting its structure, its habits, and its way of doing things for the life of the product.

For reading resumes, the practical fact is that frameworks are where daily experience concentrates. "React developer" tells you more about someone's day-to-day work than "JavaScript developer" does, because the framework determines what the work actually looks like.

How much of an app does the team actually write?

Typically a few percent. The rest is prewritten code the team selected and connected: the framework, the libraries, and everything those pieces themselves rely on.

Prewritten code arrives as packages. A package is a bundle of someone else's code, published to a public collection, that a developer installs into a project with a single command. Each language has its own collection, and the big ones hold millions of packages. Every package a project installs is called a dependency, because the project now depends on it, and the count compounds: each package has dependencies of its own, and those have theirs. A routine application ends up depending on several hundred packages, sometimes over a thousand.

Nearly all of this shared code is open source, meaning the code is public and free for anyone to use. Why so many people give serious work away, and what it means about them, is a question with enough depth to earn its own module later in this course. For now the load-bearing fact is that the world's software runs on a shared commons of parts, and every company draws from the same one.

This reframes what the job is. A developer's day is closer to engineering with existing components than to writing everything from a blank page: evaluate the available parts, pick well, connect them cleanly, and write original code only where the product is genuinely original. Judgment about what to use carries as much weight as ability to write. When a developer says a team "had a lot of dependencies" or "chose bad dependencies," they are describing exactly this responsibility, and its failures cost real time.

What does an ecosystem mean?

An ecosystem is everything that has grown up around a language: its frameworks, its libraries and packages, its tools, its documentation, and the community of people producing all of it. The biological word is chosen honestly. These things feed each other and grow together, and a language succeeds or stalls largely on the health of its ecosystem.

A runtime is one more piece of that surrounding world, and the word appears often enough on resumes to pin down. A runtime is the program that actually executes code in a given language, in a given place. The clearest example is Node.js, a name you will see everywhere: JavaScript was born inside the browser, and Node.js is the runtime that lets the same language run outside it, powering the behind-the-scenes half of an application. "Node" on a resume means JavaScript used for that behind-the-scenes work, a distinction the next lesson makes concrete.

Ecosystem size explains hiring gravity. A big ecosystem means more prewritten parts, better tools, answers already written for most problems, and a deep pool of developers, so teams keep choosing big ecosystems, which makes them bigger. When an engineer defends a technology choice by saying "the ecosystem is stronger," this is the whole argument: more of the application already exists, and more people can be hired to work on it.

The picture from this lesson carries through the rest of the module. A language is a trade's material. A framework supplies the shape, libraries and packages supply the parts, a runtime executes the result, and the developer's craft is in the choosing and connecting. Next: how those assembled parts divide into the halves every job title refers to.