Power of Modern Programming Languages is That They Are Expressive, Readable, Concise, Precise, and Executable (scientificamerican.com)

An anonymous reader shares a Scientific American article: Programming has changed. In first generation languages like FORTRAN and C, the burden was on programmers to translate high-level concepts into code. With modern programming languages -- I'll use Python as an example -- we use functions, objects, modules, and libraries to extend the language, and that doesn't just make programs better, it changes what programming is. Programming used to be about translation: expressing ideas in natural language, working with them in math notation, then writing flowcharts and pseudocode, and finally writing a program. Translation was necessary because each language offers different capabilities. Natural language is expressive and readable, pseudocode is more precise, math notation is concise, and code is executable. But the price of translation is that we are limited to the subset of ideas we can express effectively in each language. Some ideas that are easy to express computationally are awkward to write in math notation, and the symbolic manipulations we do in math are impossible in most programming languages. The power of modern programming languages is that they are expressive, readable, concise, precise, and executable. That means we can eliminate middleman languages and use one language to explore, learn, teach, and think.

Comments

Re:What?

[PCM2]

Everybody simmer down. TL;DR:

1. TFA is not an article in Scientific American magazine, it is a "guest blog." Quote: "The views expressed are those of the author(s) and are not necessarily those of Scientific American."

2. The author teaches computer science at a private undergraduate college. He has written a series of books, all of which use Python examples to explain concepts.

3. When he talks about "modern languages," he's clearly referring to languages that look and feel a lot like Python. Mainly Python.

4. When he talks about "eliminating intermediary languages," he means things like pseudocode. He believes (and gives an example to illustrate) that Python is now expressive enough that anything you might previously have expressed in pseudocode you can now express in Python in one go.

5. From there, he makes the leap that you no longer need to teach computer science from a "math-first" approach; you can instead use a "code-first" approach, where you teach students to "think" in Python.

6. Hand-waving about the future from there.

Re: What a piece of crap

[K. S. Kyosuke]

I've read the article and I didn't notice any connection between "executable" and "interpreted" that you seem to be making. By "executable", the author very clearly means "executable". Executable means a computer can execute it, period. The mechanism is immaterial here. And had you actually read the article, it would have been obvious to you because of the contrasting comparison with pseudo-code example that *cannot* be executed - it's not something you can type into a computer in an unchanged form and still have it run.

Re:What?

[Anubis IV]

Neither Fortran, nor C are first generation languages

In fact, every language he mentions in the article is a textbook example of a third-gen language (3GL). I didn't see any mention of even a single first generation language.

I'll give him the benefit of the doubt and assume he was trying to keep his writing approachable, but "first generation languages" has had an established meaning in this field for the last several decades, so misusing the terminology just makes it look like he has no idea what he's talking about. A far better way to phrase it would have been "In early high-level languages like FORTRAN and C [...]", since that would have been accurate while also being descriptive enough for most lay people to understand well enough.

For anyone who doesn't know about them, programming language generations refer to the level of abstraction, NOT to when they were introduced:

1. 1GL = Machine code. Flipping bits to issue machine-specific instructions
2. 2GL = Assembly. Using human-readable text to issue basically the same instructions
3. 3GL = Most high-level programming languages. Abstracting away machine instructions (e.g. using loops and function calls to abstract away jump instructions) to the point that it's both easier to use and mostly machine-independent (e.g. Fortran, COBOL, C, C++, C#, Java, Python, Ruby, Go, Rust, Swift, etc.)
4. 4GL = Languages that, among other things, abstract generating reports, generating UIs, and/or handling collections of information (e.g. SQL, some 3GLs with libraries, etc.)
5. 5GL = Languages where you describe the problem and let the computer come up with the algorithm (e.g. Prolog)

All of which is to say, starting off an article with a glaring misuse of established terminology is a great way to get anyone with a passing awareness of the topic to immediately dismiss anything he has to say. As a professor, I'd hope he'd have a better awareness about the importance of using those terms correctly. And as the publisher, I'd hope that Scientific American would have an editor who would recognize when they were out of their depth and would need to call in a domain expert to proof the text.