Здравствуйте, Sheridan, Вы писали:
S>Выбор идет между скоростью проектирования/программирования и скоростью работы. Я выбираю скорость работы.
Для десктопного не слишком навороченного ПО — это правильный выбор ИМХО.
S> Корпорации и компании выбирают скорость проектирования. Почемуто простые фрилансеры и мелкие конторы тянутся вслед компаниям, не замечая что заказчика можно победить не только скоростью написания софта но и тем, что этот софт будет прекрасно работать на тех машинах, которые заказчик купил 2 года назад в уцененке, да к томуже что можно установить этот софт и забыть про сервак, пока винт не посыпется.
Ответ на этот вопрос прост:
1) месяц работы квалифицированного программиста, который сможет написать быстрое ПО, стоит в Москве >1700-2000$ (т.к. столько надо только на зарплату), на Западе еще дороже, сервак с достаточно мощным процом и до хрена памяти можно собрать в 2 раза дешевле.
Да и в уцененке покупать может оказаться себе дороже — быстрее посыпется и гарантии нет.
2) Основные проблемы в современном бизнес-программировании — постоянно меняющиеся требования и необходимость интеграции разнородных компонентов. Чем быстрее будет прототип, тем быстрее можно будет потестировать его и понять что надо менять и модифицировать.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, Sheridan, Вы писали:
S>>Ошибаешся, понимаю. Сколько можно писать, ято я оношусь к дотнету как к ВБ? АХ>
Ну, ничего другого я не ожидал...
Я не могу поверить просто что люди в восторге от подобной технологии. Обещали кроссплатформенную виртмашину типа явы. Что имеем? тормознутую переделку бэйсика на новый лад. Да, улучшили. Да, поменяли синтаксис. Да, прикрутили студию. И развели сверхмощную рекламную компанию. Про кроссплатформенность я уже и не вспоминаю. Далее, что микрософт проталкивало раньше в массы? Правильно, ВБ. А что сделает манагер из МС, если видит, что продукт непопулярен? Начнет думать, как сделать популярным, а заодно и привязать к операционке, дабы не было прецендентов отказа от использования винды. Скажеж дотнет не привязан к винде? А люди глотают полученную наживку, радуются сверхлегкости кодинга, не замечая что все меньше и меньше оставляют себе места для маневра.
[RSDN@Home][1.2.0][alpha][668]
[Кто не знает, что такое мир, не знает, где он сам... [Марк Аврелий]]
Здравствуйте, EvilChild, Вы писали:
TBG>>Ну тогда bash+vim+hexedit+ncftp. А под "удобными" вы какое понятие вкладываете? EC>Я бы вместо bash порекомендовал zsh.
Кто-то порекомендует tcsh. Дело привычки. Другие шеллы навернутее, но пока то, что мне нужно, есть в bash. Время покажет. Пока баш лет 6 держится.
Здравствуйте, Donz, Вы писали: D>Чем "умное" поле нагляднее в коде, чем метод, если выглядит также, как и "неумное" поле? D>Я, кстати, не говорил, что мне неудобно. Я сказал, что непонятно зачем вводить лишнюю сущность. Можете назвать принципиальное отличие свойств от геттеров/сеттеров?
Можно.
1. Метаданные. Я могу отличить проперть от случайно названной пары методов, в том числе и через Reflection. Я застрахован от
float getWidth();
void setWidth(int width);
2. Читаемость. Что лучше читается:
Width+=2;
setWidth(getWidth()+2)
?
В целом, существует такой Property Pattern. В джаве его приходится реализовывать руками, а в шарпе он встроен в язык. Как и еще несколько паттернов.
Впрочем, на эту тему уже очень хорошо написано. Типичный Блаб программист делит все фичи на две группы:
— фичи, которые есть в Блабе, и значит обязаны быть в любом мало-мальски полезном языке
— фичи, которых нет в Блабе, и значит они никому не нужны.
Вот типичные высказывания блаб программистов:
"Десять лет программирую без пропертей, и ни разу не замечал, что мне чего-то не хватает", "нафига вводить какой-то искусственный event, когда можно обойтись интерфейсом?", "непонятно, зачем придумывать урезанную версию оператора for", "на языке без checked exceptions невозможно писать корректные программы", "енумы легко эмулируются силед классами без методов", "yield return вообще непонятно, что делает".
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали:
S>Абсолютно верно подмечено. Иногда это конечно бывает хорошо, но чаще плохо. Приводит к трудноуловимым ошибкам оптимизации кода. Я имею ввиду ситуацию, например, когда проперти попадает в цикл, а в свою очередь в проперти туча кода. S>Я к чему? была бы ф-я — глаз бы за скобки зацепился. Скобок нет — больше времени на поиск тормозов. Особенно если проект большой, и программит его не один человек.
Здравствуйте, Sinclair, Вы писали:
S>Можно. S>1. Метаданные. Я могу отличить проперть от случайно названной пары методов, в том числе и через Reflection. Я застрахован от S>
Здравствуйте, prVovik, Вы писали:
V>Погугли по слову "профайлер"
Ты так часто им пользуешся?
Профайлер применяется как правило уже на заведомо тормозной машине. Он конечно выявит применение пропертя ни к месту, но ведь при отсутствии пропертей не нужно будет запускать профайлер в данном случае.
[RSDN@Home][1.2.0][alpha][668]
[Мир ловил меня, но не поймал. [Г. С. Сковорода]]
M>>Почти оффтоп, почти СВ. Если бы в МС сделали MFC хоть наполовину похожую на Qt, на .NET бы сейчас никто бы не переезжал, имхо WH>Не гуем идиным... Многие вещи которые элементарно делаются под .НЕТ требуют при разработке на С++ чудовищных усилий.
Я не спорю. Да и Qt — это уже тоже не ГУЙ един
В общем, имеем мы сейчас то, что имеем, и мучатся нам с ним, а не с тем, что могло бы быть
Здравствуйте, prVovik, Вы писали:
S>>Согласен наполовину. Во втором случае я буду видеть возможную проблему в производительности. V>Да, способности к ясновидению — это очень полезная вещь!
Ты зря убрал
Width+=2;
setWidth(getWidth()+2);
Во втором случае все намного более наглядно.
[RSDN@Home][1.2.0][alpha][668]
[Одно и то же слово и совет Hа пользу мудрецу, глупцу во вред. [аль-Хусри]]
WolfHound wrote:
> C>А вообще, все чего Линуксу не хватает — это замены FARа и VisualStudio > для С++ > Однако samba рулит > Сижу под WinXP, а разрабатываю под линухом... использую Far и VC++8 > Правда компилировать приходится через ssh кстати может кто знает как > научить студию компилять через ssh и зачитывать сообщения об ошибках?
Попробуй похимичить с plink из пакета PuTTY.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, prVovik, Вы писали:
V>>Погугли по слову "профайлер"
S>Ты так часто им пользуешся?
В последнее время да. Я сейчас не представляю, как реально можно ускорить программу без профайлера, или его ручных аналогов (оценки "не на глаз" времени выполнения определенных кусков программы).
S>Профайлер применяется как правило уже на заведомо тормозной машине.
Это еще почему?
S>Он конечно выявит применение пропертя ни к месту, но ведь при отсутствии пропертей не нужно будет запускать профайлер в данном случае.
Совершенно неверно! Определить место в программе без профайлера (или его ручных аналогов), в котором тормозит программа обычно очень трудно. И то, что вместо проперти используется функиция — аьсолютно ниочем не говорит, так как эта функция может отрабатывать мгновенно, либо вызываться редко и не влиять потому на общую производительность.
Когда я работал над последним проектом, я полностью забил поначалу на оптимизации и решил сделать все как можно быстрее, а потом профайлером обработать. В результате выяснилось, что, те места, которые я изначально предполагал оптимизировать, совершенно на нуждались в оптимизациях. А вот реально тормоза оказались в абсолютно неожиданных местах, на "ровном месте", как я предполагал изначально. Так что сам факт, что в конкретном месте программы используется функция, а не мембер еще не значит, что именно тут надо оптимизировать.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, prVovik, Вы писали:
S>>>Согласен наполовину. Во втором случае я буду видеть возможную проблему в производительности. V>>Да, способности к ясновидению — это очень полезная вещь!
S>Ты зря убрал S>
S>Width+=2;
S>setWidth(getWidth()+2);
S>
S>Во втором случае все намного более наглядно.
По приведенным данным, проблем в производительности увидеть невозможно. Даже если внутри setWidth и getWidth происходит, например, обращение к базе данных, это еще не значит, что в этом месте будут проблемы с производительностью.
Здравствуйте, Sheridan, Вы писали: S>Согласен наполовину. Во втором случае я буду видеть возможную проблему в производительности. Ты — ни в каком случае не увидишь возможную проблему в производительности. Увидеть ее может только профайлер.
Вот тебе пример. Какой из циклов выполняется быстрее?
public static int Sum(int[] array)
{
int a=0;
for(int i=0;i<array.Count;i++)
a+= array[i];
return a;
}
или
public static int Sum(int[] array)
{
int a=0;
int count = array.Count;
for(int i=0;i<count;i++)
a+= array[i];
return a;
}
Неочевидно?
Давай перепишем первый цикл так, чтобы скобочки подсказывали тебе про возможную проблему с производительностью (это конечно не шарп, но предположим мы убрали из него свойства. спеециально для тебя):
public static int Sum(int[] array)
{
int a=0;
for(int i=0;i<array.getCount();i++)
a+= array[i];
return a;
}
Бинго? Хрен, а не бинго.
Во-первых, в современных языках высокого уровня оптимизатор вполне способен сделать инлайнинг, а потом вынести инвариант за цикл. Так что для плюсов, к примеру, оба цикла семантически эквивалентны.
Во-вторых, JIT дотнета знает, что выражение (i<array.Count) проверяется на каждой итерации, так что выкинет проверки выхода за границу массива, которые присуствуют внутри цикла. В итоге вариант, за который цепляется твой соколиный глаз, выполняется быстрее, чем гладкий.
Резюме: инструмент поиска причины проблем с производительностью — не глаза, а профайлер. А ему, извини, по барабану, насколько "невинно" выглядит код.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, prVovik, Вы писали:
S>>Профайлер применяется как правило уже на заведомо тормозной машине. V>Это еще почему?
Сорри, подразумевалось на заведомо тормозном софте.
V>Когда я работал над последним проектом, я полностью забил поначалу на оптимизации и решил сделать все как можно быстрее, а потом профайлером обработать. В результате выяснилось, что, те места, которые я изначально предполагал оптимизировать, совершенно на нуждались в оптимизациях. А вот реально тормоза оказались в абсолютно неожиданных местах, на "ровном месте", как я предполагал изначально. Так что сам факт, что в конкретном месте программы используется функция, а не мембер еще не значит, что именно тут надо оптимизировать.
Согласен. Я говорил к тому, что при использовании функций часто меньше сделать тормоза, так как видно что это функция, значит будет выполняться некий код, etc.
[RSDN@Home][1.2.0][alpha][668]
[Кто молчать не умеет, тот и говорить не способен. [Сенека Младший]]
Здравствуйте, prVovik, Вы писали:
V>По приведенным данным, проблем в производительности увидеть невозможно. Даже если внутри setWidth и getWidth происходит, например, обращение к базе данных, это еще не значит, что в этом месте будут проблемы с производительностью.
Я и не говорю что будет проблема, я говорю, что проще и быстрее найти, если изначально были тормоза.
Здравствуйте, Sinclair, Вы писали:
S>Резюме: инструмент поиска причины проблем с производительностью — не глаза, а профайлер. А ему, извини, по барабану, насколько "невинно" выглядит код.
Ладно, убедил.
[RSDN@Home][1.2.0][alpha][668]
[Hе удивление, а недоумение и печаль суть начало философии. [А. Шопенгауэр]]
Здравствуйте, Sheridan, Вы писали:
S>>>Профайлер применяется как правило уже на заведомо тормозной машине. V>>Это еще почему? S>Сорри, подразумевалось на заведомо тормозном софте.
А если софт и без того летает, то зачем его еще оптимизировать?
ИМХО, оптимизации и нужны как раз на тормозном софте.
Здравствуйте, Sinclair, Вы писали:
S>Во-вторых, JIT дотнета знает, что выражение (i<array.Count) проверяется на каждой итерации, так что выкинет проверки выхода за границу массива, которые присуствуют внутри цикла.
А как он знает, что array.Count не меняется?
S>Резюме: инструмент поиска причины проблем с производительностью — не глаза, а профайлер. А ему, извини, по барабану, насколько "невинно" выглядит код.
1.2.0 alpha rev. 655
