Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #2727 > unrolled thread

What is wrong in an even higher level programming?

Back to article view | Back to comp.programming

Contents

  What is wrong in an even higher level programming? rahul.online.9@gmail.com - 2013-01-03 16:26 -0800
    Re: What is wrong in an even higher level programming? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2013-01-04 06:22 +0100
      Re: What is wrong in an even higher level programming? x <x@x.x> - 2013-01-04 08:53 +0100
      Re: What is wrong in an even higher level programming? rahul.online.9@gmail.com - 2013-01-04 02:57 -0800
        Re: What is wrong in an even higher level programming? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2013-01-04 18:13 +0100
      Re: What is wrong in an even higher level programming? "BartC" <bc@freeuk.com> - 2013-01-04 12:04 +0000
    Re: What is wrong in an even higher level programming? rahul.online.9@gmail.com - 2013-01-04 02:15 -0800
    Re: What is wrong in an even higher level programming? Willem <willem@turtle.stack.nl> - 2013-01-04 17:36 +0000
    Re: What is wrong in an even higher level programming? rahul.online.9@gmail.com - 2013-01-06 11:24 -0800

#2727 — What is wrong in an even higher level programming?

We started off with 0,1... machine languages ... c .... c++ .... php ....

Why dint we proceed? - A very high level language

A programming language that can be written with pictures and connections, much like how our mind visualizes a program

By "very high level language", I will explain with the following scenario :

If a programmer wants to create a website.

He drags a box "web-site". (If he wanted a console app, he would have dragged console)

He needs a form.

He drags an places a form. (A form with a text field, submit and reset.  And he can drag and drop other elements or delete "reset" etc)

He needs a payment gateway attached to form.  

So there are 2 boxes now - 1 is form and 2 is payment gateway.

Now he connects them (Like we do in electronic simulation softwares)

He drags and places the payment gateway near the form. He connect it with a line. The compiler figure out what all data in the form (name, cc no, cvv, exp) is needed by the payment gateway and populates it. For things, the compiler could not figure out, it suggest the user to add links manually. (It figures out what to do with the data because of polymorphism - it figures out what the programmer wants) (And all the other parameters for payment gateway like paypal/google wallet, usd/euro/inr, etc etc is asked from the user)

Sincle most web-apps will need forms, payment gateways, ssl support, logs, analytics etc etc. Why cant all these be modules. 

In short, what we picturize in our mind, as to how our apps should behave (what we draw as application architecture) should be used to create the program - and NOT write thousands of lines of code.

In case we need to detail/customize any block, we can do it manually. (like we do now)

Why has this kind of system not developed yet?
Is it because this requires a lot of work?
Or is there something very wrong with this kind of system?

[toc] | [next] | [standalone]

#2728

On Thu, 3 Jan 2013 16:26:37 -0800 (PST), rahul.online.9@gmail.com wrote:

> We started off with 0,1... machine languages ... c .... c++ .... php ....

It is language generations actually: 1GL, 2GL ... 5GL. The last one is
mostly mythical than real.

See:

http://en.wikipedia.org/wiki/Fourth-generation_programming_language
http://en.wikipedia.org/wiki/5GL

> Why dint we proceed? - A very high level language

Many reasons. The simplest one: if that were possible one would need no
programmers, and so, no programming languages.

> A programming language that can be written with pictures and connections,
> much like how our mind visualizes a program
> 
> By "very high level language", I will explain with the following scenario :
> 
> If a programmer wants to create a website.
[...] 

A domain-specific [Web design as the domain] 4GL graphical language
described.

> Why has this kind of system not developed yet?
> Is it because this requires a lot of work?
> Or is there something very wrong with this kind of system?

Because it was understood that the nGL axis led to nowhere.

1. The level of abstraction is not exactly about closeness to the
application domain. In reality, 4GLs are very low level from the point of
view of abstractions like value <- type (sets of values) <- class (set of
types). 4GL aren't well with types. Classes, which are essential for OO and
generic programming are totally alien there. There are many axes of
abstraction.

2. An ability to express domain specifics is not for free. It reduces
language power and versatility. Some 4GL languages are not even Turing
complete.

3. There is a general issue with declarative vs. imperative approaches to
programming that the former is not exactly programming which expectedly
leads to problems. nGL have a strong tendency of being more and more
declarative.

4. Domain specific language are not scalable which makes them unsuitable
for designing large, heterogenous, distributed systems = modern systems.
The key property of a good programming language is how it supports software
decomposition (e.g. procedural, OO, functional decomposition). nGL and
graphic languages are extremely poor here.

5. They don't fit into software developing cycle. This is especially
characteristic for graphical languages. The issues are: non-testability,
lack of separation of specifications and implementations. As a consequence
lack of formal methods for verification and validation. How would you
formally define icons, their connections, pulling/dropping icons? Mere
comparing diagrams is a problem for both computer and human reader. Here go
the problems with source code management and version control (merging
pictures, good grief).

6. Schism. Instead of learning one universal language you have to learn N+
languages for whatever domain applies + N*N toolkits to integrate these
into one system. The idea that engineers/brokers/dishwashers/whoever would
replace professional programmers sells well to managers but fails
challenges of real life.

7. Ergonomics. Graphics overloads cognition. Image processing requires much
brain resources. It works well on small scale e.g. traffic lights, but
fails completely on large scale: making comics from Shakespeare.

But as any deeply wrong idea, this one is alive and well.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#2729

W dniu 2013-01-04 06:22, Dmitry A. Kazakov pisze:
> On Thu, 3 Jan 2013 16:26:37 -0800 (PST), rahul.online.9@gmail.com wrote:
>
>> We started off with 0,1... machine languages ... c .... c++ .... php ....
>
> It is language generations actually: 1GL, 2GL ... 5GL. The last one is
> mostly mythical than real.
>
> See:
>
> http://en.wikipedia.org/wiki/Fourth-generation_programming_language
> http://en.wikipedia.org/wiki/5GL
>
>> Why dint we proceed? - A very high level language
>
> Many reasons. The simplest one: if that were possible one would need no
> programmers, and so, no programming languages.
>
>> A programming language that can be written with pictures and connections,
>> much like how our mind visualizes a program
>>
>> By "very high level language", I will explain with the following scenario :
>>
>> If a programmer wants to create a website.
> [...]
>
> A domain-specific [Web design as the domain] 4GL graphical language
> described.
>
>> Why has this kind of system not developed yet?
>> Is it because this requires a lot of work?
>> Or is there something very wrong with this kind of system?
>
> Because it was understood that the nGL axis led to nowhere.
>
> 1. The level of abstraction is not exactly about closeness to the
> application domain. In reality, 4GLs are very low level from the point of
> view of abstractions like value <- type (sets of values) <- class (set of
> types). 4GL aren't well with types. Classes, which are essential for OO and
> generic programming are totally alien there. There are many axes of
> abstraction.
>
> 2. An ability to express domain specifics is not for free. It reduces
> language power and versatility. Some 4GL languages are not even Turing
> complete.
>
> 3. There is a general issue with declarative vs. imperative approaches to
> programming that the former is not exactly programming which expectedly
> leads to problems. nGL have a strong tendency of being more and more
> declarative.
>
> 4. Domain specific language are not scalable which makes them unsuitable
> for designing large, heterogenous, distributed systems = modern systems.
> The key property of a good programming language is how it supports software
> decomposition (e.g. procedural, OO, functional decomposition). nGL and
> graphic languages are extremely poor here.
>
> 5. They don't fit into software developing cycle. This is especially
> characteristic for graphical languages. The issues are: non-testability,
> lack of separation of specifications and implementations. As a consequence
> lack of formal methods for verification and validation. How would you
> formally define icons, their connections, pulling/dropping icons? Mere
> comparing diagrams is a problem for both computer and human reader. Here go
> the problems with source code management and version control (merging
> pictures, good grief).
>
> 6. Schism. Instead of learning one universal language you have to learn N+
> languages for whatever domain applies + N*N toolkits to integrate these
> into one system. The idea that engineers/brokers/dishwashers/whoever would
> replace professional programmers sells well to managers but fails
> challenges of real life.
>
> 7. Ergonomics. Graphics overloads cognition. Image processing requires much
> brain resources. It works well on small scale e.g. traffic lights, but
> fails completely on large scale: making comics from Shakespeare.

Dmitry, congratulations. You have perfectly worded my thoughts and 
experiences with graphical languages. (I have used two, EAI/ESB domain)

-- 
Marcin Jaskolski

[toc] | [prev] | [next] | [standalone]

#2732

Dear Dmitry and Team,

Request some more clarification please, so that I can understand better.


> It is language generations actually: 1GL, 2GL ... 5GL. The last one is
Thanks :-) I did not know about these.

> Many reasons. The simplest one: if that were possible one would need no
> programmers, and so, no programming languages.
Agreed.  Is that not an advantage?  Suppose 100 years later every single human being can create their own programs by simply drawing what they have in their mind on to the computer and get the entire work flow complete without the need of coding.  He/she is still a programmer who does not know C++ etc.
=>(In 2100) Future Language : C++ :: (In 2012)C ++ : Machine code

> A domain-specific [Web design as the domain] 4GL graphical language
> described.
I mean one single graphical language - not just for web.
I will explain :
User 1 : Create a Windows Service.
Code : 
Opens the IDE. 
Box1 : Blank Screen
Box1.1 : He drags "Console" (just like we include. (Box 2 is inside box1)
Box1.1.1 : Then he drags "windows service" inside that  (box3 is inside box2 ....)
Box1.1.1.1 : He needs the service to poll the printer spool every 10 seconds.  So, he drags the "spool".  
Box1.1.1.2 : Since he needs to "poll", he drags the "poll" box and keeps it near spool.  So now, the computer needs to know that printer spool should be polled.
Connection1.1.1.3 : He connect the "poll" box and "spool" box.  Computer understands the programmer want the "spool" to "poll".  It understands this because this is one of the common behaviors that have been done by programmers in the past (the compiler uses its rich real time db of past action by programmers all around the world in determining what this particular programmer is trying to do)
so on .....

Now, if the same this was a linux deamon, he would have first dragged console, then linux, then daemon and rest of the flow will be the same as above.

So, he does not have to look up the internet to know how to create a service/daemon.  He gets his work done "easily".

Now in case he needs a lot more, he can flip the ide (so the graphics flip to back) and the underlying C++ code comes up.  Now, he can code the remaining.

> Because it was understood that the nGL axis led to nowhere.
ok.  I  wont argue, because you are far more experienced. 

> 1. The level of abstraction is not exactly about closeness to the
> application domain. In reality, 4GLs are very low level from the point of
> view of abstractions like value <- type (sets of values) <- class (set of
> types). 4GL aren't well with types. Classes, which are essential for OO and
> generic programming are totally alien there. There are many axes of
> abstraction.
The classes in C++/Java would be translate as "box" that a user can define himself by using existing "boxes" or writing code, like we do now.

> 2. An ability to express domain specifics is not for free. It reduces
> language power and versatility. Some 4GL languages are not even Turing
> complete.
As I said, not just for one domain.  I meant for the entire ecosystem right from machine level coding, console programs, services, web services, api libraries, web development, enterprise applications .....

> 3. There is a general issue with declarative vs. imperative approaches to
> programming that the former is not exactly programming which expectedly
> leads to problems. nGL have a strong tendency of being more and more
> declarative.
Agreed.

> 4. Domain specific language are not scalable which makes them unsuitable
> for designing large, heterogenous, distributed systems = modern systems.
> The key property of a good programming language is how it supports software
> decomposition (e.g. procedural, OO, functional decomposition). nGL and
> graphic languages are extremely poor here.
Agree that the level of freedom we get by using existin OOP languages are hard to get in a graphical language.  But I feel if some body (google/linux team/apache or some one) develops such a graphical language which actually translates the boxes and connections to classes and its methods, the freedom we have now, will remain then also.

> 5. They don't fit into software developing cycle. This is especially
> characteristic for graphical languages. The issues are: non-testability,
> lack of separation of specifications and implementations. As a consequence
> lack of formal methods for verification and validation. How would you
> formally define icons, their connections, pulling/dropping icons? Mere
> comparing diagrams is a problem for both computer and human reader. Here go
> the problems with source code management and version control (merging
> pictures, good grief).
Assume that in test phase we have an executable program, we give it a set of inputs and expected outputs.  And then "switch on" the "test it" button in the IDE.  It will push all the inputs and check if the outputs are as expected, else it returns failure.  I dont think testing will be affected.  Just like we create test cases now in Java by calling its own test classes, we can have test "boxes" using which we can create the test cases

> 6. Schism. Instead of learning one universal language you have to learn N+
> languages for whatever domain applies + N*N toolkits to integrate these
> into one system. The idea that engineers/brokers/dishwashers/whoever would
> replace professional programmers sells well to managers but fails
> challenges of real life.
It is just an extra tool which common people can use.  Programmers can still use C++ etc.  But simple things like - "Find all the friends whose phone numbers have been updated in facebook and google plus in last 3 months" can be done by the ordinary human being using these graphical languages instead of studying C++/Java for that.  


> 7. Ergonomics. Graphics overloads cognition. Image processing requires much
> brain resources. It works well on small scale e.g. traffic lights, but
> fails completely on large scale: making comics from Shakespeare.
Agreed.  But if some how we can create a system where we start with a main box, like in C++/Java and then drill down to the various branches of the box, and even deeper into the nested boxes, we might be able to understand how the program functions even better.
When we look at enterprise code, we make a mental picture of how the data flows, the same flow, instead of keeping it in the mind, we will pass it to the computer.  I think this will actually ease another programmer to understand how the data flows rather than lookup the 1000s of lines of code.

I dont know if I was able to pass what is there in my mind fully, please do ask in case something did not make sense to you.

Additional thought trains : 
Initially google did not giive any auto complete so we had to type in the whole query, now we have to type a few letters and it figures out what we want to find.  I use this analogy.  When a programmer creates a few boxes, after a limit, the compiler know what this guy is trying to do and gives suggestions.

Emphasizing again that, we just draw(our mind knows to visualize) our thoughts onto the source code window instead of writing a language our mind does not know (c++,java).  

Then the compiler will help us along the way suggesting what we might need, and finally we connect all the boxes.   Now, I can flip the source code window to see the underlying C++/Java/xyz code that the compiler has generated (like the bytecode in Java in 2012) and since it is in C++/Java, we can edit it to fine tune.  

Whole point is, the entire software design and coding is done through figures and graphics and what ever the compiler could not understand, we will code it.  

Request a response, if you find my views to have issues, wish to know it.

Thank you once again for your previous post.

[toc] | [prev] | [next] | [standalone]

#2734

On Fri, 4 Jan 2013 02:57:37 -0800 (PST), rahul.online.9@gmail.com wrote:

> Suppose 100 years later every single
> human being can create their own programs by simply drawing what they have
> in their mind on to the computer and get the entire work flow complete
> without the need of coding.

I don't know what your definition of coding is. The purpose of any language
is to communicate one's mind.

> He/she is still a programmer who does not now C++ etc.

Is it merely replacing the language X with the language Y?

>> A domain-specific [Web design as the domain] 4GL graphical language
>> described.
> I mean one single graphical language - not just for web.
[..]
> He gets his work done "easily".

OK, my favorite example in such cases is matrix inversion. Go figure.

[ Once ready, we would sightly complicate this trivial task for your
"Wunderwaffe," the matrix will become sparse, computations distributed. ]

> Now in case he needs a lot more, he can flip the ide (so the graphics flip
> to back) and the underlying C++ code comes up.  Now, he can code the
> remaining.

Replace a few characters of the C++ code and flip back.

[ Code generators rarely can sustain iterative processes. ]

>> 1. The level of abstraction is not exactly about closeness to the
>> application domain. In reality, 4GLs are very low level from the point of
>> view of abstractions like value <- type (sets of values) <- class (set of
>> types). 4GL aren't well with types. Classes, which are essential for OO and
>> generic programming are totally alien there. There are many axes of
>> abstraction.
> The classes in C++/Java would be translate as "box" that a user can define
> himself by using existing "boxes" or writing code, like we do now.

This is another thing. Box represents a class, e.g. in UML

http://en.wikipedia.org/wiki/Unified_Modeling_Language

The point is different, that the language like UML *itself* lacks classes.
UML is not what it is supposed to model. Its properties are not the
properties of the code generated. Compare: C++ is not x86 code it spits
out.

Value in UML could be a block. Type could be a set of blocks sharing some
common properties, e.g. geometric properties: ellipse. Class would be a set
of sets of blocks, e.g. using the geometric analogy conic sections.

>> 2. An ability to express domain specifics is not for free. It reduces
>> language power and versatility. Some 4GL languages are not even Turing
>> complete.
> As I said, not just for one domain.  I meant for the entire ecosystem
> right from machine level coding, console programs, services, web services,
> api libraries, web development, enterprise applications .....

and?

> But I feel if some body (google/linux team/apache or some one) develops
> such a graphical language which actually translates the boxes and
> connections to classes and its methods, the freedom we have now, will
> remain then also.

To put things straight: language does not translate anything. It describes
something. Translates a compiler also called translator. Before you start
writing a translator, you should define the semantics of the language you
are proposing. That is, you define the meaning of the boxes, their
placement, colors whatever.

[ Won't comment anything on innovative forces behind Google and Linux ]

>> 5. They don't fit into software developing cycle. This is especially
>> characteristic for graphical languages. The issues are: non-testability,
>> lack of separation of specifications and implementations. As a consequence
>> lack of formal methods for verification and validation. How would you
>> formally define icons, their connections, pulling/dropping icons? Mere
>> comparing diagrams is a problem for both computer and human reader. Here go
>> the problems with source code management and version control (merging
>> pictures, good grief).
> Assume that in test phase we have an executable program, we give it a set
> of inputs and expected outputs.  And then "switch on" the "test it" button
> in the IDE.  It will push all the inputs and check if the outputs are as
> expected, else it returns failure.

How do you know which outputs correspond to which inputs? [The keyword is
"specification"]

> I dont think testing will be affected. 
> Just like we create test cases now in Java by calling its own test
> classes, we can have test "boxes" using which we can create the test cases

Yep, a use case: heat the core to 500 Celsius, make sure the reactor did
not explode.

>> 6. Schism. Instead of learning one universal language you have to learn N+
>> languages for whatever domain applies + N*N toolkits to integrate these
>> into one system. The idea that engineers/brokers/dishwashers/whoever would
>> replace professional programmers sells well to managers but fails
>> challenges of real life.
> It is just an extra tool which common people can use.

Like growing an extra leg? Must be handy. First step is to show that the
tool does what expected: sufficient for typical programming tasks:

http://en.wikipedia.org/wiki/Software_development_process

The second step is to show that common people (how common, by the way?) can
use it.

>> 7. Ergonomics. Graphics overloads cognition. Image processing requires much
>> brain resources. It works well on small scale e.g. traffic lights, but
>> fails completely on large scale: making comics from Shakespeare.
> Agreed.  But if some how we can create a system where we start with a main
> box, like in C++/Java and then drill down to the various branches of the
> box, and even deeper into the nested boxes, we might be able to understand
> how the program functions even better.

Such language has been existed for decades. E.g. LabView.

http://en.wikipedia.org/wiki/Labview

It is a maintenance disaster for anything serious to program. Problems
start with trivial tasks like browsing/navigation the sources.

> I think this will actually ease another programmer to
> understand how the data flows rather than lookup the 1000s of lines of
> code.

How is 1000 nested blocks better?

> Additional thought trains : 
> Initially google did not giive any auto complete so we had to type in the
> whole query, now we have to type a few letters and it figures out what we
> want to find.  I use this analogy.  When a programmer creates a few boxes,
> after a limit, the compiler know what this guy is trying to do and gives
> suggestions.

Huh, Genesis 1:3 describes even more advanced approach:

   "And God said, Let there be light: and there was light."

That is the language we all need! Basically just one construct: DoIt.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#2733

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:19by5qwqu52oa$.1hd0l7sy864bq.dlg@40tude.net...
> On Thu, 3 Jan 2013 16:26:37 -0800 (PST), rahul.online.9@gmail.com wrote:

>> Why dint we proceed? - A very high level language
>
> Many reasons. The simplest one: if that were possible one would need no
> programmers, and so, no programming languages.

Somebody has to be specify something in the first place. Who ever does that 
becomes the 'programmer'.

Unless perhaps 'programs' can spontaneously come into existence of their own 
accord...

-- 
bartc 

[toc] | [prev] | [next] | [standalone]

#2731

Wow.

Really appreciate the answer.  And also thank you for the time and effort.

[toc] | [prev] | [next] | [standalone]

#2735

rahul.online.9@gmail.com wrote:
) We started off with 0,1... machine languages ... c .... c++ .... php ....
)
) Why dint we proceed? - A very high level language
)
) A programming language that can be written with pictures and connections, much like how our mind visualizes a program
)
) By "very high level language", I will explain with the following scenario :
)
) If a programmer wants to create a website.
)
) He drags a box "web-site". (If he wanted a console app, he would have dragged console)
)
) He needs a form.
)
) He drags an places a form. (A form with a text field, submit and reset.  And he can drag and drop other elements or delete "reset" etc)
)
) He needs a payment gateway attached to form.  
)
) So there are 2 boxes now - 1 is form and 2 is payment gateway.

<snip> (We get the drift.)

One implementation of this is Uniface.  Been around for 20 years or so I
think.  It's actually quite good for rapid development, web-based and
otherwise.  It's just a bitch to do anything that doesn't fit in the mold.

There are dozens of other languages like that.

) Why has this kind of system not developed yet?

It has been, look above.  It's just that it has little makret share.

) Is it because this requires a lot of work?
) Or is there something very wrong with this kind of system?

SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#2741

@All.  Thank you for the responses.  I need to go through and understand each of your response.  It will take me more than a few days to understand it well.  Will respond when I feel I can add anything to this conversation.

Thanks to all for pointing me to knowledge, I did not know existed for long.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web