Re[4]: 10 самых важных нерешенных задач IT - Философия программирования

Коллеги,
долго думал в какой из форумов запостить свой вопрос, в итоге остановился на Проектировании. Имхо близко.

Итак, известно что в математике есть некий Top10 нерешенных задач очень основопологающих, важных, будоражущих умы и проч. Про то же в ИТ мне не известно но суть не в этом. Итак, коллеги, какие глобальные проблемы ИТ вы могли бы обозначить?

Думаю что обсуждение будет интересным, полезным и не перерастет в флейм.
Просьба отнестись серьезно.

Regards,
Rene Descartes

22.03.05 14:38: Перенесено модератором из 'Архитектура программного обеспечения' — Хитрик Денис

Здравствуйте, descartes, Вы писали:

D>Коллеги,
D>долго думал в какой из форумов запостить свой вопрос, в итоге остановился на Проектировании. Имхо близко.

D>Итак, известно что в математике есть некий Top10 нерешенных задач очень основопологающих, важных, будоражущих умы и проч. Про то же в ИТ мне не известно но суть не в этом. Итак, коллеги, какие глобальные проблемы ИТ вы могли бы обозначить?

D>Думаю что обсуждение будет интересным, полезным и не перерастет в флейм.
D>Просьба отнестись серьезно.

Основные задачи давно уже во флейме обозначены:
1. кто быстрее?
2. кто дешевле?
3. у кого пиписька длинее?..

и до сих пор ещё не решены..

Здравствуйте, Dimonka, Вы писали:

D>Здравствуйте, descartes, Вы писали:

D>>Коллеги,
D>>Просьба отнестись серьезно.

D>Основные задачи давно уже во флейме обозначены:
D>1. кто быстрее?
D>2. кто дешевле?
D>3. у кого пиписька длинее?..

D>и до сих пор ещё не решены..

Просил же отнестись серьезно!!!

Я бы не сильно расстроился если бы Вы не ответили.

1) Семантика ( смысловое описание информации)
2) AI (диллема между символами и мыслью ), а если вспомнить, что @"AI — это то, что сейчас нет", то это всегда нерешенная задача
3) Возможно, чтобы программы сами писались ( собирались с учетом всяких стратегий и т.п) только по высокоуровнему ( почти на уровне б. требований) Problem Space описанию.

Здравствуйте, flax, Вы писали:

F>2) AI (диллема между символами и мыслью ), а если вспомнить, что @"AI — это то, что сейчас нет", то это всегда нерешенная задача

интересное определение AI
можно поподробнее? это кто сказал что AI — то чего нет и всегда нерешенная задача?

D>можно поподробнее? это кто сказал что AI — то чего нет и всегда нерешенная задача?

кто-то из "великих", кто — не помню.
В целом, эта мысль явно выделена в одной из глав у Хавштатера "Гедель, Эшер, Бах" (книга про AI в принципе)

Здравствуйте, descartes, Вы писали:

D> Итак, коллеги, какие глобальные проблемы ИТ вы могли бы обозначить?

Навскидку:

Повторное использование кода.
Параллельные и распределенные вычисления — семантика.
Пиринговые системы — эффективность, безопасность.
Хранилища данных, добыча данных.

Здравствуйте, descartes, Вы писали:

D>Итак, коллеги, какие глобальные проблемы ИТ вы могли бы обозначить?

Вирусы.
Спам.
Плата за использование программ.
Надежность ПО (в том числе критического)

Здравствуйте, descartes, Вы писали:

1) Культура потребления ПО;
2) Защита прав производителей ПО;
3) Реальная подготовка и сертификация квалифицированных кадров;
4) Точное определение сроков и бюджета;
5) Полностью интегрированная среда разработки ПО — все в одном флаконе, причем со вкусом и без компромиссов;
6) Быстродействие компиляторов C++;
7) Существование программирования как нормальной публичной научной дисциплины, являющейся главной движущей силой для всей индустрии;
9) Автоматическое распознавание кодировки Web-браузерами;
8) Стационарное лечение компьютероманов, с последующим курсом реабилитации и социальной адаптации;

10) Качество драйверов от ATI

Здравствуйте, lextasy, Вы писали:

L>10) Качество драйверов от ATI

С этим полность. согласен. Но ведь раньше же они делали нормальные дрова!
Может кто знает как бороться с ATI RADEON 9600, а то Doom 3 слетает время от времени

Здравствуйте, Ведмедь, Вы писали:

В>Здравствуйте, lextasy, Вы писали:

В>С этим полность. согласен. Но ведь раньше же они делали нормальные дрова!
В>Может кто знает как бороться с ATI RADEON 9600, а то Doom 3 слетает время от времени

а драйвера последние, если нет то обнови, помогает

Здравствуйте, descartes, Вы писали:

D>Итак, известно что в математике есть некий Top10 нерешенных задач очень основопологающих, важных, будоражущих умы и проч. Про то же в ИТ мне не известно но суть не в этом. Итак, коллеги, какие глобальные проблемы ИТ вы могли бы обозначить?

Пару лет назад слышал, что главной задачей IT (не программирования!) является "достижение трех Т":
— Терагерц частоты процессора;
— Терабайт оперативной памяти;
— Тераби(ай?)т/сек. пропускной способности сети.

Здравствуйте, poilk, Вы писали:

P>Здравствуйте, descartes, Вы писали:

D>>Итак, известно что в математике есть некий Top10 нерешенных задач очень основопологающих, важных, будоражущих умы и проч. Про то же в ИТ мне не известно но суть не в этом. Итак, коллеги, какие глобальные проблемы ИТ вы могли бы обозначить?

P>Пару лет назад слышал, что главной задачей IT (не программирования!) является "достижение трех Т":
P>- Терагерц частоты процессора;
P>- Терабайт оперативной памяти;
P>- Тераби(ай?)т/сек. пропускной способности сети.

Здравствуйте, descartes, Вы писали:

D>Просил же отнестись серьезно!!!

D>Я бы не сильно расстроился если бы Вы не ответили.

Точно такая же флеймовая тема как и эта:
http://rsdn.ru/Forum/?mid=763228&flat=0

Серьёзней уж тут не ответишь.

Здравствуйте, descartes, Вы писали:

D>Итак, известно что в математике есть некий Top10 нерешенных задач очень основопологающих, важных, будоражущих умы и проч. Про то же в ИТ мне не известно но суть не в этом. Итак, коллеги, какие глобальные проблемы ИТ вы могли бы обозначить?

А вот интересно сначала выяснить что такое ИТ?
ИТ — это только железо или программы туда тоже включены?

Есть одна основополагающая важная задача. Доказать что P # NP, или наоборот, что P = NP и придумать эффективные алгоритмы решения NP задач. Ну или придумать железо, на котором NP задачи можно более-менее быстро решать.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Здравствуйте, descartes, Вы писали:

D>>Итак, известно что в математике есть некий Top10 нерешенных задач очень основопологающих, важных, будоражущих умы и проч. Про то же в ИТ мне не известно но суть не в этом. Итак, коллеги, какие глобальные проблемы ИТ вы могли бы обозначить?

SYG>А вот интересно сначала выяснить что такое ИТ?
SYG>ИТ — это только железо или программы туда тоже включены?

SYG>Есть одна основополагающая важная задача. Доказать что P # NP, или наоборот, что P = NP и придумать эффективные алгоритмы решения NP задач. Ну или придумать железо, на котором NP задачи можно более-менее быстро решать.

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

Здравствуйте, descartes, Вы писали:

D>Итак, известно что в математике есть некий Top10 нерешенных задач очень основопологающих, важных, будоражущих умы и проч. Про то же в ИТ мне не известно но суть не в этом. Итак, коллеги, какие глобальные проблемы ИТ вы могли бы обозначить?

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

--
Vitaly Belekhov

Здравствуйте, Andrew Simontsev, Вы писали:

AS>Меня всегда интересовал вопрос — а существует ли практические примеры NP-полных задач для которых бы нельзя было найти воркэраунда типа ограничения перебора, симплекс-метода или чего-нибудь в этом роде? Может на практике оно и не надо вовсе...
Задача проверки эквивалентности двух произвольных крафов

Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, Andrew Simontsev, Вы писали:

AS>>Меня всегда интересовал вопрос — а существует ли практические примеры NP-полных задач для которых бы нельзя было найти воркэраунда типа ограничения перебора, симплекс-метода или чего-нибудь в этом роде? Может на практике оно и не надо вовсе...
LVV>Задача проверки эквивалентности двух произвольных крафов

ограничение перебора

Здравствуйте, Andrew Simontsev, Вы писали:

AS>Меня всегда интересовал вопрос — а существует ли практические примеры NP-полных задач для которых бы нельзя было найти воркэраунда типа ограничения перебора, симплекс-метода или чего-нибудь в этом роде? Может на практике оно и не надо вовсе...

Ограничение перебора, действительно, можно применять в большинстве задач. Но всё равно это не помогает.

Здравствуйте, Andrew Simontsev, Вы писали:

AS>Меня всегда интересовал вопрос — а существует ли практические примеры NP-полных задач для которых бы нельзя было найти воркэраунда типа ограничения перебора, симплекс-метода или чего-нибудь в этом роде? Может на практике оно и не надо вовсе...

Да, разумеется есть.

Вот пожалуйста, Задача дистрибьюторской сети.

В городе есть несколько складов с продуктами. На каждом складе в каждый момент времени есть какое-то количество каких-то видов продуктов. Продукты доставляются на склады с заводов изготовителей по какому-то определенному расписанию. Есть потребительские точки в которые нужно развозить всякие разные товары к опреденному времени. Для развозки товара есть несколько грузовиков разной вместимости. Есть несколько ориентированных графов городских дорог (для каждого типа грузовиков свой граф — так как, например тяжеловозам нельзя ездить по некоторым мостам или по центру города). Есть такой фактор, как пробки на дорогах, который выражаетмся в пропускной способности дуг орграфа в зависимости от времени суток и габаритов грузовика. Ну, до кучи, у потребительских точек еще есть VIP фактор, то есть приоритет обслуживания (то есть если вдруг оказывается, что грузовик не успевает объехать все точки (задержался где-то), то какие-то из точек ему надо игнорировать, а ехать в первую очередь в более приоритетные потребительские точки. Ну еще добавьте к этому, что рабочий день водителя городского грузовика есть 8 часов + перерыв на обед. А, ну еще, само собой разумеется, что принято к одному клиенту груз целиком доставляеть все-таки одним грузовиком к какому-то одному времени, а не подвозить его частями на разных грузовиках в разные времена. Надо найти такие пространственно-временные траектории движения для всех грузовиков, и такое распределение разных сортов грузов по этим грузовикам, чтобы как можно больше клиентов обслужить и как можно мешьше бензина истратить. А еще как можно меньше грузовиков задействовать — это чтобы на зарплату водителям меньше тратить и на амортизацию дополнительного грузовика.

Реальные цифры:
1-2 склада
200-600 потребительских точек каждый день (вообще по городу их 10'000)
20-30 разных грузовиков (15 штатных — остальные вольнонаемные)
Каждый грузовик за рабочий день может объехать не больше 20-40 точек (либо не хватит 8-часового рабочего дня, либо вместимости).
Десяток VIP клиентов.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Здравствуйте, Andrew Simontsev, Вы писали:

AS>>Меня всегда интересовал вопрос — а существует ли практические примеры NP-полных задач для которых бы нельзя было найти воркэраунда типа ограничения перебора, симплекс-метода или чего-нибудь в этом роде? Может на практике оно и не надо вовсе...

SYG>Да, разумеется есть.

SYG>Вот пожалуйста, Задача дистрибьюторской сети.
[...]

А разве симплекс метод тут не поможет? Понятно, что условия и ограничения тяжко все сформулировать, но думаю это возможно...

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

VVB>--
VVB>Vitaly Belekhov

Полностью согласен!

Слова не мальчика — но мужа!

От себя добавлю — бубен, конечно, сила — но не решение.

По мимо правильной (т.е. эффективной) организации труда в IT (что есть, была и будет первой задачей IT от момента творения и до конца света) — следующая важнейшая задача — это как раз выделения наиболее приоритетных задач. Всю дорогу можно наблюдать, как огромные средства бухаются чёрти-знает куда, а довольно интересные и переспективные (как потом показывает будущее) направления игнорируются. Вспомним хотя бы историю с ADA и объектным программированием.

Здравствуйте, Andrew Simontsev, Вы писали:

AS>А разве симплекс метод тут не поможет? Понятно, что условия и ограничения тяжко все сформулировать, но думаю это возможно...

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

1. Патенты на алгоритмы и идеи ( реально экономически выгодная и не тормозящая ИТ индустрию).
2. Бизнес система распостранения программ с отрытыми исходниками ( реально экономически выгодная ).
3. Авто оптимизация кода и трансляция из одного аппаратно программного окружения в другое.
4. Контроль качества программного обеспечения.

Здравствуйте, Andrew Simontsev, Вы писали:

AS>Меня всегда интересовал вопрос — а существует ли практические примеры NP-полных задач для которых бы нельзя было найти воркэраунда типа ограничения перебора, симплекс-метода или чего-нибудь в этом роде? Может на практике оно и не надо вовсе...

Военные динамические задачи. Ну типа как в Civilization, War/StarCraft, C&C, Периметр, HomeWorld. Я правда не вкурсе доказывал ли кто-нибудь что они NP, но, например, лично у меня по этому поводу сомнений нет.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Ну или придумать железо, на котором NP задачи можно более-менее быстро решать.

квантовый компьютер ;)

Здравствуйте, descartes, Вы писали:

D>Коллеги,
D>долго думал в какой из форумов запостить свой вопрос, в итоге остановился на Проектировании. Имхо близко.
Skip.....
D>Думаю что обсуждение будет интересным, полезным и не перерастет в флейм.
D>Просьба отнестись серьезно.

Увеличение производительности труда разработчиков. Особенно в софтверной области.
На лицо глобальное отставание развития ПО от железа

Здравствуйте, descartes, Вы писали:

D>Здравствуйте, flax, Вы писали:

F>>2) AI (диллема между символами и мыслью ), а если вспомнить, что @"AI — это то, что сейчас нет", то это всегда нерешенная задача

D>интересное определение AI
D>можно поподробнее? это кто сказал что AI — то чего нет и всегда нерешенная задача?

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

borka пишет:
> Повторное использование кода.

Занятно. Недавно видел краткий обзор с цитатами анонсов новых
технологий. Все обещали(-ют) повторное использование. Похоже таки проблема

--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.

Posted via RSDN NNTP Server 1.9

Здравствуйте, Dimonka, Вы писали:

D>Основные задачи давно уже во флейме обозначены:
D>1. кто быстрее?
D>2. кто дешевле?
D>3. у кого пиписька длинее?..

на самом деле первые две — это частные случаи третьей, фундаментальной

.

Здравствуйте, descartes, Вы писали:

D>Итак, известно что в математике есть некий Top10 нерешенных задач очень основопологающих, важных, будоражущих умы и проч. Про то же в ИТ мне не известно но суть не в этом. Итак, коллеги, какие глобальные проблемы ИТ вы могли бы обозначить?

1. Менеджмент. Давно известный факт, что программистами управляют люди, слабо представляющие как расшифровывается сама аббревиатура IT.
2. Сертификация. Не в смысле экзамены типа от MS, которые может зазубрить по дампам любой индус. А в смысле, как у докторов — чтобы начать самостоятельно практиковать, нужно сдать экзамен своим практикующим коллегам. Если же IQ не хватает, то будешь всю жизнь подносить патроны. Сейчас же ситуация такова, что при достаточной шероховатости языка любой Click-click Anyhow VBeloper может легко превратиться в Senior Enterprise Blah-blah-blah Architect и начать принимать судьбоносные решения.

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

Здравствуйте, IT, Вы писали:

IT>Давно известный факт, что программистами управляют люди, слабо представляющие как расшифровывается сама аббревиатура IT.
Игорь Ткачев?

C уважением, Gleb.

Здравствуйте, descartes, Вы писали:

За все IT не скажу, благо не знаю. А вот некоторые проблемы разработки от себя:
1. Проблема художника. Где кончается работа и начинается творчество. Граница непонятна. Все стараются уменьшить последнее, да вот эффект обратный.
2. Проблема маленькой головы. Как впихнуть всю информацию накопленную в сфере, в бедную голову конкретного разработчика. Кто это должен делать, и главное как, и как часто.
3. Проблема количества. При развитии IT возникает большее количество инструментов и повышается сложность работы с ними. А не наоборот. Нет процесса сходимости, особенно в области их взаимодействия. Жить становится не легче.
4. Проблема Microsoft vs Sun. Высокая степень монополизации. В этом есть и плюс, в этом есть и минус. Монополизация позволяет как устанавливать стандарты, так и нарушать их. Мир IT разделен на монополии. Причем эти миры стараются не контактировать.
5. Проблема велосипедов. В этом участвуют п1,п2,п3,п7. Во многом работа — изобретение велосипедов о которых мы ничего не знали. Иногда велосипеды получаются с 10 колесами, с одной педалью и к тому-же все находится сверху оного.
6. Деньги vs Качество. Процесс разработки настроен на получение максимума прибыли, а не на увеличении качества продукта. Недостатки буржуазного строя.
7. Проблема индийцов. Низкая квалификация. Особенно если индиец становится архитектором, team manager'ом и т.д. Пускай граждане индийской национальности не обижаются, но имя просто стало нарицательным. Надеюсь здесь все понятно.

С уважением, Gleb.
PS:Ессно, тут такое IMHO — мама не горюй.

AS>Меня всегда интересовал вопрос — а существует ли практические примеры NP-полных задач для которых бы нельзя было найти воркэраунда типа ограничения перебора, симплекс-метода или чего-нибудь в этом роде? Может на практике оно и не надо вовсе...

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

Здравствуйте, borka, Вы писали:

D>> Итак, коллеги, какие глобальные проблемы ИТ вы могли бы обозначить?

B>Навскидку:

B>Повторное использование кода.
B>Параллельные и распределенные вычисления — семантика.
B>Пиринговые системы — эффективность, безопасность.
B>Хранилища данных, добыча данных.

Где можно подробнее узнать о семантических проблемах параллельных программ?

dimon0981,

AS>>Меня всегда интересовал вопрос — а существует ли практические примеры NP-полных задач для которых бы нельзя было найти воркэраунда типа ограничения перебора, симплекс-метода или чего-нибудь в этом роде? Может на практике оно и не надо вовсе...

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

Задача нахождения оптимальной стратегии в шахматах точно в PSPACE, а вот в NP — крайне маловероятно. Здесь тоже ещё открытая проблема PSPACE =? NP, и в данном случае равенство ещё более сомнительно, ежели в случае проблемы NP =? P.

Вообще есть класс задач RE — рекурсивно перечислимые задачи, их всего лишь счетное множество. Так вот, самые интересные задачи — в ¬RE, и там их — континуум.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, descartes, Вы писали:

GZ>За все IT не скажу, благо не знаю. А вот некоторые проблемы разработки от себя:
GZ>1. Проблема художника. Где кончается работа и начинается творчество. Граница непонятна. Все стараются уменьшить последнее, да вот эффект обратный.
GZ>2. Проблема маленькой головы. Как впихнуть всю информацию накопленную в сфере, в бедную голову конкретного разработчика. Кто это должен делать, и главное как, и как часто.
GZ>3. Проблема количества. При развитии IT возникает большее количество инструментов и повышается сложность работы с ними. А не наоборот. Нет процесса сходимости, особенно в области их взаимодействия. Жить становится не легче.
GZ>4. Проблема Microsoft vs Sun. Высокая степень монополизации. В этом есть и плюс, в этом есть и минус. Монополизация позволяет как устанавливать стандарты, так и нарушать их. Мир IT разделен на монополии. Причем эти миры стараются не контактировать.
GZ>5. Проблема велосипедов. В этом участвуют п1,п2,п3,п7. Во многом работа — изобретение велосипедов о которых мы ничего не знали. Иногда велосипеды получаются с 10 колесами, с одной педалью и к тому-же все находится сверху оного.
GZ>6. Деньги vs Качество. Процесс разработки настроен на получение максимума прибыли, а не на увеличении качества продукта. Недостатки буржуазного строя.
GZ>7. Проблема индийцов. Низкая квалификация. Особенно если индиец становится архитектором, team manager'ом и т.д. Пускай граждане индийской национальности не обижаются, но имя просто стало нарицательным. Надеюсь здесь все понятно.

Прикол всех твоих пунктов в том, что они суть п.6:

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

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

Отсюда имеем распространенные сейчас подходы, типа "писать надо так, чтобы и дебил разобрался". Мое имхо, далеко не обязательно так писать. Писать надо так, как это наиболее отвечает задаче. Уровень "дебила" тоже должен соответствовать задаче. А вот с этим напряг, обычно... и т.д. и т.п. и еще тонна следствий из главного п. №6. (палата №6

)

Здравствуйте, vdimas, Вы писали:

V>Прикол всех твоих пунктов в том, что они суть п.6:

V>Миллионы людей по всему миру пишут одно и то же, пишут настолько минимально, насколько это возможно, а потому ужасно. И потому пишут снова и снова, и опять одно и то же.
Не соглашусь. Универсальных решений не бывает. Точнее сказать для одной и той же задачи существует большое количество решений. И каждое решение имеет свои бенефиты. А некоторые решения вообще до сих пор не решены, и их решения просто нет в обозримом будуйщем.

V>Всевозможные известные пособия по управлению проектами учат как правильно реализовать лишь минимально необходимое путем "правильной" расстановки приоритетов. "Провалить проект" в современном мире зачастую означает "выйти за бюджет",а не только лишь "сделать бездарно".
+1

V>При найме команды берут программистов минимально необходимого уровня для каждой из позиций, т.е. максимально дешевых для конкретного проекта. Эдакое сознательное балансирование на грани фола.
+1. Хотя бывает и по другому, но в большинстве своем(почему-то многие здесь с этим не согласны), к сожалению это так.

V>Отсюда имеем распространенные сейчас подходы, типа "писать надо так, чтобы и дебил разобрался". Мое имхо, далеко не обязательно так писать. Писать надо так, как это наиболее отвечает задаче. Уровень "дебила" тоже должен соответствовать задаче.
Вот с тем, что надо писать так, чтобы дебил разобрался, я абсолютно согласен.
Во-первых, библиотеки и решения пишутся не для собственного пользования. Существует люди которые видят и оценивают твой код. Точно так же будут люди которые будут использовать и работать с твоим кодом. И от того, как они оценят его и смогу быстро врубиться в него зависит долгота жизни этого кода. Я не один раз встречался с кодом который выбрасывался только из-за того, что в нем сам черт ногу сломит. Кстати, я встречался со случаями когда клиент просил показать код, чтобы просто оценить его качество.
Во-вторых, я заметил (и я думаю я не один), что существует зависимость от визуального качества кода, и количества ошибок который он несет. И к сожалению, я редко вижу код хорошего качества поскольку приходится обращать внимание не низкое качество визуализации кода.

С уважением, Gleb.

Здравствуйте, IT, Вы писали:

IT>1. Менеджмент. Давно известный факт, что программистами управляют люди, слабо представляющие как расшифровывается сама аббревиатура IT.
IT>2. Сертификация. Не в смысле экзамены типа от MS, которые может зазубрить по дампам любой индус. А в смысле, как у докторов — чтобы начать самостоятельно практиковать, нужно сдать экзамен своим практикующим коллегам.

Такой экзамен есть — вступительное interview. Без него трудно "практиковать"

И оно по-определению серьезней, чем сдача какого-нить кандидатского диссера — экзаменующий материально заинтересован в результате.

Здравствуйте, EM, Вы писали:

EM>Такой экзамен есть — вступительное interview. Без него трудно "практиковать"

И оно по-определению серьезней, чем сдача какого-нить кандидатского диссера — экзаменующий материально заинтересован в результате.

Нет, это не так по нескольким причинам.

Во-первых, умение ездить собеседнику по ушам — это такой же скил как и умение писать код. Наибольшего успеха добивается тот, кто умеет и то и другое. Так вот для интервьюирующего понять где правда, а где бла-бла-бла очень трудно. Причём чем на более судьбоносную позицию набирается человек, тем труднее это различить. Теперь берём в качестве примера большие консалтинги, такие как MS и IBM. Для них главное — срубить бабло и чем более профессионально их архитекторы умеют ездить по ушам кастомерам, тем для них лучше. Всё бы ничего, но потом эти же архитекторы начинают принимать технические решения, который порой принимают самые причудливые формы. Но прикрываясь брендом и вышеупомянутым скилом можно продавить абсолютно всё. Самое перчальное, что этих людей если и интервьюируют, то в основном менеджеры, а не технари, да и MS с IBM делают всё возможное чтобы этот процесс из контракта вовсе исключить. Вы разве не верите Microsoft? Сомневаетесь, что вы получите настоящий солюшин от IBM? А зачем вы тогда сюда пришли?

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

Третье. Необходимость качественного софта — это фикция, просто декларация. Качественный софт никому не нужен. Если ты группой в пять квалифицированных бойцов сделаешь за год качественную систему, то через год все эти пять бойцов будут сидеть и от безделья бацаться в офисе в Дум. Ещё через пол года их всех уволят вместе с их начальником. Если же на их место взять 20 посредственностей, то такой проект не закончится никогда, будут выходить патчи, заплатки, заявленные ранее фичи будут откладываться на потом и так до бесконечности. Но всем будет хорошо, 20 человек при деле и начальника никто не уволит.

В принципе, я не против всего этого, ради бога. Если MS с IBM по полной натягивют кастомеров, значит кастомеры получают от этого удовольствие. Если банки нанимают в IT департмент только индусов — это их дело. Начальники любят посредственностей — файн. Я хочу лишь одного — чтобы все эти бла-бла-бла-архитекторы и тяп-ляп-девелоперы не заблуждались считая себя экстроординаными личностями... и стояли по стойке смирно, когда с ними разговаривают старшие и более опытные товариши

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

Вот такая правда жизни

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

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

Здравствуйте, IT, Вы писали:

IT>Второй момент. Известный факт, что достаточно только одному индусу попасть на минимальски руководящую должность, как тут же вся структура под ним становится индусской. Если он идёт вверх по служебной лестнице, то за ним образуется характерный шлейф. Как ты думаешь, у тебя много шансов пройти в такую контору интервью?

И все таки я был прав. Был у тебя начальником индус!

Здравствуйте, Mika Soukhov, Вы писали:

IT>>Второй момент. Известный факт, что достаточно только одному индусу попасть на минимальски руководящую должность, как тут же вся структура под ним становится индусской. Если он идёт вверх по служебной лестнице, то за ним образуется характерный шлейф. Как ты думаешь, у тебя много шансов пройти в такую контору интервью?

MS>И все таки я был прав. Был у тебя начальником индус!

Почитай внимательнее, там же ясно написано, что если начальник индус, то шансов к нему попасть практически нет

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, EM, Вы писали:

EM>>Такой экзамен есть — вступительное interview. Без него трудно "практиковать"

И оно по-определению серьезней, чем сдача какого-нить кандидатского диссера — экзаменующий материально заинтересован в результате.

IT>Нет, это не так по нескольким причинам.

<... поскипаное с интересом прочитано ...>

IT>Третье. Необходимость качественного софта — это фикция, просто декларация. Качественный софт никому не нужен. Если ты группой в пять квалифицированных бойцов сделаешь за год качественную систему, то через год все эти пять бойцов будут сидеть и от безделья бацаться в офисе в Дум. Ещё через пол года их всех уволят вместе с их начальником. Если же на их место взять 20 посредственностей, то такой проект не закончится никогда, будут выходить патчи, заплатки, заявленные ранее фичи будут откладываться на потом и так до бесконечности. Но всем будет хорошо, 20 человек при деле и начальника никто не уволит.

Вот здесь, имхо, перегиб. Если пятеро бойцов создадут удачный продукт, который найдет широкое применение, то они будут загружены работой по сопровождению (не только в виде bug-fixing-а) и развитию этого продукта настолько, что все равно придется нанимать еще 20 посредственностей, "чтобы снаряды подносили". И есть шанс, что первоначальная команда распадется как раз из-за обилия монотонной и однообразной работы по добавлению очередной небольшой фичи.

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

<... поскипаное с интересом прочитано ...>

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, EM, Вы писали:

EM>Такой экзамен есть — вступительное interview. Без него трудно "практиковать"

И оно по-определению серьезней, чем сдача какого-нить кандидатского диссера — экзаменующий материально заинтересован в результате.

Просто для объективной оценки сказанного тобой: у тебя самого есть защищенный кандидатский дисcер?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, IT, Вы писали:

IT>>>Второй момент. Известный факт, что достаточно только одному индусу попасть на минимальски руководящую должность, как тут же вся структура под ним становится индусской. Если он идёт вверх по служебной лестнице, то за ним образуется характерный шлейф. Как ты думаешь, у тебя много шансов пройти в такую контору интервью?

MS>>И все таки я был прав. Был у тебя начальником индус!

IT>Почитай внимательнее, там же ясно написано, что если начальник индус, то шансов к нему попасть практически нет

Это при условии того, что индус пришел в начальство раньше. А если позднее, когда ты уже работал

Игорь, расскажи, как ты умеешь держать такую ненависть к азиатским народам и при этом работать в стране, которая не терпит рассковых предрассудков?

Если серьезно, то насчет десяти не уверен, но могу вспомнить несколько действительно важнейших:
1 — Действительно разумная логика.
Проблема заключается в написании такой программы. Ведь программа впринципе не может быть умнее своего создателя

, а зачастую она оказывается намного хуже. К тому же такая программа будет требовать выполнения ОГРОМНОГО количества операций по перекачке данных с одного угла в другой. И нужно так же очччень много памяти. От программы как таковой потребуется правильная организация данных, чтобы не хранить видеофрагменты целиком, а представлять их в ментальном виде, также нужно будет создать блоки, которые преобразовывали бы физический сигнал (звук, видео, осязание и т.д.) в объектный поток, так например человек помнит разговор не по звукам, а по словам, а уже потом, вспоминая, мозг идет по кучам ссылок, забирая по песчинке, чтобы в итоге получилось воспоминаение, имитирующее реальность. Мозгу проще создавать ссылки, каждая клетка имеет тысячи контактов с другими клетками (а то и больше) и в итоге может легко направить поток данных в другую клетку, добавив от себя еще частичку. Каждая клетка — небольшой примитивный процессор, а в ПК процессор один и в этом самая главная сложность. И последняя из основных трудностей реализации этой задачи — образование. Невозможно за пару часов вложить в разумное создание то, что другое не менее разумное создание изучало в течение десятилетий. Однако, стоит обучит всему одного "робота", как можно будет эти знания скопировать другим. Кстати, программа должна будет делать ошибки так, чтобы они никогда не вели к сбою и исправлялись моментально.
2 — сжатие данных
Тут нет предела совершенству. Раньше думали, что zip — это все, предел, пик (а может и не думали), а потом rar появился, который мог еще больше сжать zip файл. Уверен, появится метод еще лучше, который сможет любой rar сжать в несколько раз. Проблема в недостатке производительности и в нахождении и реализации хорошего алгоритма.
3 — Защита данных.
Как сказал Ньютон, на каждое действие есть свое противодействие. Так же и везде. И в защите — на всякую защиту найдется свой ключ. Раньше методы были примитивными — замена алфавита другими символами, перемена мест символов в алфавите, метод Вижинера (хотя это не такой уж примитивный метод, но и его сломали), добавление числа к числовому аналогу текста, гаммирование, и проч. и проч. и проч. Тем не менее теоретически можно взломать любую систему защиты, вопрос только во времени, которого всегда мало. Создать такой метод шифрования, который даже теоретически невозможно будет взломать — вот третья задача.
4 — Исправление багов и повышение производительности.
Чем больше программа, тем больше в ней ошибок, трат, недочетов и прочих недостатков, причем в геометрической прогрессии. Самым меньшим из всех зол является трата ресурсов, поэтому зачастую возникновение ошибок сводят к минимуму именно за счет "прожорливости" программы, создания огромных блоков отлавливания ошибок и т.д. Если бы windows был бы совершенством, он мог бы поместиться на дискету и выполняться в тысячи раз быстрее. Для каждой цели есть свои средства, так для повышения производительности используется ассемблер, но на нем оччччень долго и трудоемко написать большой проект. Для них используется например Си, но Си забирает очень много производительности. Для исправления багов используется время, но оно, как я уже говорил, всегда ограничено.

Пожалуй, это пока все, что могу вспомнить. Остальное мелочно и незначительно, на фоне этих проблем
Сюда я редко захожу, поэтому ответы лучше на мыло: killen_co@e-mail.ru

IT,

IT>Третье. Необходимость качественного софта — это фикция, просто декларация. Качественный софт никому не нужен. Если ты группой в пять квалифицированных бойцов сделаешь за год качественную систему, то через год все эти пять бойцов будут сидеть и от безделья бацаться в офисе в Дум. Ещё через пол года их всех уволят вместе с их начальником. Если же на их место взять 20 посредственностей, то такой проект не закончится никогда, будут выходить патчи, заплатки, заявленные ранее фичи будут откладываться на потом и так до бесконечности. Но всем будет хорошо, 20 человек при деле и начальника никто не уволит.

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

Зато клиент будет счастлив.

eao197,

IT>>Третье. [про бойцов]

E>[про сопровождение]

Как у нас с тобой мысли совпали...

Здравствуйте, Mika Soukhov, Вы писали:

MS>Это при условии того, что индус пришел в начальство раньше. А если позднее, когда ты уже работал

Игорь, расскажи, как ты умеешь держать такую ненависть к азиатским народам и при этом работать в стране, которая не терпит рассковых предрассудков?

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

... << RSDN@Home 1.1.4 beta 7 rev. 457>>

Здравствуйте, GlebZ, Вы писали:

V>>Отсюда имеем распространенные сейчас подходы, типа "писать надо так, чтобы и дебил разобрался". Мое имхо, далеко не обязательно так писать. Писать надо так, как это наиболее отвечает задаче. Уровень "дебила" тоже должен соответствовать задаче.
GZ>Вот с тем, что надо писать так, чтобы дебил разобрался, я абсолютно согласен.
GZ>Во-первых, библиотеки и решения пишутся не для собственного пользования. Существует люди которые видят и оценивают твой код. Точно так же будут люди которые будут использовать и работать с твоим кодом. И от того, как они оценят его и смогу быстро врубиться в него зависит долгота жизни этого кода. Я не один раз встречался с кодом который выбрасывался только из-за того, что в нем сам черт ногу сломит. Кстати, я встречался со случаями когда клиент просил показать код, чтобы просто оценить его качество.
GZ>Во-вторых, я заметил (и я думаю я не один), что существует зависимость от визуального качества кода, и количества ошибок который он несет. И к сожалению, я редко вижу код хорошего качества поскольку приходится обращать внимание не низкое качество визуализации кода.

Разве я сказал, что писать можно коряво? Речь шла о соответствии задачи и выбранного пути решения. Мне кажется, что ты озвучил одно из распространенных заблуждений. "Красивое оформление" и сложность кода — совершенно разные вещи. Они никак не связаны. Я полностью согласен с тем, что если код написан коряво, то его трудно читать. Код еще бывает сложно не читать, а "понять", для этого надо разбираться в технологии, которую этот код использует. Я против неоправданного примитивизма, который сейчас завоевывает все больше сторонников. Я видел достаточно проектов, которые были написаны "красиво" и легкочитаемо. Но сама "красивая" архитектура никак не соответствовала прикладной области. (например — реализация парсеров или автоматных моделей "в лоб"). Зато любой разбирался. Вот тебе красота ценой многократного проседания эффективности.

Здравствуйте, Mika Soukhov, Вы писали:

MS>Это при условии того, что индус пришел в начальство раньше. А если позднее, когда ты уже работал

Игорь, расскажи, как ты умеешь держать такую ненависть к азиатским народам и при этом работать в стране, которая не терпит рассковых предрассудков?

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

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

Здравствуйте, L.C.R., Вы писали:

LCR>Возможно это от плохого настроения, но вывод неправильный. Из того что 5+1 бойцов сделают качественную систему не следует что через полтора года всех уволят. Заплатки, патчи и прочие диффы нужны и затем, чтобы ответить на постоянно меняющиеся требования к функционалу системы. Процесс разработки системы — это именно процесс — потенциально бесконечен. Ты это сам прекрасно знаешь.

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

LCR>Так что бойцы без работы не останутся

Бойцы и так без работы не остануться

LCR> Зато клиент будет счастлив.

Вот это самый неопределённый момент. Самый простой способ сделать человека счастливым — это сначала отнять у него что-нибудь, а потом ему это вернуть. Проверено на практике миллион раз. Скорее всего группа из посредственностей будет радовать клиента гораздо чаще. А какая радость, сам подумай, будет от незаметно работающего без глюков софта? Знаешь как называют людей, которые ещё на стадии обсуждения говорят, что эта идея работать не будет или будет такие-то проблемы? Точно — troublemaker. А людей которые в последнюю минуту самоотверженно решают подобные проблемы? Правильно — hero. И что странно, практически никто не вспоминает, что эти проблемы были порождены ими же самими или при их попустительстве. Главное — результат.

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

Здравствуйте, flax, Вы писали:

F>1) Семантика ( смысловое описание информации)
F>2) AI (диллема между символами и мыслью ), а если вспомнить, что @"AI — это то, что сейчас нет",

Есть еще и другое определение AI

Искусственный интеллект — это то, чем занимаются, когда не хватает естественного.

Здравствуйте, Mika Soukhov, Вы писали:

MS>Это при условии того, что индус пришел в начальство раньше. А если позднее, когда ты уже работал

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

... IN
...  DO
    S = ...

По любимым кейвордам и именам переменных у низкоквалифицированных девелоперов.

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

IT,

IT>Если бойцы напишут правильную систему, то на её сопровождение нужен будет только один из них, остальные будут гонять в дум. Чтобы занять на сопровождении их всех, надо "очень профессионально" продумать это всё с самого начала.
Как то у тебя всё наизнанку вывернулось. Занять работой — не проблема. Сложность программного обеспечения не ограничена сверху. А вот ресурсы (в т.ч. и человеческие) ограничены.

IT>Вот это самый неопределённый момент. Самый простой способ сделать человека счастливым — это сначала отнять у него что-нибудь, а потом ему это вернуть. Проверено на практике миллион раз. Скорее всего группа из посредственностей будет радовать клиента гораздо чаще. А какая радость, сам подумай, будет от незаметно работающего без глюков софта?
Всё правильно, без несчастья счастья не познать. Но в данном случае опять вывод вывернут наизнанку. Всё ведь познаётся в сравнении... На моей памяти был следующий случай:

Клиент А покупает систему С1. По крайней мере раз в неделю клиент пользуется услугами (платными) вызова мальчиков. Мальчики чего-то чинят, но на следующей неделе опять что-то ломается, и приходится опять вызывать мальчиков. Минуты удовлетворённого облегчения сменялись досадой.

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

И теперь клиента А колбасой не заманишь на С1. Кроме всего прочего, был ещё один побочный эффект что А рекомендовал систему С2 своему другу Б. А как известно, рекомендация — лучшая реклама.

Группа посредственностей будет капать на мозг гораздо чаще — не радовать.

IT>Знаешь как называют людей, которые ещё на стадии обсуждения говорят, что эта идея работать не будет или будет такие-то проблемы? Точно — troublemaker.
Имхо "Пророки". Правильно подмечено — они никогда не пользовались благоговением народа.

IT>А людей которые в последнюю минуту самоотверженно решают подобные проблемы? Правильно — hero. И что странно, практически никто не вспоминает, что эти проблемы были порождены ими же самими или при их попустительстве. Главное — результат.
Часто таких героев называют "козлами". С соответсвующим уважением и почётом.

Да и вообще, вся индустрия IT — это борьба со своими же ветряными мельницами.

Здравствуйте, IT, Вы писали:

Все верно, но в условиях высокой конкуренции не работает.

У клиентов тоже не лохи сидят. Хороших айтишников со стороны клиента тоже тяжко найти, но они есть. В следующий тендер героев турнут.

С уважением, Gleb.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

Здравствуйте, Killen, Вы писали:

K>Если серьезно, то насчет десяти не уверен, но могу вспомнить несколько действительно важнейших:
K>1 — Действительно разумная логика.
При появлении способности к абстракции сразу появится способность к ошибке.

K>2 — сжатие данных
K> Тут нет предела совершенству. Раньше думали, что zip — это все, предел, пик (а может и не думали), а потом rar появился, который мог еще больше сжать zip файл. Уверен, появится метод еще лучше, который сможет любой rar сжать в несколько раз. Проблема в недостатке производительности и в нахождении и реализации хорошего алгоритма.
Zip и Rar — одинаковые LZW алгоритмы. Если хочешь посмотреть на настоящее качество сжатия, надыбай ha. Жутко тормозной, но зато круто сжимал. Не думаю что это важная и нерешенная задача.

K>3 — Защита данных.
K> Как сказал Ньютон, на каждое действие есть свое противодействие. Так же и везде. И в защите — на всякую защиту найдется свой ключ. Раньше методы были примитивными — замена алфавита другими символами, перемена мест символов в алфавите, метод Вижинера (хотя это не такой уж примитивный метод, но и его сломали), добавление числа к числовому аналогу текста, гаммирование, и проч. и проч. и проч. Тем не менее теоретически можно взломать любую систему защиты, вопрос только во времени, которого всегда мало. Создать такой метод шифрования, который даже теоретически невозможно будет взломать — вот третья задача.
Есть абсолютно защищенные шифры. Только это никому не нужно (особенно государству). Поэтому опять -1.
K>4 — Исправление багов и повышение производительности.
K> Чем больше программа, тем больше в ней ошибок, трат, недочетов и прочих недостатков, причем в геометрической прогрессии. Самым меньшим из всех зол является трата ресурсов, поэтому зачастую возникновение ошибок сводят к минимуму именно за счет "прожорливости" программы, создания огромных блоков отлавливания ошибок и т.д. Если бы windows был бы совершенством, он мог бы поместиться на дискету
Windows на дискетке? А это кому-то надо? Мне сейчас пару гиг на винды не жалко. Мне значительно важнее не сколько весит, а что она делает.

K>и выполняться в тысячи раз быстрее.
Тормозит в основном не Windows. Тормозят программы написанные под Windows(Unix, Linux и т.д). Может просто записать как нерешенную проблему как сделать так, чтобы любая программа выполнялась за 1 такт?

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

K>Для них используется например Си, но Си забирает очень много производительности.
Очень много производительности? Ну-ну. Не читайте советских газет 15 летней давности.
K>Пожалуй, это пока все, что могу вспомнить. Остальное мелочно и незначительно, на фоне этих проблем
Все что написал, это не проблемы.
K>Сюда я редко захожу, поэтому ответы лучше на мыло: killen_co@e-mail.ru
А это здесь не принято. Если для общества, так для общества. Если личное(ну например личный спам), вот тогда на мыло.

С уважением, Gleb.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

Здравствуйте, GlebZ, Вы писали:

GZ>Zip и Rar — одинаковые LZW алгоритмы. Если хочешь посмотреть на настоящее качество сжатия, надыбай ha. Жутко тормозной, но зато круто сжимал. Не думаю что это важная и нерешенная задача.

По-моему, ты не прав. Алгоритмы разные. Zip — это как минимум еще и алгоритм Deflate, который != LZW.

GZ>Есть абсолютно защищенные шифры. Только это никому не нужно (особенно государству). Поэтому опять -1.

Как известно из курса математики, таких шифров ровно один — шифр Шеннона (шифр с длиной ключа = длине текста). При длине ключа < длине текста шифр абсолютно защищенным не является.

GZ>Windows на дискетке? А это кому-то надо? Мне сейчас пару гиг на винды не жалко. Мне значительно важнее не сколько весит, а что она делает.

K>>и выполняться в тысячи раз быстрее.
GZ>Тормозит в основном не Windows. Тормозят программы написанные под Windows(Unix, Linux и т.д). Может просто записать как нерешенную проблему как сделать так, чтобы любая программа выполнялась за 1 такт?

Размер, кстати, не в последнюю очередь влияет на тормоза. Размер = Скорость * Время

Здравствуйте, GlebZ, Вы писали:
K>>Сюда я редко захожу, поэтому ответы лучше на мыло: killen_co@e-mail.ru
GZ>А это здесь не принято. Если для общества, так для общества. Если личное(ну например личный спам), вот тогда на мыло.

Здравствуйте, WFrag, Вы писали:

WF>По-моему, ты не прав. Алгоритмы разные. Zip — это как минимум еще и алгоритм Deflate, который != LZW.
Ты хотел сказать плюс Haffman. Все алгоритмы и rar и zip и arj и еще большой кучи которая называется основными архиваторами основаны на LZW(LZ) алгоритмах или им подобных. Они различаются небольшими довесками(различные haffman'ы и подобное) и оптимальной работой со словарем. То есть, их можно объединить как алгоритмы LZW(LZ).
Существуют алгоритмы на основе ha. Это было значительно покруче, но на чем было основано уже не помню. Из неточных — jpeg(MPEG). Про RLE как архиваторе лучше не поминать.

Поэтому сравнение rar и zip — во первых несовсем корректно как большим развитием технологий. А во вторых, этот вопрос значительно легче решается увеличением пропускной способностью канала.

GZ>>Есть абсолютно защищенные шифры. Только это никому не нужно (особенно государству). Поэтому опять -1.

WF>Как известно из курса математики, таких шифров ровно один — шифр Шеннона (шифр с длиной ключа = длине текста). При длине ключа < длине текста шифр абсолютно защищенным не является.

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

WF>Размер, кстати, не в последнюю очередь влияет на тормоза. Размер = Скорость * Время

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

С уважением, Gleb.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

Здравствуйте, IT, Вы писали:

MS>>Это при условии того, что индус пришел в начальство раньше. А если позднее, когда ты уже работал

Игорь, расскажи, как ты умеешь держать такую ненависть к азиатским народам и при этом работать в стране, которая не терпит рассковых предрассудков?

IT>Кто тебе сказал что я испытываю к индусам ненависть? К тому же испытвать что-либо к индусам или к их проф пригодности — это разные вещи, не находишь?

Видать не доводилось тебе с информиксом семеркой работать

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, Sinclair, Вы писали:

S>индус — это не национальность.
S>Это аббревиатура от
S>

S>... IN
S>...  DO
S>    S = ...
S>

S>По любимым кейвордам и именам переменных у низкоквалифицированных девелоперов.
Тогда уж "in DOS". По имени любимой ОС.

GZ>При появлении способности к абстракции сразу появится способность к ошибке.

И ты не считаешь это основной проблемой? Я, знач, не прав? Ну-ну.
GZ>Zip и Rar — одинаковые LZW алгоритмы. Если хочешь посмотреть на настоящее качество сжатия, надыбай ha. Жутко тормозной, но зато круто сжимал. Не думаю что это важная и нерешенная задача.

А ты в этом уверен? Всегда можно найти что-то лучшее (и алгоритм тоже). В том числе и быстрый (при той же степени сжатия).
GZ>Есть абсолютно защищенные шифры. Только это никому не нужно (особенно государству). Поэтому опять -1.
Не, всегда есть люди, которые хотят защитить свою инфу на вечно. Простые юзеры не в счет. А наше государство действительно в этом не нуждается. Но это не значит, что эта проблема не существенна.
GZ>Windows на дискетке? А это кому-то надо? Мне сейчас пару гиг на винды не жалко. Мне значительно важнее не сколько весит, а что она делает.

А я говорю, что при той же функциональности и на дискету.
GZ>Тормозит в основном не Windows. Тормозят программы написанные под Windows(Unix, Linux и т.д). Может просто записать как нерешенную проблему как сделать так, чтобы любая программа выполнялась за 1 такт?

А ведь я серьезно. И насчет того, кто тормозит — ты ОЧЕНЬ ошибаешься. Если сравнить, сколько тактов тратит на себя виндовоз и сколько он бы мог тратить при более-менее качественном коде, то

GZ>Ага, и пишут программы учитывая логику кэширования процессором памяти и очереди комманд.

Хоть в чем то согласен со мной...
GZ>Очень много производительности? Ну-ну. Не читайте советских газет 15 летней давности.
Сам пошевели чем-нибудь, за сколько тактов выполнит цель программа на Си и на асме.
GZ>Все что написал, это не проблемы.
Сам такой. И столько же!
GZ>С уважением, Gleb.
Тебе туда же

Здравствуйте, L.C.R., Вы писали:

LCR>

LCR>Клиент А покупает систему С1. По крайней мере раз в неделю клиент пользуется услугами (платными) вызова мальчиков. Мальчики чего-то чинят, но на следующей неделе опять что-то ломается, и приходится опять вызывать мальчиков. Минуты удовлетворённого облегчения сменялись досадой.

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

LCR>И теперь клиента А колбасой не заманишь на С1. Кроме всего прочего, был ещё один побочный эффект что А рекомендовал систему С2 своему другу Б. А как известно, рекомендация — лучшая реклама.

Знаешь, откуда в твоей сказке взялся хэппи-энд? От предварительного общения заказчика с системой C1. Если бы сразу неискушенному заказчику поставили систему С2, то начались бы хныканья:
— а почему так долго, что тут делать-то?
— а чего так дорого?
— а почему мы должны перестраивать свои процессы? Отчего вы решили, что так эффективней???
— и вообще нам все время кажется, что вас нас наеживаете. Мы же видим, что все, что вы делаете — делается легко (

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

И этот список можно продолжать до бесконечности.

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

(опять же, если уверены в себе)

Здравствуйте, Killen, Вы писали:
Рекомендую все же ознакомиться с предметом. При данном уровне владения подойдут не слишком замороченные научно-популярные книги, типа "Знакомьтесь, компьтер", М. "Мир", 1991.
Затем можно начать задавать вопросы в форумы. Тогда можно ожидать постепенного повышения уровня квалификации до такого, что твои комментарии перестанут смешить людей.

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

Здравствуйте, vdimas, Вы писали:

V>Знаешь, откуда в твоей сказке взялся хэппи-энд? От предварительного общения заказчика с системой C1. Если бы сразу неискушенному заказчику поставили систему С2, то начались бы хныканья:
V>- а почему так долго, что тут делать-то?
V>- а чего так дорого?
V>- а почему мы должны перестраивать свои процессы? Отчего вы решили, что так эффективней???
V>- и вообще нам все время кажется, что вас нас наеживаете. Мы же видим, что все, что вы делаете — делается легко (

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

а потом заказчику втирают о преимуществах системы С1, и он радостно бежит ее покупать

Здравствуйте, GlebZ, Вы писали:

IT>>Давно известный факт, что программистами управляют люди, слабо представляющие как расшифровывается сама аббревиатура IT.
GZ>Игорь Ткачев?

Кто есть такой господин Игорь Ткачев?

ntr soft: www.dkdens.narod.ru :: giref: www.retroforth.org/board/index.php?topic=177.0

Здравствуйте, DJ KARIES, Вы писали:

DK>Здравствуйте, GlebZ, Вы писали:

IT>>>Давно известный факт, что программистами управляют люди, слабо представляющие как расшифровывается сама аббревиатура IT.
GZ>>Игорь Ткачев?

DK>Кто есть такой господин Игорь Ткачев?
Ты и есть тот управленец о котором он писал в исходном сообщенииRe: 10 самых важных нерешенных задач IT?

(см автора этого сообщения).

С уважением, Gleb.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

IT> Главное — результат.

здесь

Здравствуйте, GlebZ, Вы писали:

GZ>Ты и есть тот управленец о котором он писал в исходном сообщенииRe: 10 самых важных нерешенных задач IT?

(см автора этого сообщения).

Начинаю терять популярность в народных массах. Уже не каждый встречный программист узнаёт меня в лицо. Пора по серьёзному возвращаться на RSDN

... << RSDN@Home 1.1.4 beta 7 rev. 447>>

Здравствуйте, IT, Вы писали:

IT>Начинаю терять популярность в народных массах. Уже не каждый встречный программист узнаёт меня в лицо. Пора по серьёзному возвращаться на RSDN

Вай, мне таки надо почаще тыкать в профиль.
Иль разработчикам КЫВТ РЩЬУ писать помимо ника настоящее имя в миру. Для саморазвития таких, как я.
Однако.

ntr soft: www.dkdens.narod.ru :: giref: www.retroforth.org/board/index.php?topic=177.0

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, DJ KARIES, Вы писали:

DK>>Здравствуйте, GlebZ, Вы писали:

IT>>>>Давно известный факт, что программистами управляют люди, слабо представляющие как расшифровывается сама аббревиатура IT.
GZ>>>Игорь Ткачев?

DK>>Кто есть такой господин Игорь Ткачев?
GZ>Ты и есть тот управленец о котором он писал в исходном сообщенииRe: 10 самых важных нерешенных задач IT?

(см автора этого сообщения).

IT == Information Technologies

Или где?

ntr soft: www.dkdens.narod.ru :: giref: www.retroforth.org/board/index.php?topic=177.0

От ламера слышу!

Может эта:
Тараканы исчезли ?

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, poilk, Вы писали:

P>Пару лет назад слышал, что главной задачей IT (не программирования!) является "достижение трех Т":

Полагаю лет 10 назад главной задачей было достижение трех "Г"

Здравствуйте, olegkr, Вы писали:

>Полагаю лет 10 назад главной задачей было достижение трех "Г"

А 20 лет назад вроде как было трёх М

	От:	descartes
	Дата:	26.08.04 09:41
	Оценка:	1 (1)

	От:	Dimonka
	Дата:	26.08.04 09:47
	Оценка:	+2 -6

	От:	descartes
	Дата:	26.08.04 10:10
	Оценка:

	От:	flax
	Дата:	26.08.04 10:45
	Оценка:

	От:	descartes
	Дата:	26.08.04 11:11
	Оценка:

От:	lextasy	www.mira-tech.com.ua
Дата:	26.08.04 16:56
Оценка:	6 (1)

От:	aero	http://www.linkedin.com/profile/view?id=71131006&trk=tab_pro
Дата:	27.08.04 10:52
Оценка:

От:	S.Yu.Gubanov	http://sergey-gubanov.livejournal.com/
Дата:	27.08.04 15:41
Оценка:	1 (1)

	От:	Andrew Simontsev
	Дата:	28.08.04 04:12
	Оценка:

	От:	VVB16
	Дата:	28.08.04 09:44
	Оценка:	18 (1) +2 -1

От:	jazzer	Skype: enerjazzer
Дата:	03.09.04 17:22
Оценка:

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	22.03.05 14:01
Оценка:

От:	Gaperton	http://gaperton.livejournal.com
Дата:	22.03.05 14:39
Оценка:	+5

От:	IT	linq2db.com
Дата:	23.03.05 14:38
Оценка:	71 (8) +2

От:	L.C.R.	lj://_lcr_
Дата:	20.05.05 20:06
Оценка:

	От:	AndreyFedotov
	Дата:	30.08.04 07:58
	Оценка:

	От:	Аноним
	Дата:	30.08.04 11:53
	Оценка:

	От:	Andy-C
	Дата:	04.09.04 04:24
	Оценка:

	От:	Andy-C
	Дата:	04.09.04 04:29
	Оценка:	+2

От:	Mika Soukhov	Stock#
Дата:	21.05.05 21:17
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	22.05.05 06:43
Оценка:	1 (1)

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	22.05.05 19:49
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	23.05.05 06:20
Оценка: