MQL5의 OOP에 대한 질문 - 페이지 26

 
Igor Makanu :

IT 거물은 이 패러다임을 지원하며 아마도 유익할 것입니다. 소프트웨어 개발자가 더 강력한 하드웨어가 작동해야 하는 복잡한 구현을 만들도록 하고 OS 또는 컴파일러에 대한 문서를 대부분의 경우 기성품 라이브러리와 함께 제시하도록 합니다. 개발자에게 강요하는 OOP의 형태 .... 등등 무한대로 ;)

글쎄, 이것은 일종의 음모 이론) 모든 것이 훨씬 간단하다고 생각합니다. 팝적인 것들은 대부분의 사람들에게 항상 더 간단하고 이해하기 쉽습니다. 기본적으로 인형을 위한 언어인 Python의 놀라운 인기를 예로 들어 보겠습니다. "프로그래밍을 배우는 방법은 거의 모든 곳에서 Python이 제공됩니다.) 그리고 컴파일러의 엄격함과 제어에 익숙한 숙련 된 프로그래머는 이것으로 전환하지 않을 것입니다.) 그러나 풍부한 pythonists는 개발자가 적응하도록 강요합니다 그들에게)

 
Alexey Navoykov :

음, 이것은 일종의 음모론입니다)

이것은 음모 이론이 아니라 삶의 경험으로, 나는 기업에서도 노동 집약적이고 시간이 많이 걸리는 역겹게 구축된 기술 주기가 있다고 오랫동안 확신해 왔습니다 ... 그러나 이것이 모든 것이 작동하는 방식입니다. 기업에 이익이 되고 시간과 자원을 현명하게 절약하기 위해 모든 것을 하면 이익이 없을 것입니다! - 특히 가입자와의 업무가 있는 경우에 해당됩니다. - 셀룰러 통신에 대한 경험이 있는 경우

그리고 그러한 "지식의 프리즘"을 통해 .opu를 통해 일반적으로 무언가가 발명된 이유를 알아보려고 합니다. 그러나 일반적으로 이렇게 작동하고 오랫동안 작동할 것입니다.

OOP가 틀릴 수도 있겠지만, 물론 비효율은 있는 그대로, 이것이 오랫동안 작동해왔고 오랫동안 작동할 것입니다 .... 글쎄, 아마도 인디언들이 작성할 수 있도록 코드가 더 정통? 또는 모든 고객이 소스를 읽을 수는 없었습니까? - 글쎄, 일반적으로 OOP가 인기있는 이유를 오랫동안 생각할 수 있지만 그러한 비판을 유발합니다.

)))

 
기사가 더 이야기 같다. 말은 많지만 본질은 없는 그로보보이가 생각난다. 근거 없는 진술.
"무슨 요점이요?..." - 기사를 훑어보면서 순진하게 우리가 가장 중요한 것에 도달했다고 생각했지만, 다시 말하지만 OOP가 나쁜 곳은 나쁜 곳, 나쁜 곳은 나쁜 곳이지만 모든 것은 괜찮습니다. 함수형 프로그래밍.
이거 어떻게 읽나요?

아마도 아이디어 자체가 흥미로울 것입니다.
 
Aliaksandr Hryshyn :
...말은 많지만 본질은 제로. 근거 없는 진술.

근거가 없는 구체적인 진술은?

 
물론 IMHO. 하지만 OOP의 문제는 OOP 자체에 있는 것이 아니라 항상 그렇듯이 사람들에게 있는 것 같습니다. 똥코더에게 플러스에 대한 작업을 부여하면 그는 성공적으로 채울 것이고 샤프에서는 Google의 도움이 있기 때문에 작업 솔루션을 잘 묘사할 수 있습니다. 그러나 다른 사람들의 코드 조각을 하나의 전체로 결합하는 어떤 종류의 복잡성(Google 도움말 mi에 대해 기억함)이 밝혀질지, 이것이 얼마나 운이 좋은지 알 수 있습니다. 결과적으로 작동하는 것 같지만 거기에서 무언가를 변경하려면 만지지 않는 것이 좋습니다 ...
 
Alexey Navoykov :

근거가 없는 구체적인 진술은?

1. OPP는 절차적 데이터베이스의 복잡성을 처리할 수 없습니다(Windows 및 기타 복잡한 소프트웨어는 어떻게든 작동함).
2. OOP는 좋은 연구 없이 설계되었습니다(OOP는 천장에서 가져왔지만 그냥 그렇게 하고 싶었습니다).
3. OOP는 인간의 두뇌에 자연스럽지 않습니다.
.....

세부 사항에 들어가지 않아도 너무 많습니다.
 
FP 지지자들은 그들의 람다 미적분학이 유한한 수의 상태와 그들 사이의 전이를 가진 튜링 기계에 의해 실행된다는 사실을 의도적으로 잊었습니다. 동일한 카운터, 분기 및 goto 명령이 사용됩니다. 따라서 FP가 C, C#, Java와 같은 고전적인 언어보다 더 많은 것을 제공한다고 말하는 것은 적어도 잘못된 것입니다.
 

어느날 유튜브에서 DOS하에서 레트로게임 추천 리뷰를 하다보니 한동안 플레이를 못했는데 오늘은 추천 https://youtu.be/edJPKwpeHh4 에서 가끔 봅니다.

그래서 그것이 마음에 떠올랐습니다. 손으로 수행한 작업(일부 gamestudio 등 없이)을 가져오겠습니다. 정말 고품질로 수행되었으며 속도가 느려지지 않았으며 정말 ... 음, 일반적으로 전설

제 생각에 떠오른 것은 Quake-1입니다. 그는 심지어 486을 타고 날아갔고 가능한 한 영리하게 만들어졌고, 그런 다음 그의 새 엔진에서 모든 게임 라인이 만들어졌습니다.

Quake-1은 무엇으로 작성되었습니까? 누가 보거나 읽었습니까?

 
Igor Makanu :

어느날 유튜브에서 DOS하에서 레트로게임 추천 리뷰를 하다보니 한동안 플레이를 못했는데 오늘은 추천 https://youtu.be/edJPKwpeHh4 에서 가끔 봅니다.

그래서 그것이 마음에 떠올랐습니다. 손으로 수행한 작업(일부 gamestudio 등 없이)을 가져오겠습니다. 정말 고품질로 수행되었으며 속도가 느려지지 않았으며 정말 ... 음, 일반적으로 전설

제 생각에 떠오른 것은 Quake-1입니다. 그는 심지어 486을 타고 날아갔고 가능한 한 영리하게 만들어졌고, 그런 다음 그의 새 엔진에서 모든 게임 라인이 만들어졌습니다.

Quake-1은 무엇으로 작성되었습니까? 누가 보거나 읽었습니까?

저는 Quake에 대해 잘 모르지만 예를 들어, Duke Nukem 3D raws에 대한 훌륭한 리뷰가 있습니다. https://habr.com/en/post/323426/

Анализ исходного кода Duke Nukem 3D: Часть 1
Анализ исходного кода Duke Nukem 3D: Часть 1
  • habr.com
Уйдя с работы в Amazon, я провёл много времени за чтением отличного исходного кода. Разобравшись с невероятно замечательным кодом idSoftware, я принялся за одну из лучших игр всех времён: Duke Nukem 3D и за её движок под названием "Build". Это оказался трудный опыт: сам движок имеет большую важность и высоко ценится за свою скорость...
 
Vasiliy Sokolov :

저는 Quake에 대해 잘 모르지만 예를 들어, Duke Nukem 3D raws에 대한 훌륭한 리뷰가 있습니다. https://habr.com/en/post/323426/

나는 그것을 중간에 읽었습니다. Duke Nukem의 지표가 아닙니다. 어린 시절 때문에 그는 어떻게 든 나를 "입력"하지 않았습니다.))), 기사에서 :

Doom/Quake가 생성하는 끝없는 포트 수를 보면서, 저는 항상 Duke Nukem 3D의 포트가 왜 그렇게 적은지 궁금했습니다. Ken Silverman이 직접 수행하기로 결정한 후에야 엔진이 OpenGL로 이식되었을 때도 동일한 질문이 발생했습니다.

기사 시작 부분에서 내가 올바르게 이해했다면 엔진 개발자는 18 세였으며 나이는 악이 아니지만 ... 제 생각에는 지식의 체계적인 적용이 없어야합니다

지금은 habr을 살펴보겠습니다. 기본 소스 또는 번역에 대한 흥미로운 리뷰가 있습니다.


추신: 사실, 여기에 레트로 전설의 출처가 있습니다 https://habr.com/ru/post/137442/