Есть ли какие-либо недостатки в том, что язык не зависит от платформы? - PullRequest
5 голосов
/ 14 февраля 2010

Я работаю над статьей о многоплатформенном программировании и хотел бы включить разделы о преимуществах / недостатках. Из моего понимания; мультиплатформенность любого приложения является огромным преимуществом для разработчика, поскольку, помимо прочего, оно позволяет практически любому пользователю компьютера стать потенциальным покупателем. Я просто пытаюсь выяснить возможные недостатки. Если есть?

Ответы [ 8 ]

2 голосов
/ 14 февраля 2010

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

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

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

Веб-браузеры являются наиболее распространенным примером этого. Если у вас есть хороший браузер, он интерпретирует стандартный веб-код (HTML / CSS / JS и т. Д.) И заботится о том, как отобразить его на вашей конкретной платформе, вместо того, чтобы составитель кода должен был учесть эти различия.

2 голосов
/ 14 февраля 2010

А как насчет "мастера на все руки, мастера нет"?

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

Это не относится к усилиям сообщества, где ресурсы в изобилии, такие как Perl.

2 голосов
/ 14 февраля 2010

Есть ли недостатки у языка (задается в заголовке) как независимого от платформы?

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

Я должен добавить, что вам не обязательно писать много кода; тебе просто нужно больше думать. Lua является хорошим примером независимого от платформы языка без большой реализации. GHC наоборот: много кода для достижения высокой производительности на многих платформах - но одна система времени выполнения в четыре раза больше, чем в Unix версии 6!

1 голос
/ 14 февраля 2010

Основной недостаток - вы не можете использовать специфичные для платформы улучшения ...

Это более философский вопрос - где граница между языковыми и компиляторскими способностями ...

вы можете написать код DirectX .. но для того же результата происходят в Linux ...

0 голосов
/ 14 февраля 2010

Спроси у ВС Как все это сработало на Java для компании? (да, я знаю, образец 1 и все)

В данном случае я смотрю на это с точки зрения поставщика. Они создали язык, который, хотя и был популярен, не делал ничего, чтобы использовать (реальную!) Силу продаваемой ими ОС. Он должен был работать на Windows, со всей этой бессмысленной чепухой, что такое влечет за собой. Вы хотите отключить дочерний процесс и открыть канал или два между родительским и дочерним процессами? Очень плохо. Веселитесь со своими ошибками темы. Получайте удовольствие от медленного ввода-вывода файлов. (когда, если вообще, Java наконец включила реализацию nio ?)

Microsoft, конечно, не сделала такой ошибки с .NET. И они сосредоточились на улучшении языковых возможностей, вместо того чтобы тратить ресурсы на несколько реализаций времени выполнения.

0 голосов
/ 14 февраля 2010

Common Lisp - это как пример на этом! : -)

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

Другими словами, они пытались быть независимыми от платформы, и это только увеличивало сложность практически без выгоды. Одним классическим примером является подсистема имени пути; подпись функции make-pathname выглядит следующим образом:

make-pathname &key host device directory name type version defaults case

В 1980-х годах, когда он был стандартизирован, могло показаться разумным включить встроенную поддержку очень богатых файловых систем, но я не видел VAX (или любой другой системы с файловой системой с версиями) более 10 лет. Сегодня сложность в том, что большинству людей наплевать на . (Я знаю, что имена путей и логические пути являются технически отдельными функциями, но они не так уж далеки от того, что они пытаются сделать.)

Как программист, вы никогда не сможете угадать, в какой области вам понадобится гибкость в будущем, или даже по какой оси вы захотите гибкости - программисты это хорошо знают, вот почему такие глупые слова, как «agile», имеют стать общим. При разработке независимого от платформы языка вы имеете дело с худшим из обоих миров: языки предназначены для абстракции, а платформы очень конкретны. Конечно же, каждый независимый от платформы язык полон приличного количества отстой, от C до.

0 голосов
/ 14 февраля 2010

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

0 голосов
/ 14 февраля 2010

Основные недостатки:

  • Дополнительное время для разработки из-за различий в платформах (например, доступ к файловой системе различается на разных платформах)
  • Требуется гораздо больше тестирования и, следовательно, гораздо большие затраты на тестирование на нескольких поддерживаемых платформах.
...