Здравствуйте, IT, Вы писали:
IT>Почему эмулируют? Точно так же можно сказать, они эмулируют и ООП
Ну, эмулирует же не значит "делают хреновую породию"?
Просто ООП изначально есть в языке, так как есть такие вещи как классы, наследование, интерфейсы и т.п.
А вот АОП — это синтаксический сахар который реализуется на макросах. Но тут ничего страшного нет, так как в языке почти все синтаксический сахар. Даже операторы && и || и то синтаксический сахар.
Так что можно смело сказать, что императивное программирование в Нэмерле тоже эмулирвется. Для его поддержки сделаны только изменяемые переменные.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>А что такое эффективность труда, скажи пожалуйста? В чем она измеряется? Уж не в объеме ли кода?
Допустим
Эффективность — мощность (работа за промежуток времени)
Всем известно что,
[Мощность] — Вт
Вт = 1 Дж / 1 сек.
1 Дж = Н * м
Н = кг * м / (сек * сек)
Итого
[Эффективность] = (кг * м ^ 2)/(сек ^ 3)
кг — количество кода
м — "правильность" кода
сек — более большая единица времени чем секунда (в зависимости от сроков и времени проекта, часов в рабочем дне и прочее)
Здравствуйте, McSeem2, Вы писали:
MS>"Промышленное производство ПО" — это оксиморон (буквально — остроумно-глупое высказывание, типа как "живой труп"). Ну или под термином "промышленное производство ПО" подрузамевается штамповка CD и упаковка в коробки. Но в этом процессе программисты как бы и не учавствуют совсем...
"Программисты любят и умеют программировать. Пусть они этим и занимаются. Но в каждом проекте много других работ: бизнес-анализ, проектирование эргономики, графический дизайн, разработка пользовательской документации. Эти работы с программированием не имеют ничего общего. Для них требуются совершенно другая квалификация и другой склад мышления. При кустарном производстве программ эти задачи, как правило, поручаются программистам, которые это делать не умеют и не любят. Получается обычно плохо и дорого. В силу своего аутистического склада программист просто не в состоянии увидеть свою программу чужими глазами – глазами пользователей. Никто уже не хочет работать с программами с технологической парадигмой навороченного пользовательского интерфейса — кустарным творением программистов — когда для того чтобы работать с системой, надо обязательно знать, как она устроена. Это типичное творение аутиста, которому гораздо важнее видеть, как работает программа, чем разбираться в том, что она делает для пользователя."
CB>"Программисты любят и умеют программировать. Пусть они этим и занимаются. Но в каждом проекте много других работ: бизнес-анализ, проектирование эргономики, графический дизайн, разработка пользовательской документации. Эти работы с программированием не имеют ничего общего. Для них требуются совершенно другая квалификация и другой склад мышления. При кустарном производстве программ эти задачи, как правило, поручаются программистам, которые это делать не умеют и не любят. Получается обычно плохо и дорого. В силу своего аутистического склада программист просто не в состоянии увидеть свою программу чужими глазами – глазами пользователей. Никто уже не хочет работать с программами с технологической парадигмой навороченного пользовательского интерфейса — кустарным творением программистов — когда для того чтобы работать с системой, надо обязательно знать, как она устроена. Это типичное творение аутиста, которому гораздо важнее видеть, как работает программа, чем разбираться в том, что она делает для пользователя."
Термины "кустарное", "мануфактурное", "мелкосерийное", "промышленное" вообще не применимы к данному роду деятельности. Они имеют смысл при производстве товаров, то есть в процессе копирования продукта. Например, в производстве процессоров. Но ни к коем случае не при рабработке процессоров. Для процессов разработки нужна какая-то другая терминология.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
EXO>>Как говорится "не нравится — не ешь". А вот ханить переписку очти годичной давности (майскую) не вижу смысла — нафиа оно мне то надо?
VD>Извини, но ты в МС никто не ведет личную переписку по багам.
Ведет. Более того, иногда даже hotfixes предоставляет, которые иным способом недоступны. См., например, http://support.microsoft.com/kb/839582/en-us
VD>Для этого есть багтрекеры в которых любой баг отмечается и может быть найден.
Публично доступные? Появились относительно недавно. Ошибки, рапортуемые другими способами туда не попадают.
VD>Так что уже видно, что ты говоришь не правду.
Или же ты просто торопишься с выводами...
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, IT, Вы писали:
IT>У меня складывается такое впечатление, что да Видимо судьба прикладного программиста не сложилась и теперь в качестве аргумента нелюбви к профессии приводится рвотный рефлекс.
Человек должен расти профессионально всю жизнь — это нормально.
Поначалу даже талантливым, но зеленым проектировщикам-механикам дают разработать шестеренчатую пару на некий механизм. Да именно так — просто шестеренчатую пару, и не думайте, что это — простая задача. По мере профессионального роста проектировщик решает все более и более сложные задачи. Однако, если его заставить проектировать шестеренчатые пары всю жизнь, профессия с очень большой вероятностью будет вызывать рвотный рефлекс.
Большинству программистов у нас, к сожалению банально НЕ УДАЕТСЯ найти задачи, сложнее этих шестеренчатых пар. Любая задача интересна лишь в первый раз. В 10-й и 100-й раз — это уже рутина. Ситуацию усугубляет то, что рынок программистского труда в странах СНГ отличается характерным перекосом в сторону тех самых "конвеерных" задач. Это реально существующая неприятность для наших программистов.
Здравствуйте, vdimas, Вы писали:
IT>>У меня складывается такое впечатление, что да Видимо судьба прикладного программиста не сложилась и теперь в качестве аргумента нелюбви к профессии приводится рвотный рефлекс.
V>Большинству программистов у нас, к сожалению банально НЕ УДАЕТСЯ найти задачи, сложнее этих шестеренчатых пар.
Выделенным ты фактически подтверждаешь мою мысль.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, McSeem2, Вы писали:
MS>Термины "кустарное", "мануфактурное", "мелкосерийное", "промышленное" вообще не применимы к данному роду деятельности. Они имеют смысл при производстве товаров, то есть в процессе копирования продукта. Например, в производстве процессоров. Но ни к коем случае не при рабработке процессоров. Для процессов разработки нужна какая-то другая терминология.
РЕМЕСЛО, мелкое ручное производство промышленных изделий, господствовавшее до появления крупной машинной индустрии (а затем частично сохранившееся наряду с нею). Для Р. характерны: применение простых орудий труда; решающее значение в производственной деятельности ремесленника его личного мастерства, которое позволяет производить высококачественные, а часто и высокохудожественные изделия; мелкий характер производства (ремесленник работает один или с крайне ограниченным числом помощников).
КУСТАРНОЕ ПРОИЗВОДСТВО, начальная, ранняя стадия развития и низшая форма капитализма в промышленности; преимущественно мелкое домашнее товарное производство на рынок или децентрализованная (раздаточная) мануфактура, основанная на эксплуатации непосредственного товаропроизводителя — кустаря торговым и промышленным капиталом.
МАНУФАКТУРА, форма крупного промышленного производства, соединение многих ремесленников и рабочих в одном помещении для производства, с широким применением разделения труда, но без паровых двигателей; представляет переход от ремесленного к фабрично-заводскому производству.
(Курсив мой. CB)
Не стоит придираться к понятиям. Эти понятия возникли задолго до программирования. И я применяю их по аналогии. Единственная мысль, которую я никак не могу убедительно донести до моих уважаемых оппонентов, это то, что переход в производстве ПО от ремесла и кустарщины к мануфактуре, основанной на специализации и разделении труда, неизбежен и уже идет. Прошу не путать мануфактуру с конвейером. Разработка ПО это не конвейер! Проектирование ПО заканчивается только после запуска компилятора. Более близкая аналогия это конструкторское бюро, в котором над проектом нового космического корабля трудятся тысячи конструкторов и инженеров, при этом каждый разрабатывает свой компонент. Ну, не получится кустарными методами разработать MS Office, при численности команды в 500 человек.
Здравствуйте, Павел Кузнецов, Вы писали:
EXO>>>Как говорится "не нравится — не ешь". А вот ханить переписку очти годичной давности (майскую) не вижу смысла — нафиа оно мне то надо?
VD>>Извини, но ты в МС никто не ведет личную переписку по багам.
ПК>Ведет.
Здравствуйте, vdimas, Вы писали:
V>Слушай, а в чем проблема с тем алгоритмом-то? Выложи сюда все условия, глядишь — поможем сообща.
Во-первых, это долго объяснять. Во-вторых, надо очень много экспериментировать, находить закономерности и т.д. Придумывать обобщенные методы решения, потому что любые ad-hoc приводят к сказке-неотвязке (never ending story). В-третьих — моё! Не дам! Я страшный-ужасный маньяк!
V>А то действительно, банально жаль твоего времени.
Этот вопрос не должен Вас беспокоить.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
V>>Слушай, а в чем проблема с тем алгоритмом-то? Выложи сюда все условия, глядишь — поможем сообща.
MS>Во-первых, это долго объяснять. Во-вторых, надо очень много экспериментировать, находить закономерности и т.д.
Звучит как минимум подозрительно... Ты с голым алгоритмом экспериментируешь или с какой-нить железкой/технологией? Если первое, то оччень подзрительно звучит, наверняка догадываешься — почему...
MS>Придумывать обобщенные методы решения, потому что любые ad-hoc приводят к сказке-неотвязке (never ending story). В-третьих — моё! Не дам! Я страшный-ужасный маньяк!
Нет, обычный жадина
V>>А то действительно, банально жаль твоего времени.
MS>Этот вопрос не должен Вас беспокоить.
Более того, меня даже не обеспокоила такая постановка вопроса, и еще более того... Вас совершенно не должен беспокоить вопрос относительно того, что же именно может беспокоить меня.
Здравствуйте, vdimas, Вы писали:
MS>>Во-первых, это долго объяснять. Во-вторых, надо очень много экспериментировать, находить закономерности и т.д.
V>Звучит как минимум подозрительно... Ты с голым алгоритмом экспериментируешь или с какой-нить железкой/технологией? Если первое, то оччень подзрительно звучит, наверняка догадываешься — почему...
Я не знаю, что такое "голый алгоритм", но подрузамеваю, что под ним понимается что-то типа quick sort. А моя задача — триангулировать Flash, всего-навсего. Но надо это сделать так, чтобы не было стыдно встраивать в железяки типа мобильников. Если есть желание — надо взять GameSWF и переписать в нем тесселятор. А вот в чем там заключается "подстава" — это действительно долго объяснять.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
VD>>Эффективность такой экстенсиной разработки стримительно стремится к нулю. Не прийми это на свой счет, но ты даже не осознашь насколько не эффективно ты трудишся.
MS>А что такое эффективность труда, скажи пожалуйста? В чем она измеряется? Уж не в объеме ли кода? MS>Подозреваю, что ты скажешь, что-то типа "в количестве успешно решенных задач". Но и это тоже не критерий, поскольку все зависит от того, что считать "решенной задачей".
MS>Я ни в коем случае не пытаюсь навязать свою точку зрения. Нет ничего унизительного в грязной работе по проектированию и дизайну форм в дот-нет студии (ну кто-то же должен — да мне и самому приходится это делать). MS>Поэтому просьба не принимать на свой счет, это просто лично мне не нравится весь этот лохотрон. Ну вот не нравится и все тут. Мне нравится свой лохотрон.
Я с тобой согласен на 100%.
Однако хочу защитить "бросание на форму контролов". Есть такое слово (и даже форум) -- искусство юзабилити. И это искусство не хуже и не лучше создания алгоритмов. "Бедных индусов" туда пускать нельзя что-бы не появлялись такие темы как Руки от ушей
.
Напоследок скажу что сам я не в коем случае не гениальный дизайнер ГУЯ, я сам то в основном клавиатурой пользуюсь . Просто хотел тебе указать что пример который ты привел малость некорректный
Здравствуйте, craft-brother, Вы писали:
CB>Не стоит придираться к понятиям. Эти понятия возникли задолго до программирования. И я применяю их по аналогии. Единственная мысль, которую я никак не могу убедительно донести до моих уважаемых оппонентов, это то, что переход в производстве ПО от ремесла и кустарщины к мануфактуре, основанной на специализации и разделении труда, неизбежен и уже идет. Прошу не путать мануфактуру с конвейером. Разработка ПО это не конвейер! Проектирование ПО заканчивается только после запуска компилятора. Более близкая аналогия это конструкторское бюро, в котором над проектом нового космического корабля трудятся тысячи конструкторов и инженеров, при этом каждый разрабатывает свой компонент. Ну, не получится кустарными методами разработать MS Office, при численности команды в 500 человек.
Единственная мысль, которую ты никак не хочешь воспринять, так это то, что ты фактически защищаешь не мануфактуру как переходную форму от кустарного к фабрично-заводскому производству. Ты защищаешь в качестве ответа на вопрос "как накормить семью" рекомендацию типа "сначала позвольте сделать заказ вашей жене. Заказ для детей тоже обычно делает жена. Только после этого глава семьи делает заказ для себя. Не стоит позволять детям заказывать много сладкого". Это все конечно здорово, но большинству народа совершенно неинтересны советы отдать приготовление еды в руки профессионалов. Сколько ни гипнотизируй себя мантрой "советский гражданин должен питаться в общепите", народ не накормишь.
Точно так же и совет "для создания удобного пользовательского интерфейса пригласите специалиста по юзабилити" на практике бесполезен. Более того, я считаю его вредным как минимум для архитекторов, потому что он подразумевает отсутствие необходимости думать самому, и поощряет мысли типа "у нас нет на это денег, а значит хрен с ней с юзабилити". В самом-самом большом проекте, даже типа офиса, уверяю тебя, главный архитектор вовсе не отдает все на откуп "спецам". Архитектор должен сам понимать, что такое юзабилити, иначе его надо гнать в шею, ибо он не сможет внятно поставить задачу юзабилисту.
Пойми, никто не призывает отказаться от разделения труда и заставлять весь коллектив включая бухгалтера рисовать UI, UML-диаграммы, писать код на C# и SQL.
Но я лично глубоко убежден, что в самом-пресамом фабричном производстве софта нельзя стать "специалистом по написанию оператора return". Разделение труда не означает разделения умений. Я пока не видел ни одного толкового разработчика, знакомого с чем-то одним. Все нормальные разработчики умеют дофига всего.
И отказываться от изучения какой-то технологии под предлогом того, что это-де не барское дело — путь в тупик. А usability — это еще одна технология, ничуть не хуже чем ООП или там SQL. За ней тоже стоит здравый смысл; а творчества чуть больше только потому, что результат чуть меньше формализован.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
VD>Все очень просто. Лично для меня не важно кто выпустит. Для меня важны потребительские качества. Я пользуюсь продуктами МС только от того, что потребительские качества их продуктов выше чем у конкурентов.
VD>AGG несомнно хороша по одному из свойств, но это свойство мне в общем-то не так важно. А вот по другим свойствам AGG резко проигрывает. Мне вообще не нужна библиотека которую я самогу использовать из С++. Мне нужна библиотека с удобной объектной моделью которую я смогу использовать из удобного мне средства разработки.
Можно я вставлю свои пять копеек? McSeem2, когда появится адекватная обертка для AGG под .NET, желательно, максимально близкая по объектной модели и синтаксису к GDI+, тогда его смогут легко использовать простые программисты .NET. Тогда, возможно, даже станет модно заменить им нетовскую обертку GDI+ на альтернативную, как модно заменять IE на Mozilla и кричать "Windows must die" И VladD2 даже сможет ее безболезненно подключить к себе в проекты и оценить красоты картинки в AGG. Реальность такова, что даже достаточно опытному С++ программисту надо убить 2-3 дня, только чтобы написать обертку для 5% ф-й AGG. Вот так. Т.е. моя мысль такова: надо сделать GDI+ — совместимую обертку на .NET и применить AGG в качестве core engine, а те возможности, которых нет в GDI+ — их будут подключать те 5% программистов, которым это действительно нужно.
P.S. Качество картинки у AGG действительно лучше, чем у GDI+, и еще одно достоинство — ее можно залинковать в модуль, тогда как gdiplus.dll придется тащить с собой в инсталлянте.
Здравствуйте, ArtemGorikov, Вы писали:
AG>Можно я вставлю свои пять копеек? McSeem2, когда появится адекватная обертка для AGG под .NET, желательно, максимально близкая по объектной модели и синтаксису к GDI+, тогда его смогут легко использовать простые программисты .NET. Тогда, возможно, даже станет модно заменить им нетовскую обертку GDI+ на альтернативную, как модно заменять IE на Mozilla и кричать "Windows must die" И VladD2 даже сможет ее безболезненно подключить к себе в проекты и оценить красоты картинки в AGG. Реальность такова, что даже достаточно опытному С++ программисту надо убить 2-3 дня, только чтобы написать обертку для 5% ф-й AGG. Вот так. Т.е. моя мысль такова: надо сделать GDI+ — совместимую обертку на .NET и применить AGG в качестве core engine, а те возможности, которых нет в GDI+ — их будут подключать те 5% программистов, которым это действительно нужно.
Ага. Но судя по моим ощущениям от McSeem2 этого никогда не будет.
ЗЫ
Я буду рад если ошибусь!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Chipsеt, Вы писали:
C>Однако хочу защитить "бросание на форму контролов". Есть такое слово (и даже форум) -- искусство юзабилити. И это искусство не хуже и не лучше создания алгоритмов. "Бедных индусов" туда пускать нельзя что-бы не появлялись такие темы как Руки от ушей
Это верно и я уже упоминал, что задача проектирования ГУИ — это сложное дело. Вот простейший пример — диалог супротив конфиг файла. Диалог — это конечно хорошо, но где в нем функция поиска нужного элемента? А когда в диалоге с два десятка закладок, без поиска становится плохо (Apple что-то сделали в этом направлении, но в общем и целом — конь не валялся). Налицо яростная профанация с оголтелым ущемлением функциональности.
C>Напоследок скажу что сам я не в коем случае не гениальный дизайнер ГУЯ, я сам то в основном клавиатурой пользуюсь . Просто хотел тебе указать что пример который ты привел малость некорректный
В том-то и трагедия, что корректный. Набор инструментов, что поставляется с той же студией — он яко бы позволяет "любой домохозяйке сделать ГУИ". И если там один чек-бокс и две кнопки, то это действительно так. Но изготовление чего-нибудь чуть более сложного в том же форм-дизайнере превращается в кошмарную рутину. Для специалиста по юзабилити — штука совершенно бесполезная, а у домохозяек в любом случае получаются "кошмарные домашние странички". Эта профанация безусловно выгодна с точки зрения мгновенных прибылей, но она создает лишь иллюзию работоспособности — некая поделка сделанная индусами для индусов рангом пониже. Да это же всемирный заговор!!!
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Для специалиста по юзабилити — штука совершенно бесполезная, а у домохозяек в любом случае получаются "кошмарные домашние странички".
Если ты конкретно про веб-дизайнер, то, действительно, лучше бы его не было. Все кого я знаю кто серьёзно занимается вебом отключают дизайнер сразу. Но без дизайнера гуёвых форм жить нельзя. Пристреливать контрол по пикселям в коде с постоянной перекомпиляций для проверки попадания — дело не для слабонервных. Даже в досе в своё время я на турбовижине наваял визуальный редактор форм, после чего дело пошло асолютно на другом уровне.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Если ты конкретно про веб-дизайнер, то, действительно, лучше бы его не было. Все кого я знаю кто серьёзно занимается вебом отключают дизайнер сразу. Но без дизайнера гуёвых форм жить нельзя. Пристреливать контрол по пикселям в коде с постоянной перекомпиляций для проверки попадания — дело не для слабонервных.
И это верно. А чем же они тогда пользуются, если сразу отключают? Есть какая-то альтернатива? Да и просто дизайнер форм для десктоп-приложений — то еще уродство. Вообще, "пристреливание по пикселам" — это по большому счету все, что требуется от ГУИ-дизайнера. Все эти рукоблудства с генерированием кода — не более чем маркетинговый тотал-булшит.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
кода
Если нам не помогут, то мы тоже никого не пощадим.
. Просто хотел тебе указать что пример который ты привел малость некорректный 
"Всё что не убивает нас, делает нас сильнее..."
1.1.4 stable rev. 510
