А как вы познаете информацию? Например о сетях? О той же CS?
Если честно может стоит начать читать, там много полезного, ничего личного, но теперь эта статья висит в публичном доступе с 5 лайками и пометкой "Туториал", и каких "дошкольников" вы тут научите я не знаю
А зачем вы файлы сохраняете на жёсткий диск? У вас нету каких нибудь носителей с копией данных которые вы бы хотели сохранить?
Если честно это все спор ради спора, мне кажется, учитывая приведенный выше вами код, без каких либо комментариев даже.
Почему-то я открываю вики и оттуда мне понятно зачем акторы, а отсюда веет каким-то противопоставлениям ООП, опять же из комментариев. Я не могу вообще уловить суть как это сравнивать.
Акторная модель, будучи одной из самых математически элегантных концепций в Computer Science (наравне, пожалуй, с теорией категорий и property-based тестированием)
Вы сами говорите что это фундаментальные подходы в информатике и сравниваете их с ООП. Назовите хоть 1 книгу по CS где написано про ООП кроме упоминаний, и то сомневаюсь.
Простите, а в вашем мире «БАЗА» — это такое магическое существо, волшебно сохраняющее всё навсегда, безотказно, даже в случае нетворк сплитов и отказов жесткого диска? Откуда у вас такая слепая вера в Великую Базу — и такое недоверие к процессам? Чем процесс хуже?
Ага, а этот конвеер ЦПУ может что-то делать без операционной системы? Программист операционной системы реализует процессы и их взаимодействие с ЦПУ, он наугад все делает?
Или кнопка в диспетчере задач "завершить процесс",на неё не то что программист может нажать и завершить процесс, а даже самый рядовой пользователь и получается повлиять на конвеер ЦПУ?)
Стиральная машинка которая у вас дома и скорее всего на линуксе, кто её работу с процессором настраивал если не программист?)
Нет. ЯП как и синтаксический сахар - это самостоятельные понятия.
Получается синтаксический сахар может существовать без языка? Или всетаки сначала идёт ЯП, а к нему уже синтаксический сахар.
Объекты легче описать на понятный язык. Представить объект машины в голове и придумать ему свойства и функционал может каждый в бизнесе, а так сказать стать актором, не каждый
ООП вообще никак не влияет на синхронность. Вам не кажется странным, впринципе, разделять ООП и ФП? Чем отличается метод от функции? Мне кажется контекстом, отсюда и DDD, бизнес хочет глубже знать разработку, вот пожалуйста готовый подход.
Мне кажется ИТ вообще огромное поле для манипуляций. А в продакт попадают модные штучки как у гугл (микросервесы с gRPC), всякие реакты как в твиттере, вью.джс и прочее (возможно, чтобы потом продукт менеджер всем рассказывал что у нас все как у больших игроков рынка). Всё это время ИТ подогревается инфоцыганщиной ( меня если честно немного смешит что Яндекс после своих курсов не берет сразу людей к себе, по крайней мере я не видел такого в их рекламах), обучись годик и будет зарплата 200+. Вот рынок и сломался под количеством вкатунов, если честно из-за этого вообще избегаю найма как огня. Да и после того как образование и достижения в своей сфере не котируется, а котируется только что ты писал точно на таком же фреймворке как в команде. В компаниях вообще не понимают что если ты пишешь на нативном языке, то и фреймворк ты осилишь и куча куча таких вот моментов которые дают понять модель бизнеса. Заплатил деньги - получаю результат, все остальное мишура и прихоти этих странных ИТшников.
Получается что разработчик должен упрощать взаимодействие с продуктом, отстраняя пользователя от условного "компилятора" (технической части продукта?) Не уверен что до конца понял что хотите сказать, но плюс поставил)
Да, я понимаю как это происходит в коммерческой разработке. Я больше про то что, впринципе 140+ человек для такого приложения это перебор 2 раза :) Это скорее про корпоративные моменты, и как видно из статьи диаграммы не помогают сократить количество участников процесса. Я к тому что 2 программиста не сделают приложение в 2 раза быстрее, а скорее наоборот все усложнят.
Статья интересная, диаграммы и показатели круто. Но если честно у меня глаз зацепился за 140+ человек участвующих в работе над продуктом, диаграммами можно все покрыть и посмотреть, но точно ли нужно столько людей?
Объективный человек более логичен, разве нет?)
Лайки к тому что это поднимает авторитет перед читателем (для чего ещё они созданы? Отсеевать что от чего?) особенно далёким от всего этого читателям.
А как вы познаете информацию? Например о сетях? О той же CS?
Если честно может стоит начать читать, там много полезного, ничего личного, но теперь эта статья висит в публичном доступе с 5 лайками и пометкой "Туториал", и каких "дошкольников" вы тут научите я не знаю
И что это за хвастовство такое?) Если я давно в ИТ сфере, почему мне не понимать его?)
Мне кажется вы и хотите похвастаться, только не могу понять чем
А зачем вы файлы сохраняете на жёсткий диск? У вас нету каких нибудь носителей с копией данных которые вы бы хотели сохранить?
Если честно это все спор ради спора, мне кажется, учитывая приведенный выше вами код, без каких либо комментариев даже.
Почему-то я открываю вики и оттуда мне понятно зачем акторы, а отсюда веет каким-то противопоставлениям ООП, опять же из комментариев. Я не могу вообще уловить суть как это сравнивать.
Вы сами говорите что это фундаментальные подходы в информатике и сравниваете их с ООП. Назовите хоть 1 книгу по CS где написано про ООП кроме упоминаний, и то сомневаюсь.
Это вера в репликацию данных
А программист, в линуксе, может это сделать вот так
Опишите, пожалуйста, мобильный телефон, его свойства и возможности на акторной модели
Ага, а этот конвеер ЦПУ может что-то делать без операционной системы? Программист операционной системы реализует процессы и их взаимодействие с ЦПУ, он наугад все делает?
Или кнопка в диспетчере задач "завершить процесс",на неё не то что программист может нажать и завершить процесс, а даже самый рядовой пользователь и получается повлиять на конвеер ЦПУ?)
Стиральная машинка которая у вас дома и скорее всего на линуксе, кто её работу с процессором настраивал если не программист?)
Получается синтаксический сахар может существовать без языка? Или всетаки сначала идёт ЯП, а к нему уже синтаксический сахар.
Почему программисту недоступна закулиса?
Если мы знаем частоту и количество нужных тактов, мы не можем рассчитать время выполнения??
Не так разве? А ассемблер синтаксический сахар над байт кодом)
Собственно для упрощения работы программиста его и отодвинули от ассемблера. Знаешь ассемблер и С++, поймешь много чего и в других языках.
?????????
У меня аж сердце ёкнуло. Как-то связался с фронтендерами, я с этим линтером боролся дольше чем библиотеки устанавливал.
Отличная статья! Если честно пока осилил только половину, получил прозрение на одном моменте:
Буквально сегодня писал код и чувствовал легкий зуд от пробела знания в этом моменте, теперь думаю мне станет чуточку легче)
Объекты легче описать на понятный язык. Представить объект машины в голове и придумать ему свойства и функционал может каждый в бизнесе, а так сказать стать актором, не каждый
ООП вообще никак не влияет на синхронность. Вам не кажется странным, впринципе, разделять ООП и ФП? Чем отличается метод от функции? Мне кажется контекстом, отсюда и DDD, бизнес хочет глубже знать разработку, вот пожалуйста готовый подход.
Но мне если честно не кажется пошаговая подсветка (обучение на сайте, думаю видели) хорошим юзер экспириенсом.
Ну если платишь за готовый продукт я думаю это логично, отдал деньги - максимально быстро и удобно решил проблему.
Мне кажется ИТ вообще огромное поле для манипуляций. А в продакт попадают модные штучки как у гугл (микросервесы с gRPC), всякие реакты как в твиттере, вью.джс и прочее (возможно, чтобы потом продукт менеджер всем рассказывал что у нас все как у больших игроков рынка). Всё это время ИТ подогревается инфоцыганщиной ( меня если честно немного смешит что Яндекс после своих курсов не берет сразу людей к себе, по крайней мере я не видел такого в их рекламах), обучись годик и будет зарплата 200+. Вот рынок и сломался под количеством вкатунов, если честно из-за этого вообще избегаю найма как огня. Да и после того как образование и достижения в своей сфере не котируется, а котируется только что ты писал точно на таком же фреймворке как в команде. В компаниях вообще не понимают что если ты пишешь на нативном языке, то и фреймворк ты осилишь и куча куча таких вот моментов которые дают понять модель бизнеса. Заплатил деньги - получаю результат, все остальное мишура и прихоти этих странных ИТшников.
Получается что разработчик должен упрощать взаимодействие с продуктом, отстраняя пользователя от условного "компилятора" (технической части продукта?) Не уверен что до конца понял что хотите сказать, но плюс поставил)
Да, я понимаю как это происходит в коммерческой разработке. Я больше про то что, впринципе 140+ человек для такого приложения это перебор 2 раза :) Это скорее про корпоративные моменты, и как видно из статьи диаграммы не помогают сократить количество участников процесса. Я к тому что 2 программиста не сделают приложение в 2 раза быстрее, а скорее наоборот все усложнят.
Статья интересная, диаграммы и показатели круто. Но если честно у меня глаз зацепился за 140+ человек участвующих в работе над продуктом, диаграммами можно все покрыть и посмотреть, но точно ли нужно столько людей?