In the past months, many new features were added to Red/System, the low-level dialect embedded in Red. Here is a sum up if you missed them. Subroutines During the work on the low-level parts of the new Red lexer, the need arised for intra-function factorization abilities to keep the lexer code as DRY as possible. Subroutines were introduced to...
OOP가 더 편리한 곳에서는 OOP를 사용합니다. 메모리와 시간을 절약하고 스스로 코드를 작성해야 하는 곳에서는 절차를 따릅니다. 나는 방금 기사를 생각해 냈고 어디에 / 무엇이 더 나은지에 대한 의견을 듣고 싶었습니다. 결론 - 나는 내 주소의 다른 것들에 대해 충분히 들었고 프로그래밍에 대해서는 이야기하지 않았습니다. 모든 것이 평소와 같습니다.
그래서 아무도 당신에게 새로운 것을 말하지 않을 것입니다. 편한대로 사용하세요.
오류를 최소화하기 위해 증거 기반 프로그래밍(특히 형식 검증)이라는 전체 영역이 있습니다.
코드의 품질을 개선하기 위한 부분적인 조치로 일반적으로 허용되는 코딩 스타일(예: google codestyle), 주장(assert) 사용, 본질적으로 다음을 수행하는 제한(const, override, 액세스 지정자 ) 중 하나를 따르도록 제안할 수 있습니다. 실행에 영향을 미치지 않지만 오용의 경우 컴파일 오류 가 발생합니다. 일반적인 디자인 접근 방식에 익숙해집니다.
사실은 일반적인 프로그래밍의 중요한 영역을 제외하고 프로덕션 버전을 얻는 속도가 코드의 품질보다 더 중요하다는 것입니다. 이것은 나쁘지만 사실입니다.
질문이 내 예에 대한 것이라면 적어도 구현을 숨깁니다(자신에게도 숨깁니다). 즉, 계산 논리만 작성하면 편리하고 읽기 쉽고 논리적 오류를 피할 수 있습니다.
추신: 거래와 관련하여 주문을 하기 위한 논리가 A + B - C로 작성되는 주문 그리드로 실험을 작성했으며 여전히 수행합니다. 여기서 A, B 및 C는 사전 정의된 매개변수가 있는 주문이므로 매우 편리합니다. 유전 알고리즘 에 사용 - 흥미로운 주제
래퍼는 훌륭하고 논리적인 솔루션입니다. 적절한 경우. 그리고 래퍼는 절차적 언어의 혁신이라고 생각합니다. 그것은 참신함과 유용성의 의미에서입니다.
거래와 관련하여 - 나는 주문을 하기 위한 논리가 A + B - C 로 작성되는 주문 그리드로 실험을 작성했고 여전히 수행하고 있습니다. 여기서 A, B 및 C는 사전 정의된 매개변수가 있는 주문이므로 사용하기에 매우 편리합니다. 유전 알고리즘 - 흥미로운 주제
사전 정의된 매개변수 가 있는 A, B 및 C - 유전 알고리즘의 표현형은 어떻습니까?
캡슐화는 이름의 자유를 제공합니다. 그리고 이 문제가 이름의 논리로 해결된다면. 이것은 물론 비용이 많이 듭니다. 그런 다음 Python은 함수에 작성할 수 있습니다. 그러나 그것은 시장 솔루션이 될 수 없습니다. 하지만 가능합니다.
파이썬에서 변수와 같은 모든 f-i는 객체입니다)
그건 그렇고, 연속 OOP의 예는 파이썬입니다. 오히려 OOP가 아닌 다른 것이 있다는 것을 아무도 모릅니다.
클로저가 있고 oop 없이 쓸 수 있습니다. 적어도 예전에는 누가 무엇을 좋아하든지
파이썬에서 변수와 같은 모든 f-i는 객체입니다)
링크는 모든 것을 해결할 수 있습니다. 이름이 겹치지 않는 한. 함수는 물론 객체이지만 그 결과는 내부에서 동일하고 전역 및 공개 버전에서만 내부를 볼 수 있습니다. 나는 파이썬 논리를 좋아한다
클로저가 있고 oop 없이 쓸 수 있습니다. 적어도 예전에는 누가 무엇을 좋아하든지
할 수 있지만 여전히 최소 구성 요소는 개체입니다.
오랜만에 보는 것.
정말 정말 다른 별명으로 갔다?
아니요, 이것은 완전히 다른 작풍의 Peter가 아닙니다.
가혹한 엔터프라이즈 OOP는 Java입니다. 우리 지역에서는 Du * *opy가 대표됩니다(뛰지 않도록 건너뛰기). 사물의 아름다움을 갈망하십시오 - 주제가 알려져 있으므로 진지하게 API를 이해하고 기억하십시오 :-)
와 다 헛소리야..
프로그래밍 기술을 높이려면 두뇌를 꼬이는 스레드를 마스터할 가치가 있습니다. 예를 들어 Rebol/Red( https://www.red-lang.org/ )가 있습니다. 이해하기 힘들지만 멋진 멋진 것입니다.
또는 고전 - Smalltalk ( https://pharo.org/ ) . 누군가는 프로덕션에서도 사용합니다.
그리고 이 모든 "A + B를 다른 스타일로 쓰자", 베이비 토크, 솔직히 한 마디.
그러면 OOP와 FP 중 누가 더 멋있는지에 대한 모든 질문이 저절로 사라집니다.
할 수 있지만 여전히 최소 구성 요소는 개체입니다.
그것은 돌파구였다.
OOP가 더 편리한 곳에서는 OOP를 사용합니다. 메모리와 시간을 절약하고 스스로 코드를 작성해야 하는 곳에서는 절차를 따릅니다. 나는 방금 기사를 생각해 냈고 어디에 / 무엇이 더 나은지에 대한 의견을 듣고 싶었습니다. 결론 - 나는 내 주소의 다른 것들에 대해 충분히 들었고 프로그래밍에 대해서는 이야기하지 않았습니다. 모든 것이 평소와 같습니다.
그래서 아무도 당신에게 새로운 것을 말하지 않을 것입니다. 편한대로 사용하세요.
오류를 최소화하기 위해 증거 기반 프로그래밍(특히 형식 검증)이라는 전체 영역이 있습니다.
코드의 품질을 개선하기 위한 부분적인 조치로 일반적으로 허용되는 코딩 스타일(예: google codestyle), 주장(assert) 사용, 본질적으로 다음을 수행하는 제한(const, override, 액세스 지정자 ) 중 하나를 따르도록 제안할 수 있습니다. 실행에 영향을 미치지 않지만 오용의 경우 컴파일 오류 가 발생합니다. 일반적인 디자인 접근 방식에 익숙해집니다.
사실은 일반적인 프로그래밍의 중요한 영역을 제외하고 프로덕션 버전을 얻는 속도가 코드의 품질보다 더 중요하다는 것입니다. 이것은 나쁘지만 사실입니다.