Tại sao C ++ vẫn được ưa thích để xây dựng các ứng dụng GUI nặng hơn các ngôn ngữ động mới nhất? [đóng cửa]

46

Tôi thấy rằng hầu hết các ứng dụng bao gồm nội dung GUI nặng thường được phát triển trong C ++. Hầu hết các trò chơi / trình duyệt được mã hóa bằng C ++.

Chúng ta có thể phát triển các ứng dụng GUI tốt hơn với các ngôn ngữ động mới nhất không? Tôi biết java sẽ không phải là một lựa chọn tuyệt vời. Nhưng những ngôn ngữ như python vốn được xây dựng trên C thì sao? Không phải ngôn ngữ mới nhất được cho là tốt hơn so với tổ tiên của họ? Tại sao chúng ta vẫn phải thích C ++ cũ hơn các ngôn ngữ mới nhất?

Và tôi cũng muốn biết, cái gì chịu trách nhiệm trong C ++, cho tốc độ xử lý GUI tốt hơn? Mặt khác, những ngôn ngữ mới nhất khác thiếu gì?

programming-languages c++

— Vamsi Emani
nguồn

22

Nếu bạn nghĩ rằng Java là ngôn ngữ 'động', thì bạn sẽ bối rối sâu sắc về ý nghĩa của từ đó trong ngữ cảnh này.

— Mike Baranczak

15

@Mike Baranczak: Đó là một câu chuyện dài. Về cơ bản, đã có một dự án nghiên cứu đầu tiên tại Stanford, sau đó tại Sun Research có tên là Self. Bản thân là một ngôn ngữ lập trình trong gia đình Smalltalk đơn giản hơn, mạnh mẽ hơn, biểu cảm hơn và quan trọng nhất là năng động hơn đáng kể so với Smalltalk. Bởi vì nó được thiết kế như một ngôn ngữ lập trình để phát triển toàn bộ hệ thống (như tất cả các phương ngữ của Smalltalk), bao gồm (nhưng không giới hạn) các ứng dụng máy tính để bàn, máy chủ, hệ điều hành, trình điều khiển thiết bị, nên nó phải cực nhanh. Vì vậy, nhóm Tự phát minh ra một loạt mới ...

— Jörg W Mittag

15

... Các kỹ thuật tối ưu hóa, và khi Self VM xuất hiện vào năm 1987 (và thậm chí nhiều hơn thế hệ thứ hai vào năm 1992), nó đã rất nhanh. Nó nhanh hơn bất kỳ máy ảo Smalltalk nào khác. Hệ thống Self được vận chuyển với rất nhiều mã ví dụ và một trong những ví dụ đó là trình thông dịch Smalltalk được viết bằng Self, và thậm chí nó còn nhanh hơn bất kỳ VM Smalltalk nào khác. Bản thân đã nhanh hơn nhiều triển khai C ++ tại thời điểm đó, và thậm chí cạnh tranh với C. Chà, bạn hiểu rồi. Đó là nhanh chóng . Tuy nhiên, Sun đã quyết định rằng họ không cần ngôn ngữ lập trình hướng đối tượng hoặc VM nhanh, vì vậy họ ...

— Jörg W Mittag

15

... về cơ bản đã bỏ đói dự án Tự đến chết bằng cách làm cạn kiệt nguồn tài trợ. Khi các kỹ sư Self VM rời khỏi Sun vì thất vọng, họ nhanh chóng bị một startup của Smalltalk gọi là LongView (thường được biết đến với tên sản phẩm nhất của họ, một hệ thống loại tĩnh tùy chọn cho Smalltalk: StrongTalk). LongView biết rằng họ sẽ không bao giờ có thể bán kiểu gõ tĩnh cho Smalltalk, vì vậy họ nghĩ rằng họ muốn bán Smalltalk nhanh nhất trên hành tinh và sau đó đưa StrongTalk vào gói trong một loại trò chơi Trojan Horse. Họ cũng nhận ra rằng không ai trong số tuyệt vời ...

— Jörg W Mittag

15

... tối ưu hóa Tự VM đã làm được trong bất kỳ cách nào đặc biệt để tự, nhưng đã áp dụng đối với khá nhiều bất kỳ ngôn ngữ hướng đối tượng (hoặc thậm chí chỉ cần bất kỳ ngôn ngữ nào cả ). Vì vậy, các kỹ sư Self VM đã làm việc trên máy ảo Smalltalk được gọi là VM Animorphic. Một lần nữa, Animorphic VM là blindingly nhanh (và vẫn là, trên thực tế, mặc dù codebase đã không được xúc động trong 15 năm hoặc lâu hơn, nó vẫn có thể cạnh tranh với hiệu suất cao hiện đại Smalltalks, JVM và .NET, đặc biệt là nếu bạn mất vào tài khoản rằng nó sử dụng ít tài nguyên hơn nhiều so với tài nguyên đó, vì nó được thiết kế cho 486 giây với 20 meg ...

— Jörg W Mittag

58

Tôi là một trong những người viết ứng dụng GUI C ++ (chủ yếu cho windows). Với Qt, chính xác là vậy. Lý do của tôi:

Tôi thích C ++. Tôi là một người làm việc tự do và thường tôi có thể chọn các công cụ của mình (may mắn cho tôi!)
Trong một môi trường được quản lý, bạn có thể gặp khó khăn khi bạn cần sử dụng một số mã không được quản lý (khai báo WinAPI dài dòng trong C #, bất cứ ai?)
Ít phụ thuộc hơn được triển khai dễ dàng hơn
Kiểm soát nhiều hơn mọi thứ.
RAII (so với GC). Và ngay cả khi tôi phân bổ new, tôi hiếm khi có deletebất cứ điều gì rõ ràng, bởi vì tôi sử dụng con trỏ thông minh hoặc QObjecthệ thống phân cấp.
C ++ rất thú vị những ngày này, tôi không thể chờ đợi một trình biên dịch hỗ trợ đầy đủ tiêu chuẩn mới.
Tốc độ (chỉ ở cuối danh sách. Tôi biết nó không quan trọng đối với GUI, nhưng nó có xu hướng nhanh hơn vì các chương trình C ++ không phải chịu chi phí mà thời gian chạy, biên dịch mã JIT và các công nghệ tương tự thêm vào chương trình.)

Như bạn có thể thấy, đây chủ yếu là sở thích cá nhân. Tôi thấy điều quan trọng là công việc của tôi phải thú vị và C ++ cung cấp điều đó cho tôi.

— Tamás Szelei
nguồn

11

Tốc độ +1 chắc chắn là lý do hàng đầu ở đây, ngoài sở thích cá nhân. Tuy nhiên, tôi thích "C ++ rất thú vị những ngày này". Để giải quyết người hỏi , không phải @ Tamás Szelei: Chắc chắn, điện toán thay đổi nhanh chóng với những ý tưởng mới, mô hình, công nghệ, sản phẩm nhưng mới nhất và lớn nhất không phải là một ưu điểm. C ++ đã xuất hiện được một thời gian và điều đó không có nghĩa là nó đã lỗi thời, thay vào đó nó có một hồ sơ theo dõi đã được chứng minh từ lâu so với các công nghệ mới hơn. Văn bản Stroustrup ban đầu (cuốn sách của nhà phát minh) rất nặng nề nhưng có một số cuốn sách hay ngoài kia - ví dụ, hãy kiểm tra oreilly.com.

— trị liệu

1

@Tarnas Tôi nghĩ rằng "luôn luôn sẽ nhanh hơn" là một chút hẹp hòi / có thẩm quyền, nhưng không đủ để đảm bảo một downvote ...

— Tối đa

2

Là hỗ trợ giai thoại: Tôi đã tham gia vào các dự án khác nhau để tạo GUI có kích thước đáng kể trên Windows bằng C ++ và JavaScript. Tôi cũng đã tham gia vào các dự án bảng điều khiển trò chơi khác nhau trong C ++ và JavaScript. Trong cả hai trường hợp, có nhiều vấn đề về tốc độ và bộ nhớ hơn với JavaScript.

— Gort Robot

2

Đến bữa tiệc muộn, nhưng bạn có thể nói rõ hơn về "sự phụ thuộc ít / dễ triển khai" không?

— weberc2

2

Tôi đã sử dụng C ++ hơn 20 năm. Nhiều tính năng mới và tuyệt vời được thêm vào từ 11, 14 và 17. Bạn gần như có thể sử dụng C ++ làm ngôn ngữ kịch bản và vẫn nhận được lợi ích của tốc độ nhanh. Khi tôi làm việc với dữ liệu LỚN, tôi gần như phải sử dụng C ++ vì bất kỳ ngôn ngữ nào khác sẽ chậm hơn 10-1000.

— Kemin Zhou

32

Bởi vì vấn đề tốc độ.

Các trò chơi sử dụng C ++ cho các nhiệm vụ cốt lõi, trong đó hiệu suất là quan trọng. Họ sử dụng các ngôn ngữ động cho các tác vụ kịch bản trong đó tính linh hoạt là quan trọng.
Các ứng dụng GUI trên máy tính để bàn : Visual Studio, ví dụ, được viết bằng .NET và không phải C ++ gốc. Nó dường như hoạt động khá tốt đối với một IDE, vì bản thân IDE không cần thực hiện nhiều nhiệm vụ cường độ cao. (Trình biên dịch, trình liên kết và các công cụ khác không nhất thiết phải được viết bằng .NET - mặc dù như wawa chỉ ra trong một nhận xét, một số có vẻ là (ví dụ VB.NET))
Trình duyệt cũng cần phải nhanh. Rốt cuộc, chúng là một loại hệ điều hành thứ cấp. Mặt khác, bạn có thể lập luận rằng phần lớn Firefox thực sự được "viết bằng" javascript, vì khung công tác Mozilla dường như phụ thuộc rất nhiều vào javascript.

Tóm lại: Tôi sẽ không nói C ++ là nhất thiết phải được ưu tiên nhưng nếu bạn có một tắc nghẽn về hiệu suất, bạn phải đến gần kim loại hơn và sau đó bạn gặp C ++ (tốt, hoặc C). Đôi khi sẽ dễ dàng hơn để làm mọi thứ trong C ++ - một ngôn ngữ.

— Martin Ba
nguồn

1

+1 Câu trả lời hay nhất: Hoàn toàn là do tốc độ là lý do hàng đầu để sử dụng C ++. Ngay cả chính Microsoft cũng thừa nhận rằng C ++ là tốt nhất cho hiệu năng so với c # và cơ bản trực quan - hãy xem họ trên các trang Visual Studio của họ. Thứ hai rất gần là tính di động - nếu bạn sử dụng các thư viện đa nền tảng như Qt. Câu trả lời tốt nhất cũng bởi vì nó khách quan hơn là chủ quan.

— trị liệu

2

Điểm thứ hai của bạn không hoàn toàn đúng. Trình biên dịch VB.NET được viết bằng VB.NET và trình biên dịch F # được viết bằng F #. Trình biên dịch C # không phải nhưng từ những gì đã được phát hành về dự án Roslyn, tôi nghĩ trình biên dịch C # đang được viết lại trong C #.

— Wesley Wiser

5

Gui phòng thu trực quan (chrome) được viết (từ vs2010) trong c # và WPF. Trình khám phá giải pháp, hệ thống xây dựng, trình duyệt mã và hộp công cụ được viết bằng c # / c ++ với winforms. Trình biên dịch được viết bằng c ++.

— Martin Beckett

Đối với hầu hết các ứng dụng trên máy tính để bàn, chỉ có các công cụ kết xuất và bố trí (nghĩa là Chế độ xem) cần phải nhanh. Model không có xu hướng dành nhiều thời gian cho nó và Bộ điều khiển dành phần lớn thời gian của nó chỉ chờ người dùng làm gì đó (và ít người dùng có thể nhấp thường xuyên 10 lần một giây với độ tin cậy).

— Donal Fellows

@MartinBa: Tôi lưu ý rằng trình biên dịch hiện tại cho C # và VB (Roslyn) được viết bằng C #.

— jmoreno

17

Các ứng dụng GUI mà bạn thấy được viết bằng C ++ thường được thực hiện vì lý do cũ. Python (với Qt hoặc Gtk) rất khả thi cho các ứng dụng GUI, cũng như C # nếu bạn làm việc trong một ngôi nhà Windows. Khi bắt đầu một cái gì đó mới, hoặc là rất được ưa thích cho C ++ vì thiếu công việc hệ thống ống nước phải được thực hiện.

— Demian Brecht
nguồn

5

Mã hiện có +1 là quan trọng. Rất hiếm khi bắt đầu hoàn toàn từ đầu khi phát triển các chương trình mới

7

Làm thế nào là sử dụng Python với Qt thích hợp hơn sử dụng C ++ với Qt? Nếu tôi bắt đầu một dự án mới ngày hôm nay, tôi vẫn sẽ sử dụng C ++ cho GUI. Bởi vì: a) Đó là những gì tôi biết, b) nó làm công việc tốt. Chỉ vì C ++ đã được một thời gian không làm cho nó "lỗi thời".

— TZHX

2

@TZHX: "Đó là những gì tôi biết" là một đối số khả thi. Nếu điều đó không được đưa ra, việc không phải chăm sóc quản lý bộ nhớ nữa là một hiệu suất rất lớn và nó có thể bù đắp cho nỗ lực học Python ngay cả đối với một dự án. Một lý do khác để sử dụng Python sẽ là tính đa nền tảng - với C ++, bạn phải cẩn thận và thực hiện các biện pháp đặc biệt, trong khi python có thể chỉ hoạt động.

— tdammers

4

Tôi không thấy bất kỳ lợi thế nào của việc sử dụng PyQt thay vì Qt với C ++ cho một người biết C ++.

— BenjaminB

13

C ++ có khả năng chỉ hoạt động. Với Python, bạn phải lo lắng về việc phiên bản python nào mà người dùng đã cài đặt hoặc lo lắng về việc gói nó. Thực sự không có quá nhiều việc phải làm "chăm sóc bộ nhớ" trừ khi bạn mắc phải những lỗi ngu ngốc. Tôi nghĩ rằng nhiều người cho "quản lý bộ nhớ" là một trở ngại lớn khi làm việc với C ++ mà không thực sự biết nó tạo ra sự khác biệt nhiều như thế nào.

— TZHX

16

Bởi vì cho dù có bao nhiêu bài kiểm tra hiệu năng .NET và những đám đông tương tự cho thấy, bất kể chúng đến gần điểm chuẩn đến đâu, cuối cùng, ứng dụng C ++ vẫn xuất hiện trên đầu trang. Nó nhanh hơn khi khởi động nguội, nó nhanh hơn và có nhiều cách hơn để cải thiện nó.

Tôi đã nghe nhiều bằng chứng tại các giai đoạn bắt đầu dự án rằng .NET là con đường để đi, nhưng một khi nó được chọn, chúng luôn luôn là một mối hận nặng nề.

Ngoài ra, C ++ hiện nay khá an toàn và khá dễ sử dụng, đặc biệt là với các khung như Qt hoặc WTL.

— Mã hóa
nguồn

2

+1: "Ngoài ra, C ++ ngày nay khá an toàn và khá dễ sử dụng, đặc biệt là với các khung như Qt ..." Tôi hoàn toàn đồng ý: Tôi nghĩ rằng một sức mạnh lớn không phải là (chỉ) C ++, mà thực tế là (1 ) nó được biên dịch thành mã gốc, (2) có một bộ tính năng hợp lý (OOP, mẫu), (3) có các khung rất tốt như Qt. Điều này bù đắp cho thực tế rằng ngôn ngữ khá lớn và khó học: một khi bạn thành thạo một tập hợp con tốt của ngôn ngữ và một số thư viện tốt, bạn có thể thực sự hiệu quả với nó.

— Giorgio

10

Hầu hết các công cụ trò chơi được mã hóa trong C ++. Ngoài ra rất nhiều công cụ trình duyệt được mã hóa trong C ++. Nhưng GUI trình duyệt thường được mã hóa bằng một số tập lệnh nhẹ (JavaScript, Python). Ngoại trừ đáng chú ý là Source Engine, hầu hết các công cụ trò chơi cũng sử dụng các ngôn ngữ script (như Lua hoặc Python). [để tham khảo: danh sách các trò chơi kịch bản Lua ]

Cũng lấy thư viện GUI C ++ phổ biến như Qt. Trong phiên bản hiện tại (4.7), nó sử dụng QML cho GUI. QML về cơ bản là JavaScript với các ràng buộc Qt.

Vì vậy, thực sự không có ngôn ngữ C ++ và ngôn ngữ động, nó bị lẫn lộn.

— vartec
nguồn

[Cần dẫn nguồn]. Tôi biết nhiều trò chơi sử dụng ngôn ngữ kịch bản để cho phép người dùng mở rộng chúng, nhưng theo tôi biết thì thực sự không có nhiều trò chơi sử dụng ngôn ngữ kịch bản cho chức năng nhị phân phát hành của họ.

— ProdigySim

1

@ProdigySim: Tôi biết một số điều đó. Ra khỏi đầu tôi, World of Warcraft (Lua + XML), sê-ri Uncharted của Naughty Dog (Lisp), sê-ri Unreal (UnrealScript), các trò chơi dựa trên các công cụ Torque và Unity, Dungeon Siege, NeverWinter Nights và nhiều game khác. Các trò chơi dựa trên dữ liệu đang trở thành chuẩn mực, trong đó máy chủ lưu trữ kịch bản chiếm hầu hết (nếu không phải tất cả) các tính năng UI và trạng thái trò chơi từ trên xuống dưới.

— greyfade

@ProdigySim: ngay cả khi nó bị ẩn khỏi người dùng bình thường, không có nghĩa là bên trong họ không sử dụng các công cụ viết kịch bản. Về cơ bản các nhà phát triển trò chơi có hai tùy chọn - tạo ngôn ngữ kịch bản riêng cho các mô hình hoặc sử dụng một trong những mục đích chung. Lua đặc biệt tốt cho các trò chơi, vì nó thường tốt cho các hệ thống thời gian thực.

— vartec

Công cụ nguồn sử dụng ngôn ngữ kịch bản Squirrel.

— cubuspl42

6

Lý do đầu tiên sẽ là: thói quen (cũ)

Lý do thứ hai: độ tin cậy thấp hơn trên Máy ảo, trình thông dịch cần được cài đặt, v.v.

Và vẫn còn khá nhiều IDE tuyệt vời để phát triển mã trong C ++.

— Roalt
nguồn

1

' vẫn là những IDE tuyệt vời' .. Tôi cho rằng Visual Studio và Eclipse rất tiên tiến và đã có khá nhiều trong một thời gian dài.

— JBRWilkinson

@JBRWilkinson: Tôi không nói ngôn ngữ khác cũng không có chúng.

— Roalt

6

Lý do là bạn có nhiều quyền kiểm soát hơn đối với mọi thứ xảy ra. Nếu bạn định viết photoshop bằng C #, bạn sẽ gặp vấn đề nghiêm trọng về hiệu năng đối với một số tác vụ. Trong một ngôn ngữ cấp thấp hơn với nhiều quyền kiểm soát hơn, bạn có thể sử dụng các phím tắt, tối ưu hóa ở những nơi cần thiết cho những thứ cường độ cao hơn. Tất nhiên điều này giả sử bạn đang sử dụng C ++ trong mã không được quản lý, không phải C ++ trong .NET.

Xem ở đây để có một ví dụ nhanh chóng.

— nhà giàu
nguồn

2

Adobe Lightroom, về cơ bản là một tập hợp con của Photoshop, được viết bằng Lua.

— Jörg W Mittag

4

@ Jörg: và phần còn lại của nó là C ++. trong thực tế đó có lẽ là sự kết hợp tốt nhất có sẵn, C ++ cho nền tảng, Lua cho phần còn lại (mặc dù tôi vẫn thích C hơn C ++ cho những thứ cấp thấp).

— Javier

2

@Javier: Vâng, Lightroom về cơ bản là các thuật toán xử lý hình ảnh từ Photoshop (có lẽ được viết chủ yếu bằng cách lắp ráp MMX / SSE) và SQLite3 (được viết bằng ANSI C tiền sử cho tính di động) được dán cùng với Lua. Adobe cũng đã phát triển Lua IDE của riêng họ, hoàn toàn bằng Lua. Có ai biết bộ công cụ đồ họa họ sử dụng không? AFAIR Photoshop có trước khá nhiều bộ công cụ hiện đại, vì vậy đây có lẽ là thứ được trồng tại nhà?

— Jörg W Mittag

4

không có hành vi phạm tội, nhưng nếu bạn nghĩ ANSI C là thời tiền sử, bạn đã đọc sai mẫu mã

— Javier

6

C ++ được gõ tĩnh. Điều này cho phép tối ưu hóa việc thực thi mã trước bằng cách có một trình biên dịch phù hợp với sự trừu tượng của bạn với quy trình hệ thống có sẵn trên một nền tảng nhất định. Cho đến nay, các ngôn ngữ động cần một lớp phần mềm bổ sung (= trình thông dịch) làm chậm truy cập vào tài nguyên hệ thống.

— đặt ra
nguồn

4

Hầu hết các lý do được đưa ra là về kỹ thuật hoặc "trên bảng" ... đây là lý do kinh doanh hoặc "dưới bàn":

phân phối mã biên dịch vs phân phối mã nguồn. Khi phát triển trong c / c ++, bạn phân phối các nhị phân. nếu bạn đang phát triển một trong những ngôn ngữ hiện đại, bạn phân phối nguồn. Thật khó để bán ý tưởng của obfuscators cho ban quản lý, những người phải trả lời cho các cổ đông / nhà đầu tư vì vậy đừng bận tâm.

người dùng ngu ngốc: ít nhất là trong suy nghĩ của quản lý. họ vẫn nhận thấy người dùng của họ hầu như không thể nhấp đúp vào "setup.exe". Nếu bạn bao gồm việc cài đặt trình thông dịch như một phần của thiết lập, họ sẽ lắc đầu từ bên này sang bên kia.

nhà phát triển cũ: hầu hết những người có kinh nghiệm đã có từ lâu và không tự cập nhật. họ lập trình bằng C ++ chứ không phải bằng các ngôn ngữ mới hơn, vì họ không biết các ngôn ngữ mới hơn.

— Kinjal Dixit
nguồn

Tôi sẽ tranh luận rằng bạn đang phân phối mã nguồn khi bạn phát hành một ứng dụng .NET. Nhìn vào Visual Studio, phần lớn giao diện được thiết kế với các mẫu WPF. Một số điểm của bạn tất nhiên là hợp lệ, phần lớn quản lý ngày nay là các nhà phát triển của ngày hôm qua, tin xấu phần lớn các khung ngày nay dường như không hợp lệ vì những thay đổi đối với máy tính ngày nay.

— Ramhound

Rất nhiều người có nhiều kinh nghiệm đã có được kinh nghiệm của họ bằng cách tự cập nhật. Họ có xu hướng không học các ngôn ngữ mới nóng bỏng (như Pascal vào đầu những năm 1980) chỉ vì chúng nóng, nhưng chỉ khi họ sử dụng chúng hoặc họ có những ý tưởng thú vị (ví dụ như Haskell).

— David Thornley

4

Tôi sẽ mở rộng phạm vi của vấn đề từ GUI sang phần mềm dự kiến sẽ cạnh tranh. C ++ không áp dụng thuế đối với nền tảng đích vì nó liên quan đến sức mạnh xử lý, thời gian chạy được cài đặt, khung công tác, v.v. Vì vậy, nó sẽ hoạt động trên phần cứng khách hàng hạn chế hơn so với một giải pháp tương tự được viết bằng ngôn ngữ được quản lý / giải thích. Trong trường hợp một phần mềm thương mại thành công, chi phí phát triển (có khả năng cao hơn trong trường hợp của C ++) được khấu hao theo số lượng bán.

Ngoài ra, C ++ thường cung cấp quyền truy cập trực tiếp vào apis hệ thống (như GUI), điều mang lại cơ hội tốt nhất để tối ưu hóa việc sử dụng và phân biệt chính nó với các giải pháp tương tự.

— jszpilewski
nguồn

3

Tôi nghĩ rằng rất nhiều trong số đó phải làm với các API cho bộ công cụ GUI. Tất cả chúng đều có API C / C ++, nhưng không phải tất cả chúng đều có (nói) các ràng buộc Python. Và đôi khi, chính các bộ công cụ đã được viết bằng C ++, vì vậy ngay cả khi chúng có hỗ trợ cho các ngôn ngữ khác, chúng không hỗ trợ đầy đủ cho chúng (ví dụ: chúng sẽ không hỗ trợ Python tuplelàm đối số).

— TMN
nguồn

Ồ, họ không hoàn toàn ủng hộ họ, vì họ không muốn, hoặc không có thời gian để thực hiện điều đó. Không phải vì điều đó là không thể.

— cubuspl42

2

Bạn đang đề cập đến các trình duyệt và trò chơi làm ví dụ. Cả hai đều là những ứng dụng quan trọng về hiệu năng, do đó, có chúng trong một ngôn ngữ cấp thấp cho tốc độ có ý nghĩa.

Nhiều ứng dụng khác có hiệu suất thấp hơn ràng buộc và có thể dễ dàng được viết bằng các ngôn ngữ khác. C # nói riêng dường như được sử dụng rất nhiều. (Và Obj-C, nhưng tôi không thực sự đủ điều kiện như cấp độ cao tôi đoán. Mặc dù vậy, tốt hơn C ++.)

Tuy nhiên, thiếu một số khung nhất định cho các ngôn ngữ lập trình mới nhất. Ví dụ, thực sự không có thư viện GUI gốc khả thi cho Python. Chắc chắn, bạn có thể sử dụng PyQt hoặc PyGtk và chúng hoạt động tốt, nhưng cuối cùng, điều đó chỉ giao tiếp với mã C một lần nữa. Một lần nữa, C # (và được cho là Obj-C) dường như là ngoại lệ và có thể, MacRuby hoặc IronPython có thể thay đổi trò chơi đó.

— khốn
nguồn

0

Đối với một ngôn ngữ để thay thế C ++ hoặc Java, nó phải thực hiện những gì bị bỏ lỡ trong các ngôn ngữ này bên cạnh việc thực hiện chúng ở thế mạnh riêng của chúng. Ngoài ra, các khoản đầu tư lớn đã đi vào các ngôn ngữ này. Điều đó có nghĩa là có một thư viện C ++ tiêu chuẩn trên nhiều nền tảng, mà trình duyệt, trò chơi và các chương trình như vậy có thể dễ dàng sử dụng. Vì vậy, chắc chắn có một quán tính. Ngôn ngữ có xu hướng cất cánh chậm chạp không giống như các phần mềm khác.

Nếu bạn nhìn vào nó, Anaconda (chương trình cài đặt của RedHat) đã tồn tại được khoảng 10 năm hoặc lâu hơn, được viết bằng Python ngay từ đầu. Python không phổ biến khi Anaconda mới.

Google Go (golang.org) đang phát triển rất nhanh. Trình biên dịch vẫn chưa được bootstrapping. Để phổ biến của nó cất cánh, thư viện của nó phải ổn định, trình biên dịch nên được khởi động và nhiều người phải sử dụng nó. Tôi đã nghe một chương trình sản xuất bên ngoài Google được viết bằng Go và được báo cáo là không có thời gian ngừng hoạt động trong vòng hơn một năm.

— vpit3833
nguồn

1

Trên thực tế, có một trình biên dịch Go thương mại cho Windows được viết bằng Go, do đó là một trình biên dịch bootstrapped cho Go. (Mặc dù vậy, nó vẫn đang trong giai đoạn thử nghiệm kín.)

— Jörg W Mittag

Ồ, tôi đã mất liên lạc rồi. Cảm ơn bạn đã nói :)

— vpit3833

2

Nó được gọi là erGo và được sản xuất bởi một công ty có tên Newquist Solutions .

— Jörg W Mittag