Комментарии 27
НЛО прилетело и опубликовало эту надпись здесь
Все так, с той лишь разницей, что она хочет создать эти кубики…
Которые до неё создавали десятки раз (список). Её бы подумать, почему ничего из созданного ранее не взлетело. Но пусть построит свои кубики, может что-то поймёт.
инженеры напрасно тратят время, воспроизводя одни и те же базовые элементы снова и сноваПо такой логике ДВС был придуман более 100 лет назад и крупносерийно использовался еще на Ford Model T, зачем этот базовый элемент совершенствовать?
Единственное, что должна сделать компания, — создать элементы, делающие её поделку уникальнойПо этой аналогии тот же Ford мог бы ставить однажды придуманный двигатель на все остальные авто и менять к примеру только кузов.
Для подобных дам движки Ford T, современной малолитражки и болида Формулы 1 ничем не отличаются — все делают одно и то же:
сжигают топливо и крутят трансмиссию, но на самом деле есть куча нюансов.
Точно также и в программировании вроде есть некие «базовые элементы» имеющие одинаковый функционал. Но в каждом конкретном проекте этот функционал реализуется разными способами просто потому, что предназначен для решения пусть и похожих, но разных задач. Вот и приходится их каждый раз «изобретать» заново.
Пока на рынке существует конкуренция между заказчиками, каждый из низ будет хотеть т.н. «базовые элементы» лучше чем у конкурентов.
А это значит, что всегда будут затребованы высококвалифицированные разработчики, которым, как бы этого не хотелось заказчикам, но придется платить
явно завышенную зарплатут.к. типовые решения не дают никаких конкурентных преимуществ.
>> Вы когда-либо задавались вопросом, почему нам нужен сервер, действующий как посредник между клиентом и базой данных? От этого следовало отказаться ещё вчера.
>> и многие (как и я) считают, что имеют право на получаемые деньги и бонусы
Ясно, человека лишили премии за внедрение «передовых идей» и он делится своей болью.
>> и многие (как и я) считают, что имеют право на получаемые деньги и бонусы
Ясно, человека лишили премии за внедрение «передовых идей» и он делится своей болью.
Девушка воду льет. Заголовок не соответствует содержанию. Мне наплевать на банальности и ереси, которые она высказала в столь объемном тексте (который я прочитал), поэтому содержание оставлю без особого внимания, а пройдусь заголовку и сделаю девушке антипиар путем выведения теории заговора из ее слов.
о заголовке:
>Прощай, программирование…
Заголовок говорит нам примерно следущее: Ассемблер появился и программисты в машкодах попрощались с программированием, С появился и программисты на асме попрощались с программированием, ..., typescript/purescript/coffeescript/etc появились и программисты на javascript попрощались с программированием.
Люди из лагеря «Прощай, программирование» умалчивают о том, что в этой сфере практически нет пределов роста, т.к. не пределов человеческим хотелкам. Каждый новый инструмент служит фундаментом для множества болееновых инструментов, построенных на его основе. Каждый год количество полезных и интересных штук, которые можно запрограммировать при помощи доступных на данный момент технологий в 2 раза вырастает. Вот когда всю вселенную запрограммируем или когда решим, что ничего полезного и интересного во вселенной больше не осталось или когда запреты/ограничения на программирование введут, то только тогда можно будет честно сказать «Прощай, программирование».
конспироложство:
>Люди должны отойти от написания схем баз данных, потому что мы неизбежно делаем это неправильно.
>инженеры напрасно тратят время, воспроизводя одни и те же базовые элементы снова и снова
если реально работающий инструмент будет, который на практике докажет, что он реально годен. Тогда люди им попользовавшись сами с удовольствием уйдут на новые фронтиры, а пока имхо девушке не следует говорить о том, чего люди должны делать. Т.к. от таких ее слов пахнет гуманитарщиной, лоббизмом и запретом на программирование (чего-то тянет меня сегодня на паранойю): некая корпорация боится утратить лидерство, поэтому заваливает всех своими бесплатными написателями схем баз данных, а законодатели принимают закон «о безопасности ПО», где прописано, что в продакшене запрешено использовать человеческий код т.к. он «неизбежно неправильный» и «возможно опасный».
о заголовке:
>Прощай, программирование…
Заголовок говорит нам примерно следущее: Ассемблер появился и программисты в машкодах попрощались с программированием, С появился и программисты на асме попрощались с программированием, ..., typescript/purescript/coffeescript/etc появились и программисты на javascript попрощались с программированием.
Люди из лагеря «Прощай, программирование» умалчивают о том, что в этой сфере практически нет пределов роста, т.к. не пределов человеческим хотелкам. Каждый новый инструмент служит фундаментом для множества болееновых инструментов, построенных на его основе. Каждый год количество полезных и интересных штук, которые можно запрограммировать при помощи доступных на данный момент технологий в 2 раза вырастает. Вот когда всю вселенную запрограммируем или когда решим, что ничего полезного и интересного во вселенной больше не осталось или когда запреты/ограничения на программирование введут, то только тогда можно будет честно сказать «Прощай, программирование».
конспироложство:
>Люди должны отойти от написания схем баз данных, потому что мы неизбежно делаем это неправильно.
>инженеры напрасно тратят время, воспроизводя одни и те же базовые элементы снова и снова
если реально работающий инструмент будет, который на практике докажет, что он реально годен. Тогда люди им попользовавшись сами с удовольствием уйдут на новые фронтиры, а пока имхо девушке не следует говорить о том, чего люди должны делать. Т.к. от таких ее слов пахнет гуманитарщиной, лоббизмом и запретом на программирование (чего-то тянет меня сегодня на паранойю): некая корпорация боится утратить лидерство, поэтому заваливает всех своими бесплатными написателями схем баз данных, а законодатели принимают закон «о безопасности ПО», где прописано, что в продакшене запрешено использовать человеческий код т.к. он «неизбежно неправильный» и «возможно опасный».
Заголовок не соответствует содержанию
Просто переводчик забил на смысл. Впрочем в последнее время на хабре это норма. В оригинале статья носит следующее название:
Coding Is Over
Что лучше перевести как "С Кодингом покончено!", а не "прощай программирование". Собственно вся статья несет одну простую мысль:
надо писать модули (если допустить что их количество ограничено, рано или поздно их все напишут), а приложения можно будет накликать в какой-нибудь мудрой примудрой програмке которую она собирается создать, хоть пока понятия не имеет как.
То есть статья делает выводы на ложных допущениях, которые к 80% задач хоть и применимы, но они и так уже решены (кучи CMS, конструкторы мобильных приложений, десктопных приложений, куча готовых сервисов). Но есть еще 20% которые формализовать так легко уже не выйдет.
Это примерно как те, кто считал, что наука уже знает всё и осталось изучить лишь сущие пустяки. В какой век ни ткни — везде такие были.
Чем меньше знаешь, тем меньше можешь осознать объём того, чего не знаешь.
Чем меньше знаешь, тем меньше можешь осознать объём того, чего не знаешь.
>Coding Is Over
тоже имхо не вариант. И дело не в том, что она не знает как создать. Допустим появляется сервис, где быстро и правильно можно делать все, о чем заявлено. Магазинчик можно накликать за 10 минут. Юзеры кликают и складывают кубики, получают то, что хотели, хотят еще больше. Те, кто раньше не думал, тоже полезли кликать, одних магазинчиков юзерам мало, инструмент-то вышел удобный, глупо его только для магазинов использовать. Юзеры хотят делать новые вещи, они хотят самых разных кубиков. Все это порождает 100500 кодеров, которые клепают модули-кубики для юзеров. «Coding Is Over».
тоже имхо не вариант. И дело не в том, что она не знает как создать. Допустим появляется сервис, где быстро и правильно можно делать все, о чем заявлено. Магазинчик можно накликать за 10 минут. Юзеры кликают и складывают кубики, получают то, что хотели, хотят еще больше. Те, кто раньше не думал, тоже полезли кликать, одних магазинчиков юзерам мало, инструмент-то вышел удобный, глупо его только для магазинов использовать. Юзеры хотят делать новые вещи, они хотят самых разных кубиков. Все это порождает 100500 кодеров, которые клепают модули-кубики для юзеров. «Coding Is Over».
НЛО прилетело и опубликовало эту надпись здесь
По-видимому, Лорен за 3 месяца своего «образования» так и не узнала, что бывает что-то еще кроме фронтэнда и CRUD сайтецов, про фрэймворки тоже, видимо, не слышала. Про опечатки вообще смешно на фоне этих «проводков» и прочих ужасов графического программирования.
Я сейчас хочу создать простой в использовании интерфейс, использующий «перетаскивание», в котором любой может создать полнофункциональное комплексное приложение без какого-либо программирования.
В сложных программах количество блоков, переключателей и связей между ними будет настолько большим, что это будет аналог языка программирования. В этом основная проблема таких рассуждений.
Как-то занимался поддержкой одного проекта на Remedy (не то 6, не то 7). Это был ужас, состоящий на половину из ворк-эраундов для ограничений платформы и извращённой, вывернутой наизнанку логики, диктуемой самой платформой. Причём выписывать все IFы при помощи мышки было просто невероятно «удобно». Самые банальные задачи требовали часов кропотливой возни мышкой. А самое забавное было в том, что разобраться во всём этом нагромождении средствами самой платформы было вообще нереально и приходилось пользоваться сторонней (и тоже платной) утилитой, название которой запамятовал.
Девушка вообще не программист. Она не понимает простой вещи — что софт развивается во времени. Что это развитие нужно отслеживать, чтобы понимать, какие именно проводки мы переключили, прежде чем оно перестало работать. Чтобы исправлять ошибки, и делать выводы.
И не понимает того, что во всех этих системах "без программирования", позволяющих таскать проводки мышкой, ничего этого делать нельзя. У этих картинок нет истории.
Более того — на эти грабли человечество уже наступало много-много раз. Она далеко не первая, и к сожалению не последняя.
Мне кажется или в этом интерфейсе с проводками может разобраться только:
* сумасшедший;
* автор (не знаю к какой из двух оставшихся групп он относится больше);
* человек, работавший с реальным оборудованием, которое данный интерфейс эмулирует.
?
Причём не факт, что последний не предпочёл бы блок-схему из необходимых эффектов вместо этой каши.
* сумасшедший;
* автор (не знаю к какой из двух оставшихся групп он относится больше);
* человек, работавший с реальным оборудованием, которое данный интерфейс эмулирует.
?
Причём не факт, что последний не предпочёл бы блок-схему из необходимых эффектов вместо этой каши.
Ну, справедливости ради, оно вполне себе наглядно показывает, какой блок аппаратуры в какую прослойку включён. Да, то же самое можно представить в виде xml, например, переименовывая ID для in{n} и out аттрибутов, но это таки менее наглядно.
Ествественно, всё будет зависеть от сложности последовательности, надо сравнивать конкретные примеры.
Хотя вот предложенный вариант с блок-схемами тоже вполне себе ничего. Но это тоже от сложности зависит, как говорят о разных модных языках "глазу не за чтио зацепиться", так что в однотипных блок схемах может не хватать разных проводков и разного вида блоков, чего здесь, конечно, в явном избытке.
Не смог осилить — маразмометр взорвался.
НЛО прилетело и опубликовало эту надпись здесь
Building stuff in virtual reality. I just bought one of these and it’s dope.Строительный материал в виртуальной реальности. Я только что купила кое-что, и это обман.
Building stuff в данном контексте переводится как «делать вещи», а не «строительный материал».
Bought one of these and it's dope — переводится как «купила это(ссылка на HTC Vive), и это круто».
Building stuff в данном контексте переводится как «делать вещи», а не «строительный материал».
Bought one of these and it's dope — переводится как «купила это(ссылка на HTC Vive), и это круто».
Сначала надо придумать единый универсальный язык программирования (ЕУЯП), который заменит все остальные, каждый из которых имеет свои очевидные недостатки, которые могут быть устранены в новом стандарте, это уже сильно упростит всем работу. И ещё желательно одну IDE, чтоб не переучиваться каждый раз.
Мне же не одному кажется, что это просто «спонсорский контент»?
Довольно часто на хабре можно встретить переводы подобных статей. Кричащий заголовок, чтобы привлечь побольше людей, автор, пытающийся открыть нам глаза и донести правду и самое главное, едва заметное упоминание какого-то сервиса\программы ( как правило со стандартной схемой подписки вида бесплатно | стартер | медиум | бизнес)
Довольно часто на хабре можно встретить переводы подобных статей. Кричащий заголовок, чтобы привлечь побольше людей, автор, пытающийся открыть нам глаза и донести правду и самое главное, едва заметное упоминание какого-то сервиса\программы ( как правило со стандартной схемой подписки вида бесплатно | стартер | медиум | бизнес)
Субъективно, отказ от базового понимания того, что ты используешь, ведет к большим потенциальным проблемам.
Наверное, «менеджеры по продуктам, не зная, вообще, программирования», могут собрать из кубиков интернет-магазин или очередной модный веб-сервис. Но в какой-то момент к ним придет специалист по информационной безопасности и скажет, что в комбинации из этих кубиков есть дыра. И менеджерам стоит молить всех богов, чтобы это произошло до взлома, а не после.
Приведу пример из недавней практики: одна чудесная компания решила создать не менее чудесный сервис, который обрабатывает ценные данные пользователей (по понятным причинам я не могу назвать компанию). Они собрали свой сервис всего из двух кубиков (один свой, другой — стороннего разработчика). И в кубике стороннего разработчика была обнаружена критическая уязвимость, которая позволяла получить полный доступ к данным всех клиентов. Но никто из сотрудников компании не может изменить код этого кубика, а разработчик не делает исправление для этой ветки.
Эта история звучит забавно, но именно такое мы будем видеть всюду, если программы и сервисы будут состоять из кучи кубиков, которые перетягивают и складывают менеджеры.
Наверное, «менеджеры по продуктам, не зная, вообще, программирования», могут собрать из кубиков интернет-магазин или очередной модный веб-сервис. Но в какой-то момент к ним придет специалист по информационной безопасности и скажет, что в комбинации из этих кубиков есть дыра. И менеджерам стоит молить всех богов, чтобы это произошло до взлома, а не после.
Приведу пример из недавней практики: одна чудесная компания решила создать не менее чудесный сервис, который обрабатывает ценные данные пользователей (по понятным причинам я не могу назвать компанию). Они собрали свой сервис всего из двух кубиков (один свой, другой — стороннего разработчика). И в кубике стороннего разработчика была обнаружена критическая уязвимость, которая позволяла получить полный доступ к данным всех клиентов. Но никто из сотрудников компании не может изменить код этого кубика, а разработчик не делает исправление для этой ветки.
Эта история звучит забавно, но именно такое мы будем видеть всюду, если программы и сервисы будут состоять из кучи кубиков, которые перетягивают и складывают менеджеры.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Прощай, программирование…