"실행 중"프로그램 편집?

"실행 중"프로그램 편집? 왜?

---

나는 최근에 Lisp와 Lispy 언어에 대해 더 많이 배우고 있으며, 그것들이 상당히 강력하다는 것을 알게되었습니다.

내가 인터넷 전체에서 읽은 한 가지는 Lisp, Clojure 등으로 작성하는 것의 이점은 "실행되는 동안"프로그램을 편집 할 수 있다는 것입니다.

아마도 내가 뭔가를 놓치고 있지만 요점은 무엇입니까?

물론입니다. 몇 초를 절약 할 수 있지만 그게 다인가요? 프로그램을 변경할 때마다 중단하고 다시 시작하면 수십 년 동안 잘 작동했습니다.

시간을 절약하는 것 외에 다른 이유가 있어야합니다.

누군가가이 기능에 빠져들게 만드는 좋은 사례 연구를 줄 수 있습니까? :)

침을 흘리기를 고대하고 있습니다!

---

매우 멋진 사용 사례가 있습니다. 한 가지 예는 GUI 프로그래밍입니다. 내 Emacs 옆에서 실행되는 GUI 앱을 실시간으로 개발하는 동안 이것을 보았습니다. 새 버튼에 대한 코드를 추가하고 "Cc Cc"를 눌러 해당 단일 함수를 컴파일하고 버튼이 방금 나타났습니다. 창문에서! 앱을 닫았다가 다시 열 필요가 없었습니다. 그런 다음 위젯을 조정하고 레이아웃을 조작하기 시작했습니다. 그러면 열려있는 창이 즉시 재정렬됩니다. 버튼이 이동하고 새 텍스트 필드가 갑자기 나타나기 시작했습니다.

또 다른 예는 프로그래머가 실시간으로 3D 테트리스 게임을 만드는 Clojure OpenGL 라이브러리 "Penumbra"에 대한 훌륭한 스크린 캐스트입니다. 그는 emacs 옆에 빈 OpenGL 창으로 시작합니다. 그는 큐브 개체 (CMx)를 정의하고 화면에 표시됩니다. 회전 명령을 실행하고 즉시 회전을 시작합니다. 각기 다른 위치에있는 5 개의 큐브를 정의하는 루프를 실행합니다 (팝-팝-팝-팝-팝). 즉시 반응하는 모든 OpenGL 툴킷을 바로 사용할 수 있습니다. 큐브에 새로운 표면 텍스처를 추가하고 즉시 나타나는지 확인하십시오. 그것은 가단성 3D 세계가됩니다. 코드는 매 변경시 3D 캔버스를 닫았다가 다시 여는 대신 기존 세계를 동적으로 수정합니다.

Penumbra Livecoding Screencast- 최상의 경험을 위해 HD 버전을 다운로드하십시오.

Clojure의 오디오 라이브러리 "Overtone"에 대한 훌륭한 프레젠테이션 / 스크린 캐스트도 있습니다. 라이브러리는 음파를 조작하기위한 신디사이저 기능 세트가있는 신디사이저 툴킷입니다. 프레젠테이션 중에 개발자는 톤 재생을 시작하는 약간의 코드를 작성합니다. 그런 다음 10 초 동안 해당 사운드를 10 번 재생하지만 매번 주파수를 높이는 루프를 작성하는 데 10 초를 소비하고 다시 CMx를 사용하면 음이 더 높게 올라갑니다. 실시간으로 20 분 동안 그는 노래를 듣습니다. 엄청난 재미처럼 보입니다.

배음 프레젠테이션 링크

다른 용도는 예를 들면 다음과 같습니다. 웹 크롤링 / 데이터 마이닝-실시간으로 정보를 추출하고 각 단계에서 반환 된 데이터를 확인하는 알고리즘을 개발하고 개선합니다. 로봇 프로그래밍-로봇이 작동하는 동안 명령을 보냅니다. 얼굴 / 이미지 인식-OpenCV와 같은 라이브러리를 사용하여 코드를 개발할 때 라이브러리가 이미지 / 비디오에서 인식하는 내용을 즉시 업데이트하는 것을 확인하십시오. 수학 작업 (Clojure는 통계를 위해 "Incanter"를 가지고 있음); 변경 사항이 작업중인 데이터에 어떤 영향을 미쳤는지 즉시 확인하려는 환경.

그래서 그것은 당신 앞에서 REPL을 갖는 가장 재미있는 측면입니다. 눈에 띄지 않고, 가단하고, 상호 작용하지 않는 것들이 시작됩니다. GUI 디자인, 3D 그래픽, 프로그래밍 방식의 사운드 제작, 데이터 추출 및 변환, 이러한 작업은 일반적으로 팔 거리에서 수행되었습니다. 그러나 Clojure를 사용하면 (그리고 어느 정도는 다른 동적 언어에서도) 실제로 눈에 띄고 즉각적으로 만들 수 있습니다. 코드를 작성하자마자 각 변경 사항을 볼 수 있으며, 무언가가 작동하지 않거나 예상 한 결과를 얻지 못하면 놓친 부분을 변경하고 즉시 다시 실행하면됩니다.

Clojure는이 작업에 매우 적합합니다. 거친 것은 자바 자체로는 할 수 없다는 사실에도 불구하고 자바 라이브러리를 동일한 방식으로 실시간으로 사용할 수 있다는 것입니다! 따라서 Overtone은 Java에서 불가능한 사실에도 불구하고 실시간으로 Java synth 라이브러리를 사용하고 있으며 Penumbra는 Java OpenGL 바인딩 등을 사용하고 있습니다. 이는 Rich Hickey가 즉시 JVM 바이트 코드로 컴파일 할 수 있도록 Clojure를 설계했기 때문입니다. 그것은 놀라운 언어입니다. Clojure는 얼마나 재미 있고 생산적인 프로그래밍이 될 수 있는지에 큰 기여를했습니다.

---

시간을 절약하는 것 외에 다른 이유가 있어야합니다.

아니, 없습니다. 내 말은,이 결코 없습니다 다음 전체 이유는 모든 시간을 절약하는 것입니다에서 컴퓨터를 사용 할 수 있습니다. 손으로 할 수없는 것보다 컴퓨터가 할 수있는 일은 없습니다. 조금 더 오래 걸립니다.

이 경우, 전체 프로그래밍 경력을 위해 하루 종일 다른 어떤 것보다 더 자주하는 일 중 하나이기 때문에 "몇 초"를 무시하지 않을 것입니다. 다시 컴파일하는 데 몇 초, 다시 실행하는 데 몇 초, 내 프로그램이 이전에 있었던 상태를 다시 만드는 데 몇 초가 걸립니다. 빠른 워크 스테이션에서도 반복 사이에 1 분 정도가 소요될 수 있습니다. (이전에는 훨씬 더 나빠졌지만 하드웨어가 빨라서 끔찍하지도 않고 좋지도 않았습니다. 전체 파일 또는 더 나쁜 재 컴파일은 I / O 바운드이며 더 세분화 된 컴파일 속도와 결코 일치하지 않을 수 있습니다.)

Lisp에서 이미 실행중인 프로세스에서 단일 함수를 다시 컴파일하는 것은 거의 즉각적이며 (5 년 된 랩톱에서도 0.1 초도 본 적이 없습니다) 다시 시작하면 상태를 다시 만들 필요가 없습니다. , 무언가 신호를 보내는 경우에도.

여기 프로그래머로서 가장 느리고 가장 일반적인 작업 중 하나보다 100 배 이상의 속도 향상을 제공하는 도구가 있습니다. 나는 당신이 더 필요한 것이 무엇인지 모릅니다. 우리는 아마도 몇 가지 이유를 설명 할 수 있지만 이것이 충분한 이유가 아니라면 무엇이 될지 모르겠습니다. 음, 그것도 꽤 멋진가요? :-)

(* 누군가가 기술과 관련된 것에 대해 "절대"라고 말할 때마다 그 사람은 2 년 후 변함없이 완전한 바보처럼 보이고 Lisp의 장수에도 불구하고 예외는 아닙니다.)

---

Lisp에 대한 마케팅 슬로건이 있습니다.

Lisp 및 점진적 개발 방법을 사용하면 소프트웨어 시스템 변경 비용은 전체 소프트웨어의 크기가 아니라 변경 크기에 따라 달라집니다.

대규모 소프트웨어 시스템이 있더라도 변경 비용 (시간, ...)은 변경 규모와 관련하여 유지됩니다. 새 메서드를 추가하거나 새 메서드를 변경하면 메서드를 편집하고 메서드를 점진적으로 컴파일하고 메서드를 점진적으로로드하려는 노력과 관련하여 노력이 유지됩니다.

기존의 많은 소프트웨어 환경에서 메서드를 변경하려면 부분 재 컴파일, 새로 연결된 실행 파일, 다시 시작, 다시로드 등이 필요할 수 있습니다. 소프트웨어가 클수록 시간이 더 오래 걸립니다.

인간의 경우 이것은 우리 가 흐름 상태에서 벗어날 수 있음을 의미 합니다. 그것은 좋은 Lisp 환경의 생산성의 일부입니다. 프로그래머가 편안하다고 느끼고이 흐름 상태에 들어가면 짧은 시간에 소프트웨어 시스템을 많이 변경할 수 있습니다 . 응답이없는 시스템 앞에 앉아 대기 시간에 직면하는 시간과는 달리 작업이 단시간에 완료되는 이런 경험을 많이했다고 생각합니다.

또한 우리와 우리가 작업하는 프로그램 사이 에는 인지 적 거리 가 거의 없습니다 . 예를 들어 배치 환경에서 클래스를 편집하는 경우 변경 사항이 미치는 영향을 상상해야합니다. Lisp에서는 클래스를 편집하고 동시에 객체 자체를 변경합니다. 즉, 일괄 편집-컴파일-링크-실행-테스트주기 후에 개체의 새 버전이 아니라 개체의 동작을 직접 변경합니다.

Lisp 시스템에서 CAD 시스템의 클래스를 변경하면 즉시 활성화 될 수 있습니다. 사람들이 Lisp가 대규모 소프트웨어 팀에서 일하는지 물으면 점진적으로 작업한다면 대규모 소프트웨어 팀이 필요하지 않다는 대답이 될 수 있습니다. 문제는 점진적 개발에 익숙한 정말 능숙한 소프트웨어 개발자가 드물다는 것입니다.

많은 응용 프로그램에는 별도의 스크립팅 언어 계층이 있으며 때로는 원래 개발자 (사용자가 아님)를위한 것입니다. Lisp에서는 이것이 필요하지 않으며 Lisp는 자체 확장 언어 입니다.

---

실제 세계에서 이것은 주로 개발에 사용되며 많은 기능과 마찬가지로 올바른 컨텍스트에서 침을 흘릴 가치가 있습니다.

1. 개인 프로그래머 깨달음의 행복 *
2. 진정한 지속적인 배포.
3. 계획된 다운 타임 없음 서비스 수준 계약.
4. 프로덕션 서버를 디버그합니다.

* 보증이 아닙니다.

---

나를 위해, 그리고 나는 여기에서 다른 사람들 이이 REPL 주도 개발 의 진정한 이점은 설명 할 수 없을 정도로 재미 있을 수 있다는 것입니다. 중독성이 있습니다. 때로는 실제로 코드를 만드는 느낌을 줄 수 있습니다. 한번 시도해보세요 ... 어서 시도해보세요. 먼저 REPL은 항상 무료입니다. :)

---

요즘 큰 매력 중 하나는 지속적인 배포입니다.

현재 지속적인 배포에 대한 아이디어는 한 가지를 변경하고 모든 것을 빌드 (또는 패키징) 한 다음 배포하는 것입니다. lisp 모델을 사용하면 배포 중에 배포 된 (일반적으로 실제 고객 세션의 미러를받는 상자) 상자를 편집 할 수 있습니다.

just a pedantic note. you dont actually edit running classes. you compile a new copy of the class and leave it in a known location (a var) then the next time it is used the new copy is found and used. its not really editing while running and more like new code takes effect immediately this reduces the scope of the devlopment process from programs to expressions (typically functions).

---

또 다른 침 흘림 포인트는 다운 타임을 선언 할 필요없이 보안 수정 의 이점을 얻는다는 아이디어입니다 . 귀중한 "예정된 다운 타임"을 SLA 비용없이 업그레이드 할 수 있습니다. 계획된 다운 타임을 6 개월 전에 미리 예약해야하는데 2 시간 밖에 걸리지 않는 경우 (불쌍한 영혼을 위해) 실제로 침을 흘릴 수 있습니다.

---

실행중인 애플리케이션이 배포 될 때 (잠재적으로 고객 사이트에서 (권한이있는)) 실행중인 애플리케이션에 대한 repl 액세스 권한이있는 경우 앱이 실행되는 동안 앱에 연결 하고 기존 컨텍스트 의 기존 코드 에 대한 테스트를 실행할 수 있습니다. 디버거를 중지하고 연결하지 않아도됩니다. 또한 디버거에서 속도 손실이 발생하지 않습니다. REPL없이이를 수행 할 수 있지만, 거기에 repl을 넣으면 새 코드를 쉽게 생성 할 수 있으며 (일부는 디버거를 통해 동적 클래스 로더를 삽입하는 것이 쉽다고 말합니다) 문제를 해결할 수 있습니다. 따라서 실행중인 서버에 연결할 수 있습니다. 잠시 중단 된 후 함수가 데이터베이스에 다시 연결하는 데 실패했음을 발견 한 다음 바로 다시 연결합니다.

---

모든 프로그래밍 구조와 마찬가지로 결코 은색 총알 이 없으며 이러한 지속적인 배포 / 개발에는 흥미로운 단점이 있습니다. 프로그램은 메모리에서 정확하고 디스크에서는 잘못 될 수 있습니다. 함수를 컴파일 한 다음 중단하고 저장하면 코드의 유일한 작업 복사본이 실행중인 것입니다. 이 사실을 알고 저장 한 직후 파일을 다시 평가하는 것은 유용하지 않습니다.

---

이것은 환상적으로 들릴 수 있으므로 프로덕션 애플리케이션에 Clojure REPL을 포함하는 방법을 확인 하십시오.

---

NASA의 누군가가 그의 경험을 설명했던 것을 기억합니다. 그의 팀은 70 년대 우주선에 사용 된 소프트를 구현했습니다. 그리고 버그가 발견되면 즉시 원격으로 소프트를 효과적으로 수정했습니다.

Or imagine you have a long process taking days to execute and at the end it cannot write results because of permissions or other small problem.

Yet another example. You are in the integration phase and you have to make a lot of small changes. And again a lot of them. I dream about such a possibility in Java because currently it takes me 30-40 min to rebuild and reinstall my application (to rebuild it again in 10 min).

---

If you look at something like Erlang, the point is to avoid down time.

It runs on stuff like phone switches that you can't just turn off for a few seconds.

For more normal uses, though, it's a "nice to have" feature, but yeah, probably not critical.

---

You see real data. That is a big advantage. You then don't have to speculate.

---

Because you can?

Seriously, just try it out for while, and you will feel the pain when you come back to your old programming language without REPL.

Instant feedback, easy making quick tests without having to set-up a fake program state in your test fixture, Ability to inspect state of running program (what is the value of that variable). All of these are a real time savers.

---

It's mostly for development, where it's just a time saver.

But time savers are staggeringly important.

Once you're used to it going back to the old way feels like going from flying to swimming in tar.

---

In industrial systems this is used for PLC programming to alleviate downtime and unsafe conditions.

These are systems that are used on nuclear power plants, manufacturing systems, steel mills, etc. The process is always running, continuously, and down time is very expensive or unsafe. Imagine a system that is controlling the cooling of a nuclear reactor, you cannot turn that system off to deploy new code, you must be able to modify it as it is running.

This is similar to the Erlang answer for phone switch systems.

---

Well, imagine you need to patch a server and not stop it.

If you do this in a "typical" language, that's going to involve some heavy magic. You have to grub around 'behind' the executing code. I think it'd require patching the function tables and so forth, all in assembly and manipulating the pointers to functions. A good place for bugs.

In Lisp, the idea of updating without downtime is built into the language model. While there are some update complexities you can't get away from (how do you handle a long-running connection), it doesn't require the heavy magic of a compiled language.

Although I haven't spent significant time on it (ie anything useful), I did work out a prototype of a server in Common Lisp that would do at least some live patching over a network without downtime.

---

Another good thing apart from modifying the program on the fly without having to restart everything (having done it for decades doesn't mean it is the best thing, right?), is that you get to inspect your program in its current state and being able to figure out what's going on.

---

Casey Muratori just did a few lessons on how to do this with C and Microsoft's C/C++ compiler. It's actually pretty simple, just a few dozen lines of code. Check out videos 22/24/25:

https://www.youtube.com/watch?v=WMSBRk5WG58

In game design, the rationale is to be able to more quickly tune constants to find the emotional tenor you are aiming for. Things like game feel, non-player behavior scripts and setpiece lighting/ambience benefit a lot from this.

참고URL : https://stackoverflow.com/questions/5074781/editing-programs-while-they-are-running-why