Programming Paradigms, Turing Completeness and Computational Thinking (2020)
programming-journal.org
Programming Paradigms, Turing Completeness and Computational Thinking (2020)
1–10 of 26 posts
Re: Programming Paradigms, Turing Completeness and Computational Thinking (2020)
#2Is this actually controversial? I'm sure a proper framing of the topic is interesting enough to warrant a paper, but the core idea is almost universally accepted by academics and practitioners alike. What exactly is the opposing viewpoint?
Re: Programming Paradigms, Turing Completeness and Computational Thinking (2020)
#3Is this actually controversial? I'm sure a proper framing of the topic is interesting enough to warrant a paper, but the core idea is almost universally accepted by academics and practitioners alike. What exactly is the opposing viewpoint?
Yeah, not controversial but it's still ingrained in the way we teach and talk about programming languages as the author points out:
> The notion of distinct programming paradigms, as opposed to permeable traditions of programming languages and methodologies, now seems anachronistic in Computer Science curricula, and should be revisited. In particular, the inconsistent uses in the influential ACM/IEEE Curricula should be addressed.
When institutions knowingly teaching people bad theory because they don't have better frames I think that means that our research has missed some good opportunities for exploration. The academy is setting people up to answer the questions "how do we improve the task of programming?" rather than exploring the more fundamental question of "what could/should programming be?".
A genuinely new programming paradigm would not be the same as just a new methodology - it would have to be accompanies by a new theory of programming itself (not just computation). I think the breakthrough comes from modeling programming not around conceptual frameworks of computation but instead around our own human process of cognition. If we create languages which provide the optimal expressiveness of the problem/solution from the point of view of the human writing the program - this could transform what programming itself means. This is where I think the majority of impactful innovation will come from in the next couple of decades.
Re: Programming Paradigms, Turing Completeness and Computational Thinking (2020)
#4Is this actually controversial? I'm sure a proper framing of the topic is interesting enough to warrant a paper, but the core idea is almost universally accepted by academics and practitioners alike. What exactly is the opposing viewpoint?
Yeah, not controversial but it's still ingrained in the way we teach and talk about programming languages as the author points out: > The notion of distinct programming paradigms, as opposed to permeable traditions of programming languages and methodologies, now seems anachronistic in Computer Science curricula, and should be revisited. In particular, the inconsistent uses in the influential ACM/IEEE Curricula should…
> A genuinely new programming paradigm would not be the same as just a new...
How would this be different from, e.g. the development of modern high-level programming languages? To a certain extent, structured programming exists because we find it cognitively easier to express our programs in terms of if/then/else statements or loops as opposed to conditional jumps.
I don't think the "algorithmic" type of thinking is really escapable if you want to end up with code that actually executes.
Re: Programming Paradigms, Turing Completeness and Computational Thinking (2020)
#5I am surprised how pervasive is the idea that most of the applications has to be written in TC languages (I suspect it's more a historical accident, due to "eternal September" of people who came into IT from home computers; before that, there was a pretty strong divide between system and application programmers). I think when they talk about paradigm shift, this could be a paradigm shift. Using TC languages only for tools, but write the application logic (and systems configuration) in non-TC languages.
(Also see my earlier comment here: https://news.ycombinator.com/item?id=26248362)
Re: Programming Paradigms, Turing Completeness and Computational Thinking (2020)
#6Earlier quoted context omitted.
Yeah, not controversial but it's still ingrained in the way we teach and talk about programming languages as the author points out: > The notion of distinct programming paradigms, as opposed to permeable traditions of programming languages and methodologies, now seems anachronistic in Computer Science curricula, and should be revisited. In particular, the inconsistent uses in the influential ACM/IEEE Curricula should…
> A genuinely new programming paradigm would not be the same as just a new... How would this be different from, e.g. the development of modern high-level programming languages? To a certain extent, structured programming exists because we find it cognitively easier to express our programs in terms of if/then/else statements or loops as opposed to conditional jumps. I don't think the "algorithmic" type of thinking is…
Software is composed of algorithms but most software engineers aren't writing the algorithms they use themselves. If algorithms are only a part of software production, maybe optimizing our languages around this subset of problems isn't actually optimal.
Higher-level languages really should mean languages that operate on another level of abstraction - programs that themselves are interpreted by other programs. Raising the level of abstraction requires also hiding details that aren't important at a higher level so, arguably, modern high-level languages are rarely all that much higher-level than C (even if they are safer/easier/faster).
Knowing a Turing complete language will probably always be a valued skill but it might one day become similar to knowing Assembly today - it's important to know if you care a lot about implementation details but it's not the language you use to reason about the overall program. Libraries, frameworks and system components all need to be able to express a level of detail which makes algorithmic thinking ideal but it's not necessarily the best model for specifying the behavior of information systems or making devices end-user programmable. There's a whole world of relatively unexplored possibilities here for language designers to explore.
(NOTE: I'm using a backup account to work around my anti-procrastination settings but I'm the author of the original comment)
Re: Programming Paradigms, Turing Completeness and Computational Thinking (2020)
#7Earlier quoted context omitted.
Yeah, not controversial but it's still ingrained in the way we teach and talk about programming languages as the author points out: > The notion of distinct programming paradigms, as opposed to permeable traditions of programming languages and methodologies, now seems anachronistic in Computer Science curricula, and should be revisited. In particular, the inconsistent uses in the influential ACM/IEEE Curricula should…
> A genuinely new programming paradigm would not be the same as just a new... How would this be different from, e.g. the development of modern high-level programming languages? To a certain extent, structured programming exists because we find it cognitively easier to express our programs in terms of if/then/else statements or loops as opposed to conditional jumps. I don't think the "algorithmic" type of thinking is…
But is it?
A lot of what we do today is not algorithmic in nature. Arguably the majority. For example, take your phone and tell me how many apps follow a computational/algorithmic paradigm, that is, you give them some parameters, they compute an answer and then terminate. But we have to express all of this algorithmically, and the mismatch is a source of a lot of the pain we have in software development today, IMHO.
I am not sure that Turing completeness is really the main driver here, but it is at least a symptom.
As Guy Steele put it:
Another weakness of procedural and functional programming is that their viewpoint assumes a process by which "inputs" are transformed into "outputs"; there is equal concern for correctness and for termination (and proofs thereof). But as we have connected millions of computers to form the Internet and the World Wide Web, as we have caused large independent sets of state to interact–I am speaking of databases, automated sensors, mobile devices, and (most of all) people–in this highly interactive, distributed setting, the procedural and functional models have failed, another reason why objects have become the dominant model. Ongoing behavior, not completion, is now of primary interest. Indeed, object-oriented programming had its origins in efforts to simulate the ongoing behavior of interacting real-world entities–thus the programming language SIMULA was born.
https://dreamsongs.com/ObjectsHaveNotFailedNarr.html
But of course objects are also highly procedural, at least as we have conceived and implemented them today:
Instead, objects use procedural abstraction to hide behavior. This difference has significant consequences for use of the two forms of data abstraction. Object interfaces are essentially higher-order types, in the same sense that passing functions as values is higher-order. Any time an object is passed as a value, or returned as a value, the object-oriented program is passing functions as values and returning functions as values. The fact that the functions are collected into records and called methods is irrelevant. As a result, the typical object-oriented program makes far more use of higher-order values than many functional programs.
William Cook, On understanding data abstraction, revisited
More here: https://2020.programming-conference.org/details/salon-2020-p...
My current attempt at overcoming: http://objective.st
Re: Programming Paradigms, Turing Completeness and Computational Thinking (2020)
#8software is a factory that produces data.
The Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with principle-based Warehouse/Workshop Model
https://github.com/linpengcheng/PurefunctionPipelineDataflow
Re: Programming Paradigms, Turing Completeness and Computational Thinking (2020)
#9I am surprised how pervasive is the idea that most of the applications has to be written in TC languages (I suspect it's more a historical accident, due to "eternal September" of people who came into IT from home computers; before that, there was a pretty strong divide between system and application programmers). I think when they talk about paradigm shift, this could be a paradigm shift. Using TC languages only for…
> due to "eternal September" of people who came into IT from home computers...
I think this is spot-on. We have relatively fixed mental models for what computing should look like which are really just based on a few accidents of history. Bret Victor's famous "The Future of Programming" talk is a great reminder that our ambitions for what computing could be were once much broader than they are today.
Re: Programming Paradigms, Turing Completeness and Computational Thinking (2020)
#10To expand on what qsort said, the paper is right in stating that it's not possible to draw bright lines between the different programming paradigms, but who expected otherwise?
You can use C++ to write C-style procedural code, or object-oriented code, or functional code. You could use it to write stack-oriented code in the Forth style. With the help of a library you could even use the logic programming style of Prolog. C++ compilers also tend to support assembly. Of course, the list goes on. You could implement a Turing machine, or a one-instruction-set computer, or Game of Life, or Langton's Ant, and use that as your computational paradigm.
The distinctions between the programming paradigms are often a fuzzy matter of emphasis and idiom, it's not precise and unambiguous.
I hadn't encountered the term hypercomputation before. [0]
> The notion of distinct programming paradigms, as opposed to permeable traditions of programming languages and methodologies, now seems anachronistic in Computer Science curricula, and should be revisited. In particular, the inconsistent uses in the influential ACM/IEEE Curricula should be addressed.
I'm not convinced. It makes good sense to have a course on functional programming, to introduce students to its concepts. The concepts aren't easy, and it makes sense to dedicate a whole course to them. What does it matter that the distinctions between programming paradigms are ultimately imprecise? The same is true for just about everything.
Also, the paper didn't mention the related concept of the Rule of least power: choose the least powerful computer language suitable for a given purpose. [1]