R vs SAS, tại sao SAS được các công ty tư nhân ưa thích?

Tôi đã học R nhưng có vẻ như các công ty quan tâm nhiều hơn đến trải nghiệm của SAS. Những lợi thế của SAS so với R là gì?

Tôi nghĩ rằng có một số vấn đề (theo thứ tự tăng dần về tính hợp lệ có thể):

1. Truyền thống / thói quen : mọi người đã quen với SAS và không muốn phải học cái gì đó mới. (Làm cho nó trở nên khó khăn hơn, cách bạn nghĩ trong SAS và R là khác nhau.) Điều này có thể áp dụng cho bất kỳ ai có thể phải gửi mã cho bạn, hoặc đọc / sử dụng mã của bạn, bao gồm cả người quản lý và đồng nghiệp.
2. Không tin tưởng vào phần mềm miễn phí : Tôi đã có một số người nói rằng họ không sẵn sàng chấp nhận kết quả từ R vì bạn không có một công ty vì lợi nhuận kiểm tra mã để đảm bảo nó mang lại kết quả chính xác trước khi đưa ra cho khách hàng, vì sợ họ cuối cùng mất kinh doanh.
3. Dữ liệu lớn : R thực hiện các hoạt động với mọi thứ trong bộ nhớ, trong khi đó, SAS không nhất thiết phải như vậy. Do đó, nếu dữ liệu của bạn đạt đến giới hạn của bộ nhớ, sẽ có vấn đề.

Cá nhân, tôi chỉ nghĩ rằng # 3 có bất kỳ giá trị hợp pháp nào, mặc dù có những cách tiếp cận dữ liệu lớn đã được phát triển với R. Các vấn đề với # 1 nói lên chính họ. Tôi nghĩ rằng # 2 bỏ qua một số sự thật: có một số thử nghiệm xảy ra với R, nhiều gói chính được viết bởi một số tên lớn nhất trong thống kê và đã có nghiên cứu so sánh độ chính xác của các phần mềm thống kê khác nhau & R chắc chắn đã cạnh tranh.

Ngoài những câu trả lời hay cho đến nay, tôi còn thêm yếu tố bối rối. Nếu bạn chi hàng trăm ngàn đô la vào năm ngoái cho hỗ trợ của SAS và SAS và bạn đề xuất không chi tiêu gì cho R, với giá hỗ trợ cực kỳ thấp (Cách mạng, v.v.), một người nào đó trong chuỗi sẽ hỏi tại sao. Có phải là một sai lầm khi chi rất nhiều tiền vào năm ngoái khi R tồn tại năm ngoái? Hoặc là một sai lầm khi bỏ phần mềm chuyên nghiệp cho một cái gì đó được tạo ra bởi một nhóm tình nguyện viên?

Một khi vấn đề được đóng khung theo cách đó, đó là một đề xuất thua lỗ, vì vậy có lẽ tốt hơn là không đưa nó lên.

Trên hết những gì gung đã xác định chính xác ở đây, vấn đề lớn nhất trong thế giới doanh nghiệp là di sản. Và khi bạn có một mã sản xuất chất lượng tốt được biết là thực hiện công việc, bạn không thay đổi nó. SAS đã ra khỏi đó từ những năm 1970, và tại thời điểm đó, nó là ngôn ngữ thống kê duy nhất có hiệu quả, theo tiêu chuẩn. Số lượng mã sản xuất được tích lũy kể từ đó trong SAS trong dược phẩm và chính phủ là không thể tưởng tượng được, hàng chục nghìn năm của con người. Viết lại điều này trong R hoặc Stata sẽ mất vài năm, mã kết quả sẽ trở nên linh hoạt hơn, hiệu quả hơn, minh bạch hơn, dễ bảo trì hơn và rẻ hơn, nhưng không ai sẽ trả tiền cho việc tái cấu trúc như vậy. (Kinh nghiệm của tôi khi làm điều này là mã Stata của tôi thường ngắn hơn khoảng ba lần; tôi đã từng có một dự án chuyển đổi mã SPSS thành Stata nơi tôi đã làm cho nó ngắn hơn khoảng 20 lần.

Theo một nghĩa nào đó, đây là một câu chuyện tương tự với các nhà xuất bản hàn lâm: họ đang thúc đẩy người dùng cuối duy trì đăng ký của họ không cần thiết; một trường đại học không đăng ký vào tự nhiên không thực sự là một trường đại học. Xuất bản miễn phí thông qua các xã hội chuyên nghiệp sẽ làm cho nó rẻ hơn, mọi người chuẩn bị bài đăng của mình trong LaTeX những ngày này, vì vậy họ sẵn sàng cho máy ảnh, và những người tương tự sẽ cung cấp đánh giá ngang hàng, do đó sẽ không có sự thụt lùi về chất lượng trên bất kỳ kích thước nào. Nhưng ... không có tên thương hiệu và yếu tố tác động đằng sau các tạp chí trực tuyến.

Điều này tổng hợp tất cả lên: http://scatter.wordpress.com/2011/06/28/stata-12/ . Stata được ưa thích trong giới kinh tế và các nhóm liên quan đến chính sách, và càng tìm hiểu về SAS, tôi càng thích Stata.

Tôi đã làm việc hiệu quả như một lập trình viên SAS trong bảy năm qua, bên cạnh tôi, một đồng nghiệp đã lập trình SAS lâu hơn tôi còn sống. Như đã lưu ý ở đây, có một lượng lớn quán tính / di sản đằng sau SAS; nhưng SAS giống như R là một cách để một phương tiện, không phải là phương tiện.

SAS cực kỳ hiệu quả trong việc truy cập dữ liệu tuần tự và truy cập cơ sở dữ liệu thông qua SQL được tích hợp cực kỳ tốt. PROC là tài liệu rất tốt, nhưng tiếc là không hoàn toàn được chuẩn hóa bằng ký hiệu (PROC OPTMODEL và IML là hai ví dụ). Đó là một chút vụng về khi viết mã phức tạp, và không thanh lịch cho mã song song. Đôi khi tôi cũng thấy việc nhập các tệp csv trở thành một nguồn đau khổ lớn và thích chỉ đổ nó vào R trước sau đó đến cơ sở dữ liệu.

Mặc dù SAS có giao diện với các đối tượng được chia sẻ và bạn sẽ không có quyền truy cập tốt vào bất kỳ tệp tiêu đề hoặc bất cứ thứ gì tương tự, và phân phối mã cũng không có sẵn thông qua các gói hạnh phúc.

Tuy nhiên, có một chút lo ngại về ai đó bao gồm một số gói bí mật hiện tại hoặc bị hỏng trong mã của bạn mà bạn cần duy trì và chất lượng mã trong SAS có xu hướng tuyệt vời đồng đều (mã lõi R cũng rất tuyệt vời và cũng tự do có sẵn cho bất cứ ai).

Như đã đề cập trước đây, SAS cũng cực kỳ đắt đỏ, nhưng nó là một công cụ tốt mà tôi tìm đến khi tôi biết có một quy trình đóng hộp hoạt động tốt cho nhu cầu của tôi.

R + SAS + mysql với một chút perl để dán chúng lại với nhau hoạt động tuyệt vời :)

Vì vậy, tôi sử dụng cả R và SAS - thừa nhận trong giới hàn lâm - nhưng có một vài lý do khiến tôi có xu hướng hướng về phía SAS:

1. Tài liệu tốt hơn. R đang trở nên tốt hơn về điều này, nhưng tài liệu, đặc biệt là tài liệu chính thức, thường là loại khủng khiếp và mờ đục. Ngoài ra, SAS được hỗ trợ bởi một cơ sở hạ tầng sách khổng lồ - sử dụng R! loạt đang giúp điều này trong R, nhưng nó chưa hoàn toàn ở đó. Tôi có thể chuyển sang Phân tích sinh tồn của Paul Allison bằng cách sử dụng SAS hoặc Phân tích dữ liệu phân loại bằng cách sử dụng SAS hoặc cuốn sách tôi có về phương pháp Monte Carlo bằng cách sử dụng SAS và tôi có một cuốn sách được viết rõ ràng theo phong cách khá phù hợp với ngôn ngữ tôi đang sử dụng.
2. Quán tính. Đây không chỉ là "các công ty lười biếng" - quán tính cũng có giá trị. Có kiến ​​thức thể chế. Cái gì đó cũng có mã làm điều đó - và làm nó tốt.
3. Gói. Một số gói trong R là tuyệt vời. Một số gói thì không. Bạn phải đi tìm chúng, đánh giá chúng, và thậm chí sau đó có một số vấn đề về niềm tin trong đó gói đó chỉ tốt như anh chàng viết nó. Thật khó tin điều đó. Về cơ bản, SAS có "niềm tin và tín dụng đầy đủ của Viện SAS", có một hồ sơ theo dõi khá vững chắc.
4. Hỗ trợ nguồn đơn. Nếu SAS bị hỏng, bạn gọi cho SAS. Nếu R bị hỏng bạn gọi ....?

Không ai đã đề xuất lý do nó được ưa thích là ngu ngốc đơn giản. Đây là hai trích dẫn tôi mới bắt gặp:

"Sử dụng phần mềm nguồn mở như R là không cần thiết - chúng tôi không thể đảm bảo một kết quả hoàn toàn có thể lặp lại"

và

"Chúng tôi sẽ không thể cung cấp bất kỳ hỗ trợ nào cho việc này vì đây là phần mềm nguồn mở"

Hai phút với những người này sẽ cho họ thấy họ đã sai như thế nào.

Một vấn đề dường như không được giải quyết rõ ràng: che mông. Nếu bạn đi với SAS và mọi thứ nổ tung, người ra quyết định luôn có thể nói rằng anh ta đã mua phần mềm hiện đại, và làm thế nào để anh ta biết nó sẽ bị hỏng? Nếu anh quyết định đi với R, cuộc tranh luận này sẽ khó thực hiện hơn. Vâng, điều này có liên quan đến đối số quán tính đã được đề cập ở đây.

Vài thập kỷ trước, họ từng nói rằng "noboby từng bị sa thải vì mua IBM" , được gọi là cụm từ tiếp thị vĩ đại nhất từ ​​trước đến nay.

Là người dùng của cả SAS và R, tôi muốn nói lý do lớn nhất chúng tôi sử dụng SAS so với R (khi chúng tôi làm) là khả năng xử lý tuần tự. Chúng tôi chỉ cần các máy có RAM không quá 4GB để xử lý dữ liệu trong 15 năm. Tôi sẽ cần một cỗ máy lớn hơn nhiều bằng cách sử dụng stock R và tôi đã không cố di chuyển mã SAS để chạy với Revolution R.

đã đến lúc để họ thay đổi

Kể từ năm 2015, các chuyên gia tính toán dưới 35 tuổi thích sử dụng R - sách văn bản sử dụng cả mã R và SAS. Các chuyên gia tính toán cũ không bao giờ học cách sử dụng R và thích SAS và không sử dụng R. Tỷ lệ các chuyên gia tính toán thực sự mã hóa trong SAS sẽ giảm.

Nếu bạn tìm kiếm học giả Google cho các bài báo đề cập đến SAS - thì bạn sẽ tìm thấy một ấn phẩm 550-ish ổn định mỗi năm trong vài năm qua. Nếu bạn tìm kiếm các bài báo bằng R ("Nền tảng R cho máy tính thống kê"), đã có 25.100 vào năm 2014 và đến giữa tháng 7 năm 2015 có 16.700. Vẽ tỷ lệ - nó đang tăng rất nhanh!

SAS đã không tự giúp mình trong một vài năm bằng cách yêu cầu phí giấy phép lớn từ các trường đại học - điều mà họ đã đảo ngược - nhưng giờ đã quá muộn, nhiều trường đại học đã chuyển đổi sang giảng dạy bằng R chứ không phải SAS.

Các kỹ thuật thống kê mới được công bố trong các bài báo kết hợp với gói R. Một số kỹ thuật đã ở cơ sở R trong nhiều năm vẫn chưa xuất hiện trong SAS. Bây giờ bạn có thể sử dụng R từ bên trong SAS.

Tóm lại, mọi thứ đang thay đổi và thay đổi nhanh chóng.

Trong ngành công nghiệp dược phẩm, SAS được sử dụng vì đó là những gì FDA sử dụng và thích. Có một số lý do nghiêm trọng mặc dù. Kết quả có thể truy nguyên và đầu ra có dấu thời gian. Thống kê của FDA có thể kiểm tra những gì bạn nhận được. Nó rất tốt cho việc quản lý cơ sở dữ liệu và nó là phần mềm đáng tin cậy. Tất nhiên, nhiều thuộc tính của SAS có thể được tranh luận là có mặt trong các gói phần mềm khác bao gồm R và SAS là đắt tiền. Tuy nhiên, tôi nghĩ rằng bất cứ ai muốn trở thành một nhà thống kê ứng dụng làm việc trong ngành công nghiệp sẽ tốt nhất là học cách lập trình trong SAS. Sử dụng R hoặc STATA nếu bạn thích nhưng biết SAS. Khi bạn làm việc cho một công ty muốn bạn sử dụng SAS, họ sẽ trả tiền cho việc cấp phép.

Tôi nghĩ rằng trích dẫn này của Anne H. Milley tổng hợp theo cách rất nhiều người cảm nhận về R:

Chúng tôi có những khách hàng chế tạo động cơ cho máy bay. Tôi rất vui khi họ không sử dụng phần mềm miễn phí khi tôi lên máy bay.

Thật không may, tôi nghĩ quan niệm sai lầm này (miễn phí == kém hơn) là phổ biến trong công chúng.

(hơi lạc đề): xem nó ở điểm khác: một số lợi thế mà R có trong học viện không áp dụng cho ngành công nghiệp.

Ví dụ, trong học viện, đó là một lợi thế rõ ràng nếu bạn có thể bảo các sinh viên đi lấy phần mềm và làm việc tại nhà. Trong công nghiệp, bạn thường không cần mang theo bất kỳ dữ liệu nào về nhà ...

Bạn cũng không nên thử một vài thứ (TM), tải xuống hàng tấn gói (ngay cả khi có uy tín & đã thử nghiệm), sử dụng các phương pháp tiên tiến. Thay vào đó, bạn thường được dự kiến ​​sẽ sử dụng các phương thức & mã đã được sử dụng trong nhiều năm và nơi hành vi được biết đến từ lâu. Bạn sẽ không giành được nhiều thành tích học tập với điều đó.

Và tất nhiên, như đã được đề cập: không ai sẽ mạo hiểm làm lại tất cả các loại phê duyệt theo quy định vì mục đích chuyển sang R. Từ những gì tôi thấy ít hơn về R và nhiều hơn về chi phí khổng lồ + làm việc để có được sự chấp thuận theo quy định .

Mặc dù khá bi quan, câu trả lời của tôi là loại người đưa ra quyết định sâu rộng trong các tập đoàn như 'chúng tôi chỉ sử dụng SAS' cũng là loại người không tin những gì họ không hiểu và tự động nghĩ về giá trị của một cái gì đó tỷ lệ thuận với số tiền bạn chi cho nó. Điều này dẫn đến việc họ thích trả tiền cho SAS hơn là dành thời gian điều tra các lựa chọn thay thế.

Tại sao một công ty dược phẩm lớn thậm chí muốn chuyển đổi sang R từ SAS? SAS chi phí hàng triệu nhưng nó không là gì đối với một công ty dược phẩm. Tuy nhiên, chuyển đổi tất cả các hệ thống báo cáo ổn định từ SAS sang R sẽ tốn gấp 50 - 100 lần.

SAS có hệ thống hỗ trợ phi thường: mỗi khi tôi cần sự giúp đỡ, họ có thể cung cấp nó trong vòng vài giờ.

Và chính xác thì R có gì mà SAS không: 1) đồ họa tốt hơn ... ok, nó là một thứ lớn nhưng đồ họa không phải là tất cả. bên cạnh R luôn có thể được sử dụng một công cụ bổ sung để tạo một số biểu đồ thú vị và SAS không quá tệ khi nói đến đồ họa 2) ngôn ngữ lập trình hiện đại và hiệu quả hơn. Nhiều người dùng SAS không phải là lập trình viên và không quan tâm đến việc sử dụng ngôn ngữ hay. Họ chỉ muốn có thể phân tích dữ liệu.

Tôi yêu R nhưng sẽ thật điên rồ khi một công ty lớn chuyển đổi sang SAS. Nó có thể có ý nghĩa đối với các công ty nhỏ hơn mặc dù

Có một số ưu điểm chính, không theo thứ tự cụ thể

• SAS có một cơ sở được cài đặt lớn và một hồ sơ theo dõi dài

Tôi cố tình tránh sử dụng các thuật ngữ sai lầm như "di sản" hoặc "thói quen" Nhiều công ty đã sử dụng SAS trong 30 hoặc 40 năm và họ có hàng triệu dòng mã làm việc. Ngoài ra, có tất cả các lợi ích của một cơ sở mã ổn định với hàng triệu ngày người dùng trong một khu vực nơi các lỗi nhỏ có thể nghiêm trọng. Đây là cùng một lý do mà hương vị Unix vẫn còn phổ biến mặc dù Unix đã hơn 40 tuổi và lỗi thời theo một số cách. Cuối cùng, có một cộng đồng lớn gồm các chuyên gia có kinh nghiệm của SAS, những người được sử dụng để giải quyết các vấn đề kinh doanh

• SAS rất phù hợp với môi trường hoạt động và dữ liệu phức tạp, không đồng nhất

Các công ty có rất nhiều nguồn dữ liệu khác nhau, dựa trên các loại hệ thống khác nhau, cũng như trong nhiều trường hợp, nhiều môi trường hoạt động. R chỉ mới gần đây đã nhận được một số khả năng cực kỳ cơ bản để đối phó với nhiều hơn mức có thể được giữ trong bộ nhớ. So sánh điều này với khả năng của SAS để hỗ trợ xử lý cơ sở dữ liệu gốc, tối ưu hóa, cơ sở dữ liệu cho terradata, chỉ trích dẫn một ví dụ. Trong hầu hết các tình huống trong thế giới thực, phần khó nhất của phân tích là xử lý dữ liệu và môi trường vận hành. (cần chạy mã chấm điểm mô hình phát triển Windows của bạn trên máy tính lớn? Với SAS, không có vấn đề gì. Với R, bạn không gặp may.) R không giải quyết được bất kỳ vấn đề nào.

• Người dùng không phải lo lắng về việc "tự mình"

Một người dùng SAS có thể chắc chắn một cách hợp lý rằng mọi mô-đun mã đã được kiểm tra bởi những người có trình độ. Không cần thiết phải dành thời gian và nỗ lực để tìm hiểu nguồn gốc của mã, hoặc xác nhận độc lập nó. Hơn nữa, nếu gặp phải bất kỳ vấn đề nào, hỗ trợ mạnh mẽ (từ thứ cơ bản như tài liệu đến thứ gì đó toàn diện như khám phá chi tiết kết quả hoặc hành vi bất ngờ của một phương pháp tinh vi), người dùng có thể nhấc điện thoại và nhận trợ giúp.

• Nó "đủ tốt"

Ngôn ngữ tắt một số người vì nó khác với ngôn ngữ hiện đại cho lập trình chung. Phải nói rằng, ngôn ngữ là trình độ cao, mạnh mẽ, biểu cảm và toàn diện. Nói tóm lại, một khi bạn học nó, nó sẽ hoàn thành công việc. Đối với các công ty, sự thanh lịch của giải pháp không phải là một điểm bán hàng.

Hỗ trợ khách hàng.

Tôi đã có một cuộc trò chuyện với một người bạn làm việc trong một công ty chuyên cài đặt máy chủ và sau đó anh ấy giải thích cho tôi tại sao các công ty lớn luôn lựa chọn các sản phẩm của Microsoft chứ không phải là nguồn mở. Lợi thế của Microsoft so với các đối thủ cạnh tranh nguồn mở là hỗ trợ khách hàng. Nếu có vấn đề với sản phẩm, công ty có thể gọi cho Microsoft, các công ty lớn thậm chí còn hỗ trợ cá nhân hóa cho họ. Không phải như vậy với phần mềm nguồn mở.

Tôi nghĩ đó là lý do chính xác tương tự như SAS đang được ưu tiên hơn R.

Thế còn Frontends? Tương đương của R đối với Hướng dẫn doanh nghiệp của SAS, Studio báo cáo web hoặc Công cụ khai thác doanh nghiệp là gì? Chỉnh sửa: Những công cụ này giúp Người dùng không lập trình có thể sử dụng KHOẢN DỮ LIỆU mà không cần biết về công nghệ cơ bản. Chúng không phải là công cụ chủ yếu để sử dụng SAS như vậy. GUI của R chỉ là IDE dành cho ngôn ngữ / hệ thống R, AFAIK. Họ không thể cung cấp trợ giúp cho người dùng không có kỹ thuật muốn tìm hiểu thông tin & cái nhìn sâu sắc từ DWH.

Tôi đã từng làm việc cho một công ty tư vấn đã hỗ trợ SAS cho một nhà sản xuất chip lớn ở Thung lũng Silicon. Người liên hệ của chúng tôi tại công ty nói với chúng tôi rằng anh ấy đã nhận được lời đề nghị của một công ty khác để cung cấp cho họ cùng một lời khuyên, bằng cách sử dụng một phần mềm khác bao gồm tất cả các khu vực được bảo hiểm bởi SAS và sẽ khiến công ty phải trả một phần cho những gì mà SAS đang tính phí cho họ ( 30.000 đô la so với 1.000.000 đô la ). Người liên lạc đã cân nhắc những việc cần làm và quyết định không thông báo cho ông chủ của mình về lời đề nghị này vì ông sợ bị đuổi việc vì sử dụng SAS ngay từ đầu và không xem xét các lựa chọn thay thế rẻ hơn. Thay vào đó, ông nhấn mạnh rằng công ty tư vấn của chúng tôi cung cấp cho công ty của họ một khoản tiền lớn trong phí tư vấn của chúng tôi. Công ty chúng tôi đồng ý.

Tôi không nghĩ rằng bảo mật ứng dụng đã được đề cập. Câu hỏi này đã được nêu ra trong Stack Overflow nhưng đã bỏ vì nó không có chủ đề.

Tôi hợp tác với Ủy ban Y tế và Phúc lợi Quốc gia Thụy Điển sử dụng SAS. Khi tôi nói chuyện với các nhà thống kê của họ (giống như R), họ cho rằng những người làm CNTT của họ thích SAS vì họ không tin tưởng các gói được tải xuống trong R. Vợ tôi cũng làm việc ở SAS và tổ chức của cô ấy thường yêu cầu vấn đề tương tự ...

Tôi rất thích xem một số ý kiến ​​về vấn đề này. Tôi đã thực hiện một tìm kiếm nhanh nhưng không tìm thấy bất kỳ tài liệu tham khảo tốt nào ...

Lý do tôi hiểu là có sức thuyết phục nhất là vì SAS có một thư viện rộng lớn gồm các mô-đun cụ thể cho doanh nghiệp theo chiều dọc mà mọi người trong các ngành dọc này đều sử dụng, do đó, nó có phần bị khóa.
Nhưng cũng là lúc đó, SAS đã giải quyết nhu cầu của các phân khúc dọc này trong kinh doanh và được tối ưu hóa theo nhu cầu của họ - được tối ưu hóa theo nghĩa "người dùng không phải làm thêm nhiều việc để có kết quả". Tôi không phải là người dùng SAS, vì vậy điều này không có nghĩa là sự bảo vệ thiên vị cho chiến lược kinh doanh của SAS.

Là sản phẩm thương mại lớn mà SAS đang có, có một nỗ lực mạnh mẽ và phối hợp bằng cách trả tiền cho nhân viên bán hàng để quảng bá nó. Tôi không nghĩ rằng những nỗ lực thúc đẩy việc sử dụng R có thể phù hợp với những điều này.

Tôi nhìn vào Nguồn mở hoặc phần mềm được cấp phép như thế này, có thể là SAS hoặc bất cứ thứ gì khác. Bộ phận CNTT của tôi có mặt để cung cấp dịch vụ cho doanh nghiệp của chúng tôi. Công ty không kiếm được tiền từ CNTT, chỉ từ hỗ trợ CNTT kinh doanh. Doanh nghiệp có doanh thu hàng năm là 16 tỷ đô la. Chi phí CNTT khoảng $ 200 triệu mỗi năm. Nếu tiền là vấn đề tôi sẽ cắt giảm chi phí, nhưng nếu tôi tiết kiệm 10% ( $ 20 triệu) của ngân sách của tôi, sẽ thông báo doanh nghiệp? Họ sẽ chỉ giảm ngân sách của tôi vào năm tới? Nếu CNTT thất bại, doanh nghiệp sẽ mất doanh thu, bản chất của sự thất bại sẽ thay đổi bao nhiêu. Các bộ phận của doanh nghiệp có thể không còn kiếm được doanh thu. Nếu một sản phẩm như SAS thất bại, tôi có thể kiện theo hợp đồng. Nếu một sản phẩm OSS thất bại, tôi không thể. Tôi sẽ không phục hồi $16 tỷ, nhưng tôi có thể lấy lại được một chút, và thực tế với SAS, bạn không có khả năng mất nhiều. Sự khác biệt về giá so với chi phí phải chứng minh bất kỳ rủi ro nhận thức bổ sung nào cho doanh nghiệp. Đôi khi gắn bó với SAS rẻ hơn so với đào tạo lại. Đôi khi có những vấn đề ưu tiên cao hơn, vì vậy các công ty ở lại với SAS. Một số công ty không cần chức năng đầy đủ trong trường hợp thay thế là khả thi. Một số không cần sự hỗ trợ và một lần nữa các lựa chọn thay thế là khả thi. Nếu bạn đáp ứng các yêu cầu kinh doanh thì một trong hai lựa chọn là hợp lệ, nếu bạn muốn cung cấp hỗ trợ cho doanh nghiệp, bạn cần xem xét tổng chi phí sở hữu trong 5-10 năm, khả năng tuyển dụng chuyên gia về các công cụ, tính ổn định trong sản phẩm vì vậy bạn không phải viết lại mọi thứ với mỗi bản phát hành mới, các khóa đào tạo có sẵn để nâng cao kỹ năng,

Một số lý do mà tôi chưa thấy đề cập đến:

1. Tài liệu tốt hơn. Tài liệu của SAS là dài dòng, tài liệu R là ngắn gọn. Nhiều công ty có thể thích tài liệu dài dòng.

2. Thông báo lỗi tốt hơn. Thông báo lỗi của R thường có vẻ được thiết kế để chứng minh rằng người viết tin nhắn thông minh hơn người đọc nó.

3. Hô trợ ky thuật. SAS có một số hỗ trợ công nghệ tốt nhất mà tôi đã gặp ở bất cứ đâu, được cung cấp bởi SAS. Bạn có thể nhận trợ giúp với R, nhưng sự trợ giúp đó nằm rải rác ở những nơi khác nhau và không phải lúc nào cũng có sẵn. Những người trên các trang web khác nhau cung cấp trợ giúp với R là tình nguyện viên - và tình nguyện viên không bắt buộc phải giúp đỡ. Những người tại bộ phận hỗ trợ kỹ thuật của SAS được trả tiền để làm những gì họ làm - và họ làm điều đó rất tốt. Họ không chỉ làm tốt điều đó, họ còn làm điều đó một cách lịch sự, một đặc điểm thường không có trong tất cả các cộng đồng R (yêu thích của tôi? "Tôi nhận được sự giúp đỡ bằng cách gõ 'trợ giúp', tại sao bạn không thử gõ 'trợ giúp'?")

4. $\LaTeX$ nhưng rất nhiều công ty sử dụng Word).

Tôi nghĩ rằng góc di sản có thể là một lớn cho lý do sau đây. Một tổ chức thuê một người, gọi họ là người X. Họ là một bậc thầy điện toán / thuật sĩ / v.v. Họ xây dựng các chương trình / công cụ / công cụ tuyệt vời của SAS. Họ giỏi đến mức những người khác trong tổ chức không cảm thấy như họ cần hiểu cách thức các chương trình hoạt động. Họ làm cho nó rất dễ dàng chỉ cần nhấn một nút, và mọi thứ chỉ hoạt động (các hộp đen ma thuật).

Người X rời khỏi tổ chức. Thật không may, kiến ​​thức mà người X rời khỏi tổ chức (tài liệu và quản lý kiến ​​thức không được ưu tiên, thay vào đó, các chương trình làm việc đã được thay thế). Họ được thay thế bởi người Y. Người Y rất tuyệt vời với R nhưng không biết gì về SAS, và do đó không biết về cách các chương trình SAS thực sự hoạt động. Có một đường cong học tập lớn để thậm chí tìm ra những gìcần được dịch sang R. Ví dụ, người Y không thể biết liệu đã thực hiện chuyển đổi dữ liệu để cho phép gọi Proc hay để hợp nhất với dữ liệu khác, v.v. Các biến đổi cần có có thể khác nhau ở R, bởi vì các hàm là khác nhau và mặc định là khác nhau (ví dụ: xử lý các biến phân loại trong Proc glm so với lm ()) Vì vậy, bây giờ bạn đang phải đối mặt với sự đánh đổi chi phí không đồng đều. Nói chi phí viết lại / dịch từ SAS sang R là$C_T$. Sau đó, chúng ta cần mức tăng hiệu quả (nhỏ?) Từ việc chuyển sang R (Tôi nói nhỏ dựa trên kinh nghiệm của tôi với việc tối ưu hóa mã SAS và tối ưu hóa mã R để dự đoán hồi quy logistic). Điều này cũng cần được so sánh với chi phí giấy phép cho SAS. Có khả năng là$C_T$cao hơn đáng kể so với giấy phép một năm cho SAS. Tôi hy vọng rằng SAS sẽ thực hiện một số phân tích về sự đánh đổi này và để ảnh hưởng này đến cách nó đặt ra lệ phí cấp phép (tốt, tôi sẽ làm nếu tôi làm việc tại SAS). Cũng lưu ý cách các quy trình âm mưu của SAS tốt hơn so với một thập kỷ trước (ví dụ: Proc sgplot so với âm mưu của Proc). trùng hợp ngẫu nhiên mà R đã làm tốt âm mưu đầu tiên? Tôi nghĩ là không! Điều này làm giảm hiệu quả từ việc chuyển đổi vì âm mưu không còn quá khác biệt nữa - R vẫn tốt hơn, nhưng không đủ để chuyển đổi ...

Đối với thống kê công nghiệp, có những người đảm bảo chất lượng (thường) không có lập trình, thống kê hoặc nền tảng khoa học và kiểm toán các nhà thống kê, lập trình viên và nhà khoa học. Họ muốn biết, "Làm thế nào để bạn biết rằng những gì bạn đang làm là đúng?" và "Nếu nó sai, làm thế nào chúng ta có thể đổ lỗi cho ai đó và họ sẽ trả tiền cho nó như thế nào?".

Giấy phép Copyleft GNU / GPL đi kèm với văn bản đóng hộp có nội dung: "R là phần mềm miễn phí và COMES VỚI TUYỆT ĐỐI KHÔNG CÓ BẢO HÀNH" trong văn bản toàn chữ chính xác như tôi đã viết. Đây là kết quả. Khi một người chất lượng đọc văn bản này, về cơ bản họ làm mất uy tín R hoàn toàn. Ý tôi là, nếu một sản phẩm tốt, nó đáng để thêm một bảo hành phải không? Như vậy có sản phẩm thương mại khiến chúng tôi tin tưởng. Trên thực tế, cuối cùng, FDA đã nói rằng họ sẽ chấp nhận đệ trình quy định trong R phản ánh một seachange trong ngành công nghiệp phần mềm. (Lưu ý tuyên bố này được đưa ra sau ngày đăng ban đầu của câu hỏi.)

Đối với một người không biết gì về máy tính, các kịch bản tưởng tượng về bảo mật, không thể sửa chữa và các lỗi khoa học nghiêm trọng không bị ràng buộc do hậu quả TUYỆT ĐỐI CỦA TUYỆT ĐỐI này. Tất cả chúng ta đồng ý sai lầm có thể có chi phí thảm khốc. Đối với giấy phép SAS của bạn, SAS có các chuyên gia có thể giải thích phần mềm của họ cho kiểm toán viên và trong trường hợp không thể xảy ra là SAS thực sự gây ra vấn đề như vậy, họ có thể chịu trách nhiệm về các khoản phạt và hình phạt (họ cũng có đủ tiền để luật sư đảm bảo họ sẽ đảm bảo được miễn hoàn toàn trong trường hợp như vậy). Gánh nặng và chi phí của việc có một nhà phân tích / lập trình viên trình bày trường hợp này cho R về cơ bản lên tới giấy phép SAS. Không phải là lập trình trong SAS hoàn toàn miễn trừ bạn khỏi gánh nặng nghiền nát của việc tuân thủ chất lượng!

Vì vậy, về cơ bản, tôi sẽ nói rằng tôn giáo đã đóng một vai trò nổi bật trong việc yêu cầu một phần mềm giấy phép tốn kém.