여기서 F# 을 보니 반가움! 에뮬레이터는 언어를 배우기에 좋은 방법이고, 처음 보기엔 작업별로 관용적인 F#과 덜 관용적인 F# 사이를 잘 골라 쓴 것 같음
할당을 줄이는 쉬운 개선점으로는 Instructions.fs의 구별 공용체(discriminated union)에 [<Struct>]를 붙이고, 필드 이름을 재사용해 내부 필드를 재사용하게 할 수 있음
사소한 지적이지만 일부 레지스터 처리가 헷갈림. 이미 byte 타입이라 setter에서 a &&& 0xFFuy를 해도 member val A = 0uy with get, set보다 추가되는 게 없어 보임. 아마 개발 중에 바뀐 흔적 같음
Register 소스에 이런 주석이 있음: 레지스터는 쓰기 시 값을 8비트로 잘라야 하므로 레코드 타입이 될 수 없고 setter가 필요하다고 되어 있음
웹 렌더러 때문에 그렇고, Fable이 JS에서 uint8을 Number로 변환해 8비트를 넘길 수 있으며 잘라내기를 적용하지 않는다는 설명임
그래서 웹 대상에서 JS Number로 넓어지는 Fable 특성 때문에 보수적으로 데이터를 정리하는 코드로 보임
실제로 글에서 Fable로 포팅하는 부분에 이 내용이 다뤄짐. Blazor도 시도했다고 함
드디어 누군가가 무언가를 배우기 위해 실제 인간의 노력을 들였고, “LLM이 X를 Y분 만에 만들게 도와줬다”가 아니라서 좋음
그래도 인류에게 아직 희망이 조금은 있는 듯함
그런 방식은 늘 남아 있을 것임. 2026년에도 손도구로 뭔가를 만드는 사람들이 있으니, 이걸 수공예 코딩이라고 부르자
인류에 대한 희망은 소련이 무너질 무렵쯤 이미 접었어야 했다고 봄
그래도 에뮬레이터는 정말 멋지고, GBA 에뮬레이터는 직접 도전해 보기 좋은 대상임
오랫동안 F# 개발자로 살아왔고, STEM 학계에서 괴롭힘도 오래 겪어온 입장에서 LLM을 쓰지 않음. 큰 이유는 ChatGPT-3.5가 F# GitHub 저장소에서 복붙한 티를 너무 노골적으로 냈기 때문임
AGI라는 느낌은 전혀 없었고, 장식이 벗겨진 표절 기계처럼 보였음
언젠가 Microsoft의 누군가가 알아채고 RLHF 경보를 울렸을 테니 GPT는 꽤 나아졌고, F#에도 제법 쓸 만해 보임. 원칙 없는 F# 개발자라면 요즘 에이전트로 잘 해내고 있을지도 모름
하지만 “표절 문제를 해결했으니 이제 잡동사니를 생성하자”가 아니라, “이제 ChatGPT가 표절해도 더는 노골적으로 드러나지 않겠구나”라고 느꼈음
생산성 이득을 얻자고 내 핵심 가치 하나를 완전히 훼손할 확률을 d100이나 d1000으로 굴리고 싶지 않음. 느리고 무직인 채로 지내겠음. 진지하게, 태양광 설치와 폐품 수거 쪽으로 들어가고 있음
“학생들이 생각하고 싶어 하지 않는다”는 문제는 LLM보다 훨씬 오래됨. 2007년에 고학년 편미분방정식 수업을 들었는데, PDE를 진짜 공부하려던 내가 숙제를 거의 다 풀었고, 심리적으로 약해서 못된 게으른 수학 전공자들을 거절하지 못해 거의 모두가 내 숙제를 베꼈음. 대학원 수학 과정에서도 또 그랬음. 정말 믿기 어려움. 그럴 거면 왜 그 과정에 있는 건지 모르겠음
아, F#, 내 가장 큰 사랑. C# 쪽 사람들이 C#을 계속 이것저것 다 되지만 어설픈 언어로 망가뜨리지 말고 이걸 봤으면 좋겠음
C#과 F#을 함께 쓰는 프로젝트를 만들면, C#에 계속 추가되는 것들을 실제로 잘 작동하고 인체공학적으로 얻을 수 있다는 걸 왜 못 보는지 모르겠음. 상호운용성도 훌륭함
다만 OCaml 세계에서 오면 F#이 C#의 그림자에 조금 갇혀 있는 것처럼 느껴져서 아쉬움
F#을 함수형 언어처럼 써도 꽤 멀리 갈 수 있지만, 결국 .NET 생태계와 상호운용하고 싶어지고, 그 순간 이상한 객체지향/함수형 하이브리드 스타일로 코딩하게 됨
F# 은 좋은 언어지만 영원히 C#의 그림자에 갇힌 느낌임. 라이브러리 코드 상당수가 C#과 .NET에서 물려받은 것이고, F#을 염두에 두고 설계된 인터페이스나 라이브러리가 아닌 경우가 많으며, F# 사용법 문서도 명시적으로 없는 일이 흔함
C#에서 F#으로 라이브러리 사용법을 옮기는 건 꽤 기계적인 작업이라, 별도 문서가 꼭 필요한지는 잘 모르겠음
더 큰 문제는 C# 커뮤니티가 객체지향을 좋아해서, 함수형 프로그래밍 방식으로 일하고 싶다면 이런 라이브러리들을 더 “함수형”인 형태로 감싸야 하는 경우가 많다는 점임
그래도 아무것도 없는 것보다는 훨씬 낫다고 봄. Haskell이나 OCaml도 좋아하지만 그런 면에서는 비교가 됨
둘의 상호작용 때문에 어느 정도 어색함이 생기는 건 맞지만, 특정 라이브러리가 F#에 잘 맞게 매핑되어야 한다기보다는 상호운용 규칙과 생성되는 내부 출력의 형태를 잘 이해하는 문제가 더 크다고 봄
C# 상호운용성은 F# 코드가 일반적으로 의존하는 보장, 특히 불변성을 느슨하게 만듦. C#으로 매핑되는 방식 때문에 제네릭에서도 의외의 한계가 나타남
정말 멋짐! F#을 좋아하지만, 작은 Smalltalk 인터프리터를 F#으로 써본 결과 이런 종류의 작업에서 의도된 방식대로 쓰면 정확히 속도 괴물은 아니라는 건 확인했음
F#에서는 멍청할 정도로 명령형으로 짜되, 부작용을 함수 안에 가둬두면 성능이 더 잘 나오는 걸 봄. 그러면 함수는 사실상 “순수”하게 유지하면서도 괜찮은 속도를 얻을 수 있음
예를 들어 보통 Map 자료구조를 좋아하고, 꽤 훌륭한 불변 구조라 대부분의 용도에는 충분함. 하지만 성능이 중요해지면 일반 해시 맵을 쓰는 지루한 명령형 루프로 들어가는 것도 어렵지 않음
모든 걸 함수 하나 안에 가둬두면 대체로 너무 더럽게 짰다는 느낌을 피할 수 있음
그 인터프리터를 언제 썼는지 궁금함. .NET 생태계 전체가 지난 몇 년 동안 엄청난 속도 개선을 겪었고, 특히 Framework 시대에 마지막으로 써본 사람이라면 차이가 큼
심지어 C# 컴파일러도 활용하지 않는 꼬리 호출 개선에도 공을 들였음. .NET 9나 10 즈음에는 F#에 꼬리 호출이 아닌 재귀 호출이 있으면 컴파일러 오류를 내게 하는 특성도 추가돼서, 실수로 망치지 않게 해줌
어떤 기능을 언제 쓸지 조심하면 F#도 매우 빠를 수 있음. 원할 때는 함수형 패러다임을 쓰고, 필요하면 뜨거운 루프에서 저수준 명령형 코드를 쓰면 됨
다만 연결 리스트, 시퀀스, 불변 자료형을 사방에 쓰면 Rust는 절대 아님
멋진 프로젝트임! 이런 걸 보니 정말 좋음
한편으로, 이건 작성자나 작업 자체에 대한 평가는 아니지만 실제 프로젝트에서 F# 코드가 어떻게 보이는지 보고 나니 F#을 배우고 쓰고 싶던 마음은 접어도 되겠다고 느꼈음
순수 함수형 부분은 아름답지만, 더 명령형이거나 변경 가능한 코드로 내려가면 보기 꽤 못생겼다고 느낌. 불행히도 대부분의 실제 프로젝트에서는 결국 그렇게 해야 할 것 같음
그래서 다른 함수형 언어를 골라 뛰어들어야 하는 건지, 아니면 이미 쓰는 언어에 함수형 개념을 적용하는 데 집중해야 하는 건지 모르겠음. 주 언어가 C#이고 함수형 패러다임 지원이 계속 늘고 있어서 후자는 꽤 쉬운 편임
함수형 언어로 작성된 에뮬레이터는 늘 인상적임. 하드웨어를 명령형 언어에 매핑하는 편이 보통 훨씬 쉽기 때문임. 사람들이 어떤 함수형 추상화를 만들어내는지 보는 게 즐거움
코드를 봤는지 궁금함. F#에는 변경 가능한 변수와 배열이 있고, 이 프로젝트도 예를 들어 메모리에 그걸 사용함
F#은 정말 재미있는 언어이고, 멋진 작업임!
F# 은 내가 절대 실무에서는 쓰지 못하는 코딩 사랑의 언어임. 개인 프로젝트 밖에서는 쓸 기회가 없음 :(
흥미롭고 즐거운 글임. 데이터 모델링 부분이 좋았음. OCaml을 조금 만져보고 있는데 그런 식의 모델링이 가장 좋은 부분임 CAMLBOY를 알게 된 것도 흥미로웠음. 작성자에게 피드백하자면, AI 편집 단계는 건너뛰는 편이 좋겠음. 지금처럼 조금 밋밋한 글보다는 문법 오류나 덜 세련된 표현이 있는 쪽을 더 선호했을 것 같음
Hacker News 의견들
여기서 F# 을 보니 반가움! 에뮬레이터는 언어를 배우기에 좋은 방법이고, 처음 보기엔 작업별로 관용적인 F#과 덜 관용적인 F# 사이를 잘 골라 쓴 것 같음
할당을 줄이는 쉬운 개선점으로는
Instructions.fs의 구별 공용체(discriminated union)에[<Struct>]를 붙이고, 필드 이름을 재사용해 내부 필드를 재사용하게 할 수 있음사소한 지적이지만 일부 레지스터 처리가 헷갈림. 이미
byte타입이라 setter에서a &&& 0xFFuy를 해도member val A = 0uy with get, set보다 추가되는 게 없어 보임. 아마 개발 중에 바뀐 흔적 같음Register소스에 이런 주석이 있음: 레지스터는 쓰기 시 값을 8비트로 잘라야 하므로 레코드 타입이 될 수 없고 setter가 필요하다고 되어 있음웹 렌더러 때문에 그렇고, Fable이 JS에서
uint8을Number로 변환해 8비트를 넘길 수 있으며 잘라내기를 적용하지 않는다는 설명임그래서 웹 대상에서 JS
Number로 넓어지는 Fable 특성 때문에 보수적으로 데이터를 정리하는 코드로 보임드디어 누군가가 무언가를 배우기 위해 실제 인간의 노력을 들였고, “LLM이 X를 Y분 만에 만들게 도와줬다”가 아니라서 좋음
그래도 인류에게 아직 희망이 조금은 있는 듯함
그래도 에뮬레이터는 정말 멋지고, GBA 에뮬레이터는 직접 도전해 보기 좋은 대상임
AGI라는 느낌은 전혀 없었고, 장식이 벗겨진 표절 기계처럼 보였음
언젠가 Microsoft의 누군가가 알아채고 RLHF 경보를 울렸을 테니 GPT는 꽤 나아졌고, F#에도 제법 쓸 만해 보임. 원칙 없는 F# 개발자라면 요즘 에이전트로 잘 해내고 있을지도 모름
하지만 “표절 문제를 해결했으니 이제 잡동사니를 생성하자”가 아니라, “이제 ChatGPT가 표절해도 더는 노골적으로 드러나지 않겠구나”라고 느꼈음
생산성 이득을 얻자고 내 핵심 가치 하나를 완전히 훼손할 확률을 d100이나 d1000으로 굴리고 싶지 않음. 느리고 무직인 채로 지내겠음. 진지하게, 태양광 설치와 폐품 수거 쪽으로 들어가고 있음
“학생들이 생각하고 싶어 하지 않는다”는 문제는 LLM보다 훨씬 오래됨. 2007년에 고학년 편미분방정식 수업을 들었는데, PDE를 진짜 공부하려던 내가 숙제를 거의 다 풀었고, 심리적으로 약해서 못된 게으른 수학 전공자들을 거절하지 못해 거의 모두가 내 숙제를 베꼈음. 대학원 수학 과정에서도 또 그랬음. 정말 믿기 어려움. 그럴 거면 왜 그 과정에 있는 건지 모르겠음
아, F#, 내 가장 큰 사랑. C# 쪽 사람들이 C#을 계속 이것저것 다 되지만 어설픈 언어로 망가뜨리지 말고 이걸 봤으면 좋겠음
C#과 F#을 함께 쓰는 프로젝트를 만들면, C#에 계속 추가되는 것들을 실제로 잘 작동하고 인체공학적으로 얻을 수 있다는 걸 왜 못 보는지 모르겠음. 상호운용성도 훌륭함
F#을 함수형 언어처럼 써도 꽤 멀리 갈 수 있지만, 결국 .NET 생태계와 상호운용하고 싶어지고, 그 순간 이상한 객체지향/함수형 하이브리드 스타일로 코딩하게 됨
F# 은 좋은 언어지만 영원히 C#의 그림자에 갇힌 느낌임. 라이브러리 코드 상당수가 C#과 .NET에서 물려받은 것이고, F#을 염두에 두고 설계된 인터페이스나 라이브러리가 아닌 경우가 많으며, F# 사용법 문서도 명시적으로 없는 일이 흔함
더 큰 문제는 C# 커뮤니티가 객체지향을 좋아해서, 함수형 프로그래밍 방식으로 일하고 싶다면 이런 라이브러리들을 더 “함수형”인 형태로 감싸야 하는 경우가 많다는 점임
그래도 아무것도 없는 것보다는 훨씬 낫다고 봄. Haskell이나 OCaml도 좋아하지만 그런 면에서는 비교가 됨
C# 상호운용성은 F# 코드가 일반적으로 의존하는 보장, 특히 불변성을 느슨하게 만듦. C#으로 매핑되는 방식 때문에 제네릭에서도 의외의 한계가 나타남
정말 멋짐! F#을 좋아하지만, 작은 Smalltalk 인터프리터를 F#으로 써본 결과 이런 종류의 작업에서 의도된 방식대로 쓰면 정확히 속도 괴물은 아니라는 건 확인했음
예를 들어 보통
Map자료구조를 좋아하고, 꽤 훌륭한 불변 구조라 대부분의 용도에는 충분함. 하지만 성능이 중요해지면 일반 해시 맵을 쓰는 지루한 명령형 루프로 들어가는 것도 어렵지 않음모든 걸 함수 하나 안에 가둬두면 대체로 너무 더럽게 짰다는 느낌을 피할 수 있음
심지어 C# 컴파일러도 활용하지 않는 꼬리 호출 개선에도 공을 들였음. .NET 9나 10 즈음에는 F#에 꼬리 호출이 아닌 재귀 호출이 있으면 컴파일러 오류를 내게 하는 특성도 추가돼서, 실수로 망치지 않게 해줌
다만 연결 리스트, 시퀀스, 불변 자료형을 사방에 쓰면 Rust는 절대 아님
멋진 프로젝트임! 이런 걸 보니 정말 좋음
한편으로, 이건 작성자나 작업 자체에 대한 평가는 아니지만 실제 프로젝트에서 F# 코드가 어떻게 보이는지 보고 나니 F#을 배우고 쓰고 싶던 마음은 접어도 되겠다고 느꼈음
순수 함수형 부분은 아름답지만, 더 명령형이거나 변경 가능한 코드로 내려가면 보기 꽤 못생겼다고 느낌. 불행히도 대부분의 실제 프로젝트에서는 결국 그렇게 해야 할 것 같음
그래서 다른 함수형 언어를 골라 뛰어들어야 하는 건지, 아니면 이미 쓰는 언어에 함수형 개념을 적용하는 데 집중해야 하는 건지 모르겠음. 주 언어가 C#이고 함수형 패러다임 지원이 계속 늘고 있어서 후자는 꽤 쉬운 편임
함수형 언어로 작성된 에뮬레이터는 늘 인상적임. 하드웨어를 명령형 언어에 매핑하는 편이 보통 훨씬 쉽기 때문임. 사람들이 어떤 함수형 추상화를 만들어내는지 보는 게 즐거움
F#은 정말 재미있는 언어이고, 멋진 작업임!
F# 은 내가 절대 실무에서는 쓰지 못하는 코딩 사랑의 언어임. 개인 프로젝트 밖에서는 쓸 기회가 없음 :(
흥미롭고 즐거운 글임. 데이터 모델링 부분이 좋았음. OCaml을 조금 만져보고 있는데 그런 식의 모델링이 가장 좋은 부분임
CAMLBOY를 알게 된 것도 흥미로웠음. 작성자에게 피드백하자면, AI 편집 단계는 건너뛰는 편이 좋겠음. 지금처럼 조금 밋밋한 글보다는 문법 오류나 덜 세련된 표현이 있는 쪽을 더 선호했을 것 같음