Які проблеми можуть виникнути при емуляції понять з інших мов?

12

Я багато разів читав в Інтернеті, що якщо ваша мова не підтримує якусь концепцію, наприклад, орієнтацію на об'єкт або, можливо, виклики функцій, і це вважається хорошою практикою в іншому контексті, ви повинні це зробити.

Єдина проблема, яку я бачу зараз, - це те, що інші програмісти можуть знайти ваш код занадто іншим, ніж звичайний, що ускладнює їх програмування. Які інші проблеми, на вашу думку, можуть виникнути з цього приводу?

programming-languages concepts idioms

— Хуліо Родрігес
джерело

3

Люди знущаються з вас, з одного боку :-)

— Карл Білефельдт

Я переклав вкладений аналізатор функцій з D в java один раз, але визнаю, це не найчистіший фрагмент коду, який я коли-небудь писав (одна велика функція з інтерфейсом і кілька класів, що реалізують її, визначені всередині неї)

— ratchet freak

23

Однією з проблем є те, що ви можете виявити, що ви пишете багато коду, щоб висловити щось таким чином, як це зробите на іншій мові, в той час як існує більш простий спосіб у мові, якою ви користуєтесь.

Наприклад, у відповіді на переповнення стека я пояснив, як контракти з кодами, концепція, що використовується в .NET Framework, можуть бути частково імітовані в PHP, який не підтримує їх. Я в кінці кінців писав багато коду, оскільки те саме можна було зробити і з простими масивами.

Більш загально, кожна мова має свою культуру, свої найкращі практики, свій стиль.

Якщо я почну писати код C #, як це був C, це було б некрасиво.
Якщо я сприймаю Haskell як розробника Java, який був змушений використовувати Haskell, але не хочу зрозуміти його сильні сторони і просто хочу клонувати поняття Java, код, який я б написав, постраждає.
тощо.

Немає нічого поганого, намагаючись вдосконалити мову (наприклад, підвищити C # , ввівши одиниці виміру, як у F #), але якщо ви робите це занадто багато, можливо, ви повинні вибрати іншу мову, яка фактично відповідає вашим потребам.

— Арсеній Муренко
джерело

+1 Хороша відповідь і дякую за додаткові пошукові терміни з додаванням одиниць виміру до C #, як у F #.

2

Як той, хто колись кинув свою роботу через те, що був змушений користуватися Java, мої 2 копійки: ніхто не може змусити його використовувати Haskell, хтось закохується в нього, і тоді він засмоктує тебе до того, що не повернешся. Haskell - це як одна прекрасна чорна діра, в яку ти просто хочеш потрапити - і на відміну від справжньої, ти все ще живеш, щоб розповісти казку :)

— Cetin Sert

можливо, ви повинні вибрати іншу мову ... за винятком випадків, коли у вас немає вибору, наприклад JavaScript на стороні клієнта. (Тим не менш, вибір не є приводом для впровадження емуляції OOP на основі класу на мові прототипу. Набагато ефективніше просто дізнатися, як працює мова.)

— kojiro

@kojiro: або інша робота. У мене була така сама проблема, коли мене змушували використовувати PHP, і я постійно намагався змінити мову, включаючи написання власного компілятора. Менш божевільним рішенням було змінити роботу і почати працювати лише над проектами, які не використовують PHP.

— Арсеній Муренко

1

@Cetin Sert: погодьтеся, Haskell - чудова мова. Але якщо хтось не хоче цього вивчати і не розуміє функціонального програмування, було б важко оцінити Haskell.

— Арсеній Муренко

10

Падіння читабельності є достатньою проблемою саме по собі: це різко зменшує коло людей, які потенційно могли б підтримувати ваш проект, не маючи широкої підготовки від вас.

В додаток,

Реалізація іноземної парадигми може коштувати дорожче, ніж потенційна економія від її використання
Ваша адаптація закордонного функціоналу може бути невдалою, збільшуючи витрати на обслуговування
Ваша адаптація зарубіжної функціональності може підштовхнути стек технологій до тих меж, що перевищують необхідні для вашої рідної реалізації.

— dasblinkenlight
джерело

2

Мені колись довелося емулювати динамічну диспетчерку C ++ (віртуальні таблиці тощо) у ванілі C і зіткнувся саме з цією проблемою: програмісти на С, які не розуміли динамічної диспетчеризації, не змогли внести свій внесок у проект або підтримати його.

— прийде штурм

4

Це не така гарна ідея, як це з’являється на папері.

Приклад 1: Якщо ви досить дорослі, ви можете згадати дні, коли С був новим малюком у місті. Програмістам Паскаля та Ада не сподобалося коротких брекетів відкритого та закритого типу C. Вони # визначились beginі endвідкрити дужку і закрити дужку, і вуаля! CAda! Невдалий результат був некрасивим з точки зору або Ада, або С.

Приклад 2, особистий: Однією з речей, які мені дуже сподобалися в системі Common Lisp Object System, є це методи до, після та навколо. Вони можуть стати дуже зручними у багатьох місцях. Тому я наслідував цю концепцію в C ++ у кількох обраних місцях. Єдиний спосіб емуляції цих конструкцій в C ++ - це вимагати від розробника похідного класу викликати однойменний метод батьківського класу в потрібному місці в коді. Це ставило вимогу до розробників, які отримали з моїх класів, які були трохи чужими для програмування на C ++ і, можливо, проти зерна програмування на C ++. Як би добре не було зафіксовано цю вимогу, люди просто не дотримувались інструкцій, оскільки вона не зовсім відповідала парадигмі C ++.

— Девід Хаммен
джерело

2

Які проблеми можуть виникнути при емуляції понять з інших мов?

Витікаючі абстракції.

— Джим Г.
джерело

Можливо, було б добре включити ще кілька деталей у відповідь. У статті йдеться про випадок, коли абстракція не вдається досягти значної оптимізації продуктивності, але я б сказав, що більші проблеми виникають із-за непослідовної поведінки у кутових випадках та непослідовних гарантій; прикладом останнього може бути спроба C # емуляції outпараметрів у рамках, який насправді їх не підтримує; C # передбачає, що кожна функція завжди записуватиме всі її outпараметри, але не-C # методи, викликані методами C #, не дають такої гарантії.

— supercat

1

Це може бути надзвичайно важко. Уявіть, що намагаєтеся реалізувати LINQ з C # у вашій програмі Java. А як щодо того, щоб просто додати лексичні закінчення до мови? Ви майже повинні були б написати новий компілятор, який в значній мірі дає вам нову мову.

Або для випадків, коли вам не доведеться реалізовувати власну мову, просто уявіть, що намагаєтеся реалізувати методи збирання, використовуючи функції вищого порядку (наприклад, карта) мовою, яка не має блоків коду чи лямбда-функцій чи закриттів або функцій, як перших об’єкти класу. Кожна функція вищого порядку повинна бути оголошена як інтерфейс і явно реалізована, і все стан, який був би захоплений у закритті, повинен бути явно збережений у класі реалізації. Настільки багато зайвого набору тексту та настільки важче для читання, що часто цього не варто.

— psr
джерело