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

[vovick]

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

То же касается и языков: есть языки краткие, но они под силу только программистам высокого класса (может и среднего тоже?), и есть многословные и упрощенные, созданные специально под софтверные бизнес-модели с большой армией посредственностей.

Последнее наверное имеет право на жизнь, но как в той статье, на которую я сослался, проблема с такими языками в том, что они тонут вместе со своими патронами. То есть если например Sun утонет, то не пройдет и 5-10 лет, как о Джаве все забудут, потому что, как сказал Пол Грэм, и я могу подтвердить на основе опроса своих знакомых и друзей: хорошие программисты никогда не пишут на Джаве добровольно.

И еще одна статья Пола Грэма по теме:
http://paulgraham.com/power.html

Енто все конечно интересно, и я сам люблю помечтать о том как бы это было круто - написать 20 строк на OCamle по формальной спеке и проверить формальным валидатором вместо того чтобы барабанить 1000+ на Ци, а потом долго и нудно тестировать...
А в реале получается, что бОльшую часть времени я трачу в перерывание исходников ядра на предмет "почем этот гребаный select не работает" и на кодирование извращенной логики заказчика, больше всего похожей на пресловутую инструкцию к бетономешалке - а тут что Джава, что Хаскель - один хрен.

[YellowMan]

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

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

Я вот раньше тоже этим страдал - попытками написать изящно и коротко. А потом понял - неправильно это, большинство кода должен быть читаемое, пусть даже в ущерб производительности.

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

[KaraNagai]

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

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

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

[Ludwig]

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

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

Верно, и мы сместились в сторону Джавы, потому что именно ее сторонники считают, что можно не лезть так глубоко в ОСи и компиляторы. Не только Kara, на самом деле все джависты так считают. Точнее так считает Sun, а джависты по-моему повторяют это не особо вникая. То есть пиши как пишется, решай свою задачку и иди домой, потому что остальное не твое дело.

Что вобщем-то окей, но я не считаю это программированием. Это скорее клепание прикладного кода. Могу даже так переформулировать: задачи, которые не требуют хоть каких-то знаний более низкого уровня, не интересны, потому что к науке/искусству/ремеслу (нужное подчеркнуть) программирования не имеют приямого отношения. Как-то так.

[TYA]

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

"Bytecode is a binary representation of an executable program ..." (см википедию).

Буквоед? Да ладно я еше и не начинал.
Акцент на самом деле должне быть вот здесь "Bytecode is a binary representation of an executable program ..." и никак не набор инструкций. Тут ясно. Деплоймент - отдельная история.

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

Вот кстати да. Так должен хороший программист знать как устроен компилятор? Я имею в виду не общую идею, а в деталях?

ИМХО, нет, если программист не пишет компилятор. Но есть одно "но", если программист знает, что этот компилятор генерит (понятно что разные компиляторы будут генерить разный исполняемный код), то это очень ценно, особенно когда речь идет о оптимизации кода, не только с точки зрения уменьшения размера, но ис точки зрения производительности. Но, и на последок, Ява программисту это не надо, за него уже все придумали и написали, и не факт, что правильно. Но Ява программиста это не должно волновать, у него другие глобальные задачи... А все кто на С++ пишут, это прошлый век, да и надо же некоторые еше на ассемблере вставки в этом и без того замороченном С++ делают, вот чудаки.

[Ludwig]

Kara, а ты помнишь о чем мы говорили? Мне кажется первым должен выложить ты, причем решить задачу в лучших традициях Джавы, или как там завещал великий Гослинг, и ни в коем случае не страдать минимализмом. И еще обязательно добавить хотя бы один use case, и тоже в традициях, пожалуйста.

Мне на Си доказывать нечего, кроме как показать как не-ОО подход экономит понятия и код, что к Си прямого отношения не имеет. Это такой стиль программирования, который хоть и не пропагандируется в коммерческом мире, но его на самом деле никто не отменял.

Так что после вас

А ты почитал статьи по ссылкам? Они хорошие, поверь, особенно вторая. Там человек доказывает то, что я пытаюсь тут сказать.

[KaraNagai]

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

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

Акцент на самом деле должне быть вот здесь "Bytecode is a binary representation of an executable program ..." и никак не набор инструкций.

Байткод - не набор инструкций? Кам он, Юра! Байткод - именно набор инструкций. набор инструкций JVM. Как и шитый код форта - набор инструкций форт-машины (которая кстати может быть и вполне аппаратной). Как и P-код преснопамятного UCSD паскаля, на котором я делал первую работу за деньги - набор инструкции соответствующего интерпретатора.

Но есть одно "но", если программист знает, что этот компилятор генерит

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

Но Ява программиста это не должно волновать,

Как это не должно? Конечно должно. Джава-программер должен знать как ведет себя JVM.

у него другие глобальные задачи... А все кто на С++ пишут, это прошлый век, да и надо же некоторые еше на ассемблере вставки в этом и без того замороченном С++ делают, вот чудаки.

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

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

Kara, а ты помнишь о чем мы говорили? Мне кажется первым должен выложить ты,

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

Если хочешь могу тебе дать исходный код моего классика в закриптованном виде. А пароль - когда функцию напишешь

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

В каких "лучших традициях джавы"? Я как раз тебе хотел показать как на практике пишется код на джаве. На игрушечном примере, но все же. А то ты об этом представление какое-то имеешь идеалистическое. Какие нафиг "лучшие традиции джавы"?

И еще обязательно добавить хотя бы один use case, и тоже в традициях, пожалуйста.

Мы только на код договаривались. Юзкейс я могу написать. Опять же не в каких-то там "традициях", а так, как он пишется на практике. Но это будет отдельная тема для обсуждения. Можно также написать и юнит тест (в каком-то виде я его естественно написал уже), но опять же.... зачем расползаться мыслью по древу? Можно подумать ты отрицаешь полезность юз кейсов или юнит тестов для программистов на С++ Или таки отрицаешь? )

А ты почитал статьи по ссылкам?

Толко вторую быстро пробежал взглядом. Времени мало. Нужно еще почитать нормально.

[Ludwig]

Kara,

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

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

Так вот, есть как минимум два подхода: (1) ОО: объявляем дискриминант полем объекта и храним его там, плюс имеем отдельный метод для его вычисления и (2) функциональный подход: пишем функции не имеющие побочных эффектов (то есть никаких данных вне функций), первая из которых возвращает дискриминант, а вторая его берет в качестве параметра.

Так вот, в ОО только из-за существования полей объекта порождается лишний код, который должен проверять в каком состоянии находятся эти поля. Ведь когда ты пишешь код для этого класса, никто тебе не сможет гарантировать, что его методы будут вызываться в нужной последовательности, и значит эти проверки нужны.

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

Но в Джаве в дополнение к этому есть еще hassle исключений. Объект, который неверно использовали, должен выкинуть исключение, причем если я правильно помню, ты должен декларировать функции как выкидывающие исключения, и тем самым заставить пользователя обязательно их обработать. Вот тебе еще лишний код.

Вот это я и имел ввиду говоря "как завещал великий Гослинг" :)

И мне кажется ты понимаешь все это, и поэтому не хочешь выкладывать свой код. :)

P.S. У функционального подхода (вообще, не в этом случае) есть еще одно очень мошное преимущество: код легко распараллеливается, как раз потому что функции не имеют побочного эффекта.

[TYA]

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

Байткод - не набор инструкций?

Ты прекрасно понимаешь о чем речь, я уже говорил раньше и еше раз скажу... уже словами вики...

An executable or executable file, in computer science, is a file whose contents are meant to be interpreted as a program by a computer.

А Ява байткод - это просто байнери файл, а не исполняемый.

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

Опять же - каждой задаче - своя тулза.

Правильно, хорошо если бы все это понимали.

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

Ты просто в какой-то дефенсив позиции стоишь, спиной защищая С++.

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

[KaraNagai]

И мне кажется ты понимаешь все это, и поэтому не хочешь выкладывать свой код.

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

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

Вообще спор "функция vs класс" неверен в корен. Класс реализует сущность "квадратное уровнение", функция ее не реализует.

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

Так... дочку укладывать пошел, вернусь - доотвечу

[Yury]

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

Так вот, в ОО только из-за существования полей объекта порождается лишний код, который должен проверять в каком состоянии находятся эти поля. Ведь когда ты пишешь код для этого класса, никто тебе не сможет гарантировать, что его методы будут вызываться в нужной последовательности, и значит эти проверки нужны.

Ludwig, хоть я и не претендую на эксперта ОО програмирования, но вы, пытаетесь применить с-шный функциональный подход в ОО - от этого так и пишете.

Вот пример (ничего, что на С++ напишу - я боюсь слегка ошибиться в синтаксисе Java)

class SqEqSolver
{
private:
SqEqSolver(double a, double b, double c)
{
// equation solving skipped
}

};

использование:
SqEqSolver s(10, 16, 2);
и дальше можно использовать и дискрименант и корни

можно и по-красивше написать

[KaraNagai]

Ты прекрасно понимаешь о чем речь,

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

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

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

Это зависит строго говоря от того как то и другое преподают. Но таки да, если С++ преподают тщательно и задачи ставят разнообразные, то у него есть шанс знать больше. Ясное ведь дело - язык богаче. Но это не значит, что человек не изучавший С++ столь тщательно, а тщательно изучавший и использовавший джаву имеет меньше нансов стать квалифицированным прикладным программистом.

Кстати, вот что ты думаешь по поводу давнишнего спора о том, следует ли студентов учить сразу С++ или правильнее сначала их прогнать через straight С? Вот скажем страус, который труп, как-то высказался на тему, что предварительное знание С вредит при изучении С++

[Ludwig]

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

Понятное дело что функционально можно и под джавой написать.

Правда? А перепиши на Джаву вот это:

function Y(le) {
    return function (f) {
        return f(f);
    }(function (f) {
        return le(function (x) {
            return f(f)(x);
        });
    });
}

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

Ludwig добавил 22.06.2007 в 09:05

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

Вот пример (ничего, что на С++ напишу - я боюсь слегка ошибиться в синтаксисе Java)

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

Именно поэтому мне не терпится взглянуть на код Kara

[KaraNagai]

Правда? А перепиши на Джаву вот это:

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

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

но доступ к значению дискриминанта в традициях ООП тоже должен быть методом, и в нем будет проверка - а вычслен ли дискриминант? Можно и так: если еще не посчитан, то посчитать и вернуть.

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

мне вот на твой код не терпится посмотреть. еще не написал? не понимаю почему

[Yury]

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

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

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