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

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

M>>>>С одной стороны виноват тот же С++. Потому что legacy и тот же ворд нет смысла переписывать с нуля
M>>>>С другой стороны — а что такое десктопный софт?

H>>>Гуглохром например, и легаси нету и работает на десктопе

G>>У гугла столько ресурсов, что они могуть ОС в машинных кодах написать.
G>>И если им будет надо — напишут.

H>У МС ресурсов не меньше, чего же легаси свое не перепишут на шарпе? Глядишь и сэкономят еще
Про это уже говорили, вроде даже в этой теме.

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

E>С подобным кодом раньше не сталкивался, обычно в таких случаях вместо ссылки просто создают локальный объект )
Чтобы создать локальный объект, надо знать его тип. А он может определяться, например, типом аргументов перегруженной порождающей функции...

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

E>Верным остаётся одно: на любой дурацкий синтетический тест найдёт столь же дурацкий аллокатор, который этот тест "уделает".
Так тест и был для стандартного аллокатора.
При страндартном аллокаторе операции выделения и освобождения памяти оказались не такими дешевыми как их считали некоторые.
Кроме этого тест и е должен был ничего показать.

E>Лично мне комфортно от того, что можно пробовать строить различные архитекутры, не думая изначально о том, сколько каких мелких объектов где выделяется, потому что в случае чего можно расчехлить тяжёлую артиллерию.
Отличная идея. GC как раз позволяет не думать о выделении и освобождении памяти вообще.
Если производительность окажется недостаточной то надо смотреть причны и бороться с ними.
Причем чаще всего прчиной оказывается применение неподходчщего алогоритма. Очень редко приходится нарываться на ситуацию когда низкая производительность вызвана особенностями платформы.

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

E>>С того, что знаю примеры быстрого кода, который сразу так и разрабатывался, как быстрый...
G>И я знаю, но обратных примеров больше.
Плохих программистов вообще меньше, чем хороших...
Да и дантистов, например, тоже

G>Ну это смотря что понимать под качеством проектирования.
G>Гуглите "premature optimization".
Это другое. Обычно этим словом обозначают желание экономить на спичках пока ещё не решено нужен ли костёр, так скажем. Но если ты, например, решил писать спел-чекер, то ответить на вопросы в какой структуре данных ты будешь хранить словарь и будет ли словарь словоформенным или полексемным, стоит ответить ещё на этапе проектирования

G>Это я неверно выразился. Вместо быстрый надо читать "оптимизированный".
Я, видимо, плохо понимаю смысл "оптимизированный". Видимо это какой-то способ портить код?

G>Хотя надо было добавить что использовать безопасным образом. Я с тех пор как изучил C++ в полной мере старался не писать кода, который передает указатели на стек куда-то.
IMHO, это догма. Надо избегать переполнений буферов, где бы они не были аллокированы. И С++ предоставляет широкие возможности для этого. Например тот класс CAutoBuffer, который я тут показывал...

G>Например мне удалось жа полчаса объяснить человек программу на F# на два экрана, при том что он F# не знал.
G>Аналогичная программа на C++ занимала бы больше и была бы гораздо более сложна в понимании.
Возможно. Но F# -- это всё равно маргинальщина. Кроме того, я не понимаю, что значит "объяснить". Он бы после твоих объяснений смог бы эту прогу поддерживать? В любом случае это тут офтоп.

G>Делать процедурную обвязку вокруг ОО-кода не хочется, тем более обычно задача низкоуровневого кода заключается в математике.
Не знаю, что такое "низкоуровневый код" В моих программах мотор намного сложнее оболочки. Возможно ты с моторами, кроме СУБД просто не сталкивался.

E>>Пока не нужна память и скорость -- да. Например для GUI ХиндиС -- это просто находка!
G>Ну а доказательства тезиса будут?
G>Или опять по принципу — чем больше повторить, там больше правда.
Доказательства чего? Что для GUI находка? Это моё мнение.
А если речь идёт об обработке большого количества данных, то я не знаю успешных примеров моторов на ХиндиС...

G>Ну и как AI делать?
В смысле "как?" Брать и делать...
G>Мой знакомый AI занимается, вообще на лиспе пишет.
На лиспе хорошо делать прототипирование в некоторых задачах AI. Правда удобно. Я как-то возился и с лиспом. Но большой скорости из всех этих списков, IMHO, не выжать -- слишком универсальные

G>Если данные лежат в субд и имеют реляционную природу, то конечно субд. И интерфейс отлично будет.
G>А если нет — то придется код писать и уж точно не на С++.
При веди пример данных, о которых речь...

G>А где еще нужна таки вычмощь кроме математических алгоритмов (физика, графика, видео) ?
Есть то, что я бы не назвал "математические алгоритмы", хотя, строго говоря, все алгоритмы "математические"...
Скажем нейронная сеть -- это мат. алгоритм? А поисковая машина?
Или, например, сжималка памяти на лету, позволяющая увеличить видимый RAM?

G>Все задачи которые требуют не только процессора, но и активно работы с другими ресурсами компьютера (память, диск, сеть), а также требующие высокую степень параллельности обработки лучше уже писать на .NET.

Про параллельность не уверен, есть более специальные средства, хотя я сторонник наоборот, крупной гранулярности, если возможно, и тогда язык не особо важен. Про сеть -- вообще всё пофиг, IMHO, если это не TCP/IP стек А если он -- то не ХиндиС, однозначно, IMHO. Работа с диском -- это известный тормоз и не ясно какая разница, какой язык, опять же... Про активную работу с памятью (что бы это не значило) я тоже как-то сильно сомневаюсь. И С и С++ позволяют отрегулировать эту "активную работу" намного тоньше...

Вот, например, хочу я разработать search engine. Типа как у google. Чтобы скармливать ему документы, а оно их разбивало на слова, как-то там индексировало, а потом отвечало на вопросы вроде: "найди мне все документы, где слова "мама" отстоит от слова "моя" не дальше двух слов, стоят в одном предложении и согласованы по грамматическому значению".
Ну и пополняем, например, на одной нити, а ищем параллельно. И что, думаешь на C# хорошо получится?
AFAIK, все такие движки на плюсах чего-то пишут...

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

E>Лично мне комфортно от того, что можно пробовать строить различные архитекутры, не думая изначально о том, сколько каких мелких объектов где выделяется, потому что в случае чего можно расчехлить тяжёлую артиллерию. Кому-то такой подход кажется нормальным, кому-то нет. Но по крайней мере есть выбор. Хотя наличие выбора может кому-то тоже показаться плохой идеей. ))

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

И вот ты разрабатываешь, разрабатываешь, и упираешься. С С++ у тебя будет ещё один шаг, практически до субмакисмльного быстродействия, а в GC архитектуре ты остановишься на просто большом быстродействии и всё. И в результате ракета у амеров летает на 250, а у РФ на 350 км... И привет арифметике...

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

VD>Почему всем будет смешно, если им расскажут о подмастерьи физика, химика или врача. Так почему же подмастерья программистов обсуждаются серьезно?
Ну посмейся. Слова "аспирант", "ординатура" и "научный руководитель диплома" и "производственная практика" для тебя новы?

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

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

IMHO, такая ситуация, когда для ускорения надо менять алгоритм, часто говорит о том, что проектировали плохо.
Часто можно сразу выбирать оптимальный алгоритм. Не понятно зачем пессимизировать-то? В большинстве задач оптимальные алгоритмы давно уже известны...

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

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

G>>Исторические причины в крупных организациях играют немалую роль.

E>Странно у тебя выходит. Типа ХиндиС для десктопа подходит, но в каждом конкретном случае что-то ему мешает...
Я уже писал:
1)кодовая база, переписывание с нуля даже небольшого проекта дает только риски и нифига прибыли.
2)программистска база — если есть команда, пишущая на С++, то они не станут на следующий день писать на C#
3)Слабая изменчивость требований, требовния для бизнес-софта меняются очень быстро, бывает что софт перестает отвечать требованиям бизнеса еще до установки клиенту. Десктопный софт такой изменчивости не подвержен, в основном идет добавление по-немногу фич, улучшение юзабилити, правка багов, при этом всем надо сохранять обратную совместимость.


E>IMHO, есть огромный сегмент ПО -- это ПО, которое пишут по случаю и как можно быстрее.
E>Раньше это делали на VB, теперь делают на ХиндиС. В целом это огромный шаг вперёд!!!
Раньше и сейчас это делают на скриптовых языках.

E>Но в своей нише выбор уже часто предопределён. Если тебе надо пять COM-верверов заставить хитро взаимодействовать меду собой, то ясно что не на С++ это удобно. А если ты хочешь написать распознавалку голоса, чтобы оно могло писать под твою диктовку, то ясно, что не C#, твой выбор...
Это еще надо обосновать.

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

E>Так что экономичность программ -- это большой плюс для десктопа
Это вы так думаете.
Можете привести пример когда именно быстродействие становилось конкурентным преимуществом. А учитывая что .NET не сильно по быстродействию отличается от C++, то ваш тезис кажется неверным.

E>а скорость разработки, на уровне "надо ещё вчера" -- нет...
При разработке для заказчика только так и можно работать.
Причем заказной софт — гораздо большая часть разработки.

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

E>>а скорость разработки, на уровне "надо ещё вчера" -- нет...
G>При разработке для заказчика только так и можно работать.
IMHO, при разработке для заказчика надо работать так, как надо заказчику

G>Причем заказной софт — гораздо большая часть разработки.
Ну и что? Индусов больше всего, потом наверное код на коболе идёт...
ХиндиС -- тут очень даже к месту. Если всё, кроме сроков разработки и реакции на изменения требований, не важно, то C# -- твой выбор. Я с этим и не спорю.
И проектировать тоже тогда не надо, потому что время терять. Надо писать как можно быстрее, а если потом заказчик, или тот, кто думает, что знает нужды заказчика, это дело завернёт, попрофилять и допилить как-то побыстрее...

Всё верно. Да так и надо вести разработку в таких условиях!
Но это один такой специфический подход к программированию.

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

А ещё есть разработка технологий и моторов всяких. Скажем сидят люди из 17-й версии СУБД делают 18-ю. Там своя специфика, и C# ещё меньше в тему. Ну и т. д.
Или, наоборот, сидят люди и пишут то, что никто ещё не писал и как это писать не знает. Тоже интересная, и тоже особенная работа...

При этом все эти активности -- программирование. Но они все разные. И кому-то нравится одно, а кому-то другое...

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

G>>Ну это смотря что понимать под качеством проектирования.
G>>Гуглите "premature optimization".
E>Это другое. Обычно этим словом обозначают желание экономить на спичках пока ещё не решено нужен ли костёр, так скажем. Но если ты, например, решил писать спел-чекер, то ответить на вопросы в какой структуре данных ты будешь хранить словарь и будет ли словарь словоформенным или полексемным, стоит ответить ещё на этапе проектирования
Я в спелл-чекерах не силен, но я так понимаю что имеет ввиду два принципиально разных алгоритма. Тогда да, выбор надо делать заранее.
Только не стоит в это месте говорить "структура данных". Именно структура может измениться до неузнаваемости при эволюционном дизайне.

G>>Это я неверно выразился. Вместо быстрый надо читать "оптимизированный".
E>Я, видимо, плохо понимаю смысл "оптимизированный". Видимо это какой-то способ портить код?
Обычно неалгоритмическая оптимизация зкалючается в расстановке хаков с целью повысить быстродействие. Эти хаки очень отрицательно сказываются.

G>>Например мне удалось жа полчаса объяснить человек программу на F# на два экрана, при том что он F# не знал.
G>>Аналогичная программа на C++ занимала бы больше и была бы гораздо более сложна в понимании.
E>Возможно. Но F# -- это всё равно маргинальщина. Кроме того, я не понимаю, что значит "объяснить". Он бы после твоих объяснений смог бы эту прогу поддерживать? В любом случае это тут офтоп.
Нет, он смог объяснить её преподу так что тот понял и еще на вопросы ответил, короче получил зачет.

G>>Делать процедурную обвязку вокруг ОО-кода не хочется, тем более обычно задача низкоуровневого кода заключается в математике.
E>Не знаю, что такое "низкоуровневый код" В моих программах мотор намного сложнее оболочки. Возможно ты с моторами, кроме СУБД просто не сталкивался.
А что за программы? С таким бешенным мотором.

E>>>Пока не нужна память и скорость -- да. Например для GUI ХиндиС -- это просто находка!
G>>Ну а доказательства тезиса будут?
G>>Или опять по принципу — чем больше повторить, там больше правда.
E>А если речь идёт об обработке большого количества данных, то я не знаю успешных примеров моторов на ХиндиС...
А я не знаю примеров где они нужны были. Приведите парочку.

G>>Если данные лежат в субд и имеют реляционную природу, то конечно субд. И интерфейс отлично будет.
G>>А если нет — то придется код писать и уж точно не на С++.
E>При веди пример данных, о которых речь...
Трейдерские системы, накопление статистики по мере прихода информации.

G>>А где еще нужна таки вычмощь кроме математических алгоритмов (физика, графика, видео) ?
E>Есть то, что я бы не назвал "математические алгоритмы", хотя, строго говоря, все алгоритмы "математические"...
E>Скажем нейронная сеть -- это мат. алгоритм?
Нейронная сеть — да, там перемножение матриц и обратное распространение ошибкм.
E>А поисковая машина?
Чего ищет?

E>Или, например, сжималка памяти на лету, позволяющая увеличить видимый RAM?

Что-то на грани фантастики.

G>>Все задачи которые требуют не только процессора, но и активно работы с другими ресурсами компьютера (память, диск, сеть), а также требующие высокую степень параллельности обработки лучше уже писать на .NET.

E>Про параллельность не уверен, есть более специальные средства, хотя я сторонник наоборот, крупной гранулярности, если возможно, и тогда язык не особо важен. Про сеть -- вообще всё пофиг, IMHO, если это не TCP/IP стек А если он -- то не ХиндиС, однозначно, IMHO. Работа с диском -- это известный тормоз и не ясно какая разница, какой язык, опять же...
Видимо вы не писали таких программ. Разница есть.
E>Про активную работу с памятью (что бы это не значило) я тоже как-то сильно сомневаюсь. И С и С++ позволяют отрегулировать эту "активную работу" намного тоньше...
Вот этого как раз не надо. "Тонкое" управление обычно выливается в очень большие сроки разработки.
Нужны простые способы абстрагироваться от этого управления.

E>Вот, например, хочу я разработать search engine. Типа как у google. Чтобы скармливать ему документы, а оно их разбивало на слова, как-то там индексировало, а потом отвечало на вопросы вроде: "найди мне все документы, где слова "мама" отстоит от слова "моя" не дальше двух слов, стоят в одном предложении и согласованы по грамматическому значению".
E>Ну и пополняем, например, на одной нити, а ищем параллельно. И что, думаешь на C# хорошо получится?
E>AFAIK, все такие движки на плюсах чего-то пишут...
Ну если учесть все аспекты хранения и обработки индексов, распараллеливания вычислений и балансировки входящей нагрузки, то думаю что на .NET получится получше.

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

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

E>>Лично мне комфортно от того, что можно пробовать строить различные архитекутры, не думая изначально о том, сколько каких мелких объектов где выделяется, потому что в случае чего можно расчехлить тяжёлую артиллерию. Кому-то такой подход кажется нормальным, кому-то нет. Но по крайней мере есть выбор. Хотя наличие выбора может кому-то тоже показаться плохой идеей. ))

E>Тут есть ещё одна тонкость. спец. аллокатор таки эффективнее для своей задачи. В этом нет ничего удивительного, так как специализированные решения часто лучше обобщённых
E>А дальше возникает вопрос насколько тебе это надо. Если ты шахматные часы пишешь, то и фиг с ним. А если, скажем, делаешь ты С-300, и надо, чтобы система управления быстрее чесалась, так как чем быстрее и точнее она чешется, тем на дальше хватает изделию топлива. И тем больше есть времени, соответственно, "на выстрелить"...

E>И вот ты разрабатываешь, разрабатываешь, и упираешься. С С++ у тебя будет ещё один шаг, практически до субмакисмльного быстродействия, а в GC архитектуре ты остановишься на просто большом быстродействии и всё. И в результате ракета у амеров летает на 250, а у РФ на 350 км... И привет арифметике...

Зато у амеров этих ракет хоть попой кушай

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

Но для этиъ целей С++ точноне подойдет.

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

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

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

E>IMHO, такая ситуация, когда для ускорения надо менять алгоритм, часто говорит о том, что проектировали плохо.
Обычно так и делают.

E>Часто можно сразу выбирать оптимальный алгоритм.
А еще чаще — нельзя. Потому что решение задачи кроется не в одном алгоритме, а в дестятках. Подобрать оптимально каждый из них нереально, кроме того заранее обычно даже не думают как данные выглядеть будут.

E>Не понятно зачем пессимизировать-то? В большинстве задач оптимальные алгоритмы давно уже известны...
Ну если у вас задачи такие что под нее сразу можно оптимальный алгоритм подобрать, то хорошо.
В реальной жизни приходит заказчик и говорит: "сделайте мне песдато!"

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

G>Только не стоит в это месте говорить "структура данных". Именно структура может измениться до неузнаваемости при эволюционном дизайне.
Ну что-то изменится, а что-то останется.
Как бы список упорядоченный по алфавиту путём эволюции в префиксное дерево не превратится...

G>Обычно неалгоритмическая оптимизация зкалючается в расстановке хаков с целью повысить быстродействие. Эти хаки очень отрицательно сказываются.
Ну даже хаки можно расставлять культурно, скажем перекрывать new|delete у какого-нибудь класса, а не у всех. Кроме того, в нормальных программах можно не заниматься совсем уж хакками...

G>Нет, он смог объяснить её преподу так что тот понял и еще на вопросы ответил, короче получил зачет.
Ха! Тогда я как-то кванты человку за ночь "объяснил"...
IMHO, к разработке это всё отношения не имеет вообще

G>А что за программы? С таким бешенным мотором.
AI в разных раскладах.

G>А я не знаю примеров где они нужны были. Приведите парочку.
поисковая машина, распознавание речи, переводчик, ICR, OCR, анализ структуры чего-нибудь, скажем поиск рака молочной железы по рентгенограмме,.. Это то, про что я сразу подумал...

G>Трейдерские системы, накопление статистики по мере прихода информации.
А что мешает статистику в БД лить? Кроме того не совсем понятно что за трейдерская система с большим трафиком данных? Ну сколько там сделок с секунду? Ну не миллиард же?

G>Нейронная сеть — да, там перемножение матриц и обратное распространение ошибкм.
Это всего лишь одна из реализаций. Наивная довольно.
E>>А поисковая машина?
G>Чего ищет?
Ну Google знаешь?

G>Что-то на грани фантастики.
Есть несколько конкурирующих продуктов...
Во всяком случае было...


E>>Про параллельность не уверен, есть более специальные средства, хотя я сторонник наоборот, крупной гранулярности, если возможно, и тогда язык не особо важен. Про сеть -- вообще всё пофиг, IMHO, если это не TCP/IP стек А если он -- то не ХиндиС, однозначно, IMHO. Работа с диском -- это известный тормоз и не ясно какая разница, какой язык, опять же...
G>Видимо вы не писали таких программ. Разница есть.
"Таких" -- это "каких"? С диском, пофиг как откуда работать, всё равно диск ждать...
Главное много лишней памяти не скушать. Либо асинхронный доступ реализовать, но тут опять же от ОС скорее зависит, а не от языка...

G>Вот этого как раз не надо. "Тонкое" управление обычно выливается в очень большие сроки разработки.
G>Нужны простые способы абстрагироваться от этого управления.
Это от целей зависит. Если цель -- очень быстро разработать, то да, лучше абстрагироваться, а если цель высокое качество, то лучше иметь возможность рулить...

G>Ну если учесть все аспекты хранения и обработки индексов, распараллеливания вычислений и балансировки входящей нагрузки, то думаю что на .NET получится получше.
Тем не менее все известные успешные реализации на С++ Даже новые...
И, кстати, я не думаю, что на ХиндиС получится лучше. Просто потому, что нет причин для этого. Хотя, скорее всего, и сильно хуже не получится. Будет по памяти менее эффективно на какой-то процент и всё... Скажем на ~10%

Ну а дальше вопрос зачем это нужно. Если на сервере, чтобы работало, то пофиг наверное, а если на сотовом телефоне, для поиска по тексту карточек словаря, то ХиндиС будет в пролёте...

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

E>Есть и другие ниши. Скажем ретейл. Обычно коробочный софт разрабатывают по какому-то графику, есть цикл выпуска версий там, то, сё, есть время на проектирование, на тестирование, на качество разработки, короче. Если ты будешь выпускать версии раз в месяц, ты только проиграешь! Так что выгодно выпускать версии пореже, но покруче...
Тоже самое, только без изменчивости требований.
При поставленном процессе выпуск релиза ниче не стоит.

E>А ещё есть разработка технологий и моторов всяких. Скажем сидят люди из 17-й версии СУБД делают 18-ю. Там своя специфика, и C# ещё меньше в тему. Ну и т. д.
Там таже самая фигня.

E>Или, наоборот, сидят люди и пишут то, что никто ещё не писал и как это писать не знает. Тоже интересная, и тоже особенная работа...
Тогда делается прототип(ы), с целью выяснить как писать, а потом пишется продукт.
А исследования планируются очень просто — поставлены цели, выделено бабло, как только цели достигнуты или бабло кончилось исследования заканчиваются и начинается разработка продукта.

E>При этом все эти активности -- программирование. Но они все разные. И кому-то нравится одно, а кому-то другое...
Это ты сам придумал. Промышленный подход к программированию заключается в том что ты пишешь примерно одинаково, только цели немного разные.

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

E>>IMHO, такая ситуация, когда для ускорения надо менять алгоритм, часто говорит о том, что проектировали плохо.
G>Обычно так и делают.
Ну ты же сам пояснил, что вы принципиально не проектируете, а сразу пишите прототип? Тогда не удивительно...

G>А еще чаще — нельзя. Потому что решение задачи кроется не в одном алгоритме, а в дестятках. Подобрать оптимально каждый из них нереально, кроме того заранее обычно даже не думают как данные выглядеть будут.
Не понимаю, в чём проблема.
Привели пример задачи, и алгоритма, который сразу трудно выбрать...

G>В реальной жизни приходит заказчик и говорит: "сделайте мне песдато!"
И что за алгоритм вы выбираете в качестве первого приближения в таком случае? Зовёте спецов по ублажению?

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

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

G>Вообще если готовы бабло платить, то можно написать суперкомпилятор, который будет специализировать программу под входные данные, тогда она будет лететь 3 раза вокруг земли.

G>Но для этиъ целей С++ точноне подойдет.

1) Ты про CT что-нибудь слышал?
2) Как думаешь, а сам компиллер С++ на чём писан?

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

G>При поставленном процессе выпуск релиза ниче не стоит.
Может и не стоит, но что ты будешь выпускать на этапе проектирования, например?
Или прототипирования...
Короче не догма. На каких-то этапах каких-то проектов полезно, а на каких-то не особо.

G>Тогда делается прототип(ы), с целью выяснить как писать, а потом пишется продукт.
Нет. Прототипы конечно делаются, но это ОЧЕНЬ УПРОЩЁННЫЙ взгляд на вещи.
Вот представь себе, что тебе надо написать игрока в го, который победит на ЧМ. Как построишь ты работу?

G>Это ты сам придумал. Промышленный подход к программированию заключается в том что ты пишешь примерно одинаково, только цели немного разные.
Не знаю что я там придумал, но с психологической точки зрения активность очень разная...

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

VD>>Почему всем будет смешно, если им расскажут о подмастерьи физика, химика или врача. Так почему же подмастерья программистов обсуждаются серьезно?
E>Ну посмейся. Слова "аспирант", "ординатура" и "научный руководитель диплома" и "производственная практика" для тебя новы?

Очень смешно. До аспирантуры или ординатура человек обязан отучиться минимум 4 года в профильном институте. В лучшем случае за бесплатно. Сейчас многие деньги уже платят. Тут же человек хочет со знанием ПХП без какой бы то ни было подготовки идти работать С++-программистом.

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

Я сутки работал, трое учился, а по вечерам еще с тем же С++ разбирался. Просить у кого-то за это деньги мне даже в голову не приходило.

Здравствуйте, Erop, Вы писали:
E>Может уважаемый MVP снизойдёт к нам, сирым и убогим и вспомнит таки азы, а уже потом будет позориться?
А что вы назыаете "азами"? Я на плюсах в последний раз писал, афаик, в 2002. И не считаю знания таких деталей "азами". Азы — это, к примеру, понимание того, в каком порядке пишутся программы

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

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

G>>Только не стоит в это месте говорить "структура данных". Именно структура может измениться до неузнаваемости при эволюционном дизайне.
E>Ну что-то изменится, а что-то останется.
E>Как бы список упорядоченный по алфавиту путём эволюции в префиксное дерево не превратится...
У меня один раз именно такое превращение произошло.


G>>Обычно неалгоритмическая оптимизация зкалючается в расстановке хаков с целью повысить быстродействие. Эти хаки очень отрицательно сказываются.
E>Ну даже хаки можно расставлять культурно, скажем перекрывать new|delete у какого-нибудь класса, а не у всех. Кроме того, в нормальных программах можно не заниматься совсем уж хакками...
Это и нижает читаемость и модифицируемость кода. Пользователю класса еще недо будет знать как работает аллокатор класса, чтобы его эффективно использовать.

G>>Нет, он смог объяснить её преподу так что тот понял и еще на вопросы ответил, короче получил зачет.
E>Ха! Тогда я как-то кванты человку за ночь "объяснил"...
E>IMHO, к разработке это всё отношения не имеет вообще
Кванты действительно не имеют.

G>>Трейдерские системы, накопление статистики по мере прихода информации.
E>А что мешает статистику в БД лить? Кроме того не совсем понятно что за трейдерская система с большим трафиком данных? Ну сколько там сделок с секунду? Ну не миллиард же?
То что лить+считать статистику в бд — не хватает скорости бд. Она не рассчитана на сочетания быстрых записей и рассчет аналитики одновременно.

G>>Нейронная сеть — да, там перемножение матриц и обратное распространение ошибкм.
E>Это всего лишь одна из реализаций. Наивная довольно.
E>>>А поисковая машина?
G>>Чего ищет?
E>Ну Google знаешь?
Ну знаю. Еще Windows Live знаю, у них вроде на C# (если не все, то большая часть)

G>>Вот этого как раз не надо. "Тонкое" управление обычно выливается в очень большие сроки разработки.
G>>Нужны простые способы абстрагироваться от этого управления.
E>Это от целей зависит. Если цель -- очень быстро разработать, то да, лучше абстрагироваться, а если цель высокое качество, то лучше иметь возможность рулить...
Это на основании кагого опыта написано?

G>>Ну если учесть все аспекты хранения и обработки индексов, распараллеливания вычислений и балансировки входящей нагрузки, то думаю что на .NET получится получше.
E>Тем не менее все известные успешные реализации на С++ Даже новые...
Скажи это разработчикам Windows Live.

E>И, кстати, я не думаю, что на ХиндиС получится лучше. Просто потому, что нет причин для этого. Хотя, скорее всего, и сильно хуже не получится. Будет по памяти менее эффективно на какой-то процент и всё... Скажем на ~10%
Я не вижу причин чтобы получилось хуже.

E>Ну а дальше вопрос зачем это нужно. Если на сервере, чтобы работало, то пофиг наверное, а если на сотовом телефоне, для поиска по тексту карточек словаря, то ХиндиС будет в пролёте...
А там сильно мощный поиск нужен?
Можно взять Lucene.net — работает очень быстро, можно собрать под CF.