تجارب مع "محولات اللغة"؟

Question

لقد قرأت بعض المقالات التي تشير إلى المحولين من لغة إلى أخرى.

أنا أكثر من متشكك قليلاً بشأن استخدام هذا النوع من الأدوات.هل يعرف أي شخص أو لديه تجارب دعنا نقول حول Visual Basic إلى Java أو مقابل المحولات؟مثال واحد فقط للاختيار

http://www.tvobjects.com/products/products.html, ، يدعي أنه "الزعيم العالمي" أو نحو ذلك في هذا الجانب، ولكن إذا قرأت هذا:

http://dev.mysql.com/tech-resources/articles/active-grid.html

وهناك يقول المؤلف:

"إن إجماع مستخدمي MySQL هو أن أدوات التحويل التلقائية لـ MS Access لا تعمل.على سبيل المثال، غالبًا ما تؤدي الأدوات التي تترجم تطبيقات Access الموجودة إلى Java إلى حلول كاملة بنسبة 80% حيث يستغرق إنهاء آخر 20% من العمل وقتًا أطول من البدء من الصفر.

حسنًا، نحن نعلم أننا نحتاج إلى 80% من الوقت لتنفيذ أول 80% من الوظائف و80% أخرى من الوقت للـ 20% الأخرى....

فهل قام أحد بتجربة هذه الأدوات ووجدها جديرة بالاهتمام؟

Answer 1

يبدو لي ، كما هو الحال دائمًا مع أسئلة الوصول MS-Access التي تحتوي على علامات تجذب السكان الأوسع نطاقًا ، والتي يجيب عليها الأشخاص الذين يفقدون السؤال الرئيسي هنا ، والذي قرأته على النحو التالي:

هل هناك أي أدوات يمكنها تحويل تطبيق الوصول بنجاح إلى أي منصة أخرى؟

والجواب هو

بالطبع لا

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

تعد مقالة MySQL المذكورة مثيرة للاهتمام للغاية ، لكنها تربك حقًا المشكلات التي تأتي مع تطبيقات غير متطورة مقابل المشكلات التي تأتي مع أدوات التطوير المستخدمة. مخطط البيانات السيئ ليس متأصلًا في الوصول - إنه متأصل في [معظم] مستخدمي قاعدة البيانات المبتدئين. ولكن يبدو أن المقالات تنسب هذه المشكلة للوصول.

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

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

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

هذا لا يعمل.

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

ثانياً ، عند التفكير في تحويل تطبيق وصول للنشر في متصفح الويب ، يختلف نموذج التطبيق بأكمله ، أي من الدولة إلى العديمة الجنسية ، وبالتالي فهي ليست مجرد مسألة عدد قليل من ميزات الوصول غير مدعومة ، ولكنها مختلفة تمامًا تمامًا. النموذج الأساسي لكيفية تفاعل كائنات واجهة المستخدم مع البيانات. ربما يمكن بسهولة تحويل تطبيق وصول غير محدود بنسبة 100 ٪ إلى تطبيق قائم على المتصفح ، ولكن كم عددهم هناك؟ قد يعني هذا تطبيق الوصول الذي لا يستخدم أي إجراءات فرعية على الإطلاق (نظرًا لأنها لا يمكن أن تكون غير محدودة) ، وتطبيق لا يستخدم سوى عدد قليل من الأحداث من نموذج الحدث الغني (معظمها يعمل فقط بأشكال/عناصر تحكم ملزمة). باختصار ، سيكون تطبيق الوصول غير المقيد بنسبة 100 ٪ هو تطبيق يحارب نموذج تطوير الوصول بالكامل. أي شخص يعتقد أنه يرغب في إنشاء تطبيق غير محدود في الوصول لا ينبغي أن يستخدم الوصول في المقام الأول ، لأن الهدف الكامل للوصول هو النماذج/الضوابط المربوطة! إذا قمت بإلغاء ذلك ، فقد ألقت غالبية ميزة RAD الخاصة بـ Access على منصات التطوير الأخرى ، ولم تكتسب شيئًا تقريبًا (بخلاف تعقيد الكود الهائل).

لإنشاء تطبيق للنشر في متصفح الويب الذي ينجز نفس المهام التي يتطلبها تطبيقات الوصول من إعادة تصميم تطبيق واجهة المستخدم وسير العمل. لا يوجد أي تحويل أو ترجمة ستعمل لأن نموذج تطبيق الوصول الناجح يتناقض مع نموذج تطبيق الويب الناجح.

بالطبع ، كل هذا يتغير مع Access 2010 و SharePoint Server 2010 مع خدمات الوصول. في هذه الحالة ، يمكنك إنشاء تطبيقك في Access (باستخدام كائنات الويب) والنشر على SharePoint للمستخدمين لتشغيله في المتصفح. النتائج مكافئة وظيفية بنسبة 100 ٪ (و 90 ٪ بصريًا) ، وتشغيلها على جميع المتصفحات (لا تبعيات خاصة هنا).

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

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

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

هذا لا يعني ذلك سهل - في كثير من الأحيان لا. كما أخبر العملاء طوال الوقت ، من الأسهل عادة بناء منزل جديد بدلاً من إعادة تشكيل منزل قديم. لكن أحد الأسباب التي تجعلنا نعيد إعادة تشكيل المنازل القديمة هو أن لديهم خصائص لا يمكن الاستغناء عنها لا نريد أن نخسرها. غالبًا ما يتضمن تطبيق الوصول ضمنيًا الكثير من قواعد العمل ونمذجة سير العمل التي لا ينبغي أن تضيع في تطبيق جديد (لغز Netscape القديم ، Pace Joel Spolsky). قد لا تكون هذه الأشياء واضحة للمطور الخارجي الذي يحاول نقله إلى منصة مختلفة ، ولكن بالنسبة للمستخدم النهائي ، إذا كان التطبيق قد أحدث نتائج من قبل فلس واحد مقارنة بالتطبيق القديم ، فسيكونون غير راضين (وربما يجب أن يكون ، لأنه قد يعني أن الجوانب الأخرى للتطبيق لا تنتج نتائج موثوقة أيضًا).

على أي حال ، لقد استمرت لفترة طويلة جدًا ، لكن رأيي هو أن التحويل لا يعمل أبدًا باستثناء التطبيقات الأكثر تافهة (أو لتلك التي تم تصميمها ليتم تحويلها ، على سبيل المثال ، تطبيق وصول غير محدود بنسبة 100 ٪). أنا جميعًا من أجل المراجعة بدلاً من الاستبدال.

لكن ، بالطبع ، هذه هي الطريقة التي أجعل بها رزقي ، أي إصلاح تطبيقات الوصول.

Answer 2

حاول؟لا، لقد تم بالفعل إنشاء (أكثر من) محول لغة.

إليك واحدة صممتها أنا (وزملائي في العمل) من أجل قاذفة القنابل الشبح B2 Spirit لتحويل برنامج المهمة، المشفر بلغة قديمة، JOVIAL، إلى كود C قابل للصيانة، مع تحويل آلي بنسبة 100%.كان أحد المتطلبات هو عدم السماح لنا برؤية كود المصدر الفعلي.بلا مزاح.

أنت محق:إذا حصلت فقط على معدل تحويل متوسط ​​مرتفع (على سبيل المثال، 70-80%)، فإن الجهد المبذول لإنهاء التحويل يظل كبيرًا جدًا إذا كان بإمكانك فعل ذلك على الإطلاق.نحن نستهدف 95%+ ونعمل بشكل أفضل عندما يُطلب منا بذل جهد أكبر كما كان الحال بالنسبة لـ B2.السبب الوحيد الذي يجعل الناس يقبلون المحولين ذوي المعدلات المتوسطة المرتفعة هو أنهم لا يستطيعون العثور على (أو لن يمولوا!) محولاً أفضل، ويصرون على البدء الآن, ، وتقبل حقيقة أن تحويله بهذه الطريقة قد يكون مؤلمًا (عادةً لا يعرفون مقداره) ولكنه في الواقع أقل إيلامًا من إعادة بنائه من الصفر.(وأنا أتفق مع هذا التقييم:بشكل عام، عادةً ما تفشل المشروعات التي تحاول إعادة ترميز نظام كبير من البداية، كما أن التحويلات باستخدام أدوات ذات معدل تحويل متوسط ​​مرتفع لا يكون لها معدل فشل مرتفع.)

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

للحصول على مثال سيء بشكل فريد، راجع ردي على سؤال SO هذا حول ترحيل COBOL: تجربة ترحيل Cobol/PL1 القديم إلى Java, ، وهو بالضبط مترجم بيان مباشر ...إنتاج الأشياء التي أدت إلى ظهور مصطلح "JOBOL".

للحصول على معدلات تحويل عالية الدقة، تحتاج إلى محللين ذوي جودة عالية، ووسائل لبناء قواعد ترجمة عالية الجودة تحافظ على الدلالات، وتحسن خصائص اللغة الهدف والحالات الخاصة.في جوهر الأمر، أنت بحاجة إلى ما يرقى إلى مستوى تقنية المترجم القابلة للتكوين.السبب وراء نجاحنا، IMHO، هو لدينا مجموعة أدوات إعادة هندسة برمجيات DMS, ، والتي تم تصميمها للقيام بهذه المهمة.(أنا المهندس المعماري؛تحقق من رمز SO/السيرة الذاتية الخاصة بي).

الكثير من الاختبارات الدقيقة تساعد أيضًا.

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

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

تُستخدم هذه الإمكانية لإنشاء مترجمين (على سبيل المثال، مترجم JOVIAL)، أو مولدات الأكواد الخاصة بالمجال.

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

Answer 3

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

• يجب أن تكون الترجمة من C ++ إلى C سهلة نسبيًا ، ولكن ترجمة C إلى اصطلاحي سيكون C ++ بجوار مستحيل لأن ذلك سيكون بجوار تحويل برنامج إجرائي تلقائيًا إلى برنامج OO.

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

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

ما يعنيه هذا هو أن بعض المترجمين بالضرورة ستكون أكثر نجاحًا من غيرها من حيث:

• اكتمال ودقة الترجمة ، و
• قابلية القراءة والصيانة للرمز الناتج.

Answer 4

الأشياء التي يجب ألا تفعلها أبدًا ، الجزء الأول بقلم جويل سبولسكي

".... لقد فعلوا ذلك من خلال ارتكاب أسوأ خطأ استراتيجي يمكن لأي شركة برمجيات ارتكابها:

قرروا إعادة كتابة الكود من الصفر ".

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

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

Answer 5

لقد استخدمت محولًا آليًا من C# إلى Visual Basic.net. لقد عملت بشكل جيد باستثناء إضافة بعض غير ضروري If True صياغات.

لقد حاولت أيضًا الاستخدام سفك الجلد لتحويل Python إلى C ++ ، لكنه لم ينجح بسبب افتقاره إلى دعم التقسيم على الطراز الجديد.

Answer 6

لقد استخدمت أدوات لتحويل مشروع VB6 إلى vb.net - والتي تأمل أن تكون واحدة من الأمثلة الأكثر بساطة لهذا النوع من الأشياء. كانت تجربتي هي أنه كان لا بد من فحص كل شيء ، وتفاصيل دقيقة ، وكان نصف الأشياء مفقودة / خاطئة.

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

مارتن

Answer 7

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

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