4 ms·

My thoughts are that we don't really need more languages. Arguably we don't need better ones either, because they aren't the problem in general computing. Inste

My thoughts are that we don't really need more languages. Arguably we don't need better ones either, because they aren't the problem in general computing. Instead we need better design paradigms that better let us model complex requirements and systems into code. Let's have new languages that then support those paradigms. We continue to struggle abstracting complex problems using functional decomposition, structured analysis, information (data) modeling, and object-based decomposition. Many newcomers I meet only know modeling problem domain concepts as data in a database, with behavior and constraints acting on that data in a separate layer, organized using functional decomposition. Of course that layer increasingly approaches a 'big ball of mud' as size and complexity increases. Sounds a lot like we are back data-flow modeling as so popular in the 1980's, in a new guise. A focus on programming languages in my opinion, masks the real issues we face.

ShallowLearning 9y ago
Much of the time, new languages lead to new design paradigms. As a general rule, newer languages are more abstracted than older ones. When people don't need to get hung up on the intricacies of low level programming, real progress can be made on the design paradigm front.
- aryehof 9y ago
  I'm curious which languages have resulted in which new design paradigms?
  - miguelrochefort 9y ago
    Elm -> Elm Architecture
  - arianvanp 9y ago
    Two good examples: Erlang led to Microservices and the Reactive Manifesto. the Open Telecom Platform is still a very modern Microservice library (in my opinion) after more than three! decades ML led to programming against generic interfaces (http://www.cs.cornell.edu/courses/cs312/2006fa/recitations/rec08.html http://www.cs.cornell.edu/courses/cs312/2006fa/recitations/r...)
    - deleted 9y ago
      [deleted]
- asavinov 9y ago
  I would say that it is a two-directional dependency: language constructs <--> design patterns Programmers experiment with and accumulates various design patterns using existing languages. Then the most useful of them are implemented (frozen) as programming constructs. Then programmers experiment with these new programming constructs and come up with new design patterns. And so on. In fact, these design patterns and language constructs come in (anti-phase) waves.
asavinov 9y ago
> A focus on programming languages in my opinion, masks the real issues we face. Indeed, major problems of programming languages can hardly be solved in the area of programming languages itself as it is being done now. I would say that one needs a new programming or computing model so it is not about languages. At least it is my conclusion after 10+ years of research and attempts to develop such a new programming paradigm. And although I have quite significant progress (concept-oriented programming), the more I do and the deeper I go, the more fundamental problems I meet. And these problems are not about programming languages at all. It is more about "how a system works", "what is a system", "what is computing" etc.
- pdimitar 9y ago
  Doing such a huge research has to have phases of some sort. At certain point you should stop, re-evaluate, and say "okay, where I am at now is good enough to solve problems X and Y, most of the time". Otherwise it's endless and one loses motivation.
timthelion 9y ago
I agree, and from a different perspective, I would compare this to literature. In English literature we have many different paradigms: Victorian literature, Modernism, Post modernism, Post colonial ect. The language has to be expressive, and in being expressive, it can express any of these different paradigms. The fact that the vocabulary is shared between the "eras" of literature is only a bonus which makes authors more flexible and more able to experiment with actually new concepts, rather than simply reinventing the same old vocabulary. We then have Chinese literature and Indian literature, and these have very different paradigms. Perhaps it is even hard to effectively translate from Chinese to English. But the actual variance within a given language is still greater than the variance between the languages. And like human languages, the vocabulary is often arbitrary. In human languages a dog is called a dog not because it makes the sound "dog" and not because it looks like the letters 'd', 'o', and 'g' but for entirely arbitrary reasons of phonetic shift and arbitrary initial designation. And in lisp you take the 'car' of a tuple and in Haskell you take the 'head' of a list. But the two concepts are very much the same. However, the distinction between continuation passing style (CPS) concurrency and the actor model can be expressed in either langauge just as well. And the distinction between CPS and the actors is FAR grater than the distinction between calling the basic function "head" or "car".
- catnaroek 9y ago
  In Haskell you don't ever take the `head` of a list, because `head` is an evil non-total function. Instead you pattern-match the list: in one branch, the head is given to you for free; in the other branch, there's no head at all.
Myrmornis 9y ago
I was going to say something which I think may be similar to what you’re saying. Software and business systems are diagrammed with totally ad-hoc “flow charts”, bubble and arrow diagrams, and less ad-hoc sequence diagrams and UML diagrams. We need advances in formal ways to model concurrent processes, from the level of threads to concurrent business processes.
- aryehof 9y ago
  In a sense yes, although I suggest that a "business process" is too broad and difficult an abstraction. Better for most [1] systems in industry and commerce to elicit and model sequences of recorded events [2] involving interactions with things, people and places in different contexts, with support for constraints [3]. Modeling the above in a business sense, with support in existing paradigms and languages is already a solved problem, just a little known one. --- [1] The other type of system in industry and commerce being the continuous system that isn't based on recorded events, but instead on logging errors and abnormal circumstances, e.g. an elevator control system or an automated warehouse delivery system, or the engine monitoring software in your car. [2] Recorded for business or legal reasons. [3] It's those constraints that prevent an elevator from moving with its doors open, or billing for that product not shipped, or allowing someone to vote twice.
  - Myrmornis 9y ago
    I’m not sure I understand everything you said there. Software engineers are often tasked with designing and implementing “business processes”, just as they are tasked with implementing correct logic in a concurrent threaded program, or system of microservices. Don’t you feel that when they step up to the whiteboard and draw yet another completely ad-hoc diagram, for any of the above problems, with no agreed rules of composition or semantics, that these people, who often have degrees in computer science and mathematics, are basically communicating using cave paintings?
    - aryehof 9y ago
      There are some that can walk up to a white-board and (repeatedly and predictably) create a domain object model representing complex business requirements. One directly convertible to code. They can do this because they know a set of higher order patterns, beyond just a knowledge of "objects" and "classes". Beyond just a design approach of identifying classes as the "nouns" in a problem domain. These higher order patterns represent those business processes, as you call them. Sadly such a skill is very rarely seen, or even in demand, given that data modeling is the basis for most design today.
lmm 9y ago
I don't think we've reached the limits of what can be done with better programming languages, just because there's already such a range in terms of what today's languages do - I really do think there are languages in use today that are multiple orders of magnitude better at general computing than other languages that are in use today (as at least nominally general-purpose languages).

ShallowLearning 9y ago

Much of the time, new languages lead to new design paradigms. As a general rule, newer languages are more abstracted than older ones. When people don't need to get hung up on the intricacies of low level programming, real progress can be made on the design paradigm front.

aryehof 9y ago
I'm curious which languages have resulted in which new design paradigms?
- miguelrochefort 9y ago
  Elm -> Elm Architecture
- arianvanp 9y ago
  Two good examples: Erlang led to Microservices and the Reactive Manifesto. the Open Telecom Platform is still a very modern Microservice library (in my opinion) after more than three! decades ML led to programming against generic interfaces (http://www.cs.cornell.edu/courses/cs312/2006fa/recitations/rec08.html http://www.cs.cornell.edu/courses/cs312/2006fa/recitations/r...)
  - deleted 9y ago
    [deleted]
asavinov 9y ago
I would say that it is a two-directional dependency: language constructs <--> design patterns Programmers experiment with and accumulates various design patterns using existing languages. Then the most useful of them are implemented (frozen) as programming constructs. Then programmers experiment with these new programming constructs and come up with new design patterns. And so on. In fact, these design patterns and language constructs come in (anti-phase) waves.

asavinov 9y ago

> A focus on programming languages in my opinion, masks the real issues we face. Indeed, major problems of programming languages can hardly be solved in the area of programming languages itself as it is being done now. I would say that one needs a new programming or computing model so it is not about languages. At least it is my conclusion after 10+ years of research and attempts to develop such a new programming paradigm. And although I have quite significant progress (concept-oriented programming), the more I do and the deeper I go, the more fundamental problems I meet. And these problems are not about programming languages at all. It is more about "how a system works", "what is a system", "what is computing" etc.

pdimitar 9y ago
Doing such a huge research has to have phases of some sort. At certain point you should stop, re-evaluate, and say "okay, where I am at now is good enough to solve problems X and Y, most of the time". Otherwise it's endless and one loses motivation.

timthelion 9y ago

I agree, and from a different perspective, I would compare this to literature. In English literature we have many different paradigms: Victorian literature, Modernism, Post modernism, Post colonial ect. The language has to be expressive, and in being expressive, it can express any of these different paradigms. The fact that the vocabulary is shared between the "eras" of literature is only a bonus which makes authors more flexible and more able to experiment with actually new concepts, rather than simply reinventing the same old vocabulary. We then have Chinese literature and Indian literature, and these have very different paradigms. Perhaps it is even hard to effectively translate from Chinese to English. But the actual variance within a given language is still greater than the variance between the languages. And like human languages, the vocabulary is often arbitrary. In human languages a dog is called a dog not because it makes the sound "dog" and not because it looks like the letters 'd', 'o', and 'g' but for entirely arbitrary reasons of phonetic shift and arbitrary initial designation. And in lisp you take the 'car' of a tuple and in Haskell you take the 'head' of a list. But the two concepts are very much the same. However, the distinction between continuation passing style (CPS) concurrency and the actor model can be expressed in either langauge just as well. And the distinction between CPS and the actors is FAR grater than the distinction between calling the basic function "head" or "car".

catnaroek 9y ago
In Haskell you don't ever take the `head` of a list, because `head` is an evil non-total function. Instead you pattern-match the list: in one branch, the head is given to you for free; in the other branch, there's no head at all.

Myrmornis 9y ago

I was going to say something which I think may be similar to what you’re saying. Software and business systems are diagrammed with totally ad-hoc “flow charts”, bubble and arrow diagrams, and less ad-hoc sequence diagrams and UML diagrams. We need advances in formal ways to model concurrent processes, from the level of threads to concurrent business processes.

aryehof 9y ago
In a sense yes, although I suggest that a "business process" is too broad and difficult an abstraction. Better for most [1] systems in industry and commerce to elicit and model sequences of recorded events [2] involving interactions with things, people and places in different contexts, with support for constraints [3]. Modeling the above in a business sense, with support in existing paradigms and languages is already a solved problem, just a little known one. --- [1] The other type of system in industry and commerce being the continuous system that isn't based on recorded events, but instead on logging errors and abnormal circumstances, e.g. an elevator control system or an automated warehouse delivery system, or the engine monitoring software in your car. [2] Recorded for business or legal reasons. [3] It's those constraints that prevent an elevator from moving with its doors open, or billing for that product not shipped, or allowing someone to vote twice.
- Myrmornis 9y ago
  I’m not sure I understand everything you said there. Software engineers are often tasked with designing and implementing “business processes”, just as they are tasked with implementing correct logic in a concurrent threaded program, or system of microservices. Don’t you feel that when they step up to the whiteboard and draw yet another completely ad-hoc diagram, for any of the above problems, with no agreed rules of composition or semantics, that these people, who often have degrees in computer science and mathematics, are basically communicating using cave paintings?
  - aryehof 9y ago
    There are some that can walk up to a white-board and (repeatedly and predictably) create a domain object model representing complex business requirements. One directly convertible to code. They can do this because they know a set of higher order patterns, beyond just a knowledge of "objects" and "classes". Beyond just a design approach of identifying classes as the "nouns" in a problem domain. These higher order patterns represent those business processes, as you call them. Sadly such a skill is very rarely seen, or even in demand, given that data modeling is the basis for most design today.

lmm 9y ago

I don't think we've reached the limits of what can be done with better programming languages, just because there's already such a range in terms of what today's languages do - I really do think there are languages in use today that are multiple orders of magnitude better at general computing than other languages that are in use today (as at least nominally general-purpose languages).