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 развалилась благодаря неблагоприятному стечению обстоятельств и «эффективным» манагерам, но их наработки оказались никому не нужны что ли?
И опять-таки, когда нужное железо появилось почему выбор этих и других крупных компаний пал именно на эти языки?
Почему не на функциональные языки?
Потому что в то время функциональные языки в основном использовались сугубо в академической среде или как?
Или если перефразировать всё вышесказанное словами моего коллеги: «если всё так круто (про ФП), то почему оно ещё не захватило рынок?»

Ответ на: комментарий от 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
()

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

Если этот ваш язык построен на использовании GC - он надежен или нет? Голову включаем.

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

Если этот ваш язык построен на использовании GC - он надежен или нет? Голову включаем.

Помню, мне когда-то такое же втирал адепт MUMPS. На самом деле, всё просто: человек ошибается, машина - нет. Чем больше контролирует человек, тем больше вероятность ошибки. Таким образом, отвечая на вопрос:

Если этот ваш язык построен на использовании GC - он надежен или нет?

да, язык на GC надежнее, чем язык без GC. Потому в Go есть GC.

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

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

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

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

O,rlly?

Прикинь?

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

человек ошибается, машина - нет. Чем больше контролирует человек, тем больше вероятность ошибки.

Иииии?...

GC это единственный способ возложить контроль на машину?

Про подсчет ссылок напомнить? Уже лучше чем «сожру, сколько смогу, стошнит тогда, когда стошнит»

И этими двумя приемами машиноконтролируемый memory management не исчерпывается. Просто его в эти ваши смузи бары не завезли.

Два. Память - не единственный ресурс, который нужно контролировать. И не самый проблемный.

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

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

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

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

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

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

Прикинь?

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

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

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

Так почему же возникло столько дырявейшего софта с переполнением стэка, с удаленным выполнением кода, с DOS? Может потому, что в случае С/С++ пямять как раз и является самым проблемным местом?

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

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

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

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

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

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

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

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

Так почему же возникло столько дырявейшего софта с переполнением стэка, с удаленным выполнением кода, с DOS?

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

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

Скриптота по-умолчанию вне игры?

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

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

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

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

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

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

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

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

Потому не счем толком сравнить, но это не значит, что надежного софта нет. Взять хотя бы ту же жаву на серверах.

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

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

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

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

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

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

Взять хотя бы ту же жаву на серверах

Жаба, при всем моем к ней уважении, не пример.

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

2. Непреодолимым свойством программы, написанной на жабе, является поведение GC. На вопросы девопсов - жаба опять все сожрала, шо мне делать? ответа нет. Это невозможно починить руками жаба-программиста. Это неуправляемо и не лечится, от слова никак. Ждите, когда вам запилят более интеллектуальный GC. А пока девопсы пусть выкручиваются, как знают.

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

3. Кроме поведения ГЦ (кстати, о том, что нужно будет учитывать специфику реализации ГЦ вам не сказали, когда продавали жизнь без деструкторов) есть еще проблема медленного старта. Нуашо, программы ж на жабе ж вечно живут! Подумаешь, полторы минуты , ну так это ж спринг, а какжеж мы без спринга жеж.

Нет, парни, это не везде приемлемо. Да, тоже решается, да, СЕЙЧАС появились более новые модные фреймворки, но проблема есть.

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

Уникальная фича? Нет. Уникальность в доступности из коробки, при минимальном количестве телодвижений.

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

Жаба заслуженно занимает достойное место в индустрии. Однако при всех плюсах - нет, не серебряная пуля.

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

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

Что следует из вот этого вот твоего вопроса? Следует то, что скриптуха сама по себе не является средством от триппера и ВПЧ. Следует то, что архитектура нужна. И то, что думать никто не отменял.

А если нет разницы - зачем платить больше? (с).

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

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

Что ты мне хочешь доказать? Что прога на жаве такая же ненадежная, как на Си? Не смеши мои тапки.

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

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

есть еще проблема медленного старта. Нуашо, программы ж на жабе ж вечно живут! Подумаешь, полторы минуты , ну так это ж спринг, а какжеж мы без спринга жеж.

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

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

Что ты мне хочешь доказать? Что прога на жаве такая же ненадежная, как на Си?

Не доказать, а рассказать.

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

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

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

Ну то есть и в сях можно фрагментировать память до безобразия - но тебя это не волнует, да?

На сях можно вообще не фрагментировать память.

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

Рецепт - агонь.

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

рукожопы

int getRandomNumber(){
    return 4; // chosen by fair dice roll
              // guaranteed to be random
}
anonymous
()
Ответ на: комментарий от 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 ★★
()

Потому, что люди думают не «функционально», а «процедурно» /или по другому «просто дурно»/.

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

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

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

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

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

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

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

Потому, что люди думают не «функционально», а «процедурно»

Инженерия, как таковая, появилась 100 лет назад. Не считая мелких брызг. До этого люди вообще можно сказать не думали никак.

Думать можно научиться в любом произвольно заданном стиле, но зачем?

Программирование - это голимая прикладуха. Можно и в стиле манга-хентай запилить язык, чтобы привлечь молодые кадры, а дальше что? А дальше придется с этим как-то жить. И это порно будет посильнее Фауста Гете. Кто будет оплачивать банкет?

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

Придумаете что-нибудь еще интересное - приходите, обсудим. Заранее спасибо.

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

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

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

Ну то есть и в сях можно фрагментировать память до безобразия - но тебя это не волнует, да?

На сях можно вообще не фрагментировать память.

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

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

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

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

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

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

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

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

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

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

Си не умеет перемещать указатели, потому память ты не фрагментируешь только если не высвобождаешь ее

курить virtual memory до полного просветления.

жава при равных затратах на разработку дает намного более надежное решение

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

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

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

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

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

Нет.

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

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

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

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

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

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

- Какова вероятность встретить динозавра? - 50 на 50 - ?! - или встретишь - или не встретишь.

Надо бы сравнивать сравнимое, а не хеллоуворлды с ядром. Десктопное с десктопным, серверное с серверным, сложное со сложным, простое с простым.

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