← All posts tagged oberon

OCTAGRAM

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

* JDK 1.0 native method interface
* Netscape’s Java Runtime Interface
* Microsoft’s Raw Native Interface and Java/COM interface
* Java Native Interface
* Java Native Access

Одновременно несмотря на претензии типо-Java-вости и украденных идей со стороны некоторых адвокатов Оберона я что-то не припоминаю, чтоб было какое-то аналогичное соревнование, как лучше совместить код на Обероне с другими языками программирования. По ключевым словам «Oberon Runtime Interface» и «Oberon Native Interface» ничего не находится. А было ли что красть?

И вообще, это надо ещё сильно постараться поискать, чтобы узнать, как обстоят дела в конкретной реализации, если скомпилировать динамическую библиотеку классов и приложение, а потом к библиотеке применить описанные в докладе трансформации и перекомпилировать её, а приложение — нет. Покажи адвокату Оберона таблицу из доклада — сможет ли он там расставить крестики и галочки для знакомых ему реализаций?

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