Какие проблемы могут возникнуть при эмуляции понятий из других языков?

12

Я много раз читал в Интернете, что если ваш язык не поддерживает какую-либо концепцию, например, объектную ориентацию или, возможно, вызовы функций, и это считается хорошей практикой в этом другом контексте, вам следует это сделать.

Единственная проблема, которую я вижу сейчас, состоит в том, что другие программисты могут найти ваш код слишком отличным от обычного, что затрудняет их программирование. Какие еще проблемы, по вашему мнению, могут возникнуть из-за этого?

programming-languages concepts idioms

— Хулио Родригес
источник

3

Люди будут смеяться над тобой, с одной стороны :-)

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

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

— ratchet freak

23

Одна из проблем заключается в том, что вы можете написать много кода, чтобы выразить что-то, как вы это делаете на другом языке, в то время как в используемом вами языке есть более простой способ.

Например, в ответе на Stack Overflow я объяснил, как контракты кода, концепция, используемая в .NET Framework, могут частично эмулироваться в PHP, который их не поддерживает. В итоге я написал много кода даром, поскольку то же самое можно было выполнить с простыми массивами.

В целом, у каждого языка есть своя культура, свои лучшие практики, свой стиль.

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

Нет ничего плохого в том, чтобы улучшить язык (например, улучшить C # , введя единицы измерения, как в F #), но если вы делаете это слишком много, вам, возможно, следует выбрать другой язык, который действительно соответствует вашим потребностям.

— Арсений Мурзенко
источник

+1 Хороший ответ, и спасибо за дополнительные условия поиска с добавлением единиц измерения к C #, как в F #.

2

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

— Cetin Sert

возможно, вам следует выбрать другой язык ... за исключением случаев, когда у вас нет выбора, например, на стороне клиента JavaScript. (Несмотря на это, отсутствие выбора не является оправданием для реализации эмуляции ООП на основе классов в языке-прототипе.

— Гораздо

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

— Арсений Мурзенко

1

@Cetin Sert: согласен, Haskell - отличный язык. Но если кто-то не хочет изучать это и не понимает функциональное программирование, было бы трудно оценить Haskell.

— Арсений Мурзенко

10

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

К тому же,

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

— dasblinkenlight
источник

2

Однажды мне пришлось эмулировать динамическую диспетчеризацию C ++ (виртуальные таблицы и т. Д.) В vanilla C, и я столкнулся именно с этой проблемой: программисты на C, которые не понимали динамическую диспетчеризацию, не могли внести свой вклад или поддержать проект.

— наступающий шторм

4

Это не такая хорошая идея, как кажется на бумаге.

Пример 1: Если вы достаточно взрослый, вы можете вспомнить дни, когда С был новым ребенком в городе. Программистам на Паскале и Аде не нравились краткие открытые и закрытые скобки Си. Они # определили beginи endоткрыть скобку и закрыть скобку, и вуаля! Када! Печальный результат был ужасен с точки зрения Ады или Си.

Пример 2, личный: Одна из вещей, которые мне действительно понравились в Common Lisp Object System - это методы до, после и вокруг. Они могут очень пригодиться в разных местах. Поэтому я эмулировал эту концепцию в C ++ в нескольких избранных местах. Единственный способ эмулировать эти конструкции в C ++ - это потребовать от разработчика производного класса вызвать метод родительского класса с тем же именем в нужном месте кода. Это накладывало требование на разработчиков, которые унаследовали мои классы, что было немного чуждо программированию на C ++ и, возможно, противоречило программированию на C ++. Независимо от того, насколько хорошо задокументировано это требование, люди просто не следовали рекомендациям, потому что оно не совсем соответствовало парадигме C ++.

— Дэвид Хаммен
источник

2

Какие проблемы могут возникнуть при эмуляции понятий из других языков?

Утечка абстракций.

— Джим Г.
источник

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

— суперкат

1

Это может быть слишком сложно. Представьте, что вы пытаетесь внедрить LINQ из C # в ваше Java-приложение. Или как насчет простого добавления лексических замыканий в язык? Вам, скорее всего, придется написать новый компилятор, который в значительной степени дает вам новый язык.

Или, в случаях, когда вам не нужно реализовывать свой собственный язык, просто представьте, что вы пытаетесь реализовать методы сбора, используя функции более высокого порядка (например, map), в языке, который не имеет блоков кода, или лямбда-функций, или замыканий, или функций в первую очередь. Объекты класса. Каждая функция более высокого порядка должна быть объявлена как интерфейс и реализована явно, и все состояния, которые были бы захвачены в замыкании, должны быть явно сохранены в реализующем классе. Это так много лишнего набора текста и так сложно читать, что часто оно того не стоит.

— PSR
источник