하스켈은 지극히 표준적인 컴퓨터 과학 이론에 기반한거고 하스켈에서 needle같은거 쓰는애들이 힙스터겠지
타입이 빡빡하고 번거로우니 현업에선 쓰이지 않는게 맞지. 하지만 lazy스택, lazy파이프 문제는 haskell로 쉽고 깔끔하게 코드가 나오는데 다른 언어로 짜려면 개삽질에 번거롭기 그지 없음.
타입이 빡빡한게 오히려 현업에 좋은데;; 실제로 페북도 프로덕션 코드에 하스켈 쓴다 - dc App
MS에 따르면, 비록 타입스크립트 만든 곳이라 완전히 신뢰할 수는 없다 해도, 정적 타입을 통해 10% 이상 에러를 줄일 수 있다고 함 하스켈을 못 쓰는 건 개발자 구하기가 힘들어서가 클 듯
커헉 - 타입이 빡빡한걸 넘어서 번거로움이 느껴지면 좋다는걸 알아도 안쓰게 됨. 페북이 이미지 압축이나 스팸 필터링 하는데 haskell 잘쓰고 있지만 그렇다고 해서 컨퍼런스에서 개발자를 구해도 못구할 정도면 사용성에 대한 개발자들의 공감대가 어느정도인지 결론난거 아니냐
슬피우는문과 - 정적 타입이 에러 줄이는 것과 상관없다. github통계만 봐도 그렇지. 다만 javascript가 워낙 엿같다 보니 타입스크립트를 쓰는 것 만으로 가장 잦은 에러인 레퍼런스나 null 잡아서 에러 줄여주는건 맞음.
타입과 에러가 상관 없다고 주장하시면 논문부터 쓰셔야될 것 같은데;; 언어학계의 오랜 상식을 그렇게 부정하시니 - dc App
하스켈은 지극히 표준적인 컴퓨터 과학 이론에 기반한거고 하스켈에서 needle같은거 쓰는애들이 힙스터겠지
타입이 빡빡하고 번거로우니 현업에선 쓰이지 않는게 맞지. 하지만 lazy스택, lazy파이프 문제는 haskell로 쉽고 깔끔하게 코드가 나오는데 다른 언어로 짜려면 개삽질에 번거롭기 그지 없음.
타입이 빡빡한게 오히려 현업에 좋은데;; 실제로 페북도 프로덕션 코드에 하스켈 쓴다 - dc App
MS에 따르면, 비록 타입스크립트 만든 곳이라 완전히 신뢰할 수는 없다 해도, 정적 타입을 통해 10% 이상 에러를 줄일 수 있다고 함 하스켈을 못 쓰는 건 개발자 구하기가 힘들어서가 클 듯
커헉 - 타입이 빡빡한걸 넘어서 번거로움이 느껴지면 좋다는걸 알아도 안쓰게 됨. 페북이 이미지 압축이나 스팸 필터링 하는데 haskell 잘쓰고 있지만 그렇다고 해서 컨퍼런스에서 개발자를 구해도 못구할 정도면 사용성에 대한 개발자들의 공감대가 어느정도인지 결론난거 아니냐
슬피우는문과 - 정적 타입이 에러 줄이는 것과 상관없다. github통계만 봐도 그렇지. 다만 javascript가 워낙 엿같다 보니 타입스크립트를 쓰는 것 만으로 가장 잦은 에러인 레퍼런스나 null 잡아서 에러 줄여주는건 맞음.
타입과 에러가 상관 없다고 주장하시면 논문부터 쓰셔야될 것 같은데;; 언어학계의 오랜 상식을 그렇게 부정하시니 - dc App