История изменений
Исправление hobbit, (текущая версия) :
Ближе всего к истине ответ выше:
Востребованность в индустрии, когда знание данного ЯП позволяет создавать реальные полезные для общества системы, и делать это в течение длительного временного интервала (а не просто прибежал-наложил-убежал).
Вот представьте себе. Жил-был язык X. Развивался довольно долго. На нём ещё и писали. И написали много полезного.
А тут появляется язык Y. И начинают писать на нём. А будут ли развиваться старые опенсорсные программы, написанные на X? Уже довольно давно можно слышать жалобы: «это написано на Си, поддерживать это невозможно». А в последнее время, пока не очень громко, то же самое начинают говорить про C++. Программисты начинают ваять с нуля на новом языке, на старый забивают.
А сейчас ещё и бегут в разные стороны: кто-то на Rust, кто-то на Go, кто-то, возможно, на Vala. А если вдруг потребуется объединить их усилия?.. Опенсорс отбрасывается на несколько лет назад.
Я не случайно подчёркиваю, что речь именно про опенсорс. Коммерция может ваять свои закрытые поделия на чём угодно, если есть ресурсы. Но кстати, внезапно, именно коммерция в этом плане очень консервативна и неспроста. Потому, что считает деньги.
Проблема была бы менее острой, если межъязыковое взаимодействие было более гладким. Для этого, на мой взгляд, нужен кросс-языковый стандарт на модули. Не на объектные файлы, как сейчас, а именно на модули. Объектный файл — это только часть модуля. Модуль должен запоминать, что откуда он экспортировал. Вот если я в объектном паскале написал uses, после компиляции уже известно, куда лезть за скомпилированным кодом. В C/С++ известно только, что есть такое неразрешённое имя, искать будем везде.
И сами имена должны сохраняться в таком формате, чтобы линкер, обрабатывая объектник от языка Y, нашёл в объектнике от языка X не просто имя, а имя функции/метода/переменной определённого типа и с соответствующими параметрами. Насколько я понимаю, сейчас такое умеет C++ для функций и методов, которые откомпилированы только в C++ же. А с другими языками?.. Впрочем, в этом пункте мои знания могут быть устаревшими.
И даже наличие стандарта на модули всех проблем не решит. Разные языки используют разные рантайм-библиотеки. А хуже всего, когда надо наладить взаимодействие нативно компилируемого кода с чем-то ещё. Как-то проблему решили в Java (JNI)…
Исправление hobbit, :
Ближе всего к истине ответ выше:
Востребованность в индустрии, когда знание данного ЯП позволяет создавать реальные полезные для общества системы, и делать это в течение длительного временного интервала (а не просто прибежал-наложил-убежал).
Вот представьте себе. Жил-был язык X. Развивался довольно долго. На нём ещё и писали. И написали много полезного.
А тут появляется язык Y. И начинают писать на нём. А будут ли развиваться старые опенсорсные программы, написанные на X? Уже довольно давно можно слышать жалобы: «это написано на Си, поддерживать это невозможно». А в последнее время, пока не очень громко, то же самое начинают говорить про C++. Программисты начинают ваять с нуля на новом языке, на старый забивают.
А сейчас ещё и бегут в разные стороны: кто-то на Rust, кто-то на Go, кто-то, возможно, на Vala. А если вдруг потребуется объединить их усилия?.. Опенсорс отбрасывается на несколько лет назад.
Я не случайно подчёркиваю, что речь именно про опенсорс. Коммерция может ваять свои закрытые поделия на чём угодно, если есть ресурсы. Но кстати, внезапно, именно коммерция в этом плане очень консервативна и неспроста. Потому, что считает деньги.
Проблема была бы менее острой, если межъязыковое взаимодействие было более гладким. Для этого, на мой взгляд, нужен кросс-языковый стандарт на модули. Не на объектные файлы, как сейчас, а именно на модули. Объектный файл — это только часть модуля. Модуль должен запоминать, что откуда он экспортировал. Вот если я в объектном паскале написал uses, после компиляции уже известно, куда лезть за скомпилированным кодом. В C/С++ известно только, что есть такое неразрешённое имя, искать будем везде.
И сами имена должны сохраняться в таком формате, чтобы линкер, обрабатывая объектник от языка Y, нашёл в объектнике от языка X не просто имя, а имя функции с соответствующими параметрами. Насколько я понимаю, сейчас такое умеет C++ для функций и методов, которые откомпилированы только в C++ же. А с другими языками?.. Впрочем, в этом пункте мои знания могут быть устаревшими.
И даже наличие стандарта на модули всех проблем не решит. Разные языки используют разные рантайм-библиотеки. А хуже всего, когда надо наладить взаимодействие нативно компилируемого кода с чем-то ещё. Как-то проблему решили в Java (JNI)…
Исправление hobbit, :
Ближе всего к истине ответ выше:
Востребованность в индустрии, когда знание данного ЯП позволяет создавать реальные полезные для общества системы, и делать это в течение длительного временного интервала (а не просто прибежал-наложил-убежал).
Вот представьте себе. Жил-был язык X. Развивался довольно долго. На нём ещё и писали. И написали много полезного.
А тут появляется язык Y. И начинают писать на нём. А будут ли развиваться старые опенсорсные программы, написанные на X? Уже довольно давно можно слышать жалобы: «это написано на Си, поддерживать это невозможно». А в последнее время, пока не очень громко, то же самое начинают говорить про C++. Программисты начинают ваять с нуля на новом языке, на старый забивают.
А сейчас ещё и бегут в разные стороны: кто-то на Rust, кто-то на Go, кто-то, возможно, на Vala. А если вдруг потребуется объединить их усилия?.. Опенсорс отбрасывается на несколько лет назад.
Я не случайно подчёркиваю, что речь именно про опенсорс. Коммерция может ваять свои закрытые поделия на чём угодно, если есть ресурсы. Но кстати, внезапно, именно коммерция в этом плане очень консервативна и неспроста. Потому, что считает деньги.
Проблема была бы менее острой, если межъязыковое взаимодействие было более гладким. Для этого, на мой взгляд, нужен кросс-языковый стандарт на модули. Не на объектные файлы, как сейчас, а именно на модули. Объектный файл — это только часть модуля. Модуль должен запоминать, что откуда он экспортировал. Вот если я в объектном паскале написал uses, после компиляции уже известно, куда лезть за скомпилированным кодом. В C/С++ известно только, что есть такое неразрешённое имя, искать будем везде.
И сами имена должны сохраняться в таком формате, чтобы язык Y нашёл в объектнике от языка X не просто имя, а имя функции с соответствующими параметрами. Насколько я понимаю, сейчас такое умеет C++ для функций и методов, которые откомпилированы только в C++ же. А с другими языками?.. Впрочем, в этом пункте мои знания могут быть устаревшими.
И даже наличие стандарта на модули всех проблем не решит. Разные языки используют разные рантайм-библиотеки. А хуже всего, когда надо наладить взаимодействие нативно компилируемого кода с чем-то ещё. Как-то проблему решили в Java (JNI)…
Исходная версия hobbit, :
Ближе всего к истине ответ выше:
Востребованность в индустрии, когда знание данного ЯП позволяет создавать реальные полезные для общества системы, и делать это в течение длительного временного интервала (а не просто прибежал-наложил-убежал).
Вот представьте себе. Жил-был язык X. Развивался довольно долго. На нём ещё и писали. И написали много полезного.
А тут появляется язык Y. И начинают писать на нём. А будут ли развиваться старые опенсорсные программы, написанные на X? Уже довольно давно можно слышать жалобы: «это написано на Си, поддерживать это невозможно». А в последнее время, пока не очень громко, то же самое начинают говорить про C++. Программисты начинают ваять с нуля на новом языке, на старый забивают.
А сейчас ещё и бегут в разные стороны: кто-то на Rust, кто-то на Go, кто-то, возможно, на Vala. А если вдруг потребуется объединить их усилия?.. Опенсорс отбрасывается на несколько лет назад.
Я не случайно подчёркиваю, что речь именно про опенсорс. Коммерция может ваять свои закрытые поделия на чём угодно, если есть ресурсы. Но кстати, внезапно, именно коммерция в этом плане очень консервативна и неспроста. Потому, что считает деньги.
Проблема была бы менее острой, если межъязыковое взаимодействие было более гладким. Для этого, на мой взгляд, нужен кросс-языковый стандарт на модули. Не на объектные файлы, как сейчас, а именно на модули. Объектный файл — это только часть модуля. Модуль должен запоминать, что откуда он экспортировал. Вот если я в объектном паскале написал uses, после компиляции уже известно, куда лезть за скомпилированным кодом. В C/С++ известно только, что есть такое неразрешённое имя, искать будем везде.
И сами имена должны сохраняться в таком формате, чтобы язык Y нашёл в объектнике от языка X не просто имя, а имя функции с соответствующими параметрами. Насколько я понимаю, сейчас такое умеет C++ для функций и методов, которые откомпилированы только в C++ же.
И даже наличие стандарта на модули всех проблем не решит. Разные языки используют разные рантайм-библиотеки. А хуже всего, когда надо наладить взаимодействие нативно компилируемого кода с чем-то ещё. Как-то проблему решили в Java (JNI)…