Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
In informatics theory I hear and read about high-level and low-level languages all time.
Yet I don't understand why this is still relevant as there aren't any (relevant) low-level languages except assembler in use today.
So you get:
Low-level
Assembler
Definitely not low-level
C
BASIC
FORTRAN
COBOL
...
High-level
C++
Ruby
Python
PHP
...
And if assembler is low-level, how could you put for example C into the same list. I mean: C is extremely high-level compared to assembler. Same even for COBOL, Fortran, etc.
So why does everybody keep mentioning high and low-level languages if assembler is really the only low-level language?
You will find that
many of the truths we cling to depend upon our own point of view.
For a C programmer, Assembler is a low-level language.
For a Java programmer, C is a low-level language and so on.
I suspect the folks programming the first stored-program computer with 1s and 0s would have thought Assembler a high-level language. It's all relative.
(Quote from Return of the Jedi)
According to Wikipedia, the low level languages are machine code and assembly.
From the source:
In computer science, a low-level
programming language is a programming
language that provides little or no
abstraction from a computer's
instruction set architecture. The word
"low" refers to the small or
nonexistent amount of abstraction
between the language and machine
language; because of this, low-level
languages are sometimes described as
being "close to the hardware."
Then, to answer:
So why does everybody keep mentioning high and low-level languages if assembler is really the only low-level language.
I don't know who "everyone" is, but I would venture a guess that back when high-level languages were not as commonplace as they are today, it was more relevant to talk about low-level vs. high-level (because there was a relatively significant amount of programmers writing assembly code). In modern times it is a less important distinction. Personally, I rarely hear people using these terms except to differentiate between assembly or not (except for those times when you might hear someone raised on Python referring to C or C++ as low-level, but this is not in the spirit of the original definition).
You're asking a relatively subjective question; it's a question about terminology, that vernacular, and perspective.
For example, is Lisp a high-level or a low-level language? What if the implementation is running on a Lisp Machine?
Often, when people attempt to build a spectrum from low-level to high-level, what they are trying to quantify is a degree of "closeness to the hardware" as opposed to the degree of "abstraction."
Qualities which count toward an implementation's closeness to the hardware:
The programmer directly controls the memory layout of data and has access at run-time to memory addresses of data.
Mathematical operations are defined in terms of the hardware or loosely defined in order to conform to different types of hardware.
There may be a library providing dynamic memory allocation, but use of dynamic memory is manual.
Management of memory during string manipulation is manual.
Converse qualities which count toward an implementation's abstraction from the hardware:
The programmer does not have run-time access to address of data (references instead of pointers).
Mathematical operations are defined in specific terms not tied to specific hardware. (e.g., ActionScript 3 supports the Number type which self-converts from integer to floating-point rather than experience overflow.)
Management of dynamic memory is handled by the environment, possibly through reference counting, garbage collection, or another automated memory management scheme.
Management of memory during string manipulation is always hidden from the programmer and handled by the environment.
Other qualities might render a language very abstract compared to the hardware on which it runs:
Declarative, search-based syntax. (e.g. Prolog)
With factors like these in mind, I would revise the spectrum you have written as follows:
Lowest level:
Assembly language of the platform in question.
Low-level languages with higher-level flow control than assembly:
C, C++
Pascal
High-level languages:
FORTRAN
COBOL
Python
Perl
Highest-level languages:
PROLOG
Python
Scheme
Python appears twice by intent -- it spans a portion of the spectrum depending on how the code is written.
As low-level, I would add:
.NET IL
Java JVM
Other P-Code used in environments like VB6
The "level" of a language is a moving target. In 1973, PL/I was considered a high-level language. Today, C is considered (at least by language professionals) as a low-level language [see footnote]. Some of the reasons:
Exposes machine-level representations of numbers
"Integer" arithmetic can overflow
No real support for strings, or at the very least, strings are not first-class
Manual memory management
Address arithmetic
Unsafe
A high-level language might include
Support for integer types independent of the target machine
Default integer arithmetic never overflows unless the machine runs out of memory
Strings as first-class values with, e.g., concatenation built in
Automatic memory management with no address arithmetic
Safe
Some candidates as "high-level languages" by this definition might include Icon, Scheme, Smalltalk, and some of your favorite scripting languages.
Back in the day when I was a young scholar and dinosaurs roamed the earth, people referred to Icon as a "very high-level language". As recently as 15 years ago you could even attend a learned symposium on Very High Level Languages. But that term isn't used much any more.
Why does everybody keep mentioning high and low-level languages?
Even though the difference between "high" and "low" keeps changing, distinctions like the ones listed above are still important. And there are so many distinction that the words "high" and "low" can be a useful shorthand. But not that useful—to a cynic, a high-level language is one that looks at least as powerful as whatever my favorite language is, and a low-level language is everything else. In other words, "level" can easily degenerate into mere name-calling.
Footnote: It's hard to find citations for terminology used at professional meetings, especially when professionals don't use the terms "low-level" and "high-level" because they're not so technical. But danben asked about citations, and I found a couple:
"To provide the required precision, experimental programs are usually written in a low-level language (eg C or Pascal)," in a refereed article on computer vision.
"The C programming language is well-known for its flexibility in dealing with low-level constructs," in an important paper by Necula et al.
P.S. Don't count too heavily on Wikipedia for good information on programming languages, especially if the Wikipedia reference cites no references or sources
Purely guessing here, but this may be a case of language-shift, whereby the distinction between low- and high-level langauges is slowly evolving in peoples' minds into the difference between managed- and unmanaged-languages, typed-and untyped-languages etc.etc. (at least in the way people are using the terminology).
To a large extent, "low-level" and "high-level" not binary categories but are a continuum. There are some languages that are clearly low-level (assembly, machine code), but beyond that there is really only "higher-level" and "lower-level".
As I see it, "lower-level" languages require code that looks more like the architecture of the computer, and "higher-level" languages accept code that looks more like the structure of the problem. But with that, languages can be high-level for one problem and low-level for another.
Low-level
Binary
Assembler
ET IL
Java JVM
Other P-Code used in environments like VB6
Definitely not low-level
C
BASIC
FORTRAN
COBOL
Python
Perl
Pascal
High-level
C++
Ruby
Python
PHP
PROLOG
Scheme
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
At university I majored in compiler theory and grammars, so have a good background in this area (although a long time ago) and know that the creation of a compiler is an enormous major undertaking, at least for a language such as C++.
So I'm confused as to the large number of programming languages that seem to have been created by individuals as opposed to large groups of people working at a company. Ruby for example, according to Wikipedia it was created by one person - I don't know the language perhaps it's incredibly simple, but my point is there are bucket loads of self-created languages out there.
So how does one go about creating their own language (which isn't too simple as to be pretty useless) as an individual and not spend one's entire life doing so?
Are there any good books on the subject (not on compilers and in general, spec)?
(although a long time ago) and know that the creation of a compiler is an enormous major undertaking, at least for a language such as C++.
A lot of things have conspired to make things easier:
Computers have a lot more RAM and speed. Much of the challenge of writing early compilers was being able to do so efficiently and with a minimum of memory. That's why C can compile in a single pass: at the time, you may not have had enough memory to even fit an entire source file in it. Where before a lot of the magic of compiler-writing was optimizing your symbol table representation and parsing as fast as physically possible, now you can get by doing things much simpler and easier.
Base technology has gotten better. Most languages have nice easy to use parser libraries, high-level data structures (symbol tables are a snap if you already have a nice hashtable implementation!) and other tools to make getting a compiler or interpreter up and running much easier.
GC is ubiquitous. Most new languages being created today are garbage collected. That makes it easier to design the language (you don't have to specify detailed memory semantics). At the same time, you can target some existing GC platform like the CLR or the JVM so as the language author, you don't have to write your own GC. In fact, targeting the CLR or JVM makes your job as a compiler writer much easier in general: as a higher-level platform, the bytecode meets you halfway.
Most new languages are dynamically-typed. The majority of new languages being created are dynamically typed. Those are much easier to design and implement. I've found that a majority of the challenge in language design is designing a type system. Likewise, compiling or interpreting a static language is more of a challenge. Dynamic languages where everything is just a property bag are surprisingly easy to get up and running.
Again, computers have a lot more RAM and speed. Back in the day, if your language was to have any chance of success, it needed to compile down to efficient machine code, use memory efficiently and run fast. Otherwise it would be unusably slow. Now that computers are so much faster, even a slow language like Ruby is still fast enough for many real uses. As a compiler writer you don't need as much optimization skill as you used to.
It's also worth noting that no one is making a new language as complex as C++ these days. C++ really is near the top end of language complexity.
I have gone a little way down the route of creating my own language. I started off doing this to represent requirements, analysis and design constructs, rather than a code compiler. For this purpose even a very simple language can be useful. I found it valuable to be able to read and write such constructs in a very constrained version of English - template sentences mainly. Then it became useful to have the language machine readable and so I constructed lexers and parsers to read the language using Lex and Yacc. As I have gone I have expanded the language and its parsers to deal with the expansions.
I am aware that this is a very long way from a robust compiler for a language as extensive as C++, but illustrates one motivation for going down this route. I would suggest that your view of simple languages as being pretty useless is an overstatement. Even a very limited language can be of substantial use.
Though I have basically no experience in making languages of my own, I do have a good amount of experience learning new ones, so I could suggest this -
The programming industry is a marketplace of languages. Languages rise and fall in popularity based on their simplicity to learn and use, lack of commercial and legal restriction, applicability to real-life situations, flexibility, and power. If you want your language to be popular one day, try to go for these.
If you're designing a toy language for its own sake (as many computer scientists do), it's a interesting theoretical exercise and still quite valid, but you might not expect it to become quite as widespread.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I want a better C. Let me explain:
I do a lot of programming in C, which is required for applications that have real-time needs such as audio programming, robotics, device drivers, etc.
While I love C, one thing that gets on my nerves after having spent a lot of time with Haskell is the lack of a proper type system. That is, as soon as you want to write a more general-purpose function, say something that manipulates a generic pointer, (like say a generic linked list) you have to cast things to void* or whatever, and you loose all type information. It's an all-or-nothing system, which doesn't let you write generic functions without losing all the advantages of type checking.
C++ doesn't solve this. And I don't want to use C++ anyways. I find OO classes and templates to be a headache.
Haskell and its type classes do solve this. You can have semantically useful types, and use type constraints to write functions that operate on classes of types, that don't depend on void.
But the domain I'm working in, I can't use Haskell, because it's not real-time capable--mostly due to garbage collection. GC is needed because it's very difficult to do functional programming, which is allocation-heavy, without automatic memory management. However, there is nothing specifically in the idea of type classes that goes against C's semantics. I want C, but with Haskell's dependable type system, to help me write well-typed systems. However, I really want C: I want to be in control of memory management, I want to know how the data structures are layed out, I want to use (well-typed) pointer arithmetic, I want mutability.
Is there any language like this? If so, why is it not more popular for low-level programming?
Aside: I know there are some small language experiments in this direction, but I'm interested in things that would be really usable in real-world projects. I'm interesting in growing-to-well-developed languages, but not so much "toy" languages.
I should add, I heard of Cyclone, which is interesting, but I couldn't get it to compile for me (Ubuntu) and I haven't heard of any projects actually using it.. any other suggestions in this vein are welcome.
Thanks!
Since nobody brought it up yet: I think the ATS language is a very good candidate for a better C! Especially since you enjoy Haskell and thus functional programming with strong types. Note that ATS seems to be specifically designed for systems programming and hard real-time applications as most of it can do without garbage collection.
If you check the shootout you will find that performance is basically on par with C. I think this is quite impressive since modern c compilers have years and years and years of optimization work behind them while ATS is basically developed by one guy. -- while other languages providing similar safety features usually introduce overhead ATS ensures things entirely at compile time and thus yields very similar performance characteristics as C.
To quote the website:
What is ATS?
ATS is a statically typed programming language that unifies implementation with formal specification. It is equipped with a highly expressive type system rooted in the framework Applied Type System, which gives the language its name. In particular, both dependent types and linear types are available in ATS. The current implementation of ATS (ATS/Anairiats) is written in ATS itself. It can be as efficient as C/C++ (see The Computer Language Benchmarks Game for concrete evidence) and supports a variety of programming paradigms that include:
Functional programming. The core of ATS is a functional language based on eager (aka. call-by-value) evaluation, which can also accommodate lazy (aka. call-by-need) evaluation. The availability of linear types in ATS often makes functional programs written in it run not only with surprisingly high efficiency (when compared to C) but also with surprisingly small (memory) footprint (when compared to C as well).
Imperative programming. The novel and unique approach to imperative programming in ATS is firmly rooted in the paradigm of programming with theorem-proving. The type system of ATS allows many features considered dangerous in other languages (e.g., explicit pointer arithmetic and explicit memory allocation/deallocation) to be safely supported in ATS, making ATS a viable programming language for low-level systems programming.
Concurrent programming. ATS, equipped with a multicore-safe implementation of garbage collection, can support multithreaded programming through the use of pthreads. The availability of linear types for tracking and safely manipulating resources provides an effective means to constructing reliable programs that can take advantage of multicore architectures.
Modular programming. The module system of ATS is largely infuenced by that of Modula-3, which is both simple and general as well as effective in supporting large scale programming.
In addition, ATS contains a subsystem ATS/LF that supports a form of (interactive) theorem-proving, where proofs are constructed as total functions. With this component, ATS advocates a programmer-centric approach to program verification that combines programming with theorem-proving in a syntactically intertwined manner. Furthermore, this component can serve as a logical framework for encoding deduction systems and their (meta-)properties.
What about Nimrod or Vala languages ?
Rust
Another (real) candidate for a better C is The Rust Programming Language.
Unlike some other suggestions, (Go, Nimrod, D, ...) Rust can directly compete with C and C++ because it has manual memory management and does not require garbage collection (see [1]).
What sets Rust apart is that it has safe manual memory management. (The link is to pc walton's blog, one of Rusts main contributors and generally worth a read ;) Among other things, this means it fixes the billion dollar mistake of nullpointers. Many of the other languages suggested here either require garbage collection (Go) or have garbage collection turned on by default and do not provide facilities for safe manual memory management beyond what C++ provides (Nimrod, D).
While Rust has an imperative heart, it does borrow a lot of nice things from functional languages, for example sum types aka tagged unions. It is also really concerned with being a safe and performance oriented language.
[1] Right now there are two main pointer types owned pointers (like std::unique_ptr in C++ but with better support from the typechecker) and managed pointers. As the name suggests the latter do require task-local garbage collection, but there are thoughts to remove them from the language and only provide them as a library.
EDITED to reflect #ReneSacs comment: Garbage collection is not required in D and Nimrod.
I don't know much about Haskell, but if you want a strong type system, take a look at Ada. It is heavily used in embedded systems for aerospace applications. The SIGADA moto is "In strong typing we trust." It won't be of much use, however, if you have to do Windows/Linux type device drivers.
A few reasons it is not so popular:
verbose syntax -- designed to be read, not written
compilers were historically expensive
the relationship to DOD and design committees, which programmers seem to knock
I think the truth is that most programmers don't like strong type systems.
Nim (former Nimrod) has a powerful type system, with concepts and easy generics. It also features extensive compile time mechanisms with templates and macros. It also has easy C FFI and all the low level features that you expect from a system programming language, so you can write your own kernel, for example.
Currently it compiles to C, so you can use it everywhere GCC runs, for example. If you only want to use Nim as better C, you can do it via the --os:standalone compiler switch, that gives you a bare bones standard library, with no OS ties.
For example, to compile to an AVR micro-controller you can use:
nim c --cpu:avr --os:standalone --deadCodeElim:on --genScript x.nim
Nim has a soft real-time GC where you can specify when it runs and the max pause time in microseconds. If you really can't afford the GC, you can disable it completely (--gc:none compiler switch) and use only manual memory management like C, losing most of the standard library, but still retaining the much saner and powerful type system.
Also, tagged pointers are a planned feature, that ensure you don't mix kernel level pointers with user level pointers, for example.
D might offer what you want. It has a very rich type system, but you can still control memory layout if you need to. It has unrestricted pointers like C. It’s garbage collected, but you aren’t forced to use the garbage collector and you can write your own memory management code if you really want.
However, I’m not sure to what extent you can mix the type richness with the low-level approach you want to use.
Let us know if you find something that suits your needs.
I'm not sure what state Cyclone is in, but that provided more safety for standard C. D can be also considered a "better C" to some extent, but its status is not very clear with its split-brain in standard library.
My language of choice as a "better C" is OOC. It's still young, but it's quite interesting. It gives you the OO without C++'s killer complexity. It gives you easy access to C interfaces (you can "cover" C structs and use them normally when calling external libraries / control the memory layout this way). It uses GC by default, but you can turn it off if you really don't want it (but that means you cannot use the standard library collections anymore without leaking).
The other comment mentioned Ada which I forgot about, but that reminded me: there's Oberon, which is supposed to be a safe(-er) language, but that also contains garbage collection mechanisms.
You might also want to look at BitC. It’s a serious language and not a toy, but it isn’t ready yet and probably won’t be ready in time to be of any use to you.
Nonetheless, a specific design goal of BitC is to support low-level development in conjunction with a Haskell-style type system. It was originally designed to support development of the Coyotos microkernel. I think that Coyotos was killed off, but BitC is still apparently being developed.
C++ doesn't solve this. And I don't want to use C++ anyways. I find OO classes and templates to be a headache.
Get over this attitude. Just use C++. You can start with coding C in C++ and keep gradually moving to better style.
At the risk of sounding naive, I ask this question in search of a deeper understanding of the concept of programming languages in general. I write this question for my own edification and the edification of others.
What is a useful definition of a computer programming language and what are its basic and necessary components? What are the key features that differentiate languages (functional, imperative, declarative, object oriented, scripting, etc...)?
One way to think about this question. Imagine you are looking at the hardware of a modern desktop or laptop computer. Assume, that the C language or any of its variants do not exist. How would you describe to others all the things needed to make the computer expressive and functional in terms of what we expect of personal computers today?
Tangentially related, what is it about computer languages that allow other languages to exist? For example take a scripting language like Javascript, Perl, or PHP. I assume part of the definition of these is that there is an interpreter most likely implemented in C or C++ at some level. Is it possible to write an interpreter for Javascript in Javascript? Is this a requirement for a complete language? Same for Perl, PHP, etc?
I would be satisfied with a list of concepts that can be looked up or researched further.
Like any language, programming languages are simply a communication tool for expressing and conveying ideas. In this case, we're translating our ideas of how software should work into a structured and methodical form that computers (as well as other humans who know the language, in most cases) can read and understand.
What is a useful definition of a computer programming language and what are its basic and necessary components?
I would say the defining characteristic of a programming language is as follows: things written in that language are intended to eventually be transformed into something that is executed. Thus, pseudocode, while perhaps having the structure and rigor of a programming language, is not actually a programming language. Likewise, UML can express many powerful ideas in an abstract manner just like a programming language can, but it falls short because people don't generally write UML to be executed.
How would you describe to others all the things needed to make the computer expressive and functional in terms of what we expect of personal computers today?
Even if the word "programming language" wasn't part of the shared vocabulary of the group I was talking to, I think it would be obvious to the others that we'd need a way to communicate with the computer. Just as no one expects a car to drive itself (yet!) without external instructions in the form of interaction with the steering wheel and pedals, no one could expect the hardware to function without being told what to do. As noted above, a programming language is the conduit through which we can make that communication happen.
Tangentially related, what is it about computer languages that allow other languages to exist?
All useful programming languages have a property called Turing completeness. If one language in the Turing-complete set can do something, then any of them can; they are said to be computationally equivalent.
However, just because they're equally "powerful" doesn't mean they're equally nice to work with for humans. This is why many people are willing to sacrifice the unparalleled micromanagement you get from writing assembly code in exchange for the expressiveness and power you get with higher-level languages, like Ruby, Python, or C#.
Is it possible to write an interpreter for Javascript in Javascript? Is this a requirement for a complete language? Same for Perl, PHP, etc?
Since there is a Javascript interpreter written in C, it follows that it must be possible to write a Javascript interpreter in Javascript, since both are Turing-complete. However, again, note that Turing-completeness says nothing about how hard it is to do something in one language versus another -- only whether it is possible to begin with. Your Javascript-interpreter-inside-Javascript might well be horrendously inefficient, consume absurd amounts of memory, require enormous processing power, and be a hideously ugly hack. But Turing-completeness guarantees it can be done!
While this doesn't directly answer your question, I am reminded of the Revenge of the Nerds essay by Paul Graham about the evolution of programming languages. It's certainly an interesting place to start your investigation.
Not a definition, but I think there are essentially two strands of development in programming languages:
Those working their way up from what the machine can do to something more expressive and less tied to the machine (Assembly, Fortran, C, C++, Java, ...)
Those going down from some mathematical or theoretical computer science concept of computation to something implementable on a real machine (Lisp, Prolog, ML, Haskell, ...)
Of course, in reality the picture is not as neat, and both strands influence each other by borrowing the best ideas.
Slightly long rant ahead.
A computer language is actually not all that different from a human language. Both are used to express ideas and concepts in commonly understood terms. Among different human languages there are syntactic differences, but you can express the same thing in every language (does that make human languages Turing complete? :)). Some languages are better suited for expressing certain things than others.
For example, although technically not completely correct, the Inuit language seems quite suited to describe various kinds of snow. Japanese in my experience is very suitable for expressing ones feelings and state of mind thanks to a large, concise vocabulary in that area. German is pretty good for being very precise thanks to largely unambiguous grammar.
Different programming languages have different specialities as well, but they mostly differ in the level of detail required to express things. The big difference between human and programming languages is mostly that programming languages lack a lot of vocabulary and have very few "grammatical" rules. With libraries you can extend the vocabulary of a language though.
For example:
Make me coffee.
Very easy to understand for a human, but only because we know what each of the words mean.
coffee : a drink made from the roasted and ground beanlike seeds of a tropical shrub
drink : a liquid that can be swallowed
swallow : cause or allow to pass down the throat
... and so on and so on
We know all these definitions by heart, but we had to learn them at some point.
In the same way, a computer can be "taught" to "understand" words as well.
Coffee::make()->giveTo($me);
This could be a perfectly valid expression in a computer language. If the computer "knows" what Coffee, make() and giveTo() means and if $me is defined. It expresses the same idea as the English sentence, just with a different, more rigorous syntax.
In a different environment you'd have to say slightly different things to get the same outcome. In Japanese for example you'd probably say something like:
コーヒーを作ってもらっても良いですか？
Kōhī o tsukuttemoratte mo ii desu ka?
Which would roughly translate to:
if ($Person->isAgreeable('Coffee::make()')) {
return $Person->return(Coffee::make());
}
Same idea, same outcome, but the $me is implied and if you don't check for isAgreeable first you may get a runtime error. In computer terms that would be somewhat analogous to Ruby's implied behaviour of returning the result of the last expression ("grammatical feature") and checking for available memory first (environmental necessity).
If you're talking to a really slow person with little vocabulary, you probably have to explain things in a lot more detail:
Go to the kitchen.
Take a pot.
Fill the pot with water.
...
Just like Assembler. :o)
Anyway, the point being, a programming language is actually a language just like a human language. Their syntax is different and specialized for the problem domain (logic/math) and the "listener" (computers), but they're just ways to transport ideas and concepts.
EDIT:
Another point about "optimization for the listener" is that programming languages try to eliminate ambiguity. The "make me coffee" example could, technically, be understood as "turn me into coffee". A human can tell what's meant intuitively, a computer can't. Hence in programming languages everything usually has one and one meaning only. Where it doesn't you can run into problems, the "+" operator in Javascript being a common example.
1 + 1 -> 2
'1' + '1' -> '11'
See "Programming Considered as a Human Activity." EWD 117.
http://www.cs.utexas.edu/~EWD/transcriptions/EWD01xx/EWD117.html
Also See http://www.csee.umbc.edu/331/current/notes/01/01introduction.pdf
Human expression which:
describes mathematical functions
makes the computer turn switches on and off
This question is very broad. My favorite definition is that a programming language is a means of expressing computations
Precisely
At a high level
In ways we can reason about them
By computation I mean what Turing and Church meant: the Turing machine and the lambda calculus have equivalent expressive power (which is a theorem), and the Church-Turing hypothesis (which is a conjecture) says roughly that there's no more powerful notion of computation out there. In other words, the kinds of computations that can be expressed in any programming languages are at best the kinds that can be expressed using Turing machines or lambda-calculus programs—and some languages will be able to express only a subset of those calculations.
This definition of computation also encompasses your friendly neighborhood hardware, which is pretty easy to simulate using a Turing machine and even easier to simulate using the lambda calculus.
Expressing computations precisely means the computer can't wiggle out of its obligations: if we have a particular computation in mind, we can use a programming language to force the computer to perform that computation. (Languages with "implementation defined" or "undefined" constructs make this task more difficult. Programmers using these languages are often willing to settle for—or may be unknowingly settling for—some computation that is only closely related to the computation they had in mind.)
Expressing computation at a high level is what programming langauges are all about. An important reason that there are so many different programming languages out there is that there are so many different high-level ways of thinking about problems. Often, if you have an important new class of problems to solve, you may be best off creating a new programming language. For example, Larry Wall's writing suggests that solving a class of problems called "systems administration" was a motivation for him to create Perl.
(Another reason there are so many different programming languages out there is that creating a new language is a lot of fun, and anyone can learn to do it.)
Finally, many programmers want languages that make it easy to reason about programs. For example, today a student of mine implemented a new algorithm that made his program run over six times faster. He had to reason very carefully about the contents of C arrays to make sure that the new algorithm would do the same job the old one did. Luckily C has decent tools for reasoning about programs, for example:
A change in a[i] cannot affect the value of a[i-1].
My student also applied a reasoning principle that isn't valid in C:
The sum of of a sequence unsigned integers will be at least as large as any integer in the sequence.
This isn't true in C because the sum might overflow. One reason some programmers prefer languages like Standard ML is that in SML, this reasoning principle is always valid. Of languages in wide use, probably Haskell has the strongest reasoning principles Richard Bird has developed equational reasoning about programs to a high art.
I will not attempt to address all the tangential details that follow your opening question. But I hope you will get something out of an answer that aims to give a deeper understanding, as you asked, of a fundamental question about programming languages.
One thing a lot of "IT" types forget is that there are 2 types of computer programming languages:
Software programming languages: C, Java, Perl, COBAL, etc.
Hardware programming languages: VHDL, Verilog, System Verilog, etc.
Interesting.
I'd say the defining feature of a programming language is the ability to make decisions based on input. Effectively, if and goto. Everything else is lots and lots of syntactic sugar. This is the idea that spawned Brainfuck, which is actually remarkably fun to (try to) use.
There are places where the line blurs; for example, I doubt people would consider XSLT to really be a programming language, but it's Turing-complete. I've even solved a Project Euler problem with it. (Very, very slowly.)
Three main properties of languages come to mind:
How is it run? Is it compiled to bare metal (C), compiled to mostly bare metal with some runtime lookup (C++), run on a JIT virtual machine (Java, .NET), bytecode-interpreted (Perl), or purely interpreted (uhh..)? This doesn't comment much on the language itself, but speaks to how portable the code may be, what sort of speed I might expect (and thus what broad classes of tasks would work well), and sometimes how flexible the language is.
What paradigms does it support? Procedural? Functional? Is the standard library built with classes or functions? Is there reflection? Is there, ideally, support for pretty much whatever I want to do?
How can I represent my data? Are there arrays, and are they fixed-size or not? How easy is it to use strings? Are there structs or hashes built in? What's the type system like? Are there objects? Are they class-based or prototype-based? Is everything an object, or are there primitives? Can I inherit from built-in objects?
I realize the last one is a very large collection of potential questions, but it's all related in my mind.
I imagine rebuilding the programming language landscape entirely from scratch would work pretty much how it did the first time: iteratively. Start with assembly, the list of direct commands the processor understands, and wrap it with something a bit easier to use. Repeat until you're happy.
Yes, you can write a Javascript interpreter in Javascript, or a Python interpreter in Python (see: PyPy), or a Python interpreter in Javascript. Such languages are called self-hosting. Have a look at Perl 6; this has been a goal for its main implementation from the start.
Ultimately, everything just has to translate to machine code, not necessarily C. You can write D or Fortran or Haskell or Lisp if you want. C just happens to be an old standard. And if you write a compiler for language Foo that can ultimately spit out machine code, by whatever means, then you can rewrite that compiler in Foo and skip the middleman. Of course, if your language is purely interpreted, this will probably result in a stack overflow...
As a friend taught me about computer languages, a language is a world. A world of communication with that machine. It is world for implementing ideas, algorithms, functionality, as Alonzo and Alan described. It is the technical equivalent of the mathematical structures that the aforementioned scientists built. It is a language with epxressions and also limits. However, as Ludwig Wittgenstein said "The limits of my language mean the limits of my world", there are always limitations and that's how one chooses it's language that fits better his needs.
It is a generic answer... some thoughts actually and less an answer.
There are many definitions to this but what I prefer is:
Computer programming is programming that helps to solve a particular technical task/problem.
There are 3 key phrases to look out for:
You: Computer will do what you (Programmer) told it to do.
Instruct: Instruction is given to the computer in a language that it can understand. We will discuss that below.
Problem: At the end of the day computers are tools (Complex). They are there to make out life simpler.
The answer can be lengthy but you can find more about computer programming
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
In your opinion, what are the most important languages for a programmer to know? I'm talking about concepts, not about how practical the language is.
List the languages and a reason. For example, Lisp for functional programming, JavaScript for prototype-based OOP, etc.
Must know:
1) C (system programming, understanding of machine architecture)
2) Perl or Python or Ruby (practical day-to-day tasks)
3) Java or C# or C++ (OOP, and quite important to get a job these days)
Really important:
1) Haskell or ML (functional programming; changes the way you think)
2) Lisp or Scheme (power of macros)
Nice additionals:
1) Forth (very low-level, explicit stack operation + joy to write your own interpreter)
2) Assembly languages (know how your CPU works)
3) Erlang (parallel processing)
4) Prolog (logic programming)
5) Smalltalk (true OOP and true interactive developent)
The assembly languages of as many chips as you can learn for low-level knowledge.
C to learn more practical knowledge of low-level workings, since almost all languages are implemented in C.
C++ for object-oriented programming on top of the low-level goodness of C.
Pascal to learn how to work with strong typing.
Java to see how you can shield yourself from low-level concerns.
Perl to learn regular expressions, weak/dynamic typing, and other good things.
Python to see strong/dynamic/duck typing.
Ruby to see how object-orientedness works on top of Perl-esque weak/dynamic typing.
Common Lisp for that functional enlightenment.
Scheme for the emphasis on recursion.
Emacs Lisp so you can extend Emacs.
Haskell to see pure functional programming done right.
APL so you learn how not to write code.
COBOL so you can make mad money maintaining legacy code.
Erlang to really learn about concurrency. (Thanks to Pete Kirkham for correcting me.)
Scala for functional programming on the JVM.
Clojure for a Lisp-like functional language on the JVM.
Prolog to understand logic programming.
D so you can see why all the D fanatics are always so pro-D.
C# so you can program for .NET (and Mono).
F# so you can do functional programming on .NET.
Forth for stack-based languages.
PHP so you can see how not to create a language. (Just kidding. Learn PHP beacause it's really useful for web development.)
JavaScript because it's basically the language for client-side web scripting.
bash for a good, general-purpose scripting language.
Visual Basic so you can read the code your boss wrote. =)
INTERCAL for "fun."
brainfuck so you can torture your friends.
LOLCODE so you can convince them to still be your friends after you subject them to brainfuck.
...And so on.
C for understanding how the most other language(-implementations) and operation systems are implemented
I think the three languages that best combine practicality and coverage of programming concepts would be
C
Python
Javascript
From these languages you can learn low-level system programming, pointers and memory management, static typing, dynamic typing, high-level scripting, event-driven programming, OO programming, functional programming.
Obviously you're not going to get as pure an intro to functional programming as you would with, say, Haskell, but you can learn a lot of the concepts in Python and (especially) Javascript.
It is not the languages rather the paradigms you should know:
procedural (like C, Pascal)
object-oriented (like Java, C++, Smalltalk)
functional (like Lisp, ML, Scala)
If you understood one of these paradigms in one language, it is easy to learn another language in the same paradigm. And there are even more fields specially supported by languages that are important to understand:
parallelism (in Erlang or Scala)
declarative templates (e.g. in C++ or Prolog)
dynamic languages (e.g. JavaScript)
At at last you should always know what goes on under the hoods, so you better have a look at assembler.
I would say:
C or Assembler to understand how the processor work.
Smalltalk (or C#, Java, Python, Ruby, etc) to understand object oriented programming.
Lisp (any Lisp, Scheme, Common Lisp, Clojure) to understand high level programming, meta programming (macros), etc.
Haskell to understand type inference and other functional concepts.
If you are into distributed systems, I'll consider learning Erlang too. Those are the language I recommend learning, even if only superficial, only for the sake of learning even if you never use them to write a real application.
Its best to know a variety. This gives you a better overall perspective of the art of programming, plus, you get to choose the best tool for the job.
My current list would be:-
C - programming close to the machine.
Python - programmers nirvana.
Perl - for when s**t happens.
Java - cause it will keep you in work.
C# - cause it will keep you in work.
lisp, scheme or something functional to get your brain out of a rut.
SQL - for managing large data sets.
JCL, COBOL, VAX DCL, CShell VB - just to remind you how bad things could be!
A good short list:
C for the machine concepts
Haskell for functional programming
Smalltalk (or maybe Ruby or Simula-67) for object-oriented programming
Prolog for logic programming
Icon for backtracking and mind-blowing string processing
Bourne shell for Unix scripting
Might also include
Scheme for macros
Awk or Perl or ... for regular expressions
FORTH for tiny bootstrapping postfix wonderfulness :-)
For concepts, I would choose assembler and Java.
The first because you should know in intimate detail how machines work.
The second because you should understand how to shield yourself from the intimate details of the way machines work :-). By that I mean a language with a rich set of data structures at hand (so really Java could be Python, C++ with Boost and so on).
Well. I'd say learn C and javascript. They are most widely used languages.
You might want to learn Java/some .Net language and/or python/ruby: they're more convenient, tho.
This have the advantage that all those languages are reasonably well designed.
For example, don't learn PHP or C++ because they're a mess. They're used widely, you might want to learn them one day, but they can seriously mess with your mind.
Limbo - a programming language with concurrency and channels, what C should have evolved into. ( see also D, another C successor )
No-one else seems to be mentioning any declarative languages, so here are a few:
Prolog - a declarative language for logic programming
Modelica - a declarative OO language for modelling systems.
XSLT - a declarative language for transforming XML.
For parallelism, you don't get much wider than shader language, and the related OpenCL - typically 512 processors in parallel on a high-end desktop, rather than Erlang's 4 processors in parallel ( though with many scheduled processes ).
This is a good question. I know a lot of people, myself included, get stuck in a rut where we are just churning out code like one would churn out burgers at a McDonald's. Coding becomes too mechanical—we understand how to get things done, but often times we forget why these things get done behind the scenes.
In my world it's been C++/C/ObjectiveC that have taught me the most, even though I write C# every day at work.
For the most part, learning C++ has helped me learn about memory management and how the various objects are stored in memory, etc.—the actual science of programming. What really opened my eyes was the Programming Paradigms class offered at Standford that you can get off of iTunes and I think YouTube.
You already mentioned two, here are a few more:
Java: Java is a good example of OOP 'cause you HAVE to use oop, and it's designed from the ground up to be an OOP language.
BASIC: Although obsolete, it's a good example of procedural languages and it has a very easy syntax.
For web programming: PHP, ANSI-SQL, javascript.
Some people may argue that HTML and CSS are not programming languages. But they are esential for web app development.
For Desktop app development, C++ with the Qt Framework. Qt gives C++ the additional "cross-platform" fizz.
Pascal or Basic for start and to master basics of procedural programming.
At school we learned Haskel for functional programming.
And then one should try assembler or C for getting deep and Java for OOP.
A have no arguments for this - that's only my taste and what I tried.
I would sat C/C++ cause it sets allot of basics for allot of other languages used around the world.
Personally I learned Java/JavaScript->VB(short course fortunately)->C#->C++, with a pinch of PHP and Perl on top of it all. Best part of that line was C# and then moving behind the scene in C++.
Look for a set of different programming languages:
C++ / C# / Java etc.
C / Assembler
Python, Ruby, Lua, Perl etc.
sh, awk, sed, regular expressions
Prolog (or similar)
Haskell / Lisp etc.
It doesn't really matter which ones you choose, but that you choose one from each "category".
Pseudocode for reading/writing documentation. :p
I think knowing C/C++ or any other low level language will help you with understanding the impacts of how managed/script languages works helps. Such as pointers will demystify variable references.
If you want to understand computers and the underlying hardware, C is the single most important language, commonly said to be the lingua franca of computers. The Stackoverflow podcast tends to cover this at least once a week.
There seem to be enough answers on this, so I'll just leave it at that.
You should know a scripting language so that you can prototype your applications faster.
Maybe python/ruby/perl . Groovy is also an alternative if you're a Java guy that likes his java libs.
Alot is already mentioned but I would definitely add C++ (already done) for the following reason:
C++ for learning how to use pointers and get the main idea about them.
Although there is the discussion if c++ is still the 'better' language (all depends on what you want to make really) it never hurts to understand pointers, just in case you do need them ever.
Having a scan through the answers so far I'm surprised I've not seen any mention of actionscript.
I think if you learn some C/C++, then some Java then that should prepare you for pretty much all of the decent languages out there.
I prefer to see my code in action and I find Actionscript 3 (not 2 or 1) along with Flex (which is MXML) great for quickly demoing visual concepts.
So C & Java helps to learn the syntax of the majority of languages.
Actionscript 3 (very similar to java syntax) & MXML for being able to express you code visually very quickly.
C - low level system programming plus to understand generic concepts about how memory is handled, stack, stack frame, heap and so on. These are helpful for understanding higher level languages
C++ - mainly std library (separation of generic algorithms and containers), templates, namespaces, but OO concepts as well. Templates meta programming will give you completely different perspective on writing software, this is compile time execution versus run time execution. Templates inheritance (static vs dynamic polymorphism).
Python - dynamic type system, list comprehension - functional programming (?), no memory management for developer, spaces for indentation
Objective-C - message dispatching (can dispatch to nil), dynamic type system (static as well), late binding, OO concepts
It may sound crazy, but I first learned to program writing VBScript macros for windows. I used a template, which is available here http://vbscript-macro-template.blogspot.com/ and I just added to it and also tried to understand everything that it did. Now, several years later I am writing my own desktop and database applications.
You should start from C and go through C++, Java and the goto WinForms,
Then better goto .NET
I have become interested in C-like languages for performance computing. Can you recommend some alternative programming languages which have the following attributes:
must be close to the hardware (bit fiddling, pointers or some alternative safe method like references)
no managed code (no jvm/.net languages)
has to be really fast (like C)
must be above ASM level (and yes I am interested in macro languages on top of ASM)
can be obscure, not very widespread
I am mainly interested in little-known languages.
How about Assembly language, or the D programming language?
If you don't know about it and are interested just in broadening your horizons, take a look at Forth. Reading about Forth always makes me feel C is high-level.
Well, I've always preferred C and/or C++ because there are multiple flavours (MSVC, glibc etc), it runs on many different platforms (e.g. mobile devices, Windows, linux) and devices, and it can be written cross platform (different processor architectures) and even for high end graphics (e.g. DirectX).
You get "decent" access to platform resources (conditions vary), it can be as fast as you choose to hone it, and it's a tad easier (IMHO) to write than ASM. There's also a pretty decent range of support tools and code analysis tools to make things a little easier.
Also C and C++ have been around for quite some time, so it's got (even today) an excellent and enthusiastic community!
You don't explicitly state that it can't be C in your question, so I'll go ahead and recommend C. It fulfills your three bulleted desires, and you won't have to worry about different versions of the language (like each different kind of assembler).
Forth!
Forth can be faster than machine language on some architectures. The compiled code is extremely dense, therefore, making optimal use of code caching.
assembly would be the closest to the hardware and therefore the fastest
Ada was originally designed for embedded systems (among other things).
OpenCL might be interesting. It's sort of like OpenGL shader language (a subset of C with extensions), but for general purpose parallel array computing.
You could start programming FPGAs in VHDL, Verilog, System C ...
Variations on a theme
FORTRAN is older than C, and is still one of the major players in numerical computing. Until 1990 (when the language was substantially modernized), the language didn't have any form of pointer (checked or not). This lack meant that there was no way to manage memory dynamically; it also made aliasing analysis easy for the compiler, which is one of the things that makes Fortran code fast.
ALGOL was the first structured programming language. Although it had limited success with programmers, it had a strong influence on language designers.
Ada is an imperative language with a strong type system and good modularity, which makes it good for low-level programming with strong assurance requirements (it was sponsored by the US government with military and avionics applications in mind). It was inspired by Pascal, like Modula-2 and Modula-3.
Going further from the mainstream of low-level imperative programming, there is FORTH. FORTH can be compiled for, and even interpreted on, devices with very little memory; it finds a lot of use on low-end embedded systems, including microcontrollers. The language is based on reverse polish notation, made famous by HP calculators (in fact, the language of HP calculators is strongly influenced by FORTH). Many implementations don't have variables: all data is kept on one or more stacks.
Just for fun, I'll mention INTERCAL, the grandaddy of esoteric languages.
Stuff that will blow your mind
Esoteric languages can be instructive, and a quite a few work close to the machine (usually a virtual machine, but in principle you could implement them for an actual computer if you were crazy enough). You could look at brainfuck (a sort of intermediate stage between Turing machines and C), or the many single-instruction languages, or befunge (what if memory was a two-dimensional array?).
Cyclone looks a lot like C. The syntax is the same, and Cyclone has pointers, untagged structures and unions, goto statements and manual memory management. And yet it's a safe language: you can't have a dangling pointer, or a buffer overflow. And you have access to high-level features such as pattern matching, exceptions, polymorphism, abstract types and optional automatic memory management (not just garbage collection, but also regions). Cyclone is both useful and instructive; for a C die-hard, it can be a good way of discovering what makes a safe language. Cyclone can compile to C, so you can run your programs anywhere you have a C compiler for.
Going in a different direction, if you want to be close to the hardware, while still not actually designing hardware, have a look at synchronous languages, such as Lustre and Esterel. These languages are used to program high-assurance realtime systems such as nuclear plants, airplanes and railway signaling. These languages give up Turing completeness and gain the assurance that programmers can know exactly how fast their program will run and how much memory it will require. If you think C is close to the machine, finding out what a language that is really close to the machine may come as a shock.
You can't get much closer than assembly language, unless you get a job with a chip-maker and start writing micro code!!!
If you're on Windows I think you can get hold of Microsoft MASM (macro assembler) that will allow you go get up and running quickly. I used it a long time ago and it's not a bad product.
Seems a bit awkward to answer my question, but I have found two languages:
Pyrex
Vala
They may not fulfill all of the constraints, but they are great for performance computing and both translates to C.