LINUX.ORG.RU

Почему ООП стало более популярным и соответствующие языки и технологии программирования чем то же ФП?

 ,


2

4

Заранее прошу прощения за то, что не в Talks, а сюда. Так получается, что теперь в Talks просто так постить нельзя, нужна некая карма и я должен «страдать» (Почему я не могу писать в раздел Talks? (комментарий)). Я в упор не помню данные своего старого аккаунта. Зарабатывать карму здесь и сейчас у меня нет ни времени, ни возможности, ни необходимости. Почему сюда, а не на другие форумы? Потому что считаю, что здесь обитают люди, которые смогут ответить на вопросы ниже и, возможно, даже, которые застали те самые времена (если конечно те самые люди ещё здесь).

Всем доброго времени суток! Не срача ради, а понимания для. Хочется понять историчность и почему так произошло. Понятно, что сейчас уже стали внедрять функциональные фичи много куда (в те же Java, C++, C# и т.д.). Стало появляться много функциональных языков (в том числе совсем новых). Но почему спустя столько времени? Почему спрашиваю:
- Functional programming has its origins in lambda calculus, a formal system developed in the 1930s (!!!) to investigate computability, the Entscheidungsproblem, function definition, function application, and recursion. Many functional programming languages can be viewed as elaborations on the lambda calculus (отсюда: https://en.m.wikipedia.org/wiki/Functional_programming);
- Lisp появился ажно в 1958 году;
- после лиспа ещё была целая куча функциональных языков (APL, IPL, ML, Miranda, Erlang, etc.);
- C++ в 1985;
- Haskell в 1990;
- Java в 1995;

Сама идея ООП (и то я так понял весьма размытая, каждый понимал (и, кстати, по-моему до сих пор понимает) по-своему) вроде как витала со времени создания самого лиспа, но до конкретных реализаций она добралась ближе к концу 80-х - начала 90-х годов.
(поправьте меня, если не прав)
И это ещё при всём при том, что ФП имеет под собой весьма конкретный математический базис (чего я, пожалуй, не могу сказать про ООП).
Я так понял, что благодаря таким крупным компаниям как Microsoft, Oracle...
Но почему они так сильно повлияли на развитие этих технологий и как именно они это сделали я, честно говоря, не совсем понимаю.
Ок, ладно, тогда железо было не такое как сейчас, памяти было маловато для нормального существования функциональных языков на x86 платформе.
Но ведь была же та же, например, Symbolics, которая вроде бы весьма активно продавала лисп-машины?
Ок, Symbolics развалилась благодаря неблагоприятному стечению обстоятельств и «эффективным» манагерам, но их наработки оказались никому не нужны что ли?
И опять-таки, когда нужное железо появилось почему выбор этих и других крупных компаний пал именно на эти языки?
Почему не на функциональные языки?
Потому что в то время функциональные языки в основном использовались сугубо в академической среде или как?
Или если перефразировать всё вышесказанное словами моего коллеги: «если всё так круто (про ФП), то почему оно ещё не захватило рынок?»

Ответ на: комментарий от arturianec100

То написание на си плохо, то теперь уже на си - хорошо, но вместе с питоном, а не башем.

Ты пишешь на крестах, но библиотека у тебя на сях - на чем в итоге у тебя получится продукт?
В Hg на Cи написана меньшая часть кода, а большая часть логики работает в питоне, который идеально подходит для задачи.
В то же время, баш ужасно подходит для сложных задач, потому пришлось много чего засовывать в хитросплетенный клубок кода на си, который дергается из баша. Один из результатов - заслуженное звание у git «самый сложный интерфейс среди систем управления версиями кода».

Какую прикладную программу он писал на Qt?

https://github.com/torvalds/subsurface-for-dirk
Гуглится на раз-два.

К сожалению, нет. Эту программу торвальдс написал на Си и GTK. Кто и когда ее переписывал на Qt - не знаю, с тех пор структура файлов в репозитории полностью изменилась.

Имхо, в наса правильно организовали процессы. Говнокод сурово отсеивают + «писать программы для запуска космических ракет» - даже последний дурак знает, что туда идут одни из самых топовых специалистов, там жёсткий отбор и сразу настройка «писать надёжно», а не «успеть до дедлайна».

Там нет никаких стимулов, вроде холодной войны или космической гонки, наса нынче - это вполне обычная контора, которая тот же питон использует, хоть и не на самих запускаемых аппаратах. Причем, на аппаратах предпочитают использовать старые программы на старом оборудовании вместо разработки новых. Например, THEMIS в 2007 летал на 8-битном Intel 8085, созданном в 1976 году, когда у НАСА еще было достойное финансирование. Когда у тебя девайсы на таком древнем оборудовании - у тебя не особо много вариантов для софта. Они, по сути, не разрабатывают технологии, а поддерживают их.

А видал пусковые комплексы для МКБР с 5-дюймовыми дискетами? Ядерный арсенал подобная участь постигла, и никаких разработок новых там не ведется.

Лисп, раст - нет, это вполне прагматичные языки.

Что на них ценного и уникального написали?

Объясняю. Что ценного и уникального написали на питоне? Ютьюб? Гугл? Но ты не видел ни строчки кода ютьюба или гугла, правильно? А, тем не менее, миллионы строчек кода написаны. Точно так же на лиспе делались огромные проекты под конечную задачу, но они не были опубликованы. Вот эта штука, например, была на лиспе сделана https://www.cleartrip.com/ Или вот эта https://en.wikipedia.org/wiki/Dynamic_Analysis_and_Replanning_Tool , или эта https://en.wikipedia.org/wiki/Mirai_(software). Но все эти системы в опенсорс не попали. В открытом же доступе остались только мелкие/средние библиотеки/фреймворки, которые нынче забываются в связи с переходом от CL на более современные диалекты.

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

То есть, ты хочешь сказать, что на Си пишут потому, что это такой простой, чистый, понятный, удобный язык

Си очень простой в том плане, что все внутренние механизмы работы прозрачны и понятно «как работает под капотом». Это важно для лоулевела. Ну а за счёт фундаментальности и гибкости на си пишут вопреки его неудобству для большинства кодеров.

Разговор шел о том, что нам не важны готовые решения, нам не важен оптимизирующий компилятор - мы просто выбираем язык, который нам удобен, а потом уже когда-нибудь может быть будем оптимизировать. Тогда можешь мне пояснить, почему они писали не на фортране, не на коболе, не на крестах, не на паскале, не на лиспе, не на схеме - а на Си? Он настолько удобен, гибок, фундаменталенг, что с ним даже кресты не нужны? Может быть популяризаторы крестов вообще ничего не понимали в программировании? Зря создали язык - могли бы писать на Си всё, он же удобнее.
Про «внутренние механизмы работы прозрачны и понятно „как работает под капотом“» можно согласиться - правда, не ясно, почему Си, а не Ассемблер - вот где-где, а в нем уж точно всё понятно как устроено.

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

Можно говорить о том, что человек, который стоит на твердой земле, не имеет никаких преимуществ над человеком, идущим по канату над пропастью. Мол, не разобьется, опора не имеет значения, потому что процесс ориентирован на надежность, а не на скорость, а на земле на тебя может упасть астероид или ИГИЛ вылезет из канализационного люка - никто не застрахован, правильно? Но подует ветерок, покачнется человечек, полетит вниз, и не соберут человечка больше.

Разработка большой системы на Си подразумевает большой риск, потому, например, никакой банк не будет строить свою логику на Си, иначе весь банк рискует от дуновения ветра сорваться и упасть в пропасть. По этой причине в ответственных приложениях довольно долго применяли Кобол - он дает намного меньше неожиданностей, чем Си, хоть и тоже не отличается особой высокоуровневостью, казалось бы. Сколько космических аппаратов было потеряно из-за элементарнейших ошибок в программе?
https://ru.wikipedia.org/wiki/Маринер-1
https://en.wikipedia.org/wiki/Cluster_(spacecraft)
https://ru.wikipedia.org/wiki/Mars_Polar_Lander
https://ru.wikipedia.org/wiki/Mars_Climate_Orbiter
https://ru.wikipedia.org/wiki/Венера-3
https://www.businessinsider.com/nasa-voyager-probes-rocket-leak-computer-prob... - Оба вояжера живы, но поволноваться они заставили солидно. А сколько ошибок софта оказалось не удалось расследовать из-за недоступности/разрушения аппарата?

Язык оказался достаточно простым, чтобы запилить ide, «читающие мысли»

Ты хотел сказать «костыль, читающий мысли»? Язык программирования - это программа для транслятора, прежде всего, и транслятор должен читать мысли. Но очень скоро выяснилось, что без костылей писать на жаве просто невыносимо. Фактически можно говорить о том, что был создан совершенно новый инструмент разработки «Java+IDE». Ну, примерно как документ в MS Word - это не просто текст, это все-таки «MS Word+текст», они уже неотрывны. Для какого-нибудь Latex, однако, не нужно никакой IDE - он сам по себе является достаточно удобным инструментом. А вот Java не является достаточно удобным инструментом, потому для нее нужны дополнительные инструменты - костыли.

Царь уже ответил - gnuc с _cleanup_fclose_ FILE *f = NULL;, _cleanup_free_ char *p = NULL;

Ну вот же, другое дело. Правда, что ты будешь делать, когда в функции нужно будет вызывать cleanup только для выделенного ресурса или когда само высвобождение выдает ошибку - мне не совсем ясно. Сейчас функции высвобождения ресурсов реализованы как-то так:
systemd/src/basic/fd-util.c

int fclose_nointr(FILE *f) {
        assert(f);
        if (fclose(f) == 0)
                return 0;
        if (errno == EINTR)
                return 0;
        return -errno;
}
FILE* safe_fclose(FILE *f) {
        if (f) {
                PROTECT_ERRNO;
                assert_se(fclose_nointr(f) != -EBADF);
        }
        return NULL;
}

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

Опачки.

Небезызвестный Оракл - это незамутненная сишечка. Что там у нас в основе банковской и прочей деятельности связанной с контролем\учетом ?

Постгрес в качестве альтернативы? Ооок, но постгрес - тоже не питон, и даже мысли ни у кого не возникает.

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

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

Задач типа quick'n'dirty в банковской сфере (как впрочем и в любой другой) тоже хватает. Для задач такого рода какая-нибудь модная платформа - самое оно. Апатамушта там не надо изысков.

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

Остаются рюшечки. Но это уже хоть на чем, плюс-минус.

что ты будешь делать, когда в функции нужно будет вызывать cleanup только для выделенного ресурса или когда само высвобождение выдает ошибку - мне не совсем ясно

Никого не хочу обидеть, но писать на си - это не твое.

Финальное итого.

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

anonymous
()
Ответ на: комментарий от anonymous

Небезызвестный Оракл - это незамутненная сишечка. Что там у нас в основе банковской и прочей деятельности связанной с контролем\учетом ?

Блин, ну оракель - это слишком тонко. Ты бы лучше вспомнил ОС, которые написаны на C/C++, и которые составляют основную угрозу для серьезных дядь. Базу данных-то можно изолировать, но как изолировать ОС, которая должна принимать данные по сети, читать-писать файлы? При этом, абсолютно все ОС - это дырявые друшлаги, в которых регулярно находят удаленное выполнение кода. И именно потому, что от них требуется высокая производительность - отсюда Asm/C/C++ и большое число багов.

Для решения этих проблем серьезные дяди, во-первых, используют оттестированные вдоль и поперек сторонние решения, как тот же оракл, а во-вторых, изолируют это стороннее решение от любых возмущений, не связанных с непосредствено возлагаемыми задачами. То есть, не вот эта твоя фантазия про «мы будем хорошими кодерами, тщательно спланируем архитектуру и будем безошибочно ее реализовывать», а более реалистичный подход «программа на Си точно будет иметь много ошибок - давайте попытаемся исправить большую их часть и устранить угрозу со стороны оставшейся меньшей части». Ты думаешь, зачем в оракле есть репликация? Можно же было сделать RAID-зеркала, и менять диски по мере их выхода из строя. Но нет, система на Си точно откажет - нужно иметь запасную машину, чтобы в любой момент можно было перезапустить один узел без остановки всей системы.

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

Вся ответственная логика, которую не удалось возложить на хорошо оттестированные сторонние решения на Си, как раз не пишется на Си, а на каком-то более надежном средстве.

что ты будешь делать, когда в функции нужно будет вызывать cleanup только для выделенного ресурса или когда само высвобождение выдает ошибку - мне не совсем ясно

Никого не хочу обидеть, но писать на си - это не твое.

Ответ на мой вопрос где? Алгоритм станет таким же сложным, как и без cleanup атрибута. Но я написал, что фича годная - это намного лучше, чем ничего.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Ты думаешь, зачем в оракле есть репликация? Можно же было сделать RAID-зеркала, и менять диски по мере их выхода из строя. Но нет, система на Си точно откажет - нужно иметь запасную машину, чтобы в любой момент можно было перезапустить один узел без остановки всей системы.

Вестник параллельной вселенной. Репликация данных нужна потому что си откажет? )

Жжошь напалмом.

anonymous
()
Ответ на: комментарий от byko3y

Ответ на мой вопрос где?

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

anonymous
()
Ответ на: комментарий от anonymous

Вестник параллельной вселенной. Репликация данных нужна потому что си откажет?

Тебе рассказать про системы на миллион строк кода с надежностью 99.999%? И не стоит путать избыточность, связанную с производительность, с избыточностью, вызванную низкой надежностью.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

Как сказал бы царь (фейкоцарь? really?) в этом трэде - помножить на ноль. Я не покупаю тезис об априорной надежности всего-чего-угодно-кроме-си. Ну хотя бы просто потому, что эту херь многократно продавали до того, продают сейчас и будут еще многократно продавать потом. И все эти продажи приносят примерно тот же выхлоп покупателю, что и гербалайф.

Да, консервативная медицина консервативна, антибиотики это вам не эко-грин-смузи-лайт, но когда надо - работает.

Здоровья вам, берегите себя.

anonymous
()
Ответ на: комментарий от anonymous

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

Ты о чем? Я тебе даже код привел конкретно реализации: «всё учтено» - это assert_se, который при отладке тебе сделает

log_assert(LOG_CRIT, text, file, line, func, "Assertion '%s' failed at %s:%u, function %s(). Aborting.");
abort();
а в релизе и вовсе ничего не сделает - как и положено обрабатывать ошибки в Си.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

а в релизе и вовсе ничего не сделает - как и положено обрабатывать ошибки в Си.

Вечер перестает быть томным.

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

anonymous
()
Ответ на: комментарий от anonymous

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

И как же ты собрался обрабатывать ошибки в сторонней либе? Ах да, ты же будешь писать каждую строчку своего приложения лично.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

И как же ты собрался обрабатывать ошибки в сторонней либе?

Ассертами, ага. Правда уволят быстро и без выходного пособия, но то такоэ.

anonymous
()
Ответ на: комментарий от anonymous

Ассертами, ага. Правда уволят быстро и без выходного пособия, но то такоэ.

Видимо, у создателей systemd есть эти проблемы с работой, раз они так код пишут. А писали бы хорошо - не занимались бы такой ерундой, как systemd.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Видимо, у создателей systemd есть эти проблемы с работой, раз они так код пишут. А писали бы хорошо - не занимались бы такой ерундой, как systemd.

Не увлекаюсь systemd, однако рискну предположить, что таки да, ассерты там присутствуют. Да и вообще, ассерты конечно же используются в сишном коде. Внимание - вопрос. А для чего? Какую именно задачу решает ассерт?

Ээээ.... нувыпонели.

anonymous
()
Ответ на: комментарий от anonymous

- Вы программист? На чем вы программируете? (на английском) - (низуя не понимая по английски, так как испанец, но на всякий случай и с улыбкой) Си, сеньор.

anonymous
()
Ответ на: комментарий от anonymous

«Граф знает счет, на своем счету».

anonymous
()
Ответ на: комментарий от anonymous

Вы программист? На чем вы программируете? Си, сеньор.

А чем может заниматься Си сеньор в 2019 году? Мне просто интересно, что я потерял, покинув кодинг на Си эн лет назад.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

А чем может заниматься Си сеньор в 2019 году? Мне просто интересно, что я потерял, покинув кодинг на Си эн лет назад.

Хайперформанс, бигдата, особенно там где требуется предсказуемое поведение (включая предсказуемое потребление ресурсов), вся фигня. Геймдев, опять же. Много сишников в эмбеде, там своя специфика.

Да в принципе везде, где не катит закрыть вопрос быстро и грязно.

anonymous
()
Ответ на: комментарий от byko3y

баш ужасно подходит для сложных задач

Согласен. Как бывший фанбой питона не пишу на баше даже простые условия и циклы. Только на питоне (если скрипт).

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

Это как раз стимулы для строжайших дедлайнов, которые мешают вдумчивой разработке. Аргумент «у них есть много древнего легаси - значит не делают новое» просто жесть. В это старьё УЖЕ вбухано куча денег, использование готовых компонентов помогает очень сильно сэкономить бюджет, который при «нет чрезвычайных стимулов» маловат по сравнению с прошлым (не забываем про инфляцию).

А, тем не менее, миллионы строчек кода написаны.

Про лисп убедительно. Питон вместе с перлом и башем занимают важное место в инфраструктуре линукса и не только. Много мелких полезных программ, которые надо часто и легко менять и темпы изменения требований не подходят под вдумчивую разработку на С/С++. А вот про раст нету примеров. Хотя Царь говорит, что ему 10 лет!

нам не важен оптимизирующий компилятор

Действительно согласился, что оптимизирующий компилятор - лишь следствие состоятельности сишки?

Тогда можешь мне пояснить, почему они писали не на фортране, не на коболе, не на крестах, не на паскале, не на лиспе, не на схеме - а на Си?

Значит, тогда он оказался состоятельнее других ЯП-современников (чем именно - я НЕ сишник). Ну и AT&T осилили создание расширяемой базы, а надстройки уже делали в привычной для ОС dev окружении.

Он настолько удобен, гибок, фундаменталенг, что с ним даже кресты не нужны?

Кресты имеют несколько «тяжёлых для рантайма» фич (exceptions, dynamic_cast, typeid...), которые сильно затрудняют контроль над программой на самом низком уровне. Что очень важно для системщины и ембедщины. А в прикладных программах С++ популярнее Си, хотя многие сишники не признают кресты из-за каких-то заморочек.

правда, не ясно, почему Си, а не Ассемблер

Везде пишут, что скорость разработки, переносимость, но не ограничивает в «спуске вниз».

человеком, идущим по канату над пропастью

Аналогия некорректна. Как раз реализация на си «в лоб» «падает от дуновения ветра». Реализация на си со всеми предосторожностями - это как раз сделать так, чтобы ни ураганы, ни метеориты, ни потопы не сломали «здание». Типа в питоне многие «укрепления» идут в комплекте, а на си нужно вручную всё укреплять.

А вот Java не является достаточно удобным инструментом, потому для нее нужны дополнительные инструменты - костыли.

С этим я согласен. Но она с пыхой и джсом прочно заняли нишу «ЯП, где кодеры легко заменимы». «Программы как продукт фабрики, а не продукт творчества».

arturianec100
()
Ответ на: комментарий от arturianec100

Это как раз стимулы для строжайших дедлайнов, которые мешают вдумчивой разработке. Аргумент «у них есть много древнего легаси - значит не делают новое» просто жесть. В это старьё УЖЕ вбухано куча денег, использование готовых компонентов помогает очень сильно сэкономить бюджет, который при «нет чрезвычайных стимулов» маловат по сравнению с прошлым (не забываем про инфляцию).

Не, ты не понял сути аргумента. Я писал о том, что с тем оборудованием, с которым работает NASA, оно при самом большом желании не сможет использовать java/lisp/etc, кое-где разве что С++ удается применить. Когда у тебя настолько мало памяти и настолько низкая производительнотсь оборудования, то надежностью реализуют через «работает - не трогай», а не через использование более совершенных средств разработки: они не могут выбирать инструмент - им приходится использовать то, что есть.

А вот про раст нету примеров.

По расту нет примеров - я не спорю. У раста еще всё впереди - стабильная версия 4 года назад вышла.

нам не важен оптимизирующий компилятор

Действительно согласился, что оптимизирующий компилятор - лишь следствие состоятельности сишки?

Кто соглашался? Точно не я. Ты представляешь примерно, что значит разработка оптимизирующего компилятора? Это значит, что собирается несколько кодеров на асме с большим опытом и оплатой 10k$+, начинают искать и реализовывать алгоритмы преобразования медленных последовательностей из AST в быстрые коды; берется еще кучка тестеров, которые гоняют программы с разными вариантами оптимизаций и без оптимизаций, тестируют работу комбинаций разных оптимизаций - тестер такого плана тоже не из самых доступных на рынке; спустя эн лет разработки эта команда выкатывает компилятор для одной платформы, и этот компилятор обошелся в эн миллионов долларов.

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

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

Тогда можешь мне пояснить, почему они писали не на фортране, не на коболе, не на крестах, не на паскале, не на лиспе, не на схеме - а на Си?

Значит, тогда он оказался состоятельнее других ЯП-современников (чем именно - я НЕ сишник). Ну и AT&T осилили создание расширяемой базы, а надстройки уже делали в привычной для ОС dev окружении.

Ага, то есть, богу помолились, и бог им сказал «пишите на Си». Хорошо.

Кресты имеют несколько «тяжёлых для рантайма» фич (exceptions, dynamic_cast, typeid...), которые сильно затрудняют контроль над программой на самом низком уровне. Что очень важно для системщины и ембедщины. А в прикладных программах С++ популярнее Си, хотя многие сишники не признают кресты из-за каких-то заморочек.

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

Реализация на си со всеми предосторожностями - это как раз сделать так, чтобы ни ураганы, ни метеориты, ни потопы не сломали «здание».

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

Справедливости ради нужно отметить, что инструменты разработки довольно сильно нивелируют ущербность Жавы

Как раз Java и C# изначально проектировались на полную интеграцию с ide. Си с классами тоже ide-friendly.

Так почему же их не было ни при Oak, ни при релизе Java в 1995? Почему же потом появились только отдельные инструменты,

Значит, с джавой я погорячился. Язык оказался достаточно простым, чтобы запилить ide, «читающие мысли».

А вот Java не является достаточно удобным инструментом, потому для нее нужны дополнительные инструменты - костыли.

С этим я согласен. Но она с пыхой и джсом прочно заняли нишу «ЯП, где кодеры легко заменимы». «Программы как продукт фабрики, а не продукт творчества».

Да, IDE прекрасно встраивается в лейтмотив жавы: «максимум механических действий и работы лопатой - минимум творчества и принятия решений». Вот тебе книжка, вот тебе IDE, вот тебе безупречная архитектура, спроектированная сеньором - всё, теперь скажешь мамке, что ты - энтерпрайз.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Да, IDE прекрасно встраивается в лейтмотив жавы:

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

теперь скажешь мамке, что ты - энтерпрайз

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

А вот Java не является достаточно удобным инструментом, потому для нее нужны дополнительные инструменты - костыли.

Clojure, Swift, Rust в костылях не нуждаются? Можно перечень язык в программирование на которых IDE особого буста не даст?

anonymous
()
Ответ на: комментарий от byko3y

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

Таки да, небоскреб невозможно построить в стиле «а давайте-ка вот сюда кирпичей нахерачим».

Из того, что условный Хуан не может в небоскребы никак не следует то, что ему нельзя участвовать в строительстве. И уж тем более не следует, что небоскреб невозможен.

Сейчас вот почему-то на Си никто не пишет игры

O,rlly?

anonymous
()
Ответ на: комментарий от arturianec100

А в прикладных программах

Раз. Нет никакого смысла приглашать архитекторов, дизайнеров и прочих всяких-там инженеров для строительства сарая. Потребность в сараях куда выше, чем потребность в небоскребах, и уж тем более выше, чем потребность в дизайнерских изысках.

Два. Берем, запиливаем расчет многоэтажки один раз и потом запиливаем нужное нам количество курятников, с предсказуемой надежностью и сроком эксплуатации. Это выгодно и решает насущную проблему. (в основе платформы электрон, на которой реализована туева хуча всего лежит что? v8 одна штука, libuv одна штука и хром, который тоже не на питоне)

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

Три. Не все в этой жизни - сарай и массовое строительство.

anonymous
()
Ответ на: комментарий от anonymous

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

Ниче-ниче, скоро школу закончишь - может быть узнаешь про такое языки, как фортран, кобол, паскаль, алгол 68, лисп, которые все прекрасно анализировались. Да-да, и в том числе лисп:
https://github.com/abo-abo/lispy
https://github.com/Wilfred/emacs-refactor
http://www.foldr.org/~michaelw/emacs/redshank/
Однако же, миллионы строк кода писали в CL на одном REPL. И почему-то ни в турбо паскале ( http://pascal.net.ru/Меню+Turbo+Pascal ), ни даже в делфи до самой семерки не было рефакторинга. Как же так, почему лишь только начав свое применение жаве сразу понадобились инструменты для работы с кодом, помимо текстового редактора и отладчика?

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

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

Clojure, Swift, Rust в костылях не нуждаются? Можно перечень язык в программирование на которых IDE особого буста не даст?

Да, для Clojure IDE не нужен - нужен только REPL. Про Свифт точно ничего не скажу, а вот про Раст я тебе скажу, что по сути статический анализатор встроен в сам язык. Даст ли Расту буст какое-то IDE на большом проекте? Не знаю, но на расте работать текстовым редактором намного приятнее, чем на C/C++/Java.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

Из того, что условный Хуан не может в небоскребы никак не следует то, что ему нельзя участвовать в строительстве. И уж тем более не следует, что небоскреб невозможен.

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

Сейчас вот почему-то на Си никто не пишет игры

O,rlly?

Прикинь?

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

Как и на чем взлетели юниксы? Протокол взаимодействия.

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

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

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

Прикинь?

Ты просто не в теме.

anonymous
()
Ответ на: комментарий от anonymous

Как и на чем взлетели юниксы? Протокол взаимодействия.

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

Амазон-лямбда, которая запускает всякую левую херь, написанную неведомой ногой неведомого индуса, как работает?

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

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

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

Я об этом и писал - так не получится написать большую интегрированную систему.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

а не через использование более совершенных средств разработки: они не могут выбирать инструмент - им приходится использовать то, что есть.

Не применяй критерии качества строительства сараев к инструменту для управления ракетами. В большинстве контор надёжность больше зависит от базовой надёжности ЯП+фреймворк. В случае сишки навыки разработчиков имеют гораздо большее значение потому, что есть полный контроль на всех уровнях. Софт для ракет требует верификации всего, там везде заранее «стелят солому». Там процессы разработки гораздо более комплексные, чем «ТЗ, написать код, тестировать». Они не по карману большинству кампаний.

Короче, надёжность скриптухи зависит от надёжности фундамента, на котором она стоит. Надёжность сишки - твоя голова и руки потому, что фундамент построен ТОБОЙ (ещё ядро в качестве фундамента, но только для прикладухи).

arturianec100
()
Ответ на: комментарий от arturianec100

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

Я читал, что Qt тоже отлично подходит для сараебилдинга. Типа многие осиливают решение на нём многих простых задач, не зная С++, но имея базовые знания о Си с классами. Но доминирование маздайки на десктопе и плохая адаптация Qt под смартфоны «перекрывают кислород». Но прямая связь с сишкой позволяет лучше оптимизировать и возможность очень легко включить сложнейшую логику на си в этот «сарай».

Кстати, раз llvm обречён догонять gcc, почему личный форк именно шланга, метапрограммирование в форке шланга, а не gcc?

arturianec100
()
Ответ на: комментарий от arturianec100

Я читал, что Qt тоже отлично подходит для сараебилдинга.

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

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

А js и html это как раз таки ответ. Наваяли, подкрутили, херакс - и в продакшн. И живет. На короткоживущих уеб страничках ваще огонь. Пришел - ушел, и все забыли. На электронах - выползают косячки, тот же ГЦ не але, но терпимо, а с учетом дешевой кросплатформенности и немеряного количества людей, освоивших технологии уеба - эльдорадо.

Qt собсна нечего предложить. Меньшее потребление памяти и ресурсов процессора? Да кого это сейчас трясет. Предсказуемость поведения? Да щас. Либа то может и да, но вы ж выдали все инструменты кастрации разрабам верхнего уровня, а они не подведут.

Короче мое мелкое ИМХО - не взлетит. Хотя попытки есть, будут и будут есть.

anonymous
()
Ответ на: комментарий от arturianec100

Кстати, раз llvm обречён догонять gcc, почему личный форк именно шланга, метапрограммирование в форке шланга, а не gcc?

В этом вопросе, кстати, я не вполне согласен с предыдущим оратором.

В целом таки да, gcc рулит и педалит. Однако.

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

Ну и благодаря появлению шланга gcc внезапно вышел из похмельного застоя. Конкуренция, однако.

Так что пусть растут тысячи цветов. Лично я не возражаю.

anonymous
()
Ответ на: комментарий от arturianec100

Кстати, раз llvm обречён догонять gcc, почему личный форк именно шланга, метапрограммирование в форке шланга, а не gcc?

Ты задаёшь вопросы не мне, но ладно. Очевидно, что я бы его вообще не увидел.

Я тебе уже отвечал на этот вопрос, хотя ты, как оказалось, ничего не читал. А может я и не тебе отвечал. Вообщем, пацан выше правильно сказал. Шланг состоятелен не как компилятор, а как статический анализатор. Собственно - в этом единственная от него польза. Ну и польза ещё от wasm-таргета.

anonymous
()
Ответ на: комментарий от anonymous

Ты задаёшь вопросы не мне, но ладно.

Модераторы регулярно трут твои посты, даже те, что без хамства и оскорблений. Мои ответы автоматом трут (на уровне движка ЛОРа, а не явного указания модератором) как «ответ на некорректное сообщение». Мне любопытно: потрут ли мои посты, если технически они

И то утверждение про «сараи на Qt» тоже было в твой адрес. Чтобы ты прокомментировал. Благо ключевые слова позволяют безошибочно отделять тебя от других анонимусов.

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

Хостинги же не заморачиваются удалением сайтов неполиткорректных блогов? Если прямая агитация за ИГИЛ, то могут быстро стереть, но рассказы про сишку и критика методички растоадептов их (хостинги) не должны волновать. Лично убедился, что амазон даёт бесплатно на один год простой сервер, достаточный для небольшого (в плане посещаемости) блога хоть на вордпрессе, хоть на сишке - виртуалка с популярными серверными дистрибутивами на твой выбор. И так же бесплатно отдельный простой сервер с бд на твой выбор. Однако уже при регистрации нужно указать полный номер банковской карты. Но бесплатностью заманивают, как правило, shared хостинги, где только пхп.

arturianec100
()
Ответ на: комментарий от arturianec100

Мне любопытно: потрут ли мои посты, если технически они

Если технически я отвечаю сам себе, а не «забаненному оппоненту».

arturianec100
()
Ответ на: комментарий от arturianec100

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

Нельзя написать за это время пост. К тому же - нужно не просто написать, а запилить блог. Это тоже время. Я всё никак не могу освободится с делами.

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

Лично убедился, что амазон даёт бесплатно на один год простой сервер, достаточный для небольшого (в плане посещаемости) блога хоть на вордпрессе, хоть на сишке - виртуалка с популярными серверными дистрибутивами на твой выбор.

Мне уже не даст у меня всё учётки стары, но дело не в этом. Я найду где хостить - мне лень этим заниматься. Я хочу попомйку на гугл-дрситне поднять.

Нормальный блог будет потом на сишке/крестах. Но то нужно ещё его запилить, а это нужно время.

В ближайшие дни попробуй запостить говно на какой-нибудь помойке. Нужно перебороть страх постить говно.

anonymous
()
Ответ на: комментарий от arturianec100

Гугл специально уничтожает нативное программирование гуя(и не только) под ведро. Эпл тоже самое - там вообще ты ничего не можешь.

Гугл как раз рекламирует свой flutter как платформу для нативного гуя и на андроиде, и даже на айос. Да, скриптуха dart, но вызывает нативные виджеты!

Что мешает Qt дёргать эти виджеты? Кроме желания продвигать qml. Всё сдк айфонов же базируется на llvm - C++-friendly, а андроидная жаба - на десктопе можно скомпилировать программы на джаве с помощью graalvm в .so, который можно дёргать из сишки. Увы, у андроида свой рантайм жабы. Всё равно можно было бы построить костыль вроде «сервера, дёргающего андроидные апи для создания виджетов на джаве» и прогаммы на си, которая через подходящий вариант ipc управляет этим сервером.

arturianec100
()
Ответ на: комментарий от byko3y

Да, IDE прекрасно встраивается в лейтмотив жавы: «максимум механических действий и работы лопатой - минимум творчества и принятия решений». Вот тебе книжка, вот тебе IDE, вот тебе безупречная архитектура, спроектированная сеньором - всё, теперь скажешь мамке, что ты - энтерпрайз.

По большей части это так, экосистема очень сбитая, количество кода на все случаи жизни из коробки тоже хватает. Но виноват ли в этом язык? Естественно нет, так что никто не запрещает и на джаве упарываться в какие угодно фундаментальные реализации, творить и принимать решения, в пределах возможности среды исполнения конечно же, если это не устраивает и язык душит (возможно не язык, но среда исполнения), всегда есть возможность притянуть еще какой-либо язык в проект, как это обычно с большими проектами и бывает. Так что немного некорректно говорить о безупречной архитектуре, ведь ничего безупречного увы нет, хоть с мамками и сеньорами, хоть без оных. Резюмируя, это подмена понятий и хейтерство на котором вы сошлись с оппонентом дабы подзамять бессмысленный холивар в котором каждый прав по своему, хотя ваша позиция она более приземленная к реалиям что ли... Нет этого фанбойского налета и синдрома утенка вперемешку с жаждой обязательно написать реализацию на максимально производительном языке и признавать за инструмент для решения задачи только тот язык где можно опуститься до уровня железа, жертвуя временем, деньгами, здоровьем. И рассказывая всем что язык то хороший, годный, просто надо перетерпеть и быть хорошим специалистом с большой буквы, мастером своего дела, надо быть стойким, надо обязательно на нем иначе и браться не стоит в лучших традициях максимализма.

abcq ★★
()
Ответ на: комментарий от abcq

написать реализацию на максимально производительном языке

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

Целесообразно ли жертвовать гарантиями? Да, когда их ценность много меньше ожидаемого профита.

Кошерно ли писать на жабе? На js? На пайтоне? Да пишите на чем хотите. Главное помнить из какой жопы растут ноги и адекватно оценивать возможности платформы.

Надо на js ОС запилить! - это речь вменяемого человека, не? Нежнее надо, и без фанатизма.

anonymous
()
Ответ на: комментарий от anonymous

В ближайшие дни попробуй запостить говно на какой-нибудь помойке.

Главное сюда маякнуть не забудь.

crutch_master ★★★★★
()
Ответ на: комментарий от abcq

Нет этого фанбойского налета и синдрома утенка

Не угадал. Я на сишке вообще ничего не писал. Первыми ЯП, которые я видел, были бейсик и паскаль, но я всерьёз их не воспринимаю. Как раз таки мой первый современный ЯП - джава. Потом C# (сначал юнити, а потом уже полноценный .Net Framework). Потом С++ в универе (сишники знают, что С++ в универе - это изучение синтаксиса Си с классами). Потом питон и js. Некоторое время я был фанбоем именно питона (за счёт быстрого написания и большой гибкости по сравнению с другой скриптухой). Это уже сейчас, после дискуссий с Царём, я проникся фундаментальностью сишки. А вообще я люблю писать только прикладуху, при этом вдумчиво и на скриптухе. Я только потихоньку изучаю С/С++.

arturianec100
()
Ответ на: комментарий от anonymous

Смотрел я на него. Имхо, какой-то примитивный. Получать сигнал о том, что нажата кнопка, через if - это жесть. Очень нишевое решение.

arturianec100
()
Ответ на: комментарий от arturianec100

Модераторы регулярно трут твои посты

Да, и будут дальше тереть, если там будет сплошное «говно, методичка, маня, школьник» и т.д.

даже те, что без хамства и оскорблений.

Нет.

Deleted
()
Ответ на: комментарий от Deleted

если там будет сплошное «говно, методичка, маня, школьник» и т.д.

Всё-таки помимо этих некультурных слов и оскорблений там есть конкретные тезисы технического характера. Есть посты, где нету оскорбления других участников дискуссии, но хватает словечек «говно...». Его рассказы интересны некоторым людям. Я не перестаю видеть смысл в его постах даже после того, как он многократно меня оскорбил.

Однако это не отрицает то, что он нарушает правила форума в плане «как выражать мысли». Я не отрицаю, что модераторы выполняют свою работу, удаляя посты, которые нарушают правила форума.

arturianec100
()
Ответ на: комментарий от abcq

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

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

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

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

У любого языка есть набор объективных плюсов и минусов, но то как тут расписывали минусы сишки - это хейтерство и некомпетентность.

Не потому что их нет, а потому что они не там.

На самом деле индустрия уже сказала свое слово. Бизнес-логика это жаба, фронтенд это вебстек, фундамент это С, алгоритмически сложные задачи - плюсы, прототипы - питон.

Да, поезда и самолеты - Ада, гуглософт го, а мозилла раст, но сути дела это не меняет. Никому не нужен «гораздо более совершенный» велосипед. Есть феррари с ламборджинями, есть бенли с майбахами и ролс-ройсами, и пусть они будут. Но массово нужен недорогой и надежный автомобиль, тчк.

olelookoe ★★★
()
Ответ на: комментарий от byko3y

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

Я не хочу строить из себя супер-специалиста. Я уже писал, что не писал код на сишке. Я оспаривал твои аргументы про сишку. Также я попал под влияние царя про фундаментальность сишки. Я писал немного прикладухи на С++, но это даже не уровень мидла. Я хочу изучить раст (вопреки рассказами царя, но его тезисы с тэгом «методичка» меня затронули) и углубить знания в С/С++. Но это не день и не месяц, так что пока я пишу логику на скриптухе (js, python).

Фундаментально ЛОР для меня нужен для того, чтобы «указали на ошибки и показали как надо». Лучше производить впечатление на противоположный пол, чем на анонимусов с форума.

arturianec100
()
Ответ на: комментарий от arturianec100

Изучать язык - это значит писать на нем.

Лучше всего писать что-нибудь полезное, желательно в команде.

Желательно посвятить этому некоторое время, для того, чтобы почувствовать вкус языка. Что нравится, что не нравится. Где он многословный, где неудобный, где в зубах навяз. Преимущества станут заметны в сравнении с другими языками. то есть пока не попишешь на языке номер два, что хорошего в языке номер один вряд ли сможешь осознать.

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

И вот тогда появится необходимая компетенция для сравнения.

Ту же джаву или тот же раст создали не просто так, а в надежде решить целые классы проблем. Хороший вопрос - а какие именно проблемы решали создатели языка? Можно ли было решить эти проблемы не изобретая новый язык, стоит ли овчинка выделки - на эти вопросы ответ можно получить только путем практического сравнения, на своей шкуре.

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

olelookoe ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.