هل نحتاج إلى جافا ++؟[مغلق]

https://stackoverflow.com/questions/484172

20-08-2019
|

سؤال

يبدو لي، في بعض النواحي، أن Java هي المكان الذي كانت فيه لغة C منذ فترة.تعتبر كلتا اللغتين بسيطتين إلى حد ما بالنسبة لوقتهما، مع وجود نواة نظيفة وبسيطة نسبيًا للبناء عليها.(أشير إلى اللغة الأساسية هنا، لا المكتبات.) كلاهما يحظى بشعبية كبيرة.كلاهما لغة مشتركة، مع الكثير من التعليمات البرمجية القديمة.كلاهما يفتقران إلى العديد من ميزات الإنتاجية الحديثة التي غالبًا ما يفتقدها المبرمجون من اللغات الأخرى.يبدو أن كلاهما يسيطر عليه الجمود الشديد وبطيء في التكيف مع عالم متغير.

يبدو لي أنه سيكون من المعقول إنشاء Java++ عبارة عن مجموعة شاملة من Java تقريبًا، كما هو الحال مع C++ بالنسبة إلى C.ستحاول مثل هذه اللغة إخراج Java من الركود النسبي الذي مرت به، وكسر التوافق العكسي فقط في بضع طرق بسيطة فقط إذا كان ذلك ضروريًا للغاية، وإضافة الكثير من الميزات الحديثة التي تفتقدها Java القديمة، والقلق بشأن التوحيد القياسي لاحقًا.تشمل الميزات التي قد تكون فكرة جيدة ما يلي:

وظائف الدرجة الأولى، المندوبين.
الإغلاق.
استنتاج النوع الثابت، على غرار var في C # أو auto في د.
التحميل الزائد على المشغل.
الهياكل كأنواع قيم مختلفة عن الفئات، مثل C# وD.
ملكيات.
خيار لتجاهل الاستثناءات المحددة.
القدرة على إعلان أكثر من فئة عامة ذات مستوى أعلى في ملف.
مصفوفات مدمجة أكثر قوة تسمح بأشياء مثل الإلحاق.
أفضل الأدوية العامة/القوالب الحقيقية.
شيء مثل الكلمة الأساسية الديناميكية لـ C# 4.0 التي تسمح بكتابة البط عند الضرورة بلغة ثابتة بشكل عام.
نظرًا لأن Java هي في المقام الأول لغة VM، فقد تكون هناك بعض ميزات البرمجة الفوقية القوية مثل إنشاء تعليمات برمجية سريعة لأشياء معينة.

هل تعتقد أنه سيكون هناك طلب على مثل هذه اللغة؟هل تعتقد أن مثل هذا الشيء سينجح؟

يحرر:أنا لا أتحدث عن التوافق على مستوى وقت التشغيل/الرمز الثانوي، أنا أتحدث عن التوافق مع Java على مستوى مصدر مستوى.أيضًا، نعم، يمكن لـ Java 7 إضافة بعض هذه الميزات، ولكن يبدو أن العملية "الرسمية" لإضافة ميزات إلى Java هي عملية متحفظة للغاية.النقطة الحقيقية هي فكرة تحويل Java إلى فرع حيث ينصب التركيز على الابتكار أكثر من الاستقرار/التوحيد القياسي.

المحلول

سأحصل على تصويت سلبي من قبل محبي Java لهذا ولكن باعتباري شخصًا يكتب كلاً من Java وC#، أود أن أقول إن C# أقرب ما يكون إلى Java ++ كما ستحصل عليه.

كانت لغة C إلى لغة C++ بمثابة نقلة نوعية، من اللغة الإجرائية إلى لغة البرمجة الكائنية، والسبب الوحيد الذي جعلهم يحتفظون بالاسم هو جذب مبرمجي لغة C إلى الاعتقاد بأنها نفس اللغة التي أدت إلى تحميل عدد كبير من أكواد C السيئة التي تتنكر على أنها لغة C++.

تتوسع Java باستمرار وتقوم شركة Sun بدمج المزيد والمزيد من الميزات بسرعة، لذلك من الممكن أن يكون Java 7 أو 8 هو Java ++ الخاص بك

نصائح أخرى

مثل، يقول، سكالا أو الأفضل من ذلك، Groovy الذي يعتبر نفسه نسخة ديناميكية من Java؟

أعتقد أن الإجابة على "هل نحتاج إلى جافا ++؟"يعتمد على من"نحن"هي (وأنا لست متأكدا من ذلك"نحن"جميعها مثيلات لفئة واحدة؛-).وقد تمت مناقشة هذه القضية في أكثر من مناسبة من قبل جافا بوسي.

يميل مستخدمو Java من الشركات الكبيرة إلى أن يكونوا أكثر تحفظًا.لديهم عدد كبير من موظفي التطوير ومجموعات كبيرة من التعليمات البرمجية الموجودة.ونتيجة لذلك، هناك تكلفة ومخاطر عالية محسوسة للتغييرات في اللغة أو المكتبات (التدريب، والصيانة، وكسر التعليمات البرمجية الموجودة، وما إلى ذلك).

من ناحية أخرى، هناك الكثير من فرق التطوير الصغيرة والسهلة (مفتوحة المصدر أو غير ذلك) والمستعدة دائمًا للتمسك بالفكرة العظيمة التالية في البرمجة.ليس من الواضح بالنسبة لي أن إجابة واحدة ستجعل الجميع راضين بما فيه الكفاية.

أقترح أن النظام البيئي المتنامي للغات المستندة إلى JVM قد يساعد في معالجة هذا التوتر.إذا كانت اللغات الأحدث (Scala، وFan، وJRuby، وJavaFxScript، وما إلى ذلك) توفر الميزات التدوينية (والحداثة) التي ترغب فيها المجموعة الثانية، مع الحفاظ على إمكانية التشغيل البيني مع Java الحالية (والتي يمكن أن تتحرك بوتيرة أكثر هدوءًا)، فربما تستطيع كلتا المجموعتين لديهم نكهة الكعكة المختارة.

أنا في حيرة بعض الشيء من الدرجة التي يبدو أن بعض الناس يريدون لغة واحدة حقيقية.في الماضي، كان من الشائع جدًا سماع فكرة أن كل لغة (تدوين) لديها "مكان مناسب" للتطبيق؛في بعض الأحيان كان الحل الصحيح هو كتابة كل جزء من النظام باللغة المناسبة وربطها معًا.

العودة إلى المستقبل، أي شخص؟

السؤال هو في الحقيقة كيف تقرر ما سيتم في "اللغة التالية".مجرد إضافة/إزالة الميزات بشكل تدريجي سيؤدي إلى مجموعة من الهراء.من الأفضل التفكير في كيفية تغيير إضافة هذه الميزات أو إزالتها (التي تعمل غالبًا معًا) إلى طريقة برمجتك وفقًا للمبادئ الجديدة.على سبيل المثال، اعتقدت أنه من المثير للاهتمام أن مقترحات إغلاق Java عانت بعدة طرق من الاضطرار إلى التعامل مع الكتابة الثابتة دون الاستدلال على النوع الغني.هناك أمثلة وفيرة للغات الديناميكية ذات النهايات الجميلة - والتي تتوافق بشكل جيد مع بعضها البعض.وقد أظهرت Scala واللغات الأخرى أن الكتابة الثابتة بالإضافة إلى الاستدلال على الكتابة الغنية يمكن أن تجعل عمليات الإغلاق جميلة أيضًا.وجهة نظري هي أن أخذ اللغة X وصنع اللغة X++ ربما لا يكون مثيرًا للاهتمام.من المثير للاهتمام رؤية المشكلات في X وإنشاء لغة جديدة Y.

من المؤكد أنه لا يوجد ما يمنعك من إنشاء Java الآن وتحويلها إلى ما تريد (طالما أنك لا تسميها Java أو ترغب في اجتياز مجموعة الاختبار).كما ذكرنا أعلاه، توجد بالفعل مجموعة من اللغات المثيرة عالية الجودة التي تقوم بذلك وتحافظ على إمكانية التشغيل التفاعلي مع Java الآن.أفكر بشكل أساسي في Groovy وScala وClojure وFan وعدد أقل من منافذ اللغات السابقة لـ JVM مثل JRuby وJython وRhino والتي تميل إلى قضاء وقت أكثر صعوبة في تنفيذ تكامل Java النظيف.

ومن المحتمل جدًا أن مميزات JSR 292 القادمة إلى JVM في جافا 7 سيوفر ملعبًا أكثر ثراءً لتطوير اللغة على قاعدة JVM الرائعة بالفعل.كما أن CLR+DLR تتخطى العديد من الحدود المثيرة للاهتمام.

أعتقد أن المستقبل سيتجه أكثر فأكثر نحو اختيار اللغة المناسبة للوظيفة.سيحدث هذا إما في اللغات ذات التقليد المختلط (Scala مثال جيد على FP / OO على سبيل المثال) أو في الأجهزة الافتراضية (JVM، CLR، BEAM، Parrot، أيًا كان) التي تعزز التكامل النظيف بين اللغات المتعددة.أو على الأغلب كلاهما.أعتقد أننا لا نتجه نحو أي لغة Next Big Language مشتقة من Java (أو أي شيء آخر).

يوجد حاليًا في Java حلول بديلة للعديد من هذه الأمور، مما يجعل من الصعب تقديم طرق أكثر طبيعية للقيام بهذه الأشياء.

وظائف الدرجة الأولى، المندوبين.

معظم الحالات تكون أقصر باستخدام الانعكاس.(ولكن أقل طبيعية)

.4.الهياكل كأنواع قيم مختلفة عن الفئات، مثل C# وD.

هذا وأنا أتفق مع.

.5.ملكيات.

ويمكن القيام بذلك الآن، ولكن الأمر يتطلب بعض الجهد.سيكون الدعم المدمج المناسب أفضل.

.6.خيار لتجاهل الاستثناءات المحددة.

يمكنك القيام بذلك الآن، ولكن هذا اختراق.ملحوظة:الاستثناءات المحددة هي ميزة وقت الترجمة.

أنا متشكك إلى حد ما في أن هذه فكرة جيدة حقًا ما لم يفهم الناس الاستثناءات حقًا.في كثير من الأحيان، لا يحب الأشخاص الذين يقترحون ذلك أن يُجبروا على التفكير في حالات الخطأ أو توثيقها أو التعامل معها.

.7.القدرة على إعلان أكثر من فئة في ملف واحد.

يمكنك أن تفعل هذا الآن.فقط ليس أكثر من فئة عامة رفيعة المستوى.

.8.مصفوفات مدمجة أكثر قوة تسمح بأشياء مثل الإلحاق.

انظر المشاعات ArrayUtils.ستبدأ المصفوفة التي تحتوي على toString() المعقولة.

.9.أفضل الأدوية العامة/القوالب الحقيقية.

وأنا أوافق، اعتمادا على ما تعنيه.أعتقد أنه ينبغي عليهم تشغيل التطبيق الحالي أولاً، قبل تحسينه.على سبيل المثاللذلك يمكن تجميع واجهات برمجة تطبيقات Java دون تحذيرات لم يتم التحقق منها.

.10.شيء مثل الكلمة الأساسية الديناميكية لـ C# 4.0 التي تسمح بكتابة البط عند الضرورة بلغة ثابتة بشكل عام.

مرة أخرى، الانعكاس يفعل هذا، لكنه قبيح نسبيًا.

.11.نظرًا لأن Java هي في المقام الأول لغة VM، فقد تكون هناك بعض ميزات البرمجة الفوقية القوية مثل إنشاء تعليمات برمجية سريعة لأشياء معينة.

مثل JavaCompiler (في Java 6)، أو دعم البرمجة النصية (في Java 6)، أو JCI أو BeanShell.

إذا كنت ستقوم بإجراء تغييرات كبيرة، ألا ترغب في البدء من جديد؟هناك الكثير من الأشياء التي يمكن فعلها بالإصلاح/الإزالة في Java.لا يمكنك النظر في الميزات بشكل فردي - فهي تتفاعل بطرق غير متوقعة.من المحتمل أن تكون اللغة الكبيرة والمعقدة لغة سيئة (انظر C++).

جافا ++ موجود هنا بالفعل...:د

هذه الأشياء في الغالب زغب.

أنت بحاجة إلى حل بعض المشكلات الأكبر مثل جعل التعليمات البرمجية المتزامنة سهلة التصميم والتفكير فيها.

تبدو كل هذه تغييرات لغوية "سطحية" إلى حد ما مدفوعة بشكل أساسي براحة المطور وليس بشكل أساسي تغيير فلسفة اللغة.

من وجهة نظري، تعديلات طفيفة على بناء الجملة لا تبرر الانتقال الشامل إلى لغة جديدة، خاصة إذا كان ذلك يعني التخلص من الاستثمارات الكبيرة في المنصات وقواعد الأكواد ومهارات المطورين.

يمكن إضافة التغييرات الطفيفة إلى لغة Java بمرور الوقت (في Java 7، 8، 9...) إذا كان هناك طلب كافٍ.ومع ذلك، هناك سؤال حقيقي حول ما إذا كان لها ما يبررها، نظرًا لأن التغيير مثل هذا يجعل اللغة أكثر تعقيدًا وبالتالي أكثر صعوبة في تعلم قواعد التعليمات البرمجية والحفاظ عليها حيث يبدأ المطورون المختلفون في استخدام مجموعة فرعية مختلفة من الميزات.

خذ على سبيل المثال لغة C++:من الناحية النظرية، إنها لغة مذهلة، مما يسمح لك بالبرمجة على أي مستوى ممكن من التجريد مع السماح بأداء مستوى كود الآلة في الكود الأمثل.من الناحية العملية، فإن تعقيد كل هذه الوظائف اللغوية يعني أن عددًا قليلًا جدًا من البشر يمكنهم أن يأملوا في فهم ما يحدث بالفعل، وتصبح قواعد التعليمات البرمجية الكبيرة غير قابلة للصيانة تقريبًا.

من وجهة نظري، فإن التغييرات الوحيدة التي من شأنها أن تبرر "Java ++" بالجملة هي التحولات النموذجية الأساسية التي تغير الطريقة التي تقوم بها بتطوير البرامج نحو الأفضل.التغييرات الأساسية التي جعلت Java ناجحة (أكثر من C++ وما إلى ذلك)في الفترة 1995-2000) كانت من وجهة نظري:

تنفيذ Bytecode في بيئة تشغيل محمولة وقياسية ومتعددة الأنظمة الأساسية (JVM/JRE) دون الحاجة إلى إعادة الترجمة
مكتبة فئة قياسية كبيرة وقوية (بما في ذلك الخيوط والشبكات وواجهة المستخدم الرسومية وما إلى ذلك) - على سبيل المثال.الاعتراف بأن النظام الأساسي يدور حول أكثر من مجرد اللغة
أصبح جمع القمامة إلزاميا

ومن الأمثلة على المرحلة التالية من التحولات الأساسية ما يلي:

تخلص من اتجاه الكائن لصالح البرمجة الوظيفية
القضاء على القفل لصالح ذاكرة المعاملات البرمجية لتمكين التزامن عالي الأداء والآمن للخيوط للبنيات متعددة النواة على نطاق واسع
استبدل المتغيرات القابلة للتغيير بـ قيم غير قابلة للتغيير في جميع أنحاء مكتبات اللغة والفصول الدراسية (لتمكين التفكير في الحالة المتزامنة)
احتضن برمجة ماكرو في وقت الترجمة كحل عام لأي رغبة في إضافة بناء جملة جديد إلى اللغة أو إنشاء خطوط DSL

أوه نعم، وهناك لغة JVM التي تفعل كل هذا - كلوجر

معظم الميزات موجودة بالفعل.

تلك اللغة هي:

_{(مصدر: codehaus.org)}

أما بالنسبة لل:

القدرة على إعلان أكثر من فئة في ملف واحد.

لقد كان موجودًا في جافا منذ البداية.

ألن يُطلق على مثل هذا الجهد الذي تبذله شركة Sun اسم Java 7 (أو 1.7 أو 2.0)؟ألن يُطلق على مثل هذا الجهد الذي يبذله شخص/مجموعة أخرى اسم آخر غير Java؟

إذا قمت بإضافة دعم لهذه الهياكل إلى JVM (عند الضرورة، على سبيل المثال، عمليات الإغلاق)، ثم قم بإنشاء السكر النحوي اللازم في اللغة المكتوبة والمترجم.بالطبع، إذا كنت ترغب في الاحتفاظ بالتوافق مع الإصدارات السابقة، فيجب عليك اتخاذ قرارات التصميم، ولهذا السبب لم تكن Java Generics جيدة كما كان من الممكن أن تكون.أعتقد أنك قد ترغب في التحرر من ذلك للحصول على Java أكثر مثالية، ولكن سيكون هناك طلب قليل جدًا لأن التوافق هو مكانه الحالي.

ويمكن أن يذهب 7 على الفور.نحن لا نواجه حدود ملفات FAT12 على القرص المرن هنا.

بما أن جافا أصبحت مفتوحة المصدر، أنت يمكنك أخذ المصدر (إذا كان متاحًا بالكامل) وإنشاء نسختك الخاصة من Java.إذا حصل هذا على اعتماد واسع النطاق، فهذا رائع، وإذا لم يكن كذلك، فقد لا يكون مجموعة من الميزات المطلوبة.

يمكن ويجب تحسين Java، لكنني لا أعتقد أنه يجب أن تكون هناك لغة واحدة تناسب جميع الاحتياجات.هذه فكرة سيئة بشكل عام، مثل نجمة الموت.

الكثير من المبرمجين كسالى ولا يريدون تعلم أشياء جديدة.إنهم يفضلون التمسك باللغة الوحيدة التي كانوا يستخدمونها خلال السنوات العشر الماضية.

إذا كنت بحاجة إلى السرعة والمزيد من التحكم في أجهزتك، فيمكنك استخدام شيء مثل C.إذا كنت بحاجة إلى مهام إدارة النظام، فمن المحتمل أن ينتهي بك الأمر باستخدام نصوص shell أو لغة برمجة نصية مثل Perl أو python أو Ruby.إذا كنت تفعل الكثير من الأشياء الخاصة بالرياضيات، فإن Matlab يعد خيارًا جيدًا.إلخ.ص.

استخدم أفضل أداة للمهمة، بغض النظر عن اللغة.يجب أن يكون المبرمج الجيد قادرًا على العمل بأي لغة (بالنسبة لي، مازلت أعمل على ذلك).

أقترح إلقاء نظرة على ما وراء جافا.

هناك جيدة مراجعة على جويل على البرمجيات.

تحقق من المعلومات المتوفرة في Java 7.أعتقد أنك ستجد أنه من المقرر إضافة عدة مميزات يطلبها الجميع وأبرزها عمليات الإغلاق.

أنا في الواقع أتفق مع مشاعرك، حيث واجهت مشكلات مع Java يمكن تخفيفها من خلال اقتراحاتك.

من حيث المبدأ، يمكنك كتابة javac الخاص بك الذي يعمل من أجل هذا واستخدام Hotspot JRE الحالي.ومع ذلك، لا يمكنك حقًا تحقيق ذلك بدون مساعدة صن.

المشكلة في الواقع ذات شقين:1) نهج Sun هو دعم "منصة Java" ومقاومة المعيار الجديد، حتى مجموعة شاملة و2) للحصول على أي تغيير في Java، يجب عليك إصدار JSR - وهذا يتطلب عادةً شركات راعية.تميل الشركات إلى أن يكون لها أولويات أخرى.

ثم مرة أخرى، أود أن أحثكم على الضغط من أجل ذلك.بعد كل شيء، حتى عام 2007، كان العديد من الأشخاص الأذكياء تقريبًا يعيدون إنشاء Java من الصفر = GNU classpath.لذلك هناك الموهبة المطلوبة لـ "لغة JVM ثانية من الدرجة الأولى."

بقدر ما أشعر أن Java أصبحت قديمة، فالحقيقة هي أنني أعتقد أننا جميعًا نعرف أنها كلغة لا تزال تعمل بشكل جيد.بالتأكيد، الكثير من الأشياء الأحدث التي يمكن أن نجدها بلغات أخرى غير موجودة، لكنها لا تزال تعمل!لا يزال بإمكانك القيام بكل شيء، ولكن في بعض الأحيان يستغرق الأمر وقتًا أطول ويتطلب المزيد من العمل.أنا بالتأكيد أتطلع إلى اليوم الذي يتم فيه استبداله، لكنني أعتقد أنه مع كل التعليمات البرمجية والتطبيقات الموجودة المكتوبة بلغة Java، لا توجد طريقة في الوقت الحالي، (تقريبًا) لن يقوم أحد بالتحول إلى Java++.أعتقد أننا ننتظر تحولًا حقيقيًا في النموذج، مثلما حدث مع C++ إلى C.ربما تكون البرمجة الوظيفية هي الشيء الكبير التالي وسيكون Scala هو Java التالي.

لغة C++ كائنية التوجه C.Java هي بالفعل موجهة للكائنات، فكيف يمكننا إجراء نقلة نوعية أخرى، وجعلها Java++؟

بطريقة ما أعتقد أن الأمر هو العكس.Java تتقدم كثيرًا على C++.تحتوي Java على مكتبات وأطر عمل عالية المستوى، في حين أن لغة C++ في كثير من الأحيان لا تزال ذات مستوى منخفض ومختلطة مع ansi C (لأننا نستطيع ذلك).

تتمتع Java بإمكانيات جيدة لاختبار الوحدات، ومجتمعات كبيرة موجهة جميعها في نفس الاتجاه.

وجود المزيد من "الميزات" لا يجعل اللغة أفضل.أعتقد أنه من الممكن أن نجعل الأمر أسوأ.

في النهاية، فإن وضع لغة واحدة "أمام" اللغة الأخرى لن يساعد.اختر أفضل أداة للوظيفة.أعتقد أن Java كلغة جيدة جدًا كما هي.ومع ذلك، يمكن لـ C++ استخدام بعض المكتبات الأفضل، مثل منفذ Spring على سبيل المثال.

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow