프로그래밍의 일몰? - 페이지 2

 
Vladimir Mametov :

특정 제한 사항이 있는 최대 생성자를 얻습니다.

지금까지는 어떤 제한도 보이지 않습니다. 아마도있을 것입니다 ...
 
Реter Konow :

그건 그렇고, 내가 만들려는 Visual Studio는 다음 원칙에 따라 구축되었습니다.

컨트롤의 한 부분은 스튜디오에 속하고 다른 부분은 사용자 프로젝트에 속합니다.

Studio 요소는 해당 매개변수를 프로젝트의 편집 가능한 요소 속성에 연결하고 해당 값을 변경합니다. 게다가 핸들러는 그것들을 다시 그리고 짜잔!

Visual Studio에서 편집하는 원리는 매우 간단합니다. 컨트롤의 매개변수와 편집 가능한 요소의 일반적인 연결.

스튜디오와 사용자 프로젝트 모두 공통 코어에 있으므로 이 연결은 동일한 배열(제어 요소)의 다른 셀에 등록된 배열 셀(커널)에 대한 포인터일 뿐입니다.

본질은 아주 간단하고 누군가가 필요했다면 오래전에 스튜디오를 만들었을 것입니다.))

프로그래밍 프로세스를 용이하게 하는 작은 링크만 얻을 수 있습니다. 복잡한 작업의 경우 패턴 및 관계의 거대한 데이터베이스가 필요합니다.

사람은 이것을 할 수 없습니다.

특정 작업에 대해 수행할 수 있습니다. 소비자를 찾아야 합니다.

 
Denis Sartakov :

다른 언어와 다른 언어가 있습니다

얼랑

보았다. 아직 확답을 드릴 수는 없지만 컨셉이 다른 것 같아요.

결론은 코드 자체가 곧 유물이 될 수 있다는 것입니다. 음성 명령으로 프로그래밍할 수 있습니다.

예를 들어(목소리로 말하기):

새 개체

상표

템플릿 만들기

옵션:

X, Y, W, H, 색상

템플릿 저장

3개의 인스턴스 생성

이름 인스턴스 1 - "기본"

인스턴스 1 수정

매개변수 간의 링크 설정

X1과 X2 사이의 값을 필터링합니다.

낮은 필터 값 - 10

상위 필터 값 - 100

값 수정기를 설정합니다(값이 범위보다 낮거나 위에 있는 경우 범위에 맞게 조정하고 매개변수에 전달).


등등...

 
Uladzimir Izerski :

프로그래밍 프로세스를 용이하게 하는 작은 링크만 얻을 수 있습니다. 복잡한 작업에는 패턴과 관계의 거대한 데이터베이스가 필요합니다.

사람은 이것을 할 수 없습니다.

특정 작업에 대해 수행할 수 있습니다. 소비자를 찾아야 합니다.

예, 하지만 아름다움은 스튜디오와 음성을 사용하여 이러한 템플릿을 얼마나 빨리 만들 수 있는지에 있습니다. 그리고 모두 코드 없이. 이것은 혁명이 될 것입니다.
 
그건 그렇고, 이러한 객체를 저장하는 방법은 최대 압축이 특징입니다. 이것들은 매개변수의 사슬과 그 연결일 뿐 그 이상은 아닙니다. 일단 저장되면 템플릿을 상속, 인스턴스화, 수정하고 새 템플릿과 새 수정 사항으로 저장할 수 있습니다. 개체의 전체 진화가 얻어집니다 ...
 
Реter Konow :
예, 하지만 아름다움은 스튜디오와 음성을 사용하여 이러한 템플릿을 얼마나 빨리 만들 수 있는지에 있습니다. 그리고 모두 코드 없이. 이것은 혁명이 될 것입니다.
https://ide.hiasm.com/

 
Aliaksandr Hryshyn :
https://ide.hiasm.com/

개선해야 할 점은 분명하지만 멋진 일입니다.

"Logic" 섹션을 보고 조건 아이콘을 보았습니다. 스튜디오에서 코드를 빌드하려고 합니다. 나는 다른 접근 방식을 가지고 있습니다. 코드가 전혀 없을 것입니다. 개체 링크만. 그리고 내 보기에 있는 개체는 매개변수, 선택, 형식, 다른 매개변수와의 연결, 값 처리기(필터, 변환기, 수정자), 수집기, 이벤트, 상태 등입니다. 이 모든 것에서 모든 개체를 수집하고 개체를 확인할 수 있습니다. 실시간 컴파일 없이 작동합니다.

 
이 전체 블록 어셈블리는 꽤 오랫동안 사용되어 왔습니다. 그러나 대규모 프로젝트 를 생성할 때는 프로젝트의 일부 개별 부분에만 적합합니다. 글쎄, 그건 그렇고, 비록 이러한 템플릿을 사용하는 사람 자신은 코드를 작성하지 않지만 기본적으로 여전히 적용되고 어떻게든 작성되었습니다.
글쎄, 그런 프로그래밍이 죽는다면. 그 프로세스는 누구도 새롭고 더 최적화된 솔루션을 작성할 수 없는 곳에서 멈춥니다. 그것은 모두 쌍둥이 프로그램으로 귀결됩니다. 여기에 숨겨진 버그가 있는 경우 이 템플릿에 의해 코드가 적용될 모든 항목에 자동으로 복제됩니다.
그래서 그들이 실제 AI를 만들 때까지, 오늘날 AI로 전달되는 패러디가 아닙니다. 프로그래밍의 소멸에 대해 이야기하기에는 너무 이르다.
 

그건 그렇고, 누군가가 이벤트 개체 또는 상태 개체가 어떻게 생겼는지 그리고 매개변수에서 생성된 구성에 연결하는 방법을 모르는 경우:

이벤트 또는 상태는 매개변수 및 해당 사전 설정 값의 모음입니다. 더 이상은 없어. 따라서 핸들러를 연결하면 모든 이벤트 모델 을 쉽게 구축할 수 있습니다.

 
Konstantin Nikitin :
이 전체 블록 어셈블리는 꽤 오랫동안 사용되어 왔습니다. 그러나 대규모 프로젝트를 생성할 때는 프로젝트의 일부 개별 부분에만 적합합니다. 글쎄, 그건 그렇고, 비록 이러한 템플릿을 사용하는 사람 자신은 코드를 작성하지 않지만 기본적으로 여전히 적용되고 어떻게든 작성되었습니다.
글쎄, 그런 프로그래밍이 죽는다면. 그 프로세스는 누구도 새롭고 더 최적화된 솔루션을 작성할 수 없는 곳에서 멈춥니다. 그것은 모두 쌍둥이 프로그램으로 귀결됩니다. 여기에 숨겨진 버그가 있는 경우 이 템플릿에 의해 코드가 적용될 모든 항목에 자동으로 복제됩니다.
그래서 그들이 실제 AI를 만들 때까지, 오늘날 AI로 전달되는 패러디가 아닙니다. 프로그래밍의 소멸에 대해 이야기하기에는 너무 이르다.

그런거야. AI를 블록 객체 표현 시스템에 연결하는 것만이 코드 작성을 가르치는 것보다 훨씬 쉽습니다. 블록 빌드 시스템이 훨씬 빠릅니다. 수년간의 훈련이 필요하지 않습니다. 개체는 실행 중인 스튜디오를 벗어나지 않기 때문에 컴파일을 위해 지체 없이 확인됩니다. 빌드 및 테스트 프로세스의 일부를 자동화할 수 있는 엄청난 잠재력. 신경망을 연결하는 능력.

블록 시스템이 미래라고 생각합니다.