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

[KaraNagai]

в дефолт-конструкторе не инициализируются поля,

а не надо. если надо делается без всяких добавлений строчек.

Естати у меня еще ошибка есть: надо (2 * a).

ну я арифметику не проверял, сам понимаешь
если проверить, то у тебя там еще дискрименант неверно считается, но не суть.

Вот тебе и 9 строк против твоих 46, которые должны быть больше 50 с учетом моего замечания.

я тебе еще раз говорю: можно все то же написать на форте. даже в одну строчку если очень хочется ) но мы говорили о С++ и джаве.

на С++ у тебя (с учетом таки моего замечания) будет строчек 22-23. а с учетом вызывающего кода и вовсе больше, чем у меня. плюс если ты захочешь результат этого решения куда-то передать, тебе придется городить кучу параметров.

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

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

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

то есть в результате мы имеем твоих 25 против моих сорока, а на разницу убрана морока с рассыпухой по другую сторону API.

разница в подходах видна. разница размерах кода - нет вообщем-то.

KaraNagai добавил 22.06.2007 в 13:16
все пошел делать доклад на мощноученую тему хехеххее. а юрий прав вообщем-то, но это уже другая история...

[Ludwig]

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

Кстати, мой окончательный вариант на JavaScript:

function qe(a, b, c)
{
    if (a == 0)
        return { x1: (b == 0 ? null : - c / b) }
    var d = b * b - 4 * a * c;
    return {
        d: d,
        x1: (d < 0 ? null : (- b + Math.sqrt(d)) / (2 * a)),
        x2: (d <= 0 ? null : (- b - Math.sqrt(d)) / (2 * a))
    }
}

Null - для того чтобы можно было проверять, скажем if (result.x1) - это будет работать и с null и с undefined значениями.

И как ни крути, Джава - самый длинный язык. public public public... и это еще Kara не инкапсулировал данные, а объявил их public, потому что было бы еще больше кода.

И пусть кто-нибудь теперь скажет что Джава хоть чем-то лучше Си или JavaScript.

Ludwig добавил 22.06.2007 в 13:25
Kara, теперь предлагаю решить другую задачу, а в противовес ты покажи что-то такое, что на Джаве выглядело бы компактнее и красивее чем на Си или JavaScript, без использования спец. библиотек, конечно. Идет?

Задача: опять же квадратное уравнение, но B и C меняются в программе реже чем A.

Ludwig добавил 22.06.2007 в 13:48
Вот решение на JavaScript, которое позволяет один раз вызвать некую функцию с B и C, а потом сколько угодно раз вызывать другую функцию с A, но при этом не иметь никаких объектов или статических данных:

function make_qe(b, c)
{
    return function (a)
    {
        if (a == 0)
            return { x1: (b == 0 ? null : - c / b) }
        var d = b * b - 4 * a * c;
        return {
            d: d,
            x1: (d < 0 ? null : (- b + Math.sqrt(d)) / (2 * a)),
            x2: (d <= 0 ? null : (- b - Math.sqrt(d)) / (2 * a))
        }
    }
}

Красота этого решения в том, что код, использующий эту функцию минимален:

var qe = make_qe(my_b, my_c);

// затем где-то в другом месте кода можно сколько угодно
// раз вычислять корни имея только A:

var result = qe(my_a);

Вот теперь пожалуйста пусть кто-нибудь честно распишет на Джаве класс и покажет как его использовать.

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

[Yury]

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

var qe = make_qe(my_b, my_c);

// затем где-то в другом месте кода можно сколько угодно
// раз вычислять корни имея только A:

var result = qe(my_a);

И как узнать, что за структура вернулась - есть ли там d или нет?

При использовании языков без проверки типов, вместо статических проверок, которые делал бы компилятор все надо проверять руками и в рантайме. Это по-вашему хорошо?

[TYA]

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

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

Не для меня, а для науки. В вике довольно четко о разнице говориться. Если ты не хочешь ее видеть, я ничем помочь не могу.

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

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

Вот например, у Явы есть библиотеки работы с графикой, как ты думаешь сколько будет занимать на диске вот это приложение (http://web.t-online.hu/archee83/sumotori/)? Что нужно иметь пользователю на своей машине и какие действия ему нужно совершить для запуска такого приложения (на Яве)?

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

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

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

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

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

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

TYA добавил 22.06.2007 в 16:42

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

При использовании языков без проверки типов, вместо статических проверок, которые делал бы компилятор все надо проверять руками и в рантайме. Это по-вашему хорошо?

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

TYA добавил 22.06.2007 в 16:53

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

а не надо. если надо делается без всяких добавлений строчек...
разница в подходах видна. разница размерах кода - нет вообщем-то.

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

[Ludwig]

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

И как узнать, что за структура вернулась - есть ли там d или нет?

if (result.d || result.d == 0)
// use result.d

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

При использовании языков без проверки типов, вместо статических проверок, которые делал бы компилятор все надо проверять руками и в рантайме. Это по-вашему хорошо?

Это уже общий вопрос бестиповых vs. типизированных языков, так же как и динамических vs. статических. Бестиповыми легче писать если освоить технику, потому что в таких языках есть много новых возможностей, и плюс код короче. Такие языки стараются облегчить участь программиста автоматическими конвертациями. Хотя плата за проезд - худшая производительность, конечно.

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

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

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

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

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

Welcome to the club

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

[Yury]

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

if (result.d || result.d == 0)
Что касается динамических vs. статических (это не о типах, а о компиляции), то первые имеют то преимущество, что могут реализовать лямбда-исчисление, которое невозможно или чрезвычайно сложно в precompiled языках вроде Си++. Когда функция является таким же типом данных как и целые итд, то возможны такие фокусы, как я выше показал.

Для с++ - на темплейтах реализуется почти все (там, конечно есть некоторые исключения). при этом проверка типов остается.
http://www.boost.org/doc/html/lambda.html

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

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

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

[TYA]

Ну вот приблизительно вот так... Исправлено после замечения Юрия

namespace myMath
{
	typedef std::pair<float, float> FloatPair;

	inline bool FindQERoots(const float& a, const float& b, const float& c, FloatPair& rootsOut)
	{
		if (a == 0 && b == 0) /* ASSERT( a != 0 | b != 0 ); */
			return false;
		if (a != 0)
		{
			float D = b * b - 4 * a * c;
			if (D < 0)
			{
				return false;
			}
			float sqrtD = sqrt(D);
			if (D > 0)
			{
				rootsOut = FloatPair((sqrtD - b) / (2*a), -(sqrtD + b) / (2*a));
			}
			else
			{
				float v = -b / (2*a);
				rootsOut = FloatPair(v, v);
			}
		}
		else
		{
			float v = -c / b;
			rootsOut = FloatPair(v, v);
			return true;
		}
		return true;
	};
};

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

if (a == 0 && b == 0)
	return false;

Лучше заменить на assert в debug режиме для отладки, а в релиз он не войдет, пустая проверка не к чему потом.

[Yury]

struct FloatPair

это можно гораздо проще сделать:

typedef std::pair<float> FloatPair;

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

[TYA]

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

это можно гораздо проще сделать:

typedef std::pair<float> FloatPair;

Точно.

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

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

Откуда?

[Yury]

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

Откуда?

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

[Ludwig]

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

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

Согласен, моя сишная версия дурная вышла.

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

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

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

Ludwig добавил 22.06.2007 в 19:35

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

Для с++ - на темплейтах реализуется почти все (там, конечно есть некоторые исключения). при этом проверка типов остается.
http://www.boost.org/doc/html/lambda.html

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

[KaraNagai]

так, народ, прошу прощения, у меня тут предотъездная гонка начинается, поэтому если я не на все отвечаю, прошу прощения. пока отвечу Юре aka TYA:

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

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

KaraNagai добавил 23.06.2007 в 11:46

Kara, теперь предлагаю решить другую задачу, а в противовес ты покажи что-то такое, что на Джаве выглядело бы компактнее и красивее чем на Си или JavaScript, без использования спец. библиотек, конечно. Идет?

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

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

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

любое другое использование настоящего С++ в веб-решении потребует решения архитектурных проблем в то время как деньги платятся за решение прикладных.

с джавой по крайней мере есть J2EE all the way down to JSP так сказать. тоже та еще каша, но по крайней мере консистентная и доступная под различными операционками.

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

KaraNagai добавил 23.06.2007 в 11:52

Задача: опять же квадратное уравнение, но B и C меняются в программе реже чем A.

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

[Ludwig]

Kara:

Для меня ясно, что из всех "живых" нынче языков Джава - самый вербозный и самый ограничивающий, и обе характеристики не нравятся некоторой категории программистов. Я опрашивал друзей и знакомых, которым приходилось много писать на Джаве, и обобщая все сказанное, им не нравились главным образом две вещи: то как Джава навязывает свой стиль программирования и то что приходится слишком много писать и читать. Для тех, кто знаком с другими языками, Джава - настоящий pain in the ass, потому что они знают насколько проще мог бы выглядеть код.

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

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

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

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

Large Systems Suck. This rule is 100% transitive. If you build one, you suck. -- Steve Yegge

И плюс я могу подписаться под каждым словом в той статье Пола Грэма о Джаве.

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

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

[KaraNagai]

Для меня ясно, что из всех "живых" нынче языков Джава - самый вербозный и самый ограничивающий, и обе характеристики не нравятся некоторой категории программистов.

Ага... ну фортран, кобол, виби и прочие обскурности у нас конечно померли уже, да?

Для тех, кто знаком с другими языками, Джава - настоящий pain in the ass, потому что они знают насколько проще мог бы выглядеть код.

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

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

До появления .NET (вообщем-то идеологически слизанного с джавы и работающего только под виндами фактически) серьезное веб-приложение с выделенным мидлтиром и без разработки собственного фреймворка для такого мидлтира с использованием единственного языка программирования можно было разработать только на джаве.

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

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

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

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

Надо понимать большими ты называешь компании, где код пишут больше трех человек, да?

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

Large Systems Suck. This rule is 100% transitive. If you build one, you suck. -- Steve Yegge

Конечно сак, ясно дело Но кому-то ведь надо их делать. А г-н Yegge считает что все задачи в мире можно решить маленькими системами, то пусть пойдет САПРы попишет для разнообразия, может иллюзии развеятся.

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

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

[Ludwig]

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

Ты уже говорил, что видел, речь не о тебе. Я скорее уже о Джаве как о социальном явлении говорю, если не хуже - как о религии :)

Если говорить за приложения с толстым клиентом или вовсе отдельные аппликухи, то таки да джаву нафиг.

Когда-то имело смысл писать на Джаве небольшие браузерные фигульки, скажем для слежения за stock market-ом в реальном времени. У меня правда, тормознутость и неуклюжесть UI вызывала фрустрацию. Тогда сторонники Джавы говорили "в следующей версии исправят". Но все равно Джава устраивала за неимением альтернатив, это была хорошая ниша именно для нее.

Прошло больше десяти лет, в "следующей версии" ничего не исправили, а тем временем уже созрели Flash и новые стандарты JavaScript (а сколько всего еще на подходе - Silverlight например), которые забили нишу. Все они, даже майкрософтовский Silverlight, очень даже переносимые.

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

Надо понимать большими ты называешь компании, где код пишут больше трех человек, да? ;)

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

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

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

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

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

Или возьми браузер - довольно ёмкая задача, целая операционная среда казалось бы, но взгляни на Internet Explorer - как он красиво разбит внутри на уровни. (Наверное единственный случай, где можно взять пример с Майкрософта.)