AI시대가 도래하면서 바이브코딩이란것이 생겼습니다.
사람이 "이러저러한 것을 만들테니 코드를 내놔라"라고 AI한테 명령을 내리면 거기에 맞는 코드를 AI가 써오는겁니다. 사람은 AI가 써온걸 검토해서 적용하면 되는것이고요.

그런데 이거 좀 골치아픕니다.
AI가 짜온걸 무지성으로 쑤셔넣으면 스파게티되는게 너무 당연해지거든요. 사실 AI가 해주는건 스파게티화를 막아주고 정리를 통해 사람이 이후에 정리된 코드를 쓰는게 목적인건데 이놈의 깡통은 코드를 어디서 가져오는건지 자꾸 변수를 복잡하게 꼬아버립니다.
특히 e p a 등 알파벳 한글자 변수를 어디서 자꾸 들고오는데 이걸 일일이 알아먹기 편한 변수로 고치려하니 골때립니다.

반대로 알고리즘자체는 훌륭하게 구현해줍니다. 문제는 이걸 다른 코드와 조화롭게 써준거냐 하면 역시 멋대로 적어놓은 변수와 함수이름으로 일관적이지 않은 요상한 코드로 도배됩니다.

C코드만 해도 중괄호를 K&R로 했다가 다른걸로 했다가 스페이스바를 2개를 썼다가 4개를 썼다가 중구난방입니다.

물론 들여쓰기랑 중괄호를 고치라고하면 고쳐서 가져오기도 합니다. 그런데 이건 코딩의 원칙을 지키려하니까 이게 가능한거지 일반적으로 무지성코딩하는 사람들은 이렇게 AI한테 한마디 더 해서 지키려들까 싶습니다.

처음부터 끝까지 AI한테 싹다 맡기면 일관적이고 깔끔한 코드가 나오긴합니다. 대신 이러면 검토하기 더럽게 힘듭니다. 게다가 이건 말이 안 되는게 프로그램이란건 계속 수정에 수정을 거듭해야하는데 AI에게 수정하라고 하면 또 제멋대로의 규칙과 제멋대로의 방식으로 수정을 해서 코드를 꼬아버리거든요.

코딩규칙을 엄하게 따지는 프로젝트에서 이 짓하면 욕먹는 수준이 아니라 다시는 코드를 안 받아줄겁니다. 하지만 욕을 먹어도 AI는 또 잊어버리고 또 요상하게 짜옵니다.

이렇게 해도 잘 구동되면 다행입니다.

최근에 자꾸 요상한버그가 있어서 뭔가 했더니 AI가 같은 기능을 중복으로 써줬더군요. 기능 충돌이 일어나니 엉뚱한일이 생기는 겁니다. 결국 사람이 손을보고 최적화해서 다시 적용해야했고 그냥 맨땅에 처리하는것과 비슷한 시간이 걸려버렸습니다.

AI를 활용한 코딩에대해 뭔가 편하면서도 회의감이 일어나는건 아직 발전하고 있는 분야라서 그런걸까요

,

사실 debian unstable은 불안정이라는 이름이 들어있을 정도로 불안정한 버전입니다.

하지만 사실 우분투 데스크탑도 unstable버전에서 가져올 정도로 그렇게 불안정한 버전은 아닙니다.

뭔가 이상하죠??

불안정하다고 하는데 또 불안정한 것은 아니라니

그것이 사실 Debian의 엄격한 심사때문입니다.

Debian의 안정버전은 총 4번의 테스트를 겪습니다.

Experiment(실험적)
Unstable(흔히 Sid라는 코드를 더 많이 씁니다)
Testing
Stable(현재 릴리즈판)

unstable이라고 해도 한번은 시험을 하고 들어가다보니 어느정도 거르고 지나간다는 의미입니다. 하지만 서버에서 주로 쓰이는 OS특성상 1번은 부족하다는 의미입니다.

물론 실사용을 못 할 정도는 아닙니다 Windows의 Insider Preview수준은 됩니다.

최근 업데이트를 묵히고 있다가 Sid의 업데이트를 한번 쭉 했습니다. 그런데 로그온이 안되는 문제가 생겼습니다. lightdm이 꼬인건지 어디가 꼬인건지...

그런데 Ctrl+Alt+F1로 콘솔모드로 가니 로그온이 됩니다.
그래서 거기서 startx를 하니 또 문제없이 데스크탑이 켜집니다. 대체 어디서 꼬인건지 감도 안 옵니다.

그래서 lightdm을 지우고 설정을 싹 지우고 다시 설치합니다.

안 됩니다.

결국 하다하다 그냥 Stable버전으로 포맷후 재설치 결정.

다만 home파티션을 분리해두었고 요즘은 Flatpak이 대세라 대부분은 home에 설치되다보니 프로그램 설치는 문제가 없어서 그냥 시스템만 갈았습니다. 기존에 쓰던 xfce4로 그대로 설치하니 원래 쓰던 모습 그대로 뜹니다.

다만 kime가 난리납니다. rustc를 설치하고 컴파일했는데 이번엔 rustc버전이 낮다고 합니다. 그동안 sid여서 문제없이 잘 썼다보니 kime에 rust버전 제한이 있는지 몰랐네요.

backports저장소에서 rustc를 끌고옵니다. 또 뭔가 골치아프게 안됩니다. QT가 이번에 문제를 일으킵니다. 다시 sid로 올려버릴까 싶은데 아까의 기억이 또 떠오릅니다.

그냥 기존 QT프로그램을 버렸습니다.

이쯤되니 그냥 조용히 Stable이나 써야겠습니다.

,

사실 Lua의 존재는 그 전부터 알고 있긴했습니다만 실질적으로 쓴적은 없었습니다.

그도 그럴게 제 주력은 Python이었고 속도에 그리 크게 신경쓸 필요는 없는 프로젝트 뿐이었거든요. Python은 라이브러리가 방대해서 Lua에서 할 수 있는것은 속도를 감안해서 충분히 가능했고 Lua는 Numpy를 쓸 수가 없으니 그냥 한쪽에 처박아두고 있었습니다.

최근에 Lua를 찾아보게 된 계기는 그냥 어쩌다보니 였습니다.

취미로 이것저것 건들고 있는데 love2D라는 게임엔진이 있더군요. 2D게임 엔진인데 사용언어가 Lua였습니다. Pygame도 써봤고 (특히 RenPy) GameMaker도 써봤지만 이건 또 이것대로 특이하더군요.

결론부터 말하면 Pygame 못지않게 아주 좋습니다. 그리고 2D게임 특성상 속도문제는 크게 없습니다만 탄막게임같이 스프라이트가 미친듯이 많을 경우에도 라즈베리파이같은 곳에서도 잘 돌아갈정도로 Pygame보다 연산속도가 우월합니다.

다만 특이한게 Python의 List같은 Table을 쓰는데 인덱스가 1부터 시작합니다. 그 외에 몇가지 특이한게 더 있고요. (;를 써도 되고 안 써도 되고 이것도 특이함)

원래 Lua가 쓰이는 곳은 C언어 프로그램에 내장되서 쓰이는게 보통이라고 하더군요. 마치 Excel에 VBA내장된것처럼요. Blender나 Gimp에 Python이 내장되는것도 마찬가지입니다.

하지만 Lua그 자체만으로도 뭔가 상당히 훌륭한건 맞는거 같습니다. 작고 빠르다 이거 하나만으로도 훌륭한 장점이니까요.

다만... Lua5.1과 Lua5.2이후간 파편화가 생기면서 좀 골치아파진거 같습니다. love2D만 해도 Lua5.1만 지원하는데 반해 MicroLua(RP2040용 Lua)는 5.4를 기준으로 하는데 문법이 판이 합니다.
Lua5.1이 워낙 완성도가 높았고 LuaJIT라는 굉장히 빠른 인터프리터가 여기까지만 지원하기 때문이라고 합니다.

98년에 나왔던 VisualStudio 6.0이 2010년 초기까지 줄기차게 쓰이던 느낌이랑 비슷하네요. 이쪽도 6.0의 완성도가 높기도 하고 이후 버전이 6.0버전에 비해 느려서 찾는 사람이 그다지 없었던게 한몫했지요. 보통 구형 컴파일러로 만들면 최신컴퓨터에서 느려지는 문제가 있지만 이 문제는 컴퓨터 그 자체의 속도가 빨라지면서 크게 신경쓸 필요가 없어진것도 있고요.

VisualStudio 6.0이 사라지게 된게 WinXP가 사라지면서 환경이 바뀌었기 때문인데 Lua는 좀 다르죠. 이쪽은 기존 프로그램에 내장되는 형태가 주류라 못 쓰게 될 일이 드뭅니다. 덕분에 5.1과 5.4를 같이 배워야하는 참사가...

비슷한걸로는 Python 2.7도 있겠네요. 역시 10년동안 줄기차게 쓰이다가 Python 3.6때부터 비로소 사장된걸로 압니다. 그런데 이쪽은 Py2to3같은 라이브러리까지 제공했고 그 외에도 많은 유인책이 많았기에 가능했다고 봅니다. (특히 한글문제가 전혀없던것이 저에겐 가장 컸습니다)

암튼 그래서 서점가서 Lua책을 한권 샀는데 5.1이군요. 저도 5.1에 눌러앉아서 좀 더 써봐야 할거 같습니다.

,