Обновить
11
@SolidSnackread⁠-⁠only

Пользователь

Отправить сообщение

Программист сам не управляет конвейером ЦПУ.

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

Или кнопка в диспетчере задач "завершить процесс",на неё не то что программист может нажать и завершить процесс, а даже самый рядовой пользователь и получается повлиять на конвеер ЦПУ?)

Стиральная машинка которая у вас дома и скорее всего на линуксе, кто её работу с процессором настраивал если не программист?)

Нет. ЯП как и синтаксический сахар - это самостоятельные понятия.

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

Что?

Почему программисту недоступна закулиса?

Если мы знаем частоту и количество нужных тактов, мы не можем рассчитать время выполнения??

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

Не так разве? А ассемблер синтаксический сахар над байт кодом)

С точки зрения программиста вся эта закулиса ему недоступна.

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

Поэтому он может предполагать

?????????

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

У меня аж сердце ёкнуло. Как-то связался с фронтендерами, я с этим линтером боролся дольше чем библиотеки устанавливал.

Отличная статья! Если честно пока осилил только половину, получил прозрение на одном моменте:

Мономорфная функция — это функция способная применяться к конкретному типу данных.

Полиморфная функция — это функция способная применяется к различным типам данных.

Буквально сегодня писал код и чувствовал легкий зуд от пробела знания в этом моменте, теперь думаю мне станет чуточку легче)

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

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

Но мне если честно не кажется пошаговая подсветка (обучение на сайте, думаю видели) хорошим юзер экспириенсом.

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

Мне кажется ИТ вообще огромное поле для манипуляций. А в продакт попадают модные штучки как у гугл (микросервесы с gRPC), всякие реакты как в твиттере, вью.джс и прочее (возможно, чтобы потом продукт менеджер всем рассказывал что у нас все как у больших игроков рынка). Всё это время ИТ подогревается инфоцыганщиной ( меня если честно немного смешит что Яндекс после своих курсов не берет сразу людей к себе, по крайней мере я не видел такого в их рекламах), обучись годик и будет зарплата 200+. Вот рынок и сломался под количеством вкатунов, если честно из-за этого вообще избегаю найма как огня. Да и после того как образование и достижения в своей сфере не котируется, а котируется только что ты писал точно на таком же фреймворке как в команде. В компаниях вообще не понимают что если ты пишешь на нативном языке, то и фреймворк ты осилишь и куча куча таких вот моментов которые дают понять модель бизнеса. Заплатил деньги - получаю результат, все остальное мишура и прихоти этих странных ИТшников.

Получается что разработчик должен упрощать взаимодействие с продуктом, отстраняя пользователя от условного "компилятора" (технической части продукта?) Не уверен что до конца понял что хотите сказать, но плюс поставил)

Да, я понимаю как это происходит в коммерческой разработке. Я больше про то что, впринципе 140+ человек для такого приложения это перебор 2 раза :) Это скорее про корпоративные моменты, и как видно из статьи диаграммы не помогают сократить количество участников процесса. Я к тому что 2 программиста не сделают приложение в 2 раза быстрее, а скорее наоборот все усложнят.

Статья интересная, диаграммы и показатели круто. Но если честно у меня глаз зацепился за 140+ человек участвующих в работе над продуктом, диаграммами можно все покрыть и посмотреть, но точно ли нужно столько людей?

Да, есть такое, тоже заметил всплывающию информацию как правильно переехать с NOSql на Sql и что в этом одни плюсы) Смешно и грустно конечно, мне кажется микросервисы тоже на волне хайпа, все начали ругать "монолит" и показывать пальцем какой у них крутой (нет) и модный (да) микросервис.

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

Может бизнесу тоже стоит маленько посмотреть в себя, и стать маленько софт, а не относится к ИТ отделам как к воронке которая только деньги тянет. Особенно сочувствую безопасникам.

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

Что значит "не делится знаниями"?

Смотрю в код, а там одна магия.

Мужики, композиция в ООП есть.

Монолит, возможно, получился в противовес микросервисам. До них такого понятия не было?

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность

Специализация

Специалист
От 399 ₽