|
Лужу, паяю, ЭВМ починяю...
| |
| Gudleifr | Дата: Четверг, 23 Июня 2016, 20:56 | Сообщение # 1 |
почти ветеран
Сейчас нет на сайте
| Этот документ - попытка объяснить, зачем начинающему программисту институт. Ведь, существует огромное количество курсов, которые обещают научить писать красивые и успешно продаваемые программы без какой-либо перегрузки мозга высшими материями и отсиживания задницы на ненужных лекциях.
Чуть ли не единственным доводом за институт остается "чисто армейский" - "школа жизни". До института ты - школяр, после - инженер - мужик, наличие мозгов и рук которого подтверждено официальным документом. Тебя можно брать с собой в командировку, затыкать тобой дыры на производстве и поручать прикрывать тылы.
Как можно изучать программирование?
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: Единственный способ написания хорошей программы - полное выбрасывание исходников, как только они перестают нравиться.
ЗАКЛЮЧЕНИЕ.
Человек в своей личной эволюции, начиная от стадии скотского эгоизма проходит стадию альтруизма, затем - пофигизма, и, наконец, дорастает до эгоизма разумного. И роль любого учебного заведения - способствовать этой эволюции. Или, хотя бы, научить человека воспринимать себя, любимого, чуть менее серьезно.
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Сообщение отредактировал Gudleifr - Четверг, 03 Ноября 2016, 00:29 |
|
|
| |
| TLT | Дата: Четверг, 23 Июня 2016, 21:03 | Сообщение # 2 |
Сейчас нет на сайте
| Цитата Gudleifr (  ) Следствие 22: Знания/умения программиста никак не могут иметь ценности за пределами конкретной задачи.
Да, согласен. Многие тут прокалываются, зачем-то берясь за то, что не входит в задачу.
И вообще интересные выводы.
Дао, выраженное словами, не есть истинное Дао.
|
|
|
| |
| Gudleifr | Дата: Воскресенье, 26 Июня 2016, 15:52 | Сообщение # 3 |
|
почти ветеран
Сейчас нет на сайте
| 
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
|
|
|
| |
| 1nt3g3r | Дата: Среда, 06 Июля 2016, 20:00 | Сообщение # 4 |
почетный гость
Сейчас нет на сайте
| Gudleifr, я почитал ваш пост. Не все выводы там верны. По пунктам:
Аксиома 5: Очень небольшой процент рабочего времени программист тратит на написание программ. Гораздо больше уходит на то, чтобы заставить их работать. Первое приятно и престижно, второе - нет.
Нет - если использовать TDD (Unit-тесты), время на отладку сильно сокращается. Пишу из своего опыта - я писал и с тестами, и без. Конечно, не всегда Unit-тесты применимы (программирование графики, например), но есть множество областей, где они доступны.
Следствие 51: Ни один программист не любит сложных программ. Пропадает даже та маленькая толика удовольствия, которая ему положена.
Я люблю сложные программы. Мне больше нравится возиться с каким-то сложным алгоритмом, писать игровые сервера, чем работать с базами данных, например.
Следствие 52: Еще эфемернее предстает возможность научиться программировать на большом проекте. Неразрешимые проблемы встретятся раньше, чем появятся первые результаты.
Если вы работаете в команде, кто-то более опытный вам поможет. Если работаете сами - интернет, форумы, документацию на технику еще никто не отменял. Я учился писать на Java именно на боевом проекте (программа для приемной комиссии института). Оглядываясь сейчас, я знаю, что много где эта программа неидеальна - но она работает, и выполняет свою задачу. В процессе ее написания трудности возникали - но неразрешимых нет. Вы можете сказать, что это небольшой проект - но для одного человека 40 тысяч строк кода примерно за полтора года - это не так уж и мало.
Следствие 53: Единственный способ написания хорошей программы - полное выбрасывание исходников, как только они перестают нравиться.
Ага, скажите это создателям всех популярных операционных систем(Windows, Linux, etc). Корни этих систем тянутся еще непонятно откуда, и в них есть ошибки. Но жизнь такова, что если взять и выбросить все исходники, как только они перестали нравиться - то чем же пользоваться? В написание сложных программ вложено миллионы человеко-часов, и непозволительно глупо переписывать исходники, как только что-то перестало в них нравиться. Способ избежать загнивания кода - регулярный рефакторинг этого самого кода. А чтобы ничего не сломать при рефакторинге - для этого придумали автоматические тесты.
Хороших программистов не так уж и много, но вы хотите поднять планку "настоящего программиста" до небывалых высот (такое впечатление у меня сложилось после прочтения ваших постов). Это все хорошо - но кому-то надо писать базы данных, прошивки контроллеров, игры, операционные системы. Нельзя написать что-то идеально - можно написать рабочий вариант, потом улучшать (эволюция тому пример).
Нужно писать такие игры, чтобы в них было интересно играть самому
|
|
|
| |
| Gudleifr | Дата: Среда, 06 Июля 2016, 20:20 | Сообщение # 5 |
|
почти ветеран
Сейчас нет на сайте
| Цитата 1nt3g3r ( ) Нет - если использовать TDD (Unit-тесты), время на отладку сильно сокращается.
Цитата Gudleifr ( ) Я люблю сложные программы. Мне больше нравится возиться с каким-то сложным алгоритмом, писать игровые сервера, чем работать с базами данных, например.
Цитата 1nt3g3r ( ) Вы можете сказать, что это небольшой проект - но для одного человека 40 тысяч строк кода примерно за полтора года - это не так уж и мало.
Цитата 1nt3g3r ( ) Ага, скажите это создателям всех популярных операционных систем(Windows, Linux, etc).
Цитата 1nt3g3r ( ) В написание сложных программ вложено миллионы человеко-часов, и непозволительно глупо переписывать исходники, как только что-то перестало в них нравиться.
Цитата 1nt3g3r ( ) Способ избежать загнивания кода - регулярный рефакторинг этого самого кода.
Цитата 1nt3g3r ( ) Это все хорошо - но кому-то надо писать базы данных, прошивки контроллеров, игры, операционные системы.
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
|
|
|
| |
| 1nt3g3r | Дата: Среда, 06 Июля 2016, 21:02 | Сообщение # 6 |
|
почетный гость
Сейчас нет на сайте
| Цитата Забудьте. Это очередная байка для умственно отсталых. Единственное, что нужно знать о тестах: они ничего не доказывают. Это просто удобная кормушка для около-программистов.
Нет, это не так. По мере того, как ваша система становится более сложной (банковская система, игровой сервер, алгоритм разбора пакетов, которые передаются по радиоканалу - тысячи их), вы не можете удержать в голове все подробности. Новые люди в проекте вообще не знают этих подробностей. Здесь тесты спасают. Unit-тесты доказывают то, что отдельные функции при определенных условиях работают. Маленький пример - вы написали функцию, которая считает сложную формулу - десятки строк кода, без знания формулы вообще непонятно, что она делает. Написав юнит-тесты для пограничных случаев, и пару тестов в середине интервала, вы знаете - в таких-то пределах функция работает. Потом вам говорят - а функция-то медленно работает, ускоряй! И вы, используя знание архитектуры целевого процессора, делаете asm-вставки - почучуть, кусочками - и прогоняете каждый раз ваш набор тестов. Таким образом, между шагами оптимизации вы можете быть уверены, что еще ничего не сломали. А ведь юнит-тесты - это лишь вершина айсберга - есть и другие виды тестирования, которые тестируют не отдельную функцию, но уже поведение программы "в сборе". Если взять ту же банковскую сферу - там никто не рискнет что-то писать или менять без тестов. А если взять космическую область - то вы там только тестированием и будете заниматься. Непозволительно запускать ракету в надежде на гениальность программиста.
Аргументируйте, пожалуйста, ваше высказывание - "Это очередная байка для умственно отсталых".
Цитата
Это не сложные программы, это программы, выглядящие сложными для непосвященных. Самый сложный алгоритм - это простая программа. Определение сложной программы очень просто - это предел для одного человека. Не по заумности, а тупо по времени и размеру текста.
Если вы что-то понимаете, то оно для вас просто. Десять леть назад для меня вывод точки на экран в Turbo Pascal и перемещение ее клавишами курсора было сложно, сейчас нет. Определение сложности по размеру текста некорректно. Один и тот же алгоритм можно написать изящно, одной рекурсивной функцией, а можно городить и городить костыли. Сложность - это когда сложно понять, как это реализовать, с какой стороны подойти. Когда на бумажке вроде и понятно, и сделаешь по бумажке сам - а вот железяка накладывает ограничения по времени, по памяти, по типам данных. Когда приходится переформулировать задачу на язык компьютера. Когда целый день промучился, на выходе - 10 строчек кода, которые делают сложную работу. То есть, выходной результат - количество текста - не коррелирует со сложностью программы.
Цитата Цитата 1nt3g3r ()
Вы можете сказать, что это небольшой проект - но для одного человека 40 тысяч строк кода примерно за полтора года - это не так уж и мало.
Возможно. Но я имел в виду именно самостоятельный сложный проект. В Вашем описании слишком мало информации, чтобы оценить сложность проекта, Вашего участия, оправданности столь большого объема.
Степень участия - я писал программу "с нуля", сам. Оправданность столь большого обьем - да потому что у программы много функций. Есть куча абитуриентов, над ними нужно производить разные сложные действия - например, если по какому-то предмету ему поставили 2 балла - он автоматически отчисляется, причиной отчисления пишется - "Двойка за (название предмета)". Или же, если сумма баллов меньше какого-то количества, но по профильному предмету их много - сделать другое действия. Все подробности я не упомню, но четко помню, что у меня на каждый серьезный чих писались тесты. Благодаря этому я мог спокойно заниматься своими делами (все работает так, как ожидается). Новая функция - окей, делаем тест, добавляем функцию, прогоняем все тесты. Зачем все тесты - потому что в большой системе не всегда очевидно, чем чреваты изменения в том или ином месте.
Цитата Цитата 1nt3g3r ()
Ага, скажите это создателям всех популярных операционных систем(Windows, Linux, etc).
Ага. Например, Linux - это написанный заново, с нуля, Unix. Windows - это, вообще анекдот, его тянут без переписывания от самого DOS, но то и дело заявляют, что "система переписана с нуля", как у порядочных. Хотите поржать - почитайте книги Шульмана (не даром мелкософт столько раз его пытался прижучить).
Linux - не юникс. Есть определенная доля совместимости на уровне API, но не более.Linux писали не от желания переписать Unix - просто Unix-а не было в открытом доступе, платный он был, Unix.
Windows - о том и речь. Нельзя так просто взять и выбросить все исходники, со всеми наработками, костылями и т.д. Например, куча железа, завязанная на особенности операционки (там, где драйвера есть - видеокарты, звуковые карты, и т.д.) просто отвалится. То же и про программы. Как результат - никто не будет пользоваться операционкой, на которой не работает железо и программы. А если переписывать код, оставляя совместимось - то по этому пути Microsoft пошли. У меня нет к ним любви, большинство времени я пользуюсь Linux, но их мотивы я понимаю - это бизнес, который хочет заработать денег, и который хочет, чтобы его софт был актуален.
Цитата Цитата 1nt3g3r ()
В написание сложных программ вложено миллионы человеко-часов, и непозволительно глупо переписывать исходники, как только что-то перестало в них нравиться.
Это только слабое оправдание бездумной траты этих самых миллионов там, где хватило бы и тысяч.
Кто-то потратил месяц для написания драйвера для конкретной модели USB-модема. Кто-то взял это за основу и сделал универсальный драйвер - подходящий для всех USB-модемов (по крайней мере, большинства). Кто-то делает такую же работу, но для другой железки. Кто-то усовершенствует планировщик задач под новую архитектуру процессора. Работы много, и она идет постоянно. Да, есть и бесполезная работа, но пока вы не сделаете ее, вы этого не поймете. А когда сделаете - потом переделаете правильно.
Цитата Цитата 1nt3g3r ()
Способ избежать загнивания кода - регулярный рефакторинг этого самого кода.
Забудьте. Это еще одна байка. Есть только один работающий вид рефакторинга - через мусорное ведро.
Нет. Это не байка. Сужу по личному примеру и по примеру друзей-программистов. Есть сложная программа - работает с какой-то железкой. И тут нужно добавить поддержку еще одной железки. Есть два варианта - писать новую программу, с учетом особенностей обеих железок. А есть вариант - отрефакторить старую программу (общий код - один модуль, код работы с железом - другой модуль). После этого мы имеем архитектуру, которая позволяет добавить новую железку (с запасом на будущее - и другие железки). Время рефакторинга - несколько дней, а переписывать программу с нуля (и неизбежно вносить другие ошибки) - это намного дольше. Пример реальный.
Опять таки, по этому пункту хочу прочитать аргументированное обьяснение, почему починка и адаптация программы (рефакторинг) - это плохо.
Цитата Цитата 1nt3g3r ()
Это все хорошо - но кому-то надо писать базы данных, прошивки контроллеров, игры, операционные системы.
И если это будут делать настоящие программисты, жизнь будет лучше.
Конечно - но прежде чем стать Программистом с большой буквы, нужно много чего написать. А если писать лишь тестовые программы, опыта много вы не наберетесь. Поэтому для повышения опыта нужно заниматься реальными проектами - со временем опыт поднимется. Вот и появляются в реальных проектах "детские" ошибки - потому что не хватает на все настоящих Программистов.
Нужно писать такие игры, чтобы в них было интересно играть самому
|
|
|
| |
| Gudleifr | Дата: Четверг, 07 Июля 2016, 00:28 | Сообщение # 7 |
|
почти ветеран
Сейчас нет на сайте
| 1nt3g3r, это все хорошо, но это не имеет отношения к программированию. Это специальные трудности, специально придуманные специальными людьми для обоснования сметы.
Например:
Цитата 1nt3g3r ( ) почему починка и адаптация программы (рефакторинг) - это плохо.
И, повторю, всегда помните два правила:
1. Сложность программы определяется только ее размером
2. Тесты ничего не доказывают
Это не обсуждается. Первое следует из единственного доступного нам способа анализа - "прорешать в голове", а второе - из свойств Машины Тьюринга.
Виноват, я не ответил подробно на все Ваши вопросы, но их слишком много. Давайте уж по одному.
Добавлено (06 июля 2016, 23:51)
---------------------------------------------
Итак, первое:
Цитата 1nt3g3r ( ) Маленький пример - вы написали функцию, которая считает сложную формулу - десятки строк кода, без знания формулы вообще непонятно, что она делает. Написав юнит-тесты для пограничных случаев, и пару тестов в середине интервала, вы знаете - в таких-то пределах функция работает.
Байка:
Моего преподавателя по "тряпкам", в те времена, когда он был еще молодым специалистом, напрягли проблемой: транзистор в многократно протестированной схеме вылетал. Тот, как умная Маша, честно выписал полный дифур транзистора (занимающий примерно тетрадную страницу), подставил числа и честно начал считать, ставя точки на миллиметровке. И, действительно, обнаружился пик, лежащий далеко за пределами ТТХ. Заводские посмотрели на студента как на бога и преклонили колена. Но тот сам испортил впечатление: спросил, а почему тесты-то проходили? Тут-то его и чморнули: мол, только чайник не знает, что тестовые схемы паяются на прибалтийских транзисторах, а серийные - на ташкентских.
Опыт:
В любой протестированной программе есть ошибки четырех типов:
1. дыры, оставленные программистами для будущего исправления.
2. ошибки и бессмысленности, исправляемые компилятором или ОС или просто избыточные.
3. ошибки, которые могут вылезти при неудачном стечении обстоятельств.
4. явные несоответствия ТЗ.
Пример
Аксиома:
В любой протестированной программе есть две серьезные ошибки. И это число не зависит от числа уже выявленных и исправленных ошибок (или тех, что будут выявлены или исправлены позже).
Добавлено (07 июля 2016, 00:10)
---------------------------------------------
Второе:
Цитата 1nt3g3r ( ) Определение сложности по размеру текста некорректно. Один и тот же алгоритм можно написать изящно, одной рекурсивной функцией, а можно городить и городить костыли.
Это обычное заблуждение. Количество глюков, порождаемое фрагментом кода пропорционально его размеру. Это как кассирша: "Я ей, дуре молодой, все твержу: не бей "*5", лупи "+ + + +", а зазевается клиент - и еще один плюсик..." Дело в том, что любой замысловатый код можно обвесить предикатами "что было, что стало", и они ничем не хуже предикатов "обычного тупого кода". Но если мы имеем два куска кода, обвешенными предикатами, мы должны эти предикаты честно перемножить. И число этих умножений добавляет гораздо больше сложностей, чем сложность одного из сомножителей.
Более того, в случае разбора чужой программы (особенно в кодах) подобные сложные фрагменты, наоборот, помогают, служа опорными вехами. Так, например, я однажды хакал программу на PASCAL под DOS, а там, каждое действие арифметики было отдельной подпрограммой с использованием сопроцессора. Стоило запомнить, что есть что, и вся механика вычислений стала прозрачной. При разборе чужой BIOS такими вехами служат, например,
вызовы процедур из другого сегмента, реализованные обычно, через хитрые манипуляции со стеком.
Добавлено (07 июля 2016, 00:16)
---------------------------------------------
Третье:
Цитата 1nt3g3r ( ) Оправданность столь большого обьем - да потому что у программы много функций. Есть куча абитуриентов, над ними нужно производить разные сложные действия - например, если по какому-то предмету ему поставили 2 балла - он автоматически отчисляется, причиной отчисления пишется - "Двойка за (название предмета)".
Это не аргумент. В подобных случаях проще записывать правила в единообразном виде и просчитывать их единственной процедурой. Работает золотое правило:
1. лучше всего просто вычислить
2. не можешь вычислить - построй таблицу
3. если и таблица не помогает, только тогда пиши if-ы.Добавлено (07 июля 2016, 00:21)
---------------------------------------------
Четвертое:
Цитата 1nt3g3r ( ) .Linux писали не от желания переписать Unix - просто Unix-а не было в открытом доступе, платный он был, Unix.
Цитата 1nt3g3r ( ) Как результат - никто не будет пользоваться операционкой, на которой не работает железо и программы. Добавлено (07 июля 2016, 00:23)
---------------------------------------------
Пятое:
Цитата 1nt3g3r ( ) Да, есть и бесполезная работа, но пока вы не сделаете ее, вы этого не поймете. А когда сделаете - потом переделаете правильно. Добавлено (07 июля 2016, 00:26)
---------------------------------------------
Шестое:
Цитата 1nt3g3r ( ) А если писать лишь тестовые программы, опыта много вы не наберетесь. Добавлено (07 июля 2016, 00:28)
---------------------------------------------
Какие-то из этих вопросов явно проходные, но некоторые, видимо, можно обсуждать и далее.
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Сообщение отредактировал Gudleifr - Четверг, 07 Июля 2016, 00:18 |
|
|
| |
| ShortKedr | Дата: Четверг, 07 Июля 2016, 02:08 | Сообщение # 8 |
Renword Studio
Сейчас нет на сайте
| Цитата Gudleifr ( ) Это обычное заблуждение. Количество глюков, порождаемое фрагментом кода пропорционально его размеру. Это как кассирша: "Я ей, дуре молодой, все твержу: не бей "*5", лупи "+ + + +", а зазевается клиент - и еще один плюсик..." Дело в том, что любой замысловатый код можно обвесить предикатами "что было, что стало", и они ничем не хуже предикатов "обычного тупого кода". Но если мы имеем два куска кода, обвешенными предикатами, мы должны эти предикаты честно перемножить. И число этих умножений добавляет гораздо больше сложностей, чем сложность одного из сомножителей.
Цитата Gudleifr ( ) Опыт:
В любой протестированной программе есть ошибки четырех типов:
1. дыры, оставленные программистами для будущего исправления.
2. ошибки и бессмысленности, исправляемые компилятором или ОС или просто избыточные.
3. ошибки, которые могут вылезти при неудачном стечении обстоятельств.
4. явные несоответствия ТЗ.
Цитата Gudleifr ( ) Потому что переписать - дешевле. Всякое "улучшение" увеличивает размер следующих "улучшений". "Универсальная" программа (по Бруксу) весит в три раза больше "просто работающей". Следовательно, проще переписать "одну программу", чем проверить и исправить программу "тройного размера".
И, повторю, всегда помните два правила:
1. Сложность программы определяется только ее размером
2. Тесты ничего не доказывают
Это не обсуждается. Первое следует из единственного доступного нам способа анализа - "прорешать в голове", а второе - из свойств Машины Тьюринга.
Хе-хе, я ещё когда в прошлый раз с вами спорил по подобному поводу, понял что доказывать вам что-то бесполезно. У вас видимо программирование никак не упирается в творчество и саморазвитие 
А вот 1nt3g3r я поддержу, много чего стоящего и правильного сказал, как оно и есть на самом деле, на практике, а не в теории "Что дешевле то и лучше"!
Цитата 1nt3g3r ( ) Определение сложности по размеру текста некорректно. Один и тот же алгоритм можно написать изящно, одной рекурсивной функцией, а можно городить и городить костыли.
Да, так и есть 
Цитата Gudleifr ( ) то обычное заблуждение. Количество глюков, порождаемое фрагментом кода пропорционально его размеру. Это как кассирша: "Я ей, дуре молодой, все твержу: не бей "*5", лупи "+ + + +", а зазевается клиент - и еще один плюсик..." Дело в том, что любой замысловатый код можно обвесить предикатами "что было, что стало", и они ничем не хуже предикатов "обычного тупого кода". Но если мы имеем два куска кода, обвешенными предикатами, мы должны эти предикаты честно перемножить. И число этих умножений добавляет гораздо больше сложностей, чем сложность одного из сомножителей.
Видимо есть любовь к написанию костылей, поэтому и считаете что заблуждение.
Это всё мне навивает мысль о преподах-информатиках, которые на практике "Не видели ничего", кроме типичных задачек. Самое грустное, что они в университетах учат программировать молодое поколение. Но как показывает нам история да и мысли людей по этому поводу(например на этом форуме), в институте(не во всех, но во многих) не учат быть программистом, большая часть Профессиональных Программистов - самоучки, в большинстве своих навыков, которые прошли через многое количество проектов, как своих, так и чужих. Думаю это знает каждый кто прошёл этот путь =)
Добавлено (07 июля 2016, 02:08)
---------------------------------------------
Gudleifr, вообще мне ваши сообщения напоминаю типичный троллинг не более, ну или вы относитесь к тем людям, о которых я выше вспомнил)
Сообщение отредактировал ShortKedr - Четверг, 07 Июля 2016, 02:17 |
|
|
| |
| dalikivug | Дата: Четверг, 07 Июля 2016, 03:17 | Сообщение # 9 |
|
почетный гость
Сейчас нет на сайте
| Цитата Gudleifr ( ) И если это будут делать настоящие программисты
дайте четкое определение "настоящего программиста"
Цитата ShortKedr ( ) Это всё мне навивает мысль о преподах-информатиках, которые на практике "Не видели ничего", кроме типичных задачек.
кажется это именно тот случай 
|
|
|
| |
| Ordan | Дата: Четверг, 07 Июля 2016, 03:29 | Сообщение # 10 |
Главный зомби
Сейчас нет на сайте
| Gudleifr, Ну бред же, полный бред.
Цитата ShortKedr ( ) Это всё мне навивает мысль о преподах-информатиках, которые на практике "Не видели ничего", кроме типичных задачек. Самое грустное, что они в университетах учат программировать молодое поколение.
В техникуме был такой, он даже не знал как виндовс переустановить) с тс видимо та же проблема. Человек пишет о том чего явно не понимает.
Цитата недели: Из-за леса, из-за гор, кишки, месиво, хардкор. (Берсерк ТВ-2)
Мои проекты ТЫК
Мои видяхи на ютубэ ТЫК
Если ты споришь с идиотом, вероятно тоже самое делает и он.
|
|
|
| |
| xMoonGuarDx | Дата: Четверг, 07 Июля 2016, 07:46 | Сообщение # 11 |
|
участник
Сейчас нет на сайте
| Цитата 1nt3g3r ( ) Один и тот же алгоритм можно написать изящно, одной рекурсивной функцией, а можно городить и городить костыли. Сложность - это когда сложно понять, как это реализовать, с какой стороны подойти.
справедливости ради, стоит отметить, что это не единственный критерий сложности. Простая программа, без сложных алгоритмов, будет сложнее, если по её объемам она будет требовать как раз тысячи человеко-часов. Встают вопросы согласования работы между программистами разного уровня и разной направленности, организация и разделение обязанностей.
|
|
|
| |
| 1nt3g3r | Дата: Четверг, 07 Июля 2016, 08:33 | Сообщение # 12 |
|
почетный гость
Сейчас нет на сайте
| Gudleifr, некоторые ваши обьяснения не вызывают доверия.
Цитата Цитата 1nt3g3r ()
почему починка и адаптация программы (рефакторинг) - это плохо.
Потому что переписать - дешевле. Всякое "улучшение" увеличивает размер следующих "улучшений". "Универсальная" программа (по Бруксу) весит в три раза больше "просто работающей". Следовательно, проще переписать "одну программу", чем проверить и исправить программу "тройного размера".
И, повторю, всегда помните два правила:
1. Сложность программы определяется только ее размером
2. Тесты ничего не доказывают
Это не обсуждается. Первое следует из единственного доступного нам способа анализа - "прорешать в голове", а второе - из свойств Машины Тьюринга.
Переписать операционную систему, базу данных, другую большую программу, на которую ушли годы разработки - дешевле, чем починить ее? Почему же бизнес , который считает деньги, так не делает?
За ваши два правила - откуда вы их взяли? Вы можете их доказать\аргументировать? То, что вы написали "не обсуждается" - не придает им веса. "Тесты ничего не доказывают" - нет, они доказывают работоспособность программы на определенных данных (заметьте, я не говорю на ВСЕХ данных, а на определенном подмножестве).
Цитата Цитата 1nt3g3r ()
Оправданность столь большого обьем - да потому что у программы много функций. Есть куча абитуриентов, над ними нужно производить разные сложные действия - например, если по какому-то предмету ему поставили 2 балла - он автоматически отчисляется, причиной отчисления пишется - "Двойка за (название предмета)".
Это не аргумент. В подобных случаях проще записывать правила в единообразном виде и просчитывать их единственной процедурой.
Не все правила можно записать в единобразном виде. Отчисление за двойку, проверка данных абитуриента (с помощью интернет-базы), и сортировка по рейтингу - несколько разные правила, не находите?Цитата
Цитата 1nt3g3r ()
Как результат - никто не будет пользоваться операционкой, на которой не работает железо и программы.
Windows же пользуются...
Да - потому что на ней работает большинство железа и программ (всяко больше, чем на других ОС).
Цитата Цитата 1nt3g3r ()
А если писать лишь тестовые программы, опыта много вы не наберетесь.
Если тесты на одно и то же правило - да. А если это этюды Уэзерелла?
Вы можете писать какие угодно тестовые программы, но не отменяет того факта, что в реальных проектах возникают совсем другие сложности. Взаимодействие с членами команды, взаимодействие с заказчиком, ограничение технологии, ресурсов машины - тысячи их. Такое впечатление, что у вас нет опыта разработки реальных относительно больших проектов - поэтому вы так и пишете.
Еще, я вас просил, но вы так и не ответили:
Цитата Аргументируйте, пожалуйста, ваше высказывание - "Это очередная байка для умственно отсталых".
Цитата Опять таки, по этому пункту хочу прочитать аргументированное обьяснение, почему починка и адаптация программы (рефакторинг) - это плохо.
Сразу скажу, что я имею в виду под аргументацией. Это логическое обоснование (используя законы формальной логики) ваших мыслей. И как минимум по одному практическому примеру, подтверждающему вашу мысль. Я привел практические примеры в защиту своих аргументов, чего не могу сказать про вас. Если вы не можете доказать свои слова, это означает лишь то, что вы бросаете слова на ветер, не имея знаний в теме, которую мы обсуждаем.
Еще, у вас спрашивали определение Настоящего Программиста. Я тоже хочу почитать это - любой спор начинается с определений, чтобы потом не было двояких трактованийДобавлено (07 июля 2016, 08:33)
---------------------------------------------
xMoonGuarDx, Цитата справедливости ради, стоит отметить, что это не единственный критерий сложности. Простая программа, без сложных алгоритмов, будет сложнее, если по её объемам она будет требовать как раз тысячи человеко-часов. Встают вопросы согласования работы между программистами разного уровня и разной направленности, организация и разделение обязанностей.
Конечно, еще Фредерик Брукс писал про это. Сложность написания большой программы размером в 5 маленьких - совсем не сумма сложности (время + ресурсы) написания 5 маленьких. Я приводил пример на уровне функции\класса\модуля - что и эти вещи можно сделать относительно более сложными или простыми.
Нужно писать такие игры, чтобы в них было интересно играть самому
|
|
|
| |
| Gudleifr | Дата: Четверг, 07 Июля 2016, 10:41 | Сообщение # 13 |
|
почти ветеран
Сейчас нет на сайте
| Цитата dalikivug ( ) дайте четкое определение "настоящего программиста"
Цитата 1nt3g3r ( ) За ваши два правила - откуда вы их взяли?
Цитата 1nt3g3r ( ) Переписать операционную систему, базу данных, другую большую программу, на которую ушли годы разработки - дешевле, чем починить ее? Почему же бизнес , который считает деньги, так не делает?
Цитата 1nt3g3r ( ) Отчисление за двойку, проверка данных абитуриента (с помощью интернет-базы), и сортировка по рейтингу - несколько разные правила, не находите?
Цитата 1nt3g3r ( ) Вы можете писать какие угодно тестовые программы, но не отменяет того факта, что в реальных проектах возникают совсем другие сложности.
Цитата 1nt3g3r ( ) Я привел практические примеры в защиту своих аргументов
Голая математика: 40 тысяч строк. По современным коммерческим нормам после тестирования останется по 30 ошибок на тысячу строк. Из них 2 (по аксиоме) критических. Сколько времени Вы будете их исправлять? По Бруксу - в 6 раз дольше, чем Вы только что ответили. Проще переписать. При этом, гарантирую, Вы не вылезете за 5-10 тысяч. И число ошибок уменьшится пропорционально.
Впрочем, я не понимаю, в чем изначальные претензии. Я написал: "Единственный способ написания хорошей программы - полное выбрасывание исходников, как только они перестают нравиться". Если, Вам ваши 40 тысяч строк нравятся, то зачем их выбрасывать?
Цитата 1nt3g3r ( ) Сложность написания большой программы размером в 5 маленьких - совсем не сумма сложности (время + ресурсы) написания 5 маленьких.
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Сообщение отредактировал Gudleifr - Четверг, 07 Июля 2016, 14:02 |
|
|
| |
| 1nt3g3r | Дата: Четверг, 07 Июля 2016, 17:42 | Сообщение # 14 |
|
почетный гость
Сейчас нет на сайте
| Gudleifr, по пунктам:
Цитата Уже давал: "Программистов не бывает. Есть только системщики и пользователи. Системщики бывают математикам или электронщиками, а пользователи - физиками или лириками".
Какая-то херня. Откуда вы взяли это определение? Приведите название книги, что ли, откуда взято определение.
Цитата
Цитата 1nt3g3r ()
Переписать операционную систему, базу данных, другую большую программу, на которую ушли годы разработки - дешевле, чем починить ее? Почему же бизнес , который считает деньги, так не делает?
Потому, что бизнесу не нужны хорошо работающие программы. Ему нужны рабочие места для быдлокодеров и операционистов. И большой размер означенных программ в большинстве сам является следствием такой починки/разработки. Про выбрасывание программы на середине см. первый том Кнута.
Снова какая-то херня. Бизнесу нужны деньги - это то, для чего делается бизнес. Бизнес покупает (или пишет) софт, чтобы максимизировать свою прибыль. Хорошая программа -> меньше ошибок -> больше денег. Вроде все просто. Не нужно искать теорию заговора там, где ее нет.
Цитата Цитата 1nt3g3r ()
Отчисление за двойку, проверка данных абитуриента (с помощью интернет-базы), и сортировка по рейтингу - несколько разные правила, не находите?
Возможно. Но не обязательно.
Извините, но снова херня. Это очевидно разные задачи, как их не классифицируй: двойка - это изменение состояние абитуриента, проверка данных через интернет - валидация, сортировка - область, не влияющая на абитуриента. Очевидно, что нельзя подогнать все эти задачи под общее правило.
Цитата Цитата 1nt3g3r ()
Я привел практические примеры в защиту своих аргументов
Извините, не заметил. Более того, у Вас какая-то путаница: то требуете логическое обоснование, то практические примеры.
Не передергивайте. Я попросил И ОБОСНОВАНИЕ И ПРИМЕР. Привожу пример - из физики. Ученые предсказывали существование бозона Хиггса - это логически следовало из Стандартной модели. Предсказывали в 1964 году. А несколько лет назад построили Большой Коллайдер, и доказали существование - доказательство - практический пример.
Это научный подход - гипотеза -> эксперимент -> подтверждение гипотезы. Вы же делаете иначе - вы не доказываете свои утверждения, вы хотите, чтобы вам верили на слово. В научных кругах таких называют "научные фрики" - бестолковые люди, которые не разбираются в теме, но делают какие-то заявления.
Цитата По двум причинам, во-первых "программистский оптимизм" о котором писал Брукс,
Я читал Брукса. Про оптимизм программиста - программист думает, что напишет программу быстрее, чем это будет на самом деле. Вы использовали его слова в другом смысле. Не знаете - не пишите.
Цитата 40 тысяч строк на обсчет поведения студента?
Вы, вероятно, не представляете суть работы приемной комиссии. Если бы понимали, вы бы так не писали.
Цитата А сколько строк у Достоевского ушло на описание Раскольникова?
Не нужно сравнивать теплое с мягким, хрен с пальцем.
Цитата А, ведь,изначально языки программирования разрабатывались для предельно компактной записи вычислений
Нет, языки программирования высокого уровня разрабатывались для увеличения производительности программиста. Сколько вы в машинних кодах будете писать решение квадратного уравнения? День? Два? А я на ЯВУ напишу за 10 минут, и тесты вам предоставлю.
Цитата По современным коммерческим нормам после тестирования останется по 30 ошибок на тысячу строк. Из них 2 (по аксиоме) критических.
30 ошибок на 1000 строк после тестирования - это много. Почитайте это - http://www.securitylab.ru/news/420674.php. В среднем, меньше 1 ошибки. За аксиому - что за аксиома, где вы ее взяли (название книги, автора, глава и страница). Пока не скажете, откуда аксиома - считайте, пернули в лужу с таким подходом к называнию выдумок аксиомами.
Цитата При этом, гарантирую, Вы не вылезете за 5-10 тысяч
Вы не знаете предметной области, но уже знаете размер программы, которая решает задачу из этой области. Сморозили херню.
Цитата Впрочем, я не понимаю, в чем изначальные претензии. Я написал: "Единственный способ написания хорошей программы - полное выбрасывание исходников, как только они перестают нравиться". Если, Вам ваши 40 тысяч строк нравятся, то зачем их выбрасывать?
Претензия в том, что вы не понимаете процесс разработки програмного обеспечения, но пытаетесь учить других, как это делать. Проблема в том, что вы выдаете ваши выдумки за аксиомы и факты. Проблема в том, что вы думаете, что вы знаете как разрабатывать программы, но на самом деле ваши знание дилетантские и устаревшие.
Цитата Это, как раз, и подтверждает тезис о размере, как единственном критерии сложности. И, заметьте, Вы сами напрямую увязывали сложность Вашей "студенческой" программы с ее размером - 40 тысяч строк.
Нет, сложность программы не зависит от ее размера напрямую (линейно). Я не писал этого. Перед тем, как что-нибудь написать, утрудитесь убедиться, что вы не пишете херню.
То, что вы написали выше, свидетельствует о вашем непрофесионализме и самоуверенности. Скорей всего, вы не участвовали в разработке сколь-либо большой системы, и именно поэтому пишете херню - в силу непонимания того, о чем рассуждаете. В общем, ваши посты смахивают на троллинг, но никак не на серьезное обсуждение вопроса.
Нужно писать такие игры, чтобы в них было интересно играть самому
|
|
|
| |
| Gudleifr | Дата: Четверг, 07 Июля 2016, 18:12 | Сообщение # 15 |
|
почти ветеран
Сейчас нет на сайте
| Думаю из всего,что Вы тут понаписали можно оставить только:
Цитата 1nt3g3r ( ) То, что вы написали выше, свидетельствует о вашем непрофесионализме и самоуверенности. Скорей всего, вы не участвовали в разработке сколь-либо большой системы, и именно поэтому пишете херню - в силу непонимания того, о чем рассуждаете.
Однако, вы поставили меня в неловкое положение. Серьезное обсуждение вопроса, действительно невозможно. Ваш уровень познаний настолько низок, что прежде, чем что-то Вам доказывать, мне придется долго и нудно заниматься ликбезом, да еще против Вашей воли. Поэтому Вам остается только одно: верить или не верить на слово тому, что я написал в первом посте. Не хотите - не верьте.
Слушать в ответ: "Я считаю это херней, поэтому это херня", это, пардон, называется "сыпать бисер перед свиньями".
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
|
|
|
| |
| 1nt3g3r | Дата: Четверг, 07 Июля 2016, 18:28 | Сообщение # 16 |
|
почетный гость
Сейчас нет на сайте
| Gudleifr,
Цитата
Это не так. Мой опыт программирования примерно в полтора раза больше вашего возраста. Соответственно увеличьте на порядок сложность задач, с которыми Вы работали, размер проектов, серьезность организаций... В общем, как говорят все старые пердуны: "Я уже забыл больше, чем ты когда-либо узнаешь".
Вы кичитесь своим опытом, проектами - но вы не можете привести никакой конкретики. Поэтому, судя по вашим высказываниям, вы действительно забыли все, что можно было забыть. Открытым остается лишь вопрос - а вы вообще что-то знали?
Цитата Однако, вы поставили меня в неловкое положение. Серьезное обсуждение вопроса, действительно невозможно. Ваш уровень познаний настолько низок, что прежде, чем что-то Вам доказывать, мне придется долго и нудно заниматься ликбезом, да еще против Вашей воли. Поэтому Вам остается только одно: верить или не верить на слово тому, что я написал в первом посте. Не хотите - не верьте.
Моего уровня познаний хватает, чтобы находить ошибки в вашем нелогическом и несвязном бреде. Ваших познаний хватает лишь на напыщенное называние своих выдумок аксиомами.
Цитата Слушать в ответ: "Я считаю это херней, поэтому это херня", это, пардон, называется "сыпать бисер перед свиньями".
Каждый комментарий про херню я обосновал. Вы откуда-то взяли фразу "Я считаю это херней, поэтому это херня", и приписываете ее мне.
Если у вас есть что сказать конкретно (конкретный проект, ситуация, выводы из ситуации) - это называется конкретика, доказательство, это хорошо. А городить херню, и обзывать ее аксиомой - это не есть подход знающего человека.
Если вы хотите прочитать мне ликбез - прочитайте, я только за. Я открыт к новым знаниям, и я готов изменить свою точку зрения, если будут факты, которые ей противоречат. Но вы не привели НИ ОДНОГО факта, который подтверждает ваши мысли. Вы лишь приводите свои выдумки, причем часто довольно абсурдные.
Нужно писать такие игры, чтобы в них было интересно играть самому
|
|
|
| |
| кракозяба | Дата: Четверг, 07 Июля 2016, 18:35 | Сообщение # 17 |
почетный гость
Сейчас нет на сайте
| ну ничего вы тут попи... поговорить. самая активная тема на форуме.
по теме: прочитал, но пропустил много строчек из-за многабукаф, и я ниасилил.
Учи русский! Отговорки "Я не из России", "Мне 11 лет" - не отговорки. Будь грамотным и правильно расставляй запятые!
|
|
|
| |
| Gudleifr | Дата: Четверг, 07 Июля 2016, 18:37 | Сообщение # 18 |
|
почти ветеран
Сейчас нет на сайте
| Цитата 1nt3g3r ( ) Каждый комментарий про херню я обосновал.
Тема закрыта. Вы не хотите учиться, я - учить.
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
|
|
|
| |
| dalikivug | Дата: Четверг, 07 Июля 2016, 18:56 | Сообщение # 19 |
|
почетный гость
Сейчас нет на сайте
| Цитата 1nt3g3r ( ) Если вы хотите прочитать мне ликбез - прочитайте, я только за. Я открыт к новым знаниям, и я готов изменить свою точку зрения, если будут факты, которые ей противоречат. Но вы не привели НИ ОДНОГО факта, который подтверждает ваши мысли. Вы лишь приводите свои выдумки, причем часто довольно абсурдные.
подписываюсь
тоже хочется ликбез от этого пациента
Цитата Gudleifr ( ) ы не хотите учиться, я - учить.
ан нет
уже сливается
Сообщение отредактировал dalikivug - Четверг, 07 Июля 2016, 18:57 |
|
|
| |
| Gudleifr | Дата: Четверг, 07 Июля 2016, 19:21 | Сообщение # 20 |
|
почти ветеран
Сейчас нет на сайте
| Цитата dalikivug ( ) тоже хочется ликбез от этого пациента
Впрочем, я, ведь, давал Вам ссылки на "что почитать", но Вы не осилили.
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
|
|
|
| |
|
