-
![[image]](https://www.balancer.ru/cache/sites/ru/bo/books/files/pic/592001-593000/592346/128x128-crop/592346.jpg)
Как обидеть быдлокодеров?
Теги:
Gudleifr
Этот документ - попытка объяснить, зачем начинающему программисту институт. Ведь, существует огромное количество курсов, которые обещают научить писать красивые и успешно продаваемые программы без какой-либо перегрузки мозга высшими материями и отсиживания задницы на ненужных лекциях.
Чуть ли не единственным доводом за институт остается "чисто армейский" - "школа жизни". До института ты - школяр, после - инженер - мужик, наличие мозгов и рук которого подтверждено официальным документом. Тебя можно брать с собой в командировку, затыкать тобой дыры на производстве и поручать прикрывать тылы.
Как можно изучать программирование?
1. Проработать один (пару-другую) патентованных учебников (видекурсов).
2. Упражняться в решении большого числа маленьких задачек на интересующие темы.
3. Изучать только то, что нужно по жизни.
4. Попытаться написать что-то большое, попутно изучая потребные науки.
Что дома, что в институте этим заниматься. Разница только в самомнении и доверии к учителю.
Есть ли какие-то "великие тайны", которые знают только "институтские", и которые дают им нечестное преимущество в конкурентной борьбе?
Есть. Но хитрость в том, что их нельзя просто так передать. Ведь, старые книжки такие толстые не потому, что там много воды, а потому, что то, о чем там рассказывается, нельзя изложить в двух словах. Как объяснить первокласснику тригонометрию? Никак. А как объяснить ему, что он еще до тригонометрии не дорос? Тоже никак. Просто есть вещи, о которых детям не говорят, чтобы самим не выглядеть глупыми.
Вот институт и пытается не столько вложить в голову студента некие знания и умения, сколько организовать в его мозгу место для их хранения. И научить инженера этим местом пользоваться разумно.
ГЛАВА ПЕРВАЯ. ОСНОВНЫЕ ПОНЯТИЯ
Аксиома 1: Программистов не бывает. Есть только системщики и пользователи. Системщики бывают математикам или электронщиками, а пользователи - физиками или лириками.
Следствие 11: Программирование - есть создание кибернетических машин, максимум энтропии которых соответствует останову при получении правильного результата.
Следствие 12: Машина понимает только действия и значения. Любые абстракции - функции, объекты, компоненты, системы, языки - это лишь многоуровневые системы имен, (обозначающих некоторые наборы действий, значений и других имен), удобных для решения некоторых конкретных задач.
Следствие 13: Если запись решения на языке программирования оказывается более путаной и длинной, чем на человеческом языке, значит, программист не владеет нужным языком программирования.
Следствие 14: Тестирование программы не может доказать отсутствия в ней ошибок.
Следствие 15: Сложность программы определяется только ее размером.
ГЛАВА ВТОРАЯ. КУРСЫ
Аксиома 2: Нельзя научить решать задачи, но можно научиться решать задачи.
Следствие 21: В обучении программированию наглядность курсов обратно пропорциональна полезности. Ибо программирование - умение абстрагироваться от наглядности.
Следствие 22: Знания/умения программиста никак не могут иметь ценности за пределами конкретной задачи.
Следствие 23: Сначала научись что-то делать и только потом учись это программировать.
ГЛАВА ТРЕТЬЯ. ЗАДАЧИ
Аксиома 3: Человек решает задачу. Человек программирует решение для машины. Человек знает необходимые детали устройства машины. Эти три умения программиста между собой никак не связаны
Следствие 31: Любое решение программистской задачи можно записать языком математики. Т.к. машина является материальным представлением языка математики, то существует способ перевода решения задачи на язык машины. Этот способ называется языком программирования.
Следствие 32: Языки программирования в равной степени могут созданы теоретиками, практикам или самим программистом.
Следствие 33: Если результат можно рассчитать, это хорошо, если нет - нужно использовать таблицы. Только, если и это невозможно, можно применять сложные структуры управления языка программирования.
Следствие 34: язык программирования выбирается/изобретается таким, чтобы как можно больше результатов рассчитать.
ГЛАВА ЧЕТВЕРТАЯ. САМОДЕЛКИ
Аксиома 4: мы живем в матрице, которую называем культурой.
Следствие 41: Машина должна исполнять не ту работу, которую легко запрограммировать, но ту, которую человеку исполнять сложно или неинтересно.
Следствие 42: Легкость программирования определяется не интеллектуальностью машины, но ее простотой.
Следствие 43: Машины/языки развиваются в двух направлениях: "понимают, что вам надо" - интерпретаторы, и "знают лучше вас, что вам надо" - компиляторы. И это развитие далеко опережает реальные потребности программиста.
Следствие 44: Простейший способ написать что-то сложное - переложить работу на пользователя.
Следствие 45: Объединять простые модули в сложную программу удобнее всего средствами операционной системы. Не стоит это делать вручную (изобретать для этого сложные языки).
ГЛАВА ПЯТАЯ. ПРОЕКТЫ
Аксиома 5: Очень небольшой процент рабочего времени программист тратит на написание программ. Гораздо больше уходит на то, чтобы заставить их работать. Первое приятно и престижно, второе - нет.
Следствие 51: Ни один программист не любит сложных программ. Пропадает даже та маленькая толика удовольствия, которая ему положена.
Следствие 52: Еще эфемернее предстает возможность научиться программировать на большом проекте. Неразрешимые проблемы встретятся раньше, чем появятся первые результаты.
Следствие 53: Единственный способ написания хорошей программы - полное выбрасывание исходников, как только они перестают нравиться.
ЗАКЛЮЧЕНИЕ.
Человек в своей личной эволюции, начиная от стадии скотского эгоизма проходит стадию альтруизма, затем - пофигизма, и, наконец, дорастает до эгоизма разумного. И роль любого учебного заведения - способствовать этой эволюции. Или, хотя бы, научить человека воспринимать себя, любимого, чуть менее серьезно.
ДАО ПРОГРАММИРОВАНИЯ.
Каждый день сокращай время, проводимое за компьютером!
Чуть ли не единственным доводом за институт остается "чисто армейский" - "школа жизни". До института ты - школяр, после - инженер - мужик, наличие мозгов и рук которого подтверждено официальным документом. Тебя можно брать с собой в командировку, затыкать тобой дыры на производстве и поручать прикрывать тылы.
Как можно изучать программирование?
1. Проработать один (пару-другую) патентованных учебников (видекурсов).
2. Упражняться в решении большого числа маленьких задачек на интересующие темы.
3. Изучать только то, что нужно по жизни.
4. Попытаться написать что-то большое, попутно изучая потребные науки.
Что дома, что в институте этим заниматься. Разница только в самомнении и доверии к учителю.
Есть ли какие-то "великие тайны", которые знают только "институтские", и которые дают им нечестное преимущество в конкурентной борьбе?
Есть. Но хитрость в том, что их нельзя просто так передать. Ведь, старые книжки такие толстые не потому, что там много воды, а потому, что то, о чем там рассказывается, нельзя изложить в двух словах. Как объяснить первокласснику тригонометрию? Никак. А как объяснить ему, что он еще до тригонометрии не дорос? Тоже никак. Просто есть вещи, о которых детям не говорят, чтобы самим не выглядеть глупыми.
Вот институт и пытается не столько вложить в голову студента некие знания и умения, сколько организовать в его мозгу место для их хранения. И научить инженера этим местом пользоваться разумно.
ГЛАВА ПЕРВАЯ. ОСНОВНЫЕ ПОНЯТИЯ
Аксиома 1: Программистов не бывает. Есть только системщики и пользователи. Системщики бывают математикам или электронщиками, а пользователи - физиками или лириками.
Следствие 11: Программирование - есть создание кибернетических машин, максимум энтропии которых соответствует останову при получении правильного результата.
Следствие 12: Машина понимает только действия и значения. Любые абстракции - функции, объекты, компоненты, системы, языки - это лишь многоуровневые системы имен, (обозначающих некоторые наборы действий, значений и других имен), удобных для решения некоторых конкретных задач.
Следствие 13: Если запись решения на языке программирования оказывается более путаной и длинной, чем на человеческом языке, значит, программист не владеет нужным языком программирования.
Следствие 14: Тестирование программы не может доказать отсутствия в ней ошибок.
Следствие 15: Сложность программы определяется только ее размером.
ГЛАВА ВТОРАЯ. КУРСЫ
Аксиома 2: Нельзя научить решать задачи, но можно научиться решать задачи.
Следствие 21: В обучении программированию наглядность курсов обратно пропорциональна полезности. Ибо программирование - умение абстрагироваться от наглядности.
Следствие 22: Знания/умения программиста никак не могут иметь ценности за пределами конкретной задачи.
Следствие 23: Сначала научись что-то делать и только потом учись это программировать.
ГЛАВА ТРЕТЬЯ. ЗАДАЧИ
Аксиома 3: Человек решает задачу. Человек программирует решение для машины. Человек знает необходимые детали устройства машины. Эти три умения программиста между собой никак не связаны
Следствие 31: Любое решение программистской задачи можно записать языком математики. Т.к. машина является материальным представлением языка математики, то существует способ перевода решения задачи на язык машины. Этот способ называется языком программирования.
Следствие 32: Языки программирования в равной степени могут созданы теоретиками, практикам или самим программистом.
Следствие 33: Если результат можно рассчитать, это хорошо, если нет - нужно использовать таблицы. Только, если и это невозможно, можно применять сложные структуры управления языка программирования.
Следствие 34: язык программирования выбирается/изобретается таким, чтобы как можно больше результатов рассчитать.
ГЛАВА ЧЕТВЕРТАЯ. САМОДЕЛКИ
Аксиома 4: мы живем в матрице, которую называем культурой.
Следствие 41: Машина должна исполнять не ту работу, которую легко запрограммировать, но ту, которую человеку исполнять сложно или неинтересно.
Следствие 42: Легкость программирования определяется не интеллектуальностью машины, но ее простотой.
Следствие 43: Машины/языки развиваются в двух направлениях: "понимают, что вам надо" - интерпретаторы, и "знают лучше вас, что вам надо" - компиляторы. И это развитие далеко опережает реальные потребности программиста.
Следствие 44: Простейший способ написать что-то сложное - переложить работу на пользователя.
Следствие 45: Объединять простые модули в сложную программу удобнее всего средствами операционной системы. Не стоит это делать вручную (изобретать для этого сложные языки).
ГЛАВА ПЯТАЯ. ПРОЕКТЫ
Аксиома 5: Очень небольшой процент рабочего времени программист тратит на написание программ. Гораздо больше уходит на то, чтобы заставить их работать. Первое приятно и престижно, второе - нет.
Следствие 51: Ни один программист не любит сложных программ. Пропадает даже та маленькая толика удовольствия, которая ему положена.
Следствие 52: Еще эфемернее предстает возможность научиться программировать на большом проекте. Неразрешимые проблемы встретятся раньше, чем появятся первые результаты.
Следствие 53: Единственный способ написания хорошей программы - полное выбрасывание исходников, как только они перестают нравиться.
ЗАКЛЮЧЕНИЕ.
Человек в своей личной эволюции, начиная от стадии скотского эгоизма проходит стадию альтруизма, затем - пофигизма, и, наконец, дорастает до эгоизма разумного. И роль любого учебного заведения - способствовать этой эволюции. Или, хотя бы, научить человека воспринимать себя, любимого, чуть менее серьезно.
ДАО ПРОГРАММИРОВАНИЯ.
Каждый день сокращай время, проводимое за компьютером!
Это сообщение редактировалось 03.11.2016 в 00:58
инфо
инструменты
ГЛАВА 2. БЫДЛОКОДЕРСТВО КАК НЕПОНИМАНИЕ ДУАЛИЗМА
Интересно, много ли осталось людей, понимающих, что если бы на этот вопрос существовал ответ в форме, ожидаемой спрашивающим, т.е. "тупо создайте темплейт объекта типа <дурацкий факт> и тупо используйте его метод <логическое осмысление>", то программирование не было бы искусством?
В чем же в данном случае это искусство заключается?
Налицо наличие некоторого набора фактов/правил на основании которых нужно произвести некоторые выводы/действия. Программированием чего программист и занимается всю свою сознательную жизнь.
С точки зрения банальной эрудиции подобные вычисления производятся путем "прямой" или "обратной цепочек рассуждений". В первом случае в цикле перебираются все факты, до получения всех возможных выводов, во втором - идут от нужного вывода, проверяя достаточно ли для него фактов.
Это знают все. Особенно изобретатели всяких там языков "логического", "автоматного" и "прочего хитрого" программирования. Но подавляющее большинство почему-то забыло, что ВСЕ языки программирования, даже какой-нибудь ALGOL-60, УЖЕ являются машинами для подобных рассуждений. Наличествующие в той или иной мере в каждом языке механизм данных и процедур уже готовы к решению "рассуждательной проблемы". Механизм данных обеспечивает накопление фактов (прямая цепочка), механизм процедур - их запрашивает и использует (обратная цепочка). Все остальное, что есть в языке - способ как-то ограничить "область перебора", т.е. разбить и факты, и действия на изолированные группы, в которых и осуществлять логические вычисления. Т.е. не проверять все условия боя на мечах при расчете космических перелетов, и не проверять, как влияет бузина в огороде на поведение дядьки в Киеве.
Т.е. любой язык программирования - способ свести в одно целое оба "переборных" решения в одно работающее. И первая примета быдлокодера - жесткая фиксация "способа решения" для всех предложенных задач, а не совмещение прямого и обратного подхода по месту. А супербыдлокодеры изобретают языки, которые фиксируют этот способ...
Существуют ли системы, при изобретении которых программист вынужден все-таки, однозначно определить, каким способом он будет рассуждать? Этот вопрос целиком относится к вопросу ограничений машины, для которой пишется программа. Противопоставление машины с хранимой программой (изменяющей свой код при получении новых фактов) машине с произвольным доступом к памяти (способной гибко запрашивать данные). Или, даже, противопоставление ОС, основанных на процессах (ожидающих готовности данных), ОС, основанным на сообщениях (где данные вызывают действия). Применение одного из методов в этих случаях диктуется железом. Но! Для программиста отличие одной машины/ОС от другой совершенно ничего не определяют! Эквивалентность этих машин/ОС многократно проверена и местами строго доказана! Так, что привязывая свою логику к WIN-объектам и/или пытаясь описать в XML-файлах все сущее, быдлокодер, по сути, отказывается от решения программистской задачи, пытаясь тупо приспособить вчерашнее решение к сегодняшней задачи.
Есть, например, юниты, у каждого - набор свойств и навыков (а-ля Герои - Минотавр имеет "Храбрость", лазутчик - "Отравленный выстрел")
Возникает, скажем, такая ситуация: лучник стреляет в пехотинца, применяя скилл "Стрельба". Пехотинец имеет навык "Щит", поэтому урон снижен. Однако лучник не простой, он имеет также способность "огненная стрела", поэтому пехотинец загорается. Но будь у пехотинца свойство "Несгораемость", не подгорел бы.
Все юниты, эффекты, навыки - отдельные объекты, с набором методов и, тем более, их реализацией, я не могу определиться.
Как бы вы стали организовывать подобное взаимодействие? Т.е. срабатывание (применение) одного скилла может активировать другой и так далее. Где какой код писать (идейно)?
Интересно, много ли осталось людей, понимающих, что если бы на этот вопрос существовал ответ в форме, ожидаемой спрашивающим, т.е. "тупо создайте темплейт объекта типа <дурацкий факт> и тупо используйте его метод <логическое осмысление>", то программирование не было бы искусством?
В чем же в данном случае это искусство заключается?
Налицо наличие некоторого набора фактов/правил на основании которых нужно произвести некоторые выводы/действия. Программированием чего программист и занимается всю свою сознательную жизнь.
С точки зрения банальной эрудиции подобные вычисления производятся путем "прямой" или "обратной цепочек рассуждений". В первом случае в цикле перебираются все факты, до получения всех возможных выводов, во втором - идут от нужного вывода, проверяя достаточно ли для него фактов.
Это знают все. Особенно изобретатели всяких там языков "логического", "автоматного" и "прочего хитрого" программирования. Но подавляющее большинство почему-то забыло, что ВСЕ языки программирования, даже какой-нибудь ALGOL-60, УЖЕ являются машинами для подобных рассуждений. Наличествующие в той или иной мере в каждом языке механизм данных и процедур уже готовы к решению "рассуждательной проблемы". Механизм данных обеспечивает накопление фактов (прямая цепочка), механизм процедур - их запрашивает и использует (обратная цепочка). Все остальное, что есть в языке - способ как-то ограничить "область перебора", т.е. разбить и факты, и действия на изолированные группы, в которых и осуществлять логические вычисления. Т.е. не проверять все условия боя на мечах при расчете космических перелетов, и не проверять, как влияет бузина в огороде на поведение дядьки в Киеве.
Т.е. любой язык программирования - способ свести в одно целое оба "переборных" решения в одно работающее. И первая примета быдлокодера - жесткая фиксация "способа решения" для всех предложенных задач, а не совмещение прямого и обратного подхода по месту. А супербыдлокодеры изобретают языки, которые фиксируют этот способ...
Существуют ли системы, при изобретении которых программист вынужден все-таки, однозначно определить, каким способом он будет рассуждать? Этот вопрос целиком относится к вопросу ограничений машины, для которой пишется программа. Противопоставление машины с хранимой программой (изменяющей свой код при получении новых фактов) машине с произвольным доступом к памяти (способной гибко запрашивать данные). Или, даже, противопоставление ОС, основанных на процессах (ожидающих готовности данных), ОС, основанным на сообщениях (где данные вызывают действия). Применение одного из методов в этих случаях диктуется железом. Но! Для программиста отличие одной машины/ОС от другой совершенно ничего не определяют! Эквивалентность этих машин/ОС многократно проверена и местами строго доказана! Так, что привязывая свою логику к WIN-объектам и/или пытаясь описать в XML-файлах все сущее, быдлокодер, по сути, отказывается от решения программистской задачи, пытаясь тупо приспособить вчерашнее решение к сегодняшней задачи.
Это сообщение редактировалось 02.12.2019 в 12:01
Gudleifr>> Конфигурирование плана счетов и аналитических отчетов с точки зрения программиста - очередное проявление дурости, извините. Честно говоря, если программист не перерастет желание подкалымить на бухах, он конченый человек. Хотя, по молодости, знакомство с классом задач, лучшее решение которых состоит в отказе от решения, бывает полезным.
Mishka> предупреждение (+2) по категории «Категоричное сомнительное заявление, не подтверждённое фактом [п.11]»
По просьбе "трудящихся", факт - трактат Луки Пачоли, 1494.
Вообще же, как говаривал Дейкстра: "задача... позволяет нам рассеять некоторые сомнения, вызванные тем, что коммерческие программы являются чем-то особенным. (Если уж говорить о чем-то особом, то, скорее, о характере коммерческих программистов...)".
Так что, эффективность метода подтверждена опытным путем!
9 минусов без каких-либо обоснований за четыре честных ответа, от человека, не участвующего в дискуссии - это отличное попадание!
Mishka> предупреждение (+2) по категории «Категоричное сомнительное заявление, не подтверждённое фактом [п.11]»
По просьбе "трудящихся", факт - трактат Луки Пачоли, 1494.
Вообще же, как говаривал Дейкстра: "задача... позволяет нам рассеять некоторые сомнения, вызванные тем, что коммерческие программы являются чем-то особенным. (Если уж говорить о чем-то особом, то, скорее, о характере коммерческих программистов...)".
Так что, эффективность метода подтверждена опытным путем!
9 минусов без каких-либо обоснований за четыре честных ответа, от человека, не участвующего в дискуссии - это отличное попадание!
Это сообщение редактировалось 01.08.2016 в 16:14
Mishka
Gudleifr> Так что, эффективность метода подтверждена опытным путем!
У тебя мало того, что каша в голове, так ещё и доказательства высказываний пальцем из носа вытащена.
PS Надо будет всю тему перенести куда-нибудь в чёрную дыру. Там ей место...
У тебя мало того, что каша в голове, так ещё и доказательства высказываний пальцем из носа вытащена.
PS Надо будет всю тему перенести куда-нибудь в чёрную дыру. Там ей место...
спокойный_тип> да мне кажется он тупо троллит...после собственно после заявлений про то что всё программирование сейчас визуальное и конфигурировать счета это западло для ТРУ-программиста - можно дальше и не читать
Ок. Правда, не помню, чтобы писал, что ВСЕ программирование сейчас визуальное. Много Вы знаете современных систем программирования, не имеющих GUI-IDE, GUI-отладчиков, не требующих редактирования мультимедиа-ресурсов? Многие из ваших знакомых программистов честно прогоняют документацию на свои программы через фильтры-форматтеры, а не лепят ее в офисе?
Конфигурировать счета не западло для ТРУ-программиста? Тогда Вы очевидно можете сформулировать задачу в терминах операций над множествами и доказать ее нетривиальнось?
Пока, единственный аргумент, который я слышал, "от тещи": "И чего спорит, знает же, что я права!"
P.S. Кстати, облегчить срыв с "бухгалтерского крючка" могут облегчить эти задачки:
STAR TREK
КОРОЛИ И КАПУСТА
Ок. Правда, не помню, чтобы писал, что ВСЕ программирование сейчас визуальное. Много Вы знаете современных систем программирования, не имеющих GUI-IDE, GUI-отладчиков, не требующих редактирования мультимедиа-ресурсов? Многие из ваших знакомых программистов честно прогоняют документацию на свои программы через фильтры-форматтеры, а не лепят ее в офисе?
Конфигурировать счета не западло для ТРУ-программиста? Тогда Вы очевидно можете сформулировать задачу в терминах операций над множествами и доказать ее нетривиальнось?
Пока, единственный аргумент, который я слышал, "от тещи": "И чего спорит, знает же, что я права!"
P.S. Кстати, облегчить срыв с "бухгалтерского крючка" могут облегчить эти задачки:
STAR TREK
КОРОЛИ И КАПУСТА
Это сообщение редактировалось 01.08.2016 в 19:14
Gudleifr> P.S. Кстати, облегчить срыв с "бухгалтерского крючка" могут облегчить эти задачки:
Gudleifr> STAR TREK
Gudleifr> КОРОЛИ И КАПУСТА
Да, кстати, как я клал на бухгалтерию?
В смутные времена пару лет просидел в районном Сбербанке инженером. Обнаглел до предела - все вокруг, даже в центральном офисе, руками ошибки в FoxBase+/Clipper базах исправляют - а я для этого программки пишу. Даже вывеску повесил: "Меньше миллиона не беспокоить". Потом начал SQL-прибамбасики для комитетов лабать. Но т.к. там сами не знали, чего им надо, то заинтересовал вопрос написания программы, которая сама бы за них думала. Перешел с реляционных баз на списковые базы знаний. Даже печатный труд почти до ума довел: "АФИГЕННО МНОГОФАКТОРНЫЙ БАЗОВЫЙ ACCESSOR - 1001 СПОСОБ ПОЛУЧИТЬ УДОВОЛЬСТВИЕ ОТ РАБОТЫ С БАЗАМИ ДАННЫХ НЕРЕЛЯЦИОННЫМ СПОСОБОМ". В общем, когда в очередной раз пришли с очередной Access-халтурой, послал на фиг и пошел искать чего поинтереснее (более кибернетическое). Спустя несколько лет два раза поржал - когда оставшийся в бухгалтерии товарищ доверительно заявил, что они, наконец, поняли, о чем первая глава "АМБЫ", и когда узнал про XML. Правда, смеялся я над мальчиками в костюмчиках, а сам числился мастером п/о с обязанностями "технического бога" (но без прав), но потом вернулся в оборонку и продолжил удовлетворение своего кибернетического любопытства за государственный счет.
Gudleifr> STAR TREK
Gudleifr> КОРОЛИ И КАПУСТА
Да, кстати, как я клал на бухгалтерию?
В смутные времена пару лет просидел в районном Сбербанке инженером. Обнаглел до предела - все вокруг, даже в центральном офисе, руками ошибки в FoxBase+/Clipper базах исправляют - а я для этого программки пишу. Даже вывеску повесил: "Меньше миллиона не беспокоить". Потом начал SQL-прибамбасики для комитетов лабать. Но т.к. там сами не знали, чего им надо, то заинтересовал вопрос написания программы, которая сама бы за них думала. Перешел с реляционных баз на списковые базы знаний. Даже печатный труд почти до ума довел: "АФИГЕННО МНОГОФАКТОРНЫЙ БАЗОВЫЙ ACCESSOR - 1001 СПОСОБ ПОЛУЧИТЬ УДОВОЛЬСТВИЕ ОТ РАБОТЫ С БАЗАМИ ДАННЫХ НЕРЕЛЯЦИОННЫМ СПОСОБОМ". В общем, когда в очередной раз пришли с очередной Access-халтурой, послал на фиг и пошел искать чего поинтереснее (более кибернетическое). Спустя несколько лет два раза поржал - когда оставшийся в бухгалтерии товарищ доверительно заявил, что они, наконец, поняли, о чем первая глава "АМБЫ", и когда узнал про XML. Правда, смеялся я над мальчиками в костюмчиках, а сам числился мастером п/о с обязанностями "технического бога" (но без прав), но потом вернулся в оборонку и продолжил удовлетворение своего кибернетического любопытства за государственный счет.
Это сообщение редактировалось 01.08.2016 в 21:04
спокойный_тип>> да мне кажется он тупо троллит...после собственно после заявлений про то что всё программирование сейчас визуальное и конфигурировать счета это западло для ТРУ-программиста - можно дальше и не читать
Gudleifr> Ок. Правда, не помню, чтобы писал, что ВСЕ программирование сейчас визуальное. Много Вы знаете современных систем программирования, не имеющих GUI-IDE, GUI-отладчиков, не требующих редактирования мультимедиа-ресурсов? Многие из ваших знакомых программистов честно прогоняют документацию на свои программы через фильтры-форматтеры, а не лепят ее в офисе?
ммм...ну я вот как-то с написанием скриптов сталкиваюсь (программист ещё тот конечно, скорее экс-админ - помогаю временами с интерфейсами между типа какойнить DWH на Оракле и CRM на ещё чемнить)- особо гуев в перле и шелле не попадалось, на REXXе тоже не было гуя
Gudleifr> Конфигурировать счета не западло для ТРУ-программиста? Тогда Вы очевидно можете сформулировать задачу в терминах операций над множествами и доказать ее нетривиальнось?
чесно говоря хоть и АСУшник но с момента получения диплома аболютно не испытываю необходимости в теории множеств (последние лет 15 как минимум), вообще ценность теоретизирования в прикладном ИТ сильно преувеличивают
Gudleifr> Пока, единственный аргумент, который я слышал, "от тещи": "И чего спорит, знает же, что я права!"
Gudleifr> P.S. Кстати, облегчить срыв с "бухгалтерского крючка" могут облегчить эти задачки:
Gudleifr> STAR TREK
Gudleifr> КОРОЛИ И КАПУСТА
просто мне претит твоё высокомерие, припёрся тут тру-программист и давай рассказывать что он дАртартаньян а кругом одни казуальщики которых нужно спасать от бухгалтерского крючка)))
Gudleifr> Ок. Правда, не помню, чтобы писал, что ВСЕ программирование сейчас визуальное. Много Вы знаете современных систем программирования, не имеющих GUI-IDE, GUI-отладчиков, не требующих редактирования мультимедиа-ресурсов? Многие из ваших знакомых программистов честно прогоняют документацию на свои программы через фильтры-форматтеры, а не лепят ее в офисе?
ммм...ну я вот как-то с написанием скриптов сталкиваюсь (программист ещё тот конечно, скорее экс-админ - помогаю временами с интерфейсами между типа какойнить DWH на Оракле и CRM на ещё чемнить)- особо гуев в перле и шелле не попадалось, на REXXе тоже не было гуя
Gudleifr> Конфигурировать счета не западло для ТРУ-программиста? Тогда Вы очевидно можете сформулировать задачу в терминах операций над множествами и доказать ее нетривиальнось?
чесно говоря хоть и АСУшник но с момента получения диплома аболютно не испытываю необходимости в теории множеств (последние лет 15 как минимум), вообще ценность теоретизирования в прикладном ИТ сильно преувеличивают
Gudleifr> Пока, единственный аргумент, который я слышал, "от тещи": "И чего спорит, знает же, что я права!"
Gudleifr> P.S. Кстати, облегчить срыв с "бухгалтерского крючка" могут облегчить эти задачки:
Gudleifr> STAR TREK
Gudleifr> КОРОЛИ И КАПУСТА
просто мне претит твоё высокомерие, припёрся тут тру-программист и давай рассказывать что он дАртартаньян а кругом одни казуальщики которых нужно спасать от бухгалтерского крючка)))
V.Stepan
с.т.> на REXXе тоже не было гуя
VisPro/REXX (или тут) и VX-REXX
Но я согласен, что для скриптов гуй в большинстве случаев не нужен.
VisPro/REXX (или тут) и VX-REXX
Но я согласен, что для скриптов гуй в большинстве случаев не нужен.
с.т.> ммм...ну я вот как-то с написанием скриптов сталкиваюсь (программист ещё тот конечно, скорее экс-админ - помогаю временами с интерфейсами между типа какойнить DWH на Оракле и CRM на ещё чемнить)- особо гуев в перле и шелле не попадалось, на REXXе тоже не было гуя
"Постепенно пустеет Дономага. В каком-то далеком ее уголке еще страдает Рожденный в Колбе, несчастный пленник машины, само существование которой давно потеряло смысл".
Пардон, навеяло. Но, ведь, Вы перечислили вещи, которые никак "современными" не назовешь. Взять то же Perl. Мало того, что он уже давно оброс визуальными прибабахами (теми же интерфейсами с Tk и Qt), так он уже давно вытесняется из области скриптостроения всякими шаблонерами-профайлерами-паттернизаторами и прочей фигней. И речь я вел не о том, что визуальность это плохо, а о том, что обвес ПО эргономическими прибабахами (да, в т.ч. и визуальными) просто не даст патриотизировать "нужное для работы" ПО. Например, прикиньте, какие из применяемых Вами инструментов будут переписаны, а про какие просто забудут "за давностью лет" и которые Вам придется срочно заменять на аналоги.
V.Stepan> Но я согласен, что для скриптов гуй в большинстве случаев не нужен.
Ага, за исключением GUI-скриптов, которых давно стало больше, чем текстовых.
с.т.> вообще ценность теоретизирования в прикладном ИТ сильно преувеличивают
И после этого меня обвиняют в категоричных утверждениях, не соответствующих действительности!
с.т.> просто мне претит твоё высокомерие
А Ваше бухгалтерское высокомерие, думаете, не претит программистам? Можно было бы сказать, что ситуация зеркальная. Те не понимают теории, эти бухгалтерии... Но! Программист может получить несомненный кайф, читая труды Дейкстры и Кнута... Как пишут, заразы! А получить кайф от "Налогового вестника" проблематично.
Кстати, я специально предложил "бухгалтерам" задачки, которые, на первый взгляд кажутся реализуемыми простейшими DB-скриптами, но в процессе вникания вызовут потребность подумать и над теорией.
"Постепенно пустеет Дономага. В каком-то далеком ее уголке еще страдает Рожденный в Колбе, несчастный пленник машины, само существование которой давно потеряло смысл".
Пардон, навеяло. Но, ведь, Вы перечислили вещи, которые никак "современными" не назовешь. Взять то же Perl. Мало того, что он уже давно оброс визуальными прибабахами (теми же интерфейсами с Tk и Qt), так он уже давно вытесняется из области скриптостроения всякими шаблонерами-профайлерами-паттернизаторами и прочей фигней. И речь я вел не о том, что визуальность это плохо, а о том, что обвес ПО эргономическими прибабахами (да, в т.ч. и визуальными) просто не даст патриотизировать "нужное для работы" ПО. Например, прикиньте, какие из применяемых Вами инструментов будут переписаны, а про какие просто забудут "за давностью лет" и которые Вам придется срочно заменять на аналоги.
V.Stepan> Но я согласен, что для скриптов гуй в большинстве случаев не нужен.
Ага, за исключением GUI-скриптов, которых давно стало больше, чем текстовых.
с.т.> вообще ценность теоретизирования в прикладном ИТ сильно преувеличивают
И после этого меня обвиняют в категоричных утверждениях, не соответствующих действительности!
с.т.> просто мне претит твоё высокомерие
А Ваше бухгалтерское высокомерие, думаете, не претит программистам? Можно было бы сказать, что ситуация зеркальная. Те не понимают теории, эти бухгалтерии... Но! Программист может получить несомненный кайф, читая труды Дейкстры и Кнута... Как пишут, заразы! А получить кайф от "Налогового вестника" проблематично.
Кстати, я специально предложил "бухгалтерам" задачки, которые, на первый взгляд кажутся реализуемыми простейшими DB-скриптами, но в процессе вникания вызовут потребность подумать и над теорией.
вот я так и знал что Кнут всплывёт...дядька давно уже кочует с мероприятия на мероприятие как автор бестселлера, живёт на популярности 
спасибо что записал меня в бухгалтеры...чесно говоря преждевременно...только начинаю понимать как ECC живёт
прикину по инструментам....шелл, ssh, *nix-ы, CLI в телекоме,скриптовые языки поверх всего этого...с 70 какого-то года живут вроде? =)
ну MS Project и всё такое (планирование и визуализации активностей) ладно, действительно может изменится
ps а перл, вот то в перле круто так это регеэкспы и его модули CPAN и никакая визуалка тут не нужна, самая фишка что "тупо дергая скрипты из крона или CLI или http " можно делать реально интересные вещи
спасибо что записал меня в бухгалтеры...чесно говоря преждевременно...только начинаю понимать как ECC живёт
прикину по инструментам....шелл, ssh, *nix-ы, CLI в телекоме,скриптовые языки поверх всего этого...с 70 какого-то года живут вроде? =)
ну MS Project и всё такое (планирование и визуализации активностей) ладно, действительно может изменится
ps а перл, вот то в перле круто так это регеэкспы и его модули CPAN и никакая визуалка тут не нужна, самая фишка что "тупо дергая скрипты из крона или CLI или http " можно делать реально интересные вещи
Это сообщение редактировалось 02.08.2016 в 15:52
Gudleifr> Ага, за исключением GUI-скриптов, которых давно стало больше, чем текстовых.
Да щаз! У любого нормального админа с течением времени появляется 100500 скриптов, заточенных под его нужды. И они должны работать в полном автопилоте, т.е. гуй им нафиг не нужен.
Да щаз! У любого нормального админа с течением времени появляется 100500 скриптов, заточенных под его нужды. И они должны работать в полном автопилоте, т.е. гуй им нафиг не нужен.
V.Stepan> Да щаз! У любого нормального админа с течением времени появляется 100500 скриптов, заточенных под его нужды. И они должны работать в полном автопилоте, т.е. гуй им нафиг не нужен.
ага...при фразе GUI-скрипт моя рука тянется...я даже не знаю куда она тянется...это макрос на excel (или там access поверх mssql) что-ли которые нужно постоянно переделывать после первого пука мелкомягких? )))
ага...при фразе GUI-скрипт моя рука тянется...я даже не знаю куда она тянется...это макрос на excel (или там access поверх mssql) что-ли которые нужно постоянно переделывать после первого пука мелкомягких? )))
с.т.> вот я так и знал что Кнут всплывёт...
А почему бы и не всплыть? Или считать программированием только бесконечное повторение того, что выписано в тетрадку в школьные/студенческие годы? Теория на то и теория, чтобы делать нудную ремеслуху искусством.
с.т.> при фразе GUI-скрипт моя рука тянется...
V.Stepan>У любого нормального админа с течением времени появляется 100500 скриптов
с.т.> а перл, вот то в перле круто так это регеэкспы и его модули CPAN и никакая визуалка тут не нужна
И что? Мы рассматриваем здесь вопросы личных предпочтений? Т.е. то, в чем меня только что облыжно обвинили. Заведите по теме для каждой фичи, которая вас (не)устраивает и обсуждайте. Зачем это здесь? Отменяем VBA специальным декретом? Запрещаем конечные автоматы, выходящие за рамки "маленькой машинки" Perl? Кончайте флуд (у меня лимит на всего три ответа в сутки еще две недели).
с.т.> прикину по инструментам.... с 70 какого-то года живут вроде?
Вот это уже ближе к теме. Т.е., по-вашему, патриотизация ПО не помешает программерам 70-х? (Правда, хоть эти вещи и относятся к 70-м, они по-прежнему - забугорные. Даже, та же МСВС, являющаяся просто пересборкой обычной Linuх с добавлением пары политик). Этакий ретрофутуризм трудно отнести к плюсам предлагаемой реформы. Ведь, большинство современных российских программистов о тех временах знают только понаслышке. (На сайте олд-гейма, например, старыми считают игры начала 2000-х).
А почему бы и не всплыть? Или считать программированием только бесконечное повторение того, что выписано в тетрадку в школьные/студенческие годы? Теория на то и теория, чтобы делать нудную ремеслуху искусством.
с.т.> при фразе GUI-скрипт моя рука тянется...
V.Stepan>У любого нормального админа с течением времени появляется 100500 скриптов
с.т.> а перл, вот то в перле круто так это регеэкспы и его модули CPAN и никакая визуалка тут не нужна
И что? Мы рассматриваем здесь вопросы личных предпочтений? Т.е. то, в чем меня только что облыжно обвинили. Заведите по теме для каждой фичи, которая вас (не)устраивает и обсуждайте. Зачем это здесь? Отменяем VBA специальным декретом? Запрещаем конечные автоматы, выходящие за рамки "маленькой машинки" Perl? Кончайте флуд (у меня лимит на всего три ответа в сутки еще две недели).
с.т.> прикину по инструментам.... с 70 какого-то года живут вроде?
Вот это уже ближе к теме. Т.е., по-вашему, патриотизация ПО не помешает программерам 70-х? (Правда, хоть эти вещи и относятся к 70-м, они по-прежнему - забугорные. Даже, та же МСВС, являющаяся просто пересборкой обычной Linuх с добавлением пары политик). Этакий ретрофутуризм трудно отнести к плюсам предлагаемой реформы. Ведь, большинство современных российских программистов о тех временах знают только понаслышке. (На сайте олд-гейма, например, старыми считают игры начала 2000-х).
Gudleifr> Отменяем VBA специальным декретом?
А при чём тут это? Ты сам сказал, что "гуёвых скриптов больше". Так вот, их явно не больше. То, что они могут по кол-ву строк обгонять консольные — так это несколько другая тема.
Gudleifr> выходящие за рамки "маленькой машинки" Perl
"Не перлом единым" почти © . Если бы ты знал, сколько уже всего намонстрячего за многие-многие-многие годы только на одном на бобике на платформах МежДелМаша...
А при чём тут это? Ты сам сказал, что "гуёвых скриптов больше". Так вот, их явно не больше. То, что они могут по кол-ву строк обгонять консольные — так это несколько другая тема.
Gudleifr> выходящие за рамки "маленькой машинки" Perl
"Не перлом единым" почти © . Если бы ты знал, сколько уже всего намонстрячего за многие-многие-многие годы только на одном на бобике на платформах МежДелМаша...
с.т.>> вот я так и знал что Кнут всплывёт...
Gudleifr> А почему бы и не всплыть? Или считать программированием только бесконечное повторение того, что выписано в тетрадку в школьные/студенческие годы? Теория на то и теория, чтобы делать нудную ремеслуху искусством.
а потому что этот Кнут у меня сколько лет простоял на полке..не нужон он
а вот регулярные выражения в Перл это вещь
если серьёзно самый полезный учебник который я когда либо читал и учил по ИТ части это "теория АСУ для УВД" (управления воздушным движением), когда Жуковку разгоняли я себе один прибрал...универсальная вещь...хоть CRM хоть DWH - по сути теже яйца в профиль
с.т.>> при фразе GUI-скрипт моя рука тянется...
V.Stepan>>У любого нормального админа с течением времени появляется 100500 скриптов
с.т.>> а перл, вот то в перле круто так это регеэкспы и его модули CPAN и никакая визуалка тут не нужна
Gudleifr> Кончайте флуд (у меня лимит на всего три ответа в сутки еще две недели).
у нас тема про быдлокодеров - она сама по себе флудовая
с.т.>> прикину по инструментам.... с 70 какого-то года живут вроде?
Gudleifr> Вот это уже ближе к теме. Т.е., по-вашему, патриотизация ПО не помешает программерам 70-х? Этакий ретрофутуризм трудно отнести к плюсам предлагаемой реформы. Ведь, большинство современных российских программистов о тех временах знают только понаслышке. (На сайте олд-гейма, например, старыми считают игры начала 2000-х).
не совсем понял о какой реформе идёт речь...патриотизация чего-либо подобного это бред - как мы могли убедиться на опять же ОС РВ, Рафосах и Фодосах и тп и тд - даже в ТЕ годы цельнотянутых ))))
в целом мне кажется вопрос патриотизации в критической массе разработчиков которые будут заниматься этим (и четких целях и задачах)...условный яндекс собрал разрабочиков, инвестировал их время и деньги с понятными целям - пожалста на выходе конкурентный продукт
собрали разрабочиков для какогонить йотафона - на выходе хрен знамо что )))
это именно не вопрос искусства программирования (конечные автоматы или нет) а стратегии - ответов на вопросы какой нам нужен продукт, кто его потребитель, какая в нише конкуренция, в чём наши преимущества......
Gudleifr> А почему бы и не всплыть? Или считать программированием только бесконечное повторение того, что выписано в тетрадку в школьные/студенческие годы? Теория на то и теория, чтобы делать нудную ремеслуху искусством.
а потому что этот Кнут у меня сколько лет простоял на полке..не нужон он
а вот регулярные выражения в Перл это вещь
если серьёзно самый полезный учебник который я когда либо читал и учил по ИТ части это "теория АСУ для УВД" (управления воздушным движением), когда Жуковку разгоняли я себе один прибрал...универсальная вещь...хоть CRM хоть DWH - по сути теже яйца в профиль
с.т.>> при фразе GUI-скрипт моя рука тянется...
V.Stepan>>У любого нормального админа с течением времени появляется 100500 скриптов
с.т.>> а перл, вот то в перле круто так это регеэкспы и его модули CPAN и никакая визуалка тут не нужна
Gudleifr> Кончайте флуд (у меня лимит на всего три ответа в сутки еще две недели).
у нас тема про быдлокодеров - она сама по себе флудовая
с.т.>> прикину по инструментам.... с 70 какого-то года живут вроде?
Gudleifr> Вот это уже ближе к теме. Т.е., по-вашему, патриотизация ПО не помешает программерам 70-х? Этакий ретрофутуризм трудно отнести к плюсам предлагаемой реформы. Ведь, большинство современных российских программистов о тех временах знают только понаслышке. (На сайте олд-гейма, например, старыми считают игры начала 2000-х).
не совсем понял о какой реформе идёт речь...патриотизация чего-либо подобного это бред - как мы могли убедиться на опять же ОС РВ, Рафосах и Фодосах и тп и тд - даже в ТЕ годы цельнотянутых ))))
в целом мне кажется вопрос патриотизации в критической массе разработчиков которые будут заниматься этим (и четких целях и задачах)...условный яндекс собрал разрабочиков, инвестировал их время и деньги с понятными целям - пожалста на выходе конкурентный продукт
собрали разрабочиков для какогонить йотафона - на выходе хрен знамо что )))
это именно не вопрос искусства программирования (конечные автоматы или нет) а стратегии - ответов на вопросы какой нам нужен продукт, кто его потребитель, какая в нише конкуренция, в чём наши преимущества......
V.Stepan> А при чём тут это? Ты сам сказал, что "гуёвых скриптов больше". Так вот, их явно не больше.
Чисто формально: "сейчас больше" - VBA, СУБД, IDE, соц.сети...
с.т.> а потому что этот Кнут у меня сколько лет простоял на полке..не нужон он
с.т.> если серьёзно самый полезный учебник который я когда либо читал и учил по ИТ части это "теория АСУ для УВД"
Но, если бы читали Кнута (кстати, свет клином не сошелся на "Искусстве программирования), то смогли бы понты кидать, а сформулировать пользу этого "АСУчивания" в терминах, понятных другим программистам.
с.т.> а вот регулярные выражения в Перл вещь
Есть только два уровня понимания РВ:
1. "Они должны совпадать, с чем надо, и не совпадать, с чем не надо". (насколько помню, переводчик упомянутой книги говорил мне, что она с этого и начинается, остальное - мусор).
2. Глава про конечные автоматы в Ахо, Хопркрофта и Ульмана в "Построение и анализ вычислительных алгоритмов".
Все остальное - избыточно.
"Маленькая машинка" Perl - это жуткая несуразица. Только, если хотите обсудить это, давайте не здесь. Например, если можете, помогите мне решить задачку - МТ. (Кстати, вот где я прищемил хвост нашему американскому другу. А я-то гадал, что это он меня минусует на пустом месте?)
с.т.> у нас тема про быдлокодеров - она сама по себе флудовая
Почему же? Она самая, что ни на есть жизненная. Ведь финансовая успешность быдлокодеров убивает искусство программирования. Не удастся пробудить в них желание учиться, так хоть наглядно показать, как относятся к ним программисты. (Ведь анекдоты про системщиков и пользователей остались далеко в советском прошлом).
с.т.> не совсем понял о какой реформе идёт речь...
Т.е. Вы начали критиковать мои аргументы, не разобравшись, к чему они относятся? А Вы, сударь, круты для белого...
Чисто формально: "сейчас больше" - VBA, СУБД, IDE, соц.сети...
с.т.> а потому что этот Кнут у меня сколько лет простоял на полке..не нужон он
с.т.> если серьёзно самый полезный учебник который я когда либо читал и учил по ИТ части это "теория АСУ для УВД"
Но, если бы читали Кнута (кстати, свет клином не сошелся на "Искусстве программирования), то смогли бы понты кидать, а сформулировать пользу этого "АСУчивания" в терминах, понятных другим программистам.
с.т.> а вот регулярные выражения в Перл вещь
Есть только два уровня понимания РВ:
1. "Они должны совпадать, с чем надо, и не совпадать, с чем не надо". (насколько помню, переводчик упомянутой книги говорил мне, что она с этого и начинается, остальное - мусор).
2. Глава про конечные автоматы в Ахо, Хопркрофта и Ульмана в "Построение и анализ вычислительных алгоритмов".
Все остальное - избыточно.
"Маленькая машинка" Perl - это жуткая несуразица. Только, если хотите обсудить это, давайте не здесь. Например, если можете, помогите мне решить задачку - МТ. (Кстати, вот где я прищемил хвост нашему американскому другу. А я-то гадал, что это он меня минусует на пустом месте?)
с.т.> у нас тема про быдлокодеров - она сама по себе флудовая
Почему же? Она самая, что ни на есть жизненная. Ведь финансовая успешность быдлокодеров убивает искусство программирования. Не удастся пробудить в них желание учиться, так хоть наглядно показать, как относятся к ним программисты. (Ведь анекдоты про системщиков и пользователей остались далеко в советском прошлом).
с.т.> не совсем понял о какой реформе идёт речь...
Т.е. Вы начали критиковать мои аргументы, не разобравшись, к чему они относятся? А Вы, сударь, круты для белого...
Это сообщение редактировалось 03.08.2016 в 15:53
Gudleifr> (Кстати, вот где я прищемил хвост нашему американскому другу. А я-то гадал, что это он меня минусует на пустом месте?)
В общем, та задача демонстрирует две вещи:
1. Тебе до понимания конечных автоматов в твоём пункте 2 очень далеко.
2. Что быдло кодер тут один — ты. Только быдлокодер может спутать МТ и автомат...
Вся информация была дана, а реализацию ты сделать не смог. Элементарную реализацию. Про рекурсию ты, видимо, даже не слышал.
В общем, та задача демонстрирует две вещи:
1. Тебе до понимания конечных автоматов в твоём пункте 2 очень далеко.
2. Что быдло кодер тут один — ты. Только быдлокодер может спутать МТ и автомат...
Вся информация была дана, а реализацию ты сделать не смог. Элементарную реализацию. Про рекурсию ты, видимо, даже не слышал.
Gudleifr> Блин, чувствую себя смесью Шерлока и Доктора Кто...
это что Will Gram какой-то из Ганнибала?
вот например конечный автомат на перле
а теперь я понял что за быдлокодеры...это все кто не "системщики" что ли? ))
это типа холивар системщики против казуалов-прикладников? )))
тогда я классический казуальный-прикладной былокодер и горжусь этим
придерживаюсь принципа "если это тупо но работает - значит не тупо, идём к следующей задаче"
это что Will Gram какой-то из Ганнибала?
вот например конечный автомат на перле
Конечные автоматы. Пишем ДКА
Если вы когда-нибудь пытались написать своего бота, программу-переговорщик (negotiator), интерпретатор протокола связи и тому подобные вещи, то наверняка... // habrahabr.ruа теперь я понял что за быдлокодеры...это все кто не "системщики" что ли? ))
это типа холивар системщики против казуалов-прикладников? )))
тогда я классический казуальный-прикладной былокодер и горжусь этим
придерживаюсь принципа "если это тупо но работает - значит не тупо, идём к следующей задаче"
Это сообщение редактировалось 02.08.2016 в 22:02
Gudleifr> Ведь финансовая успешность быдлокодеров убивает искусство программирования.
Программисты балованные. Любой форум программерский почитаешь, там всегда полно "художников" с разнообразными капричосами, да еще угнетаемых тупыми тимлидами. Художники рассуждают как важно лелеять их творческие начала, и как неправы тупые тимлиды, когда это самое не лелеят. Всерьёз иногда обсуждается вопрос, что надо перейти на четыре рабочих дня вместо пяти, а так как при этом производительность отдохнувшей творческой личности возрастёт, то и з/п тоже должно возрасти.
Ну, и быдлокодеров художники тоже ругают. Всё из-за какой-то неадекватности восприятия своего ремесла. Вот, скажем, водопроводчики или шиномонтажники про искусство в своей деятельности говорят гораздо меньше. А тут, видимо, грёзы футурологов и отсутствие физического труда позволяют программистам делать всякие ложные выводы о своей роли в истории.
Финансовая успешность быдлокодеров напрямую говорит, что роль искусства программирования сугубо надута "художниками". Задача коммерческого проекта по разработке софта дать профит продаж над совокупными затратами по писанию и сопровождению. После окончания жизненного цикла код отправиться в виртуальную корзину, а не в Лувр или Эрмитаж. Соответственно, если больший профит можно сделать с быдлокодерами, а не с "художниками", то это и есть оптимум.
Программисты балованные. Любой форум программерский почитаешь, там всегда полно "художников" с разнообразными капричосами, да еще угнетаемых тупыми тимлидами. Художники рассуждают как важно лелеять их творческие начала, и как неправы тупые тимлиды, когда это самое не лелеят. Всерьёз иногда обсуждается вопрос, что надо перейти на четыре рабочих дня вместо пяти, а так как при этом производительность отдохнувшей творческой личности возрастёт, то и з/п тоже должно возрасти.
Ну, и быдлокодеров художники тоже ругают. Всё из-за какой-то неадекватности восприятия своего ремесла. Вот, скажем, водопроводчики или шиномонтажники про искусство в своей деятельности говорят гораздо меньше. А тут, видимо, грёзы футурологов и отсутствие физического труда позволяют программистам делать всякие ложные выводы о своей роли в истории.
Финансовая успешность быдлокодеров напрямую говорит, что роль искусства программирования сугубо надута "художниками". Задача коммерческого проекта по разработке софта дать профит продаж над совокупными затратами по писанию и сопровождению. После окончания жизненного цикла код отправиться в виртуальную корзину, а не в Лувр или Эрмитаж. Соответственно, если больший профит можно сделать с быдлокодерами, а не с "художниками", то это и есть оптимум.
16-й> Ну, и быдлокодеров художники тоже ругают. Всё из-за какой-то неадекватности восприятия своего ремесла. Вот, скажем, водопроводчики или шиномонтажники про искусство в своей деятельности говорят гораздо меньше.
у водопроводчиков всё просто...хорошую работу сразу видно - пришёл, сделал, сделал красиво, из металла, хорошим инструментом, красиво аккуратно всё покрасил, получил бабки, ушёл - вот он хороший водопроводчик - типичный быдлокодер
а системщик (тру-системщик) должен начать с написания как минимум своей ОС, потом средства разработки...а потом уже начать писать программу
у водопроводчиков всё просто...хорошую работу сразу видно - пришёл, сделал, сделал красиво, из металла, хорошим инструментом, красиво аккуратно всё покрасил, получил бабки, ушёл - вот он хороший водопроводчик - типичный быдлокодер
а системщик (тру-системщик) должен начать с написания как минимум своей ОС, потом средства разработки...а потом уже начать писать программу
Это сообщение редактировалось 03.08.2016 в 10:43
Перенес на место:
Mishka_#02.08.2016_20:34> ...
Блин, чувствую себя смесью Шерлока и Доктора Кто...
спокойный_тип_#02.08.2016_21:50> вот например конечный автомат на перле
Т.к. задачка вполне конкретная, то требуется конкретное решение, а не "сферический конь в вакууме". К тому же, согласитесь, мое решение на порядок компактнее того, на которое Вы сослались. И почему, наконец, в этой теме?
спокойный_тип_#02.08.2016_21:50> это типа холивар системщики против казуалов-прикладников? )))
Ну, холивар-то, быдлокодеры завсегда устроят (ведь они бахвалятся непониманием того, что делают). Только прикладниками они себя зря считают. Прикладные программы работают, казуальные - имитируют работу. Например, я спросил Вашего совета. В ответ получил ссылку на какую-то хрень, вроде, делающую что-то похожее. Имитация...
спокойный_тип_#02.08.2016_21:50> придерживаюсь принципа "если это тупо но работает - значит не тупо, идём к следующей задаче"
Да, это по-быдлокодерски. Программист говорит: "Я могу доказать, что это тупо, и могу доказать, что это работает".
16-й_#03.08.2016_10:28> Ну, и быдлокодеров художники тоже ругают. Всё из-за какой-то неадекватности восприятия своего ремесла. Вот, скажем, водопроводчики или шиномонтажники про искусство в своей деятельности говорят гораздо меньше.
Почему же меньше? Хороший рабочий иного инженера задвинет. В идеале, это два пути в инженерство - через голову и через руки. Кому как сподручнее. Университетская и цеховая формы обучения. Быдлокодеров ругают не из-за "восприятия", а из-за производимого мусора; как худого сантехника, за которым переделывать приходится. Взять тот же Хабрахабр - вроде благая идея, а толку - никакого. Просто потому, что большинство там пишущих сами не понимают, что пишут. Не знают языка и пытаются объяснить на пальцах.
16-й_#03.08.2016_10:28> Соответственно, если больший профит можно сделать с быдлокодерами, а не с "художниками", то это и есть оптимум.
Это возможно только для уже решенной ранее "художниками" задачи. Конечно, есть вероятность, что по незнанию, быдлокодер хоть раз в жизни случайно угадает, но это бывает раз в жизни. По сути, Ваш "оптимум" - это те самые шесть шимпанзе за пишущими машинками, от которых ждут "Макбета". Работает эта схема только по одной причине - никому не нужен "Макбет". Нужна макулатура, и побольше. Вместо одного программиста - сто кодеров, вместо одного кассира - сто операционистов.
спокойный_тип_#03.08.2016_10:32> хороший водопроводчик - типичный быдлокодер
Если он не понимает, что делает.
спокойный_тип_#03.08.2016_10:32> а системщик (тру-системщик) должен начать с написания как минимум своей ОС, потом средства разработки...а потом уже начать писать программу
Типичная пугалка быдлокодеров *). Они считают, что ОС и средства разработки есть страшно заумное творение гениальных умов. Это не так. Сложность в программировании состоит только в размере текста программы. И "написать свою ОС" часто бывает проще, чем разобраться в чужой. Например, есть огромного размера IDE, прячущие от пользователя за всякими эвентами-пропертями WIN-API, с подсветкой синтаксиса и макроязыками. Но взяв простейший masm32 и поняв, как это WIN-API вызывается, программист спокойно может делать то же самое. Более того, написав простое FORTH-ядро (2000 строк), он может писать WIN-программы на языке высокого уровня. И разослав это ядро друзьям - далее посылать им все свои программы в текстовых исходниках!
(*) - скорее надо опасаться, что тру-системщик, аргументированно убедит заказчика отказаться от АСУчивания такой ерунды.
Разница между программистами-художниками и быдлокодером состоит в том, что первые, будучи сведущи в неких "великих тайнах программирования" **) могут себе позволить не быть еще и "обычными инженерами" (будучи, правда, инженерами-электронщиками и инженерами-математиками). А быдлокодеры не хотят быть "обычными инженерами" (инженерами-профессионалами, способными запрограммировать что-то им полезное) просто потому, что "и так умные". Что доставляет. Например, первый пост был навеян разговором на форуме программистов-игроделов, которые сошлись на том, что программисту институт только мешает.
(**) - они, в основном, перечислены в первом посте. Ну, и разумеется прилагаемый к ним математический аппарат и производственный опыт.
Mishka_#02.08.2016_20:34> ...
Блин, чувствую себя смесью Шерлока и Доктора Кто...
спокойный_тип_#02.08.2016_21:50> вот например конечный автомат на перле
Т.к. задачка вполне конкретная, то требуется конкретное решение, а не "сферический конь в вакууме". К тому же, согласитесь, мое решение на порядок компактнее того, на которое Вы сослались. И почему, наконец, в этой теме?
спокойный_тип_#02.08.2016_21:50> это типа холивар системщики против казуалов-прикладников? )))
Ну, холивар-то, быдлокодеры завсегда устроят (ведь они бахвалятся непониманием того, что делают). Только прикладниками они себя зря считают. Прикладные программы работают, казуальные - имитируют работу. Например, я спросил Вашего совета. В ответ получил ссылку на какую-то хрень, вроде, делающую что-то похожее. Имитация...
спокойный_тип_#02.08.2016_21:50> придерживаюсь принципа "если это тупо но работает - значит не тупо, идём к следующей задаче"
Да, это по-быдлокодерски. Программист говорит: "Я могу доказать, что это тупо, и могу доказать, что это работает".
16-й_#03.08.2016_10:28> Ну, и быдлокодеров художники тоже ругают. Всё из-за какой-то неадекватности восприятия своего ремесла. Вот, скажем, водопроводчики или шиномонтажники про искусство в своей деятельности говорят гораздо меньше.
Почему же меньше? Хороший рабочий иного инженера задвинет. В идеале, это два пути в инженерство - через голову и через руки. Кому как сподручнее. Университетская и цеховая формы обучения. Быдлокодеров ругают не из-за "восприятия", а из-за производимого мусора; как худого сантехника, за которым переделывать приходится. Взять тот же Хабрахабр - вроде благая идея, а толку - никакого. Просто потому, что большинство там пишущих сами не понимают, что пишут. Не знают языка и пытаются объяснить на пальцах.
16-й_#03.08.2016_10:28> Соответственно, если больший профит можно сделать с быдлокодерами, а не с "художниками", то это и есть оптимум.
Это возможно только для уже решенной ранее "художниками" задачи. Конечно, есть вероятность, что по незнанию, быдлокодер хоть раз в жизни случайно угадает, но это бывает раз в жизни. По сути, Ваш "оптимум" - это те самые шесть шимпанзе за пишущими машинками, от которых ждут "Макбета". Работает эта схема только по одной причине - никому не нужен "Макбет". Нужна макулатура, и побольше. Вместо одного программиста - сто кодеров, вместо одного кассира - сто операционистов.
спокойный_тип_#03.08.2016_10:32> хороший водопроводчик - типичный быдлокодер
Если он не понимает, что делает.
спокойный_тип_#03.08.2016_10:32> а системщик (тру-системщик) должен начать с написания как минимум своей ОС, потом средства разработки...а потом уже начать писать программу
Типичная пугалка быдлокодеров *). Они считают, что ОС и средства разработки есть страшно заумное творение гениальных умов. Это не так. Сложность в программировании состоит только в размере текста программы. И "написать свою ОС" часто бывает проще, чем разобраться в чужой. Например, есть огромного размера IDE, прячущие от пользователя за всякими эвентами-пропертями WIN-API, с подсветкой синтаксиса и макроязыками. Но взяв простейший masm32 и поняв, как это WIN-API вызывается, программист спокойно может делать то же самое. Более того, написав простое FORTH-ядро (2000 строк), он может писать WIN-программы на языке высокого уровня. И разослав это ядро друзьям - далее посылать им все свои программы в текстовых исходниках!
(*) - скорее надо опасаться, что тру-системщик, аргументированно убедит заказчика отказаться от АСУчивания такой ерунды.
Разница между программистами-художниками и быдлокодером состоит в том, что первые, будучи сведущи в неких "великих тайнах программирования" **) могут себе позволить не быть еще и "обычными инженерами" (будучи, правда, инженерами-электронщиками и инженерами-математиками). А быдлокодеры не хотят быть "обычными инженерами" (инженерами-профессионалами, способными запрограммировать что-то им полезное) просто потому, что "и так умные". Что доставляет. Например, первый пост был навеян разговором на форуме программистов-игроделов, которые сошлись на том, что программисту институт только мешает.
(**) - они, в основном, перечислены в первом посте. Ну, и разумеется прилагаемый к ним математический аппарат и производственный опыт.
03.08.2016 16:12, спокойный тип: +1: ну собственно как я и ожидал. успехов тебе в искусстве и удачи ;-)
Коллеги, похоже, это "синдром непризнанного гения".
Luchnik> Коллеги, похоже, это "синдром непризнанного гения".
Вспомнил прибитую гвоздём надпись на фанерке, над столом "старого" системщика.
"НЕВОЗОМНИ СЕБЯ БОГОМ!"... .
Вспомнил прибитую гвоздём надпись на фанерке, над столом "старого" системщика.
"НЕВОЗОМНИ СЕБЯ БОГОМ!"... .
Luchnik> Коллеги, похоже, это "синдром непризнанного гения".
m.G.> Вспомнил прибитую гвоздём надпись на фанерке, над столом "старого" системщика.
m.G.> "НЕВОЗОМНИ СЕБЯ БОГОМ!"... .
Не, ребята, свалить все на происки Доктора Зло не удастся. Конечно, мы все знаем, что технологии высших порядков неотличимы для слабых умов от магии, но в том, что я написал, нет ничего нового. Как правильно заметил коллега спокойный тип, почти все это придумано еще в 70-х и по сей день прекрасно работает. Я просто подытожил и придал вид "проверки на вшивость".
m.G.> Вспомнил прибитую гвоздём надпись на фанерке, над столом "старого" системщика.
m.G.> "НЕВОЗОМНИ СЕБЯ БОГОМ!"... .
Не, ребята, свалить все на происки Доктора Зло не удастся. Конечно, мы все знаем, что технологии высших порядков неотличимы для слабых умов от магии, но в том, что я написал, нет ничего нового. Как правильно заметил коллега спокойный тип, почти все это придумано еще в 70-х и по сей день прекрасно работает. Я просто подытожил и придал вид "проверки на вшивость".
Gudleifr> Я просто подытожил и придал вид "проверки на вшивость".
Твоего скилла не хватает, чтобы это подытожить. Поэтому выходит фигня.
Твоего скилла не хватает, чтобы это подытожить. Поэтому выходит фигня.
Copyright © Balancer 1997..2019
Создано 09.07.2016
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Создано 09.07.2016
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
