Yet another lame implementation
Робити те що робили до нас – тупо. Якщо звісно це не ми робили. Чому? Бо вони почали раніше, в них було більше часу на розробку, і більше часу на тестування. Тоді вони ще були унікальними, відповідно тестерів в них теж було більше. Закон Лінуса, як його описував Ерік Реймонд.
Крім того, коли починаю робити щось своє, роблю стільки, щоб воно запрацювало, і не на йоту більше. Про який там захист від дурня, і try catch ви говорите? Все буде добре… Звісно свої програми простіші, до них навіть документації не треба. Але в чужих все таки помилок менше, і цінності в код вкладено більше.
Це я про що? Старайтесь по максимуму використовувати те що написано, а не писати щоразу з нуля. Якщо писати з нуля, майже ніяка нова цінність не з’являється, бо більшість все одно користується стабільною бібліотекою. З іншого боку вивчення документації, та використання бібліотеки інколи може мати побічним ефектом покращення документації, та додаткове тестування…
Крім того, срібна куля є: І це повторне використання коду. Брукс писав що програмки треба купувати. А в наш час навіть купувати не треба – бери найкращу безплатну, і дописуй…
Ах, і до чого це я? До того, що коли щось не виходить, треба RTFM (в разі чого повторно), а не забивати, і писати своє заново. Читати все одно легше ніж написати своє.
От недавно я написав, що pywikipediabot глючний:
UnicodeDecodeError: 'ascii' codec ....
Вкажіть кодування консолі для правильної обробки кирилиці.
console_encoding='код'
Мораль – при проблемах з кирилицею – треба шукати українську інструкцію. А не матюкати Python 2, і робити все вручну, для однієї конкретної задачі…
Хоча свого тількичитаючого бота я все таки залишу. Він простіший, не потребує реєстрації, і треба буде таки познайомити його з graphviz.
Анонс: Далі я планую розказати вам про парсер вікірозмітки від PediaPress… Писати її парсер самостійно – це вже точно погана ідея, бо вона тільки для користувача простіша ніж html.
Блоґ одного кібера 
Увы, большинство задач не требуют придумывания ничего нового, только правильно сложить кирпичики, которые написаны до тебя. И программирование превращается в попытки соединить эти кирпичики.
jtimv
21 Листопада, 2010 at 22:47
Срібної кулі досі немає – не будь-яка програма має можливість бути складеною з готових цеглинок + цеглинка може містити баги (для прикладу, ми у своїй розробці використовуємо готовий компонент HTML-редактора на основі IE. І ось, на IE8 все працює, а на IE9beta – вилітає. Це я до того, що будь-де присутні баги). Крім того, суттєві проблеми про-ння не відміняються.
По-друге, категорично не згоден з твоїм дилетантськи слабообгрунтованим першим виділеним твердженням. Власне
danbst
22 Листопада, 2010 at 09:01
Став крапку в кінці коментаря, а то не ясно, чи ти вже завершив думку.
Може містити баги, але потенційно менше ніж в нашій (хоча в нашій нам їх легше виправити).
По друге, ти не можеш бути зовсім категорично незгодним з моїм першим твердженням. А тільки в випадках коли кількість зв’язки з тією підсистемою суттєво складніші ніж реалізація, але тоді це доволі поганий компонент.
bunyk
22 Листопада, 2010 at 19:22
Я категорично не згідний з додатком “по максимуму”. А з присудком “використовувати те що написано” я згоден. Наприклад, кожен раз писати свій кодек JPEG – це занадто навіть для мене.
Проте і тут є нюанс. “використовувати те що написано” – це не обов’язково “використовувати написаний код”. Це може також бути “використовувати написану методологію”. Зараз поясню.
Уяви собі такий собі програмотворчий процес. Перед тобою стоїть певне завдання, і ти цю задачу уже розбив на абстрактні компоненти. Після цього ти розглядаєш кожен компонент як систему широковідомих цеглинок і зв’язків між ними. Кожна широковідома цеглинка – це реалізований кимось уже шматок коду, бібліотека, програма, алгоритм, тп + методологія. Так ось, ти НЕ використовуєш готовий код. Ти використовуєш методологію. На її основі ти реалізовуєш цеглинку сам. Важливо, щоб методологія включала в себе всю необхідну інформацію для можливості реалізації цеглинки, всі можливі варіанти розвитку цеглинки, всі альтернативи та можливості заміни, всі аспекти взаємодії з іншими цеглинками. Виходить, програміст затратить багато часу реалізацію уже давно до нього реалізованого, проте здобуде з цього набагато більше корисного, ніж якби він одразу скачав готову лібу.
Більш конкретно. Недоліків у даного методу програмування 2: програміст витрачає багато часу на роботу, яку можна виконати швидше і 2) не кожен зможе написати хорошу методолгію до своєї (або чужої) цеглинки.
Переваги:
* власні реалізації компонентів дають більше гнучкості та цілісності проекту (і виправлення багів буде простішим і швидшим)
* програміст буде вчитись. Фактично, кожна цеглинка буде заставляти його вивчати новий аспект програмування, а їх накопичення підвисить рівень самосвідомості, орієнтування в коді, можливості швидкого “врубання” у будь-який код і тп.
* після реалізації своєї цеглинки використання чужих того ж напрямку стане набагато звичнішим – стануть зрозумілішими особливості реалізації, стане простіше пояснити роботу компонента іншим та собі, можливо навіть програміст перейде на використання тільки готових компонентів з більш високим “ментальним” рівнем розуміння коду
* якщо знати багато методолгій, то можна стати дуже хорошим керівником якогось проекта або якоїсь фірми (при наявності здібностей до управління), адже саме рівень розуміння принципів програмування буде тільки зростати.
Щоб завершити думку – не обов’язково завжди реалізовувати цеглинку. Головне завжди мати методологію цеглинки, щоб у програміста завжди була опора при використання чужого коду. Тобто, основна задача у даному методі програмування – складання коректної і доступної методолгії. До-речі, її складання також розвиває навички, причому сильніше ніж звичайне програмування.
Чекаю вашу відповідь, Тарасе Олександровичу,
крапка в кінці коментаря
danbst
22 Листопада, 2010 at 21:49
Не зрозумів що означає слово методологія біля ” Так ось, ти НЕ використовуєш готовий код. Ти використовуєш методологію.”
Поясни простіше. (Переваги важких шляхів можеш не пояснювати, я тебе знаю).
bunyk
22 Листопада, 2010 at 22:44
У мене немає точного формулювання цього поняття. Найбільше це схоже на документацію методу розробки методу програмування (звідки і слово “методологія”).
Наприклад, мені потрібно прикрутити до своєї програми візуальний редактор блок-схем. Їх розроблено уже більше мільйона у всі часи і народи, проте для прикручення у свою програму мені треба розробити свій власний мільйон перший. І ось, ніде немає документації по способу розробки візуальних редакторів блок-схем. І що робити? Наново проходити всі помилки всіх людей чи може розбиратись в сорсах Dia і витягувати звідти потрібний мені код чи може взагалі плюнути і сказати “чуваки, малюйте в Візіо а потім імпортуйте в мою прожку”?
А так, якби була дока по методу розробки, то я вибрав би перший варіант і не зробив би при цьому жодного серйозного наступання на граблі.
І таких прикладів можна придумати ще огого скільки.
danbst
22 Листопада, 2010 at 22:55
Тепер ясно. І над цим працюють. Правда для дуже специфічних випадків. Є програми що пишуть програми (flex, antlr), і на цьому мої приклади закінчуються…
bunyk
23 Листопада, 2010 at 00:52
шкода, шо ти нічого не зрозумів
danbst
23 Листопада, 2010 at 09:04
Можливо. Тобі залишається або старатись пояснювати краще, або шукати людей які б розуміли. 🙂
bunyk
23 Листопада, 2010 at 15:29
Я то зрозумів проблему, але не зрозумів як її вирішити. То уявляю собі туторіал (але він зазвичай прив’язаний до конкретної платформи), то алгоритм (але він як на сучасні програми доволі низькорівнева штука), то просто дуже високорівневий код…
Загалом, будь-який достатньо формальний опис задачі – можна вважати кодом на декларативній мові дуже високого рівня. Залишається лише пропустити через кілька трансляторів (ну, один з них людина, але то вже таке…).
Класно, якби реалізували транслятор чогось подібного до VDM:
bunyk
23 Листопада, 2010 at 15:25
Та я кажу не про код, а про документацію!!! Замість викладення “в публіку” документації по своєму коду треба викладати в публічний доступ документацію по методу створення свого коду! Після того, як з’явиться кілька мануалів по спорідненим задачам можна буде формувати одну велику доку.
І це не обов’язково паперова книга. Це може навіть бути вікі. Основна задача ставиться так – описати методологію так, щоб більшість інших програмістів змогли відтворити по ній власноруч оригінальну програму прикладаючи мінімум зусиль.
А на рахунок VDM – що тут класного? Окрім імперативного та ОО стилю програмування нічого справді корисного не придумано.
danbst
23 Листопада, 2010 at 19:59
«Читати все одно легше ніж написати своє.»
Насправді це слабке місце повторного використання — адже потрібно не лише прочитати, а й зрозуміти. Свій власний програмний код програміст, як правило, розуміє (принаймні, в момент написання), а ось логіка роботи чужих програм чи бібліотек може бути для нього місцями загадкою. Просто читати недостатньо — потрібно застосовувати інструмент, щоб зрозуміти деякі особливості його роботи. І в ряді випадків краще написати свій код, ніж намагатися пристосувати для конкретної задачі вже існуючий: найпоширеніші інструменти можуть робити не зовсім те, пошук більш вдалого інструменту займає час, і нема гарантії, що його справді буде знайдено.
Якщо колись програмування нагадувало математику, то зараз воно все частіше починає скидатись на щось гуманітарне: сучасні програми можуть майже не містити алгоритмів, і більша частина їхньої суті — в шапках з «пруфлінками» на правильні бібліотеки, використання яких, знову ж, часто перетворюється на копіпаст готових зразків.
Ще одна проблема — «пекло залежностей», що виникає внаслідок залежності програми від бібліотек, які доводиться тягати з нею. Звичайно, цю проблему на лінуксах більш-менш вирішили, але той, хто вірить у кросплатформність, мабуть, ніколи не пробував портувати щось юніксове у віндоус.
А взагалі, ідея більш ніж правильна. Повторний винахід колеса — хибний шлях.
Python
22 Листопада, 2010 at 21:46
Ну, не обов’язково розуміти код. Це доводиться робити хіба в тому випадку, якщо до нього написана погана документація. А інтерфейс загалом має бути простіший ніж система.
А щоб вирішити проблему залежностей – можна ці залежності постачати разом з програмою. Жорсткі диски тепер недорогі. (P.S. В Windows інсталятори теж якось вирішують проблему з відстуністю dll (принаймі щодо directX точно))
bunyk
22 Листопада, 2010 at 22:49
[…] І ще одне. Коли дивлюсь сюди, то хочеться повернутись в часі назад, і вдарити себе по голові якоюсь хорошою книжкою (Червоного Дракона скоріш за все). Невже я навіть в 2010 році таке жахіття писав? От це і означає LAME implementation. […]
Кольоровий вивід в термінал « Блог одного кібера
23 Листопада, 2010 at 09:29
Обожнюю пости пояснення до яких довші за самі пости. Тоді навіть я дізнаюсь купу нового 🙂 .
bunyk
23 Листопада, 2010 at 15:30