Sunset programming? - page 7

 
Andrey Pogoreltsev:

What are you arguing with me now? That the programmer has gradually become a developer, with an increase in the number of tools and task requirements?

I did not deny that.

I merely asked a few questions which logically follow from your theses.

 
Dmitry Fedoseev:

I was just asking a few questions that follow logically from your theses.

Well, yes, every industry develops and goes its own way. Including software development. Here's a good definition from the wiki, by the way:

Software development is the process of conceiving, specifying, designing,programming,documenting,testing, andbug fixing involved in creating and maintainingapplications,frameworks, or other software components.

 
Andrey Pogoreltsev:
He replies to you to troll, not to understand something, do not waste your time - Peter and Fedoseyev are two of the brightest representatives of mql sandbox, who do not want to get out of it.
 
Andrey Pogoreltsev:

It has been in use for about 30 years. You describe a highly specialised task and extrapolate it to the entire class of development tasks. Visual development has been around for a long time, both partially and fully automated. This in no way negates the necessity of developing other classes of tasks or even tasks solved by visual environments, to which greater performance requirements are applied, for example. Because any universalism sooner or later turns into a monster.

Suppose you're right. Let's look at examples of tasks which cannot:

1. decompose into objects.

2. represent objects as assemblies of parameters and relations.

3. Assemble the objects with visual tools.

If it is not difficult, give examples of such tasks.

 
TheXpert:
He replies to you to troll, not to understand something, do not waste your time - Peter and Fedoseyev are two of the brightest representatives of mql sandbox, who do not want to get out of it.

Whenever a question comes up that you can't answer and makes you realise your points are untenable, it's trolling. It's funny.

 
Andrey Pogoreltsev:

Well, yes, every industry develops and goes its own way. Including software development. Here's a good definition from the wiki, by the way:

Software development is the process of conceiving, specifying, designing,programming,documenting,testing, andbug fixing involved in creating and maintainingapplications,frameworks, or other software components.

In other words, programmers (or developers) did not write documentation, did not test, and did not fix bugs. And now they are involved in design?

 
Реter Konow:

Let's say you are right. Let's look at examples of tasks that cannot:

1. decompose into objects.

2. represent objects as assemblies of parameters and relations.

3. Assemble the objects with visual tools.

If you don't mind, please give some examples of such tasks.

No, Peter. The future belongs to biological programming. This is approximately as follows: a man is shaved bald, a special active biomass is placed on his head, and he begins to think intensively about the task in hand. As a result, in the biomass deposited on the head, neuronal connections are built, a kind of artificial ganglia is formed, corresponding to the thoughts being thought... This is how biocomputer units for cyborgs will be created. ))) Well, you know what I mean.

 
Andrey Pogoreltsev:

1. Visual development has been around for a long time, both partially and fully automated.

2. this in no way negates the need to develop other classes of tasks or even tasks solved by visual environments to which greater performance requirements are applied, for example.

3. Because any universalism sooner or later turns into a monster.

1. If you can - give me a link to read about such.

2. Can you break down the problems by class and specifically indicate which solutions are not amenable to visual tools?

3. It's not all straightforward here. A huge computer from the 50's fit into a mobile phone, which suggests that universalism works fine and is not rigidly tied to performance. At any rate, performance solves the problem of monster universalism.

 
Реter Konow:

Let's say you are right. Let's look at examples of tasks that cannot:

1. decompose into objects.

2. represent objects as assemblies of parameters and relations.

3. Assemble the objects with visual tools.

If it is not difficult, please give examples of such tasks.

Calculating Fibonacci numbers, creating certain UI reactions to user actions outside a predefined set, writing documentation, writing unit tests.

These are very simple tasks, but there are huge systems, e.g. image rendering and so on.

There are a lot of them, in general.

 
And why is some "visual" programming in the form of cubes and arrows better than, well, excuse me, visual programming as well, but in the form of words displayed on the screen? By the way, readability is much higher, because it is clear in what order and what to read after. And a visual diagram - a hundred squares and lines, sticking out in different directions, and which end to view it from?