Где и как лучше учиться программированию?

[KaraNagai]

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

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

а с другой стороны есть языки, которые даже при желании не позволяют тебе выражаться лаконично, например Java и C#.

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

На лиспе можно _для_отдельных_задач_ писать более лаконично, чем на алголоподобных языках.

Впрочем, может быть ты не считаешь лаконичность преимуществом?

Я считаю разумную лаконичность преимуществом. Продавать понятность за лаконичность кода не имеет смысла.

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

В человеческом общении ценится прежде всего понятность. И лаконичность ценится только как средство, обеспечивающее понятность (скажем так, я с некоторых пор интересуюсь public speech, и лаконичность в этой области ценится именно из-за ограниченности attention span аудитории имхо).

Далее: математическую нотацию придумали отнюдь не для лаконичности, а потому что естественный язык просто неточен и неадекватен задаче.

По поводу размера IE: помнится в одной из старых систем, когда ты запрашивал установку IE6, он скачивал порядка 50 мег. IE7 update может быть меньше, потому что они в основном изменили UI, а движок остался тем же.

скажи под какой системой - я проверю то есть я не возражаю, но мне просто интересно проверить, сам такого не помню.

И еще, по поводу простоты функциональных спецификаций. Это большое заблуждение счтать, что простота ФС буквально переводится в простой код.

Не совсем так. В каждом классе задач по размеру функциональной спеки (если она написана правильно) можно оценить объем работы.

Вот тебе задачка: напиши ФС для Google Search.

Да собственно там не много чего писать. Хотя и больше, чем кажется с первого взгляда. И реализация там небольшая вообщем-то по-моему. А что этот пример призван показать?

[Ludwig]

Google Search: призван опровергнуть твое утверждение, будто простота спецификации означает простоту реализации. Далее ты скажешь "смотря насколько подробна спецификация".

Код Гугла чрезвычайно сложен, но просто потому, что они обрабатывают миллиарды страниц, а не сотни. То же самое с Фликром: хостить сотни картинок - это сделает любой школьник, а сотни миллионов - не любой. Функциональная спецификация не описывает как справляться со scalability, однако это может стать огромной проблемой.

Но scalability - это только одна сторона дела. Если в спецификации сказано, что требуется реализовать рейтинговую систему наподобие гугловской и фликровской - а для обоих она является коньком - то это ничего не говорит о сложности реализации этой системы. Поверь, что в обоих случаях реализация далеко нетривиальна, хотя функциональные требования формулируются парой предложений.

Языки: скажи честно, сколько строк кода ты написал на Си++ и Лиспе?

Далее: математическую нотацию придумали отнюдь не для лаконичности, а потому что естественный язык просто неточен и неадекватен задаче.

"Сила, действующая на тело, равна произведению массы тела на ускорение, сообщаемое этому телу силой" vs. F=ma - Что короче? Впрочем это уже полный оффтоп.

Продавать понятность за лаконичность кода не имеет смысла.

Это не продажа понятности, Kara. Лаконичный код может быть понятнее раздутого кода потому, что он короче. Это смотря кто пишет Я так понимаю, что ты не видел простого и лаконичного кода, которого в мире Юникса очень много, а в мире Windows и в мире Java - нету вообще.

[KaraNagai]

Код Гугла чрезвычайно сложен, но просто потому, что они обрабатывают миллиарды страниц, а не сотни. То же самое с Фликром: хостить сотни картинок - это сделает любой школьник, а сотни миллионов - не любой. Функциональная спецификация не описывает как справляться со scalability, однако это может стать огромной проблемой.

Вот я не понимаю что ты хочешь сейчас сказать. Вроде ты привел пример фликра и компании как компактного кода разработанного небольшим количеством людей типа эффективно и все такое. Я тебе в ответ на это сказал, что то ясно дело так, потому что спецификация функциональности таких систем будет мала. Ты теперь пытаешься сказать, вроде как, на примере того же фликра (и гугла), что мол хоть спека мала, но работы там дофига? Так вроде как твоему изначальному тезису это противоречит.

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

Языки: скажи честно, сколько строк кода ты написал на Си++ и Лиспе?

Шутишь? ) На лиспе я ничего коммерческого не писал. Писал код на muSimp/muLisp очень давно (в школе), потом игрался с какой-то реализацией коммон лиспа какое-то время в универе, делал парочку интерператоров с урезанных версий лиспа для разных учебных целей (один правда незаработал нифига нормально, второй сдавал по учебе), по работе с автолиспом сталкивался и что-то там на нем пправил-пописывал, плохо помню.

На С и затем С++ я пишу с 1988 года, последний раз писал по работе на С++ года три назад. С где-то 1996 года по 2002 это вообщем-то был мой основной язык разработки везде где я работал. То есть я ежедневно на нем писал код. Заглядывать и всякие сандбоксы делать на нем сейчас приходится время от времени. А к чему этот вопрос вообще? К размеру кода?

"Сила, действующая на тело, равна произведению массы тела на ускорение, сообщаемое этому телу силой" vs. F=ma - Что короче?

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

Это не продажа понятности, Kara. Лаконичный код может быть понятнее раздутого кода потому, что он короче.

Э во многих случаях продажа. Вот гляди: лаконичность достигается универсализацией кусков кода, согласен? Универсализация приводит к тому, что становится сложнее понять с чем имеет дело тот или иной кусок кода, потому что он может иметь дело с чем угодно.

Я так понимаю, что ты не видел простого и лаконичного кода, которого в мире Юникса очень много, а в мире Windows и в мире Java - нету вообще.

Ну это вообще уже совсем плохой уровень дискуссии. Почему вдруг под одним его дофига, а под другим нет? Я видел различный код под различными системами (приходилось и под HP-UX и под AIX писать). Разной степени компактности и сложности.

[Ludwig]

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

Kara, извини, друг, это уже демагогия чистой воды. Вобщем я не спорю и выбрасываю белый флаг

[KaraNagai]

Неискренне, а жаль ))

[Ludwig]

Уж извини, если выглядит неискренне, но взгляды на жизнь у нас настолько разные, что тут не один литр потребуется

[Yapi]

Сообщение от Ludwig

Уж извини, если выглядит неискренне, но взгляды на жизнь у нас настолько разные, что тут не один литр потребуется

Я-бы сказал что у вас немного перфекционистский взгляд на ремесло Что не есть плохо. Не всегда есть плохо

[Ludwig]

Сообщение от Yapi

Я-бы сказал что у вас немного перфекционистский взгляд на ремесло Что не есть плохо. Не всегда есть плохо

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

[TYA]

Ну, бла-бла, лаконичность, понятность, функциональность... и перфекционизм. Иногда он вреден, и нужно помнить о компромиссах.
Добавлю, что в очень упрошеной форме - от функциональный требований (на основании требований пользователя) зависит техническая спецификация (язык, функциональный спек... вплоть до детального описания функций и их параметров), а от технической спецификации и от исполнителя зависит качество кода и в конечном итоге - программного продукта.
И качество кода как правило зависит от детальной функциональной спеки, на ~70%, на ~30% от исполнителя - это кстати тоже грубо, но очень близко к практике.

Сообщение от KaraNagai

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

Не понял. Как компактный код может быть более сложным? Хммм... Денег стоит все, и поиск и исправление ошибки в некомпактном коде... что в итоге некомпактный код может либо сделать компактным, т.е. простым (я так понимаю), либо более сложным - зависит от исполнителя. Причем зачастую, написание компактного и некомпатного кода занимает приблизительно одинаковое время, а вот отладка... и тем, более поддержка... читай выше.

Сообщение от KaraNagai

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

Не верю. Что значит на Яве скомпилированный исполняемый? Ты о .жар?

[KaraNagai]

Не понял. Как компактный код может быть более сложным?

Ну как? А вот так: уменьшение размеров кода (в смысле меньше обычного) дается:

1. Чересчур усердным обобщением, что делает код менее очевидным - раз и более сложным в случае непредвиденных изменений - два.

2. Применением всяческих сокращающих код нотаций и т.п., что делает код плохо читаемым.

Не верю. Что значит на Яве скомпилированный исполняемый? Ты о .жар?

Скажем так: .class файлы (непожатые) - это конечно грех сравнивать с исполняемыми файлами из-под С++, потому что это вообщем-то скорее объектные файлы, чем исполняемые. Но фигня в том, что эти объектные файлы могут быть исполнены без проблем, они линковки предварительной не требуют. А джар их еще уменьшает соответственно.

KaraNagai добавил 18.06.2007 в 17:06

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

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

KaraNagai добавил 18.06.2007 в 17:11
И про размер кода: давайте Ludwig напишет класс для решения квадратных уровнений. Без пользовательского интерфейса, просто класс. На С++ скажем. А я напишу на джаве, например )

И мы сравним результат по размеру. И заодно посмотрим что такое правильный код в понимании Людвига Притом я специально к компактности кода стремиться не стану, я буду писать так, как я бы писал этот класс встань такая задача и будь у меня на нее достаточно времени (то есть не 10 минут, а побольше).

Специально предлагаю тривиальную и не требующую никакого почти что API задачу.

KaraNagai добавил 18.06.2007 в 17:13
А да и добавлю еще: специально не будем специфицировать требования четко. Будем специфицировать их именно так, как их обычно специфицирует заказчик, а именно "ну надо мне, вот". В данном случае нужен класс для решения квадратных уравнений.

[TYA]

Сообщение от KaraNagai

Ну как? А вот так: уменьшение размеров кода (в смысле меньше обычного) д ается:

У нас наверно разные понятия об обычном и компактном. То, что ты называешь компактным в моем понимании является...

Сообщение от KaraNagai

1. Чересчур усердным обобщением, что делает код менее очевидным - раз и более сложным в случае непредвиденных изменений - два.

... плохой тех. спек, как отсутствие детального функц. спека, в любом случае плохая работа программиста...

Сообщение от KaraNagai

2. Применением всяческих сокращающих код нотаций и т.п., что делает код плохо читаемым.

... говорит о том, что у исполнителя отсутсвует культура программирования, и как правило отсутствие стандарта кода в компании (включая плохой тех. спек).

Это ничего обшего не имеет с компактностью кода. Одним из примеров компактности кода является логичекое разбиение функции на подфункции вместо банального копи/пэйст.

Сообщение от KaraNagai

Скажем так: .класс файлы (непожатые) - это конечно грех сравнивать с исполняемыми файлами из-под С++, потому что это вообщем-то скорее объектные файлы, чем исполняемые. Но фигня в том, что эти объектные файлы могут быть исполнены без проблем, они линковки предварительной не требуют. А джар их еще уменьшает соответственно.

Хммм... тогда давай сравнивать С++ объектные и .класс файлы. А когда речь идет об исполнямом машинном коде, то здесь просто нечего сравнивать.

Сообщение от KaraNagai

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

Искусству программирования?
Перфекционизм прежде всего (на мой взгляд) это предвидение проблем, и постановка их сейчас, а не когда это поздно. И связано напрямую с тем как удачно спроектирована программа (тех. спек), насколько далеко вперед адресуются проблемы, о кот. тот же самый заказчик не подозревает. Перфекционизм напрямую связан с профессионализмом, и как я уже говорил случается, что порой нужно искать компромисс, что само по себе опять говорит о присутствии профессионализма.
Как Ludwig заметил, перфекционизм приходит с возрастом, но я бы сказал с опытом, так же как и профессионализм.

[Yapi]

Сообщение от TYA

Перфекционизм прежде всего (на мой взгляд) это предвидение проблем, и постановка их сейчас, а не когда это поздно. И связано напрямую с тем как удачно спроектирована программа (тех. спек), насколько далеко вперед адресуются проблемы, о кот. тот же самый заказчик не подозревает. Перфекционизм напрямую связан с профессионализмом, и как я уже говорил случается, что порой нужно искать компромисс, что само по себе опять говорит о присутствии профессионализма.

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

Если-бы "Мировое Сло" стояло на принципах перфекционизма, то "Глава Мирового Сла" никогда бы не стал Самым Богатым Айтишником.

Говорить же что перфекционизм это синоним профессионализма, это ИМХО сильно преувеличивать. Признак профессионализма это делать именно то что нужно для достижения поставленной цели максимально эффективным способом и игнорировать сторонние раздражители. Бывает что для этого нужен перфекционизм. Да.

[KaraNagai]

У нас наверно разные понятия об обычном и компактном. То, что ты называешь компактным в моем понимании является...

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

... плохой тех. спек, как отсутствие детального функц. спека, в любом случае плохая работа программиста...

Ну дык плохая. Но мотивировано оно может быть как раз компактностью кода, а еще точнее - (иногда кажущейся) минимизацией труда самого разработчика. Или углубление иерархии абстракций заради упрощения задачи на каком-то уровне этой иерархии. Условно говоря "мы торгуем свиньями, у нас есть продавец, покупатель и свинья, все они - личности, стало быть первым делом делаем класс Person...."

... говорит о том, что у исполнителя отсутсвует культура программирования, и как правило отсутствие стандарта кода в компании (включая плохой тех. спек).

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

Одним из примеров компактности кода является логичекое разбиение функции на подфункции вместо банального копи/пэйст.

См. пример про свиней Даже если у свиней есть имена и возрасты, делать общий класс Person со свойствами name и birthday не нужно. То есть огульный копи-н-пейст - это плохо, но попытка универсализовать весь код дабы избежать хоть каких-либо повторений кода - это зло. Надо знать меру, короче.

Кстати, копи-н-пейст может не столько создавать проблему увеличения размера кода, сколько проблему внесения изменений в код. Если в таком коде надо что-то подправить, то лучше б у тебя была одна копия его. Собственно размер кода здесь не так важен.

тогда давай сравнивать С++ объектные и .класс файлы. А когда речь идет об исполняемом машинном коде, то здесь просто нечего сравнивать.

Ну объектные файлы на С++ вроде как запустить нет никакой возможности, в отличие от джавовских И кстати я не уверен, что они так уж короче.

Искусству программирования?

Ага. К нему болезному.

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

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

То есть можно сколько угодно прокручивать воображаемые сценарии и писать спеки и код на их основе, но чем дальше эти сценарии будут от того, с чем сталкивается заказчик, тем больше вероятность того, что он с этими сценариями никогда не столкнется, а столкнется с другими. А код будет в результате больше и/или сложнее поменять.

Перфекционизм напрямую связан с профессионализмом,

Однако почему-то на деле я в основном сталкивался с ним у двух типов людей: у людей занимающихся программированием и в свободное от работы время для развлечения и у недавних студентов.

Ни тот ни другой типы для меня не являются идеалом инжинера, честно говоря Хотя разумеется и тот и другой могут выдавать замечательные перлы искусства программирования, но на практике лучше все же иметь dependable человека, который не пойдет переписывать более оптимально какой-нибудь базовый кусок кода с 2% улучшением производительности всей системы в результате только потому, что предыдущий кусок написан "неправильно".

[TYA]

Сообщение от Yapi

По этому поводу существуют разные мнения.

Согласен. Мы же не в армии.

Сообщение от Yapi

Говорить же что перфекционизм это синоним профессионализма, это ИМХО сильно преувеличивать. Признак профессионализма это делать именно то что нужно для достижения поставленной цели максимально эффективным способом и игнорировать сторонние раздражители. Бывает что для этого нужен перфекционизм. Да.

Они не синонимы. Уточню (себя). ИМХО, умение применять перфекционизм в сочетании с компромиссами один из признаков профессионализма.

TYA добавил 19.06.2007 в 12:36

Сообщение от KaraNagai

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

Вполне возможно.

Сообщение от KaraNagai

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

Попахивает псевдо перфекционизмом.

Сообщение от KaraNagai

Условно говоря "мы торгуем свиньями, у нас есть продавец, покупатель и свинья, все они - личности, стало быть первым делом делаем класс Персон...."

А если так. ...Анимал; Анимал->Хуман->Персон; Анимал->ДоместицАнимал->Пиггы;

Сообщение от KaraNagai

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

Как правило.

Сообщение от KaraNagai

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

О чем и речь.

Сообщение от KaraNagai

Ну объектные файлы на С++ вроде как запустить нет никакой возможности, в отличие от джавовских И кстати я не уверен, что они так уж короче.

Ну в этом случае надо Яву машину запустить, а в другом батч фаил (с линковшиком и запуском)... короче.

Сообщение от KaraNagai

Дело в том, что чем дальше адресуются проблемы о которых заказчик не подозревает, тем больше вероятность в этом ошибиться, когда заказчик таки заподозрит об этих проблемах. Я прежде всего о функциональности, а не об ограничениях по ресурсам системы.
То есть можно сколько угодно прокручивать воображаемые сценарии и писать спеки и код на их основе, но чем дальше эти сценарии будут от того, с чем сталкивается заказчик, тем больше вероятность того, что он с этими сценариями никогда не столкнется, а столкнется с другими. А код будет в результате больше и/или сложнее поменять.

Кхммм... Мы вроде не собирались модель мира описывать.

Сообщение от KaraNagai

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

Что значит пойдет переписывать, кто ему позволит? Анархия! А почему такой код был написан с самого начала? Кто позволил? Менеджера и лид. программера в шею!

[Ludwig]

Kara:

Насчет квадратного уравнения: ты бы еще предложил создать класс Integer с операцией инкремента Это кстати вполне в духе Джавы - раздувать тривиальные вещи до классов с гигантскими интерфейсами. Так вот, для квадратного уравнения класс не нужен, а нужна одна функция. Язык тут вроде как не причем, потому что раздувать аналогичным образом можно в любом ОО языке, но трагедия Джавы в том, что она навязывает такой стиль мышления, будучи чисто ОО языком. Вот тебе и ответ на твой тест с квадратным уравнением: я бы не стал раздувать задачу до класса

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

В общем случае может быть сложнее, чем просто находить повторы, но на то человеку дана целая куча нейронов в черепной кробке, надо их использовать. Грех не использовать

Ты как-то говорил о множественном наследовании. Я это часто слышу от джавистов, мол в Си++ было много лишнего. Речь прежде всего о шаблонах, о МН тоже, и о многом другом. Проблема не в том, что это "плохие" парадигмы, а в том, что они не всем по зубам. Вырезая их из языка, ты как-бы опускаешь планки для тех, кто учится на програмиста. Собственно, этот трюк Sun-а удался - планки сильно опустились, армия программистов увеличилась в размерах, качество кода упало, а затраты на разработку в итоге поднялись, все счастливы. Не это ли нужно с точки зрения бизнеса?