Prolog, 왜 이렇게 불편할까? 개발자의 솔직한 불만 토로!
Prolog는 표준화된 문자열 부재, 함수 부재, 그리고 리스트 외의 컬렉션 타입 부재 등 여러 단점을 지적받음
부울 값(Boolean Value) 부재로 인해 중간 결과를 저장하는 데 불편함이 있으며, 컷(Cut) 연산자의 사용은 코드의 복잡성을 증가시킴
`bagof` 사용 시 자유 변수(Free Variable) 처리의 어려움과 `sort` 함수의 예상치 못한 동작 등, 언어의 직관적이지 않은 부분에 대한 불만이 제기됨
커뮤니티에서는 이러한 문제점들을 해결하기 위한 다양한 해결책과 대안을 제시하며, Prolog의 개선 가능성을 모색함
Prolog의 비표준 문자열과 컬렉션 타입 부재
Prolog는 표준화된 문자열(Standardized Strings)이 없어, 다양한 구현체 간 호환성이 떨어진다는 비판을 받는다. 특히, ISO 표준 문자열은 원자(Atom) 또는 단일 문자 원자 리스트로 표현되어, 구현체별 커스텀 연산자(Custom String Operators) 사용 시 코드 이식성이 저하된다. 또한, 키-값 맵(Key-Value Maps)이나 구조체(Struct Types)와 같은 컬렉션 타입(Collection Types)의 부재는 데이터 구조 표현의 유연성을 제한한다.
Prolog의 함수 부재와 Bidirectionality
Prolog는 함수(Functions) 부재로 인해, 로직 표현이 규칙(Rule) 기반의 술어(Predicate)에 의존한다. 이는 양방향성(Bidirectionality)을 가능하게 하지만, 복잡한 연산 표현에는 어려움을 야기한다. 예를 들어, 리스트 길이에 1을 더하는 연산을 수행하기 위해서는 별도의 변수를 사용해야 한다. 하지만, Picat과 같은 언어는 함수를 지원하며, 양방향성(Bidirectionality)을 유지하여 이러한 단점을 극복한다.
컷(Cut) 연산자의 혼란스러운 동작
Prolog에서 컷 연산자(!, Cut Operator)는 백트래킹(Backtracking)을 제한하여 성능을 최적화하지만, 코드의 예측 가능성을 저해한다. 특히, 조건문(Conditional Statements)에서 컷 연산자가 사용될 경우, 예상치 못한 결과가 발생할 수 있다. 이러한 문제로 인해, 개발자는 컷 연산자 사용을 회피하거나, 조건부 로직(Conditional Logic)을 복잡하게 구현해야 하는 경우가 발생한다.
bagof와 sort 함수의 예상치 못한 동작
Prolog의 `bagof` 함수는 쿼리 결과를 한 번에 얻기 위해 사용되지만, 자유 변수(Free Variable) 처리 방식 때문에 예상치 못한 결과를 반환할 수 있다. 또한, `sort` 함수는 중복을 제거한 정렬된 집합을 반환하여, 정렬된 리스트(Sorted List)를 기대하는 개발자에게 혼란을 야기한다. 이러한 언어의 비직관적인 동작은 Prolog 학습 및 사용의 어려움을 증가시킨다.
