Здравствуйте, VladD2, Вы писали:
VD>Что-то меняется в этом мире. Я то думал, что мне тут сразу минусов понаставят, а прошло уже несколько часов, а мне только один смайлик поставили .
Может потому, что уже общеизвестно твое отношение к С++ и никто уже к подобным твоим заявлениям всерьёз не относится?
Здравствуйте, FR, Вы писали:
FR>Все так, но ты не хочешь понять простую вещь, для программ-монстров, общие затраты на кодирование (и низкоуровневое проектирование) настолько малы что выбор языка почти ни окажет влияния на общую скорость разработки. Возьми хоть того же Макконнелла посмотри графики из 27 главы.
Код есть код. Его надо проектировать, писать, отлаживать и менять. На любой из этих аспектов разработки влияет инструмент и уровень владения им разработчиков/дизайнеров.
Конечно есть скажем игры где много времени уходит на дизайн левелов и т.п., но и там скорость и качество разработки много стоят. Ведь и в уровнях много скриптов, и движок развивать надо. В итоге получаем по 3 года разработки, а потм софт вылетает, течет, глючит...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CreatorCray, Вы писали:
CC>Может потому, что уже общеизвестно твое отношение к С++ и никто уже к подобным твоим заявлениям всерьёз не относится?
До сих пор это никого не останавливало. Похоже, все же что-то меняется. Это не может не радовать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Конечно есть скажем игры где много времени уходит на дизайн левелов и т.п., но и там скорость и качество разработки много стоят. Ведь и в уровнях много скриптов, и движок развивать надо. В итоге получаем по 3 года разработки, а потм софт вылетает, течет, глючит...
Год разработки, да и глюкавых игр достаточно мало.
Да и шарп с явой в них, что характерно, почти не применимы (во всяком случае в серьёзных проектах).
Здравствуйте, MasterZiv, Вы писали:
MZ>-- коллекции (забудьте про STL, — не отвечает критериям "продуманная" и "стандартная")
Стандартнее некуда, и очень продуманная. Есть люди, которые считают, что не в ту сторону продуманная, но это из другого флейма.
MZ>1) хорошая стандартная кроссплатформенная build-система.
Стандартной системы сборки ни у какого языка нет. Тем более, что часто приходится использовать сразу несколько языков в проекте. А хороших кросс-платформенных кросс-языковых систем сборки много. Хотя бы CMake и Boost.Build.
Здравствуйте, MasterZiv, Вы писали:
>> Библиотек, собственно, много. Наверное, больше, чем для любого другого >> языка. Не хватает грамотно спроектированных качественных библиотек.
MZ>Да как раз и проблема, что нужно не много библиотек. А одна, хорошая MZ>и стандартная.
Должен быть Единственный Правильный Путь написания библиотек. Как в Python, как в Java. Тогда они будут с легкостью интегрироваться.
Здравствуйте, VladD2, Вы писали: VD>Что-то меняется в этом мире. Я то думал, что мне тут сразу минусов понаставят, а прошло уже несколько часов, а мне только один смайлик поставили .
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, VladD2, Вы писали:
VD>Код есть код. Его надо проектировать, писать, отлаживать и менять. На любой из этих аспектов разработки влияет инструмент и уровень владения им разработчиков/дизайнеров.
Угу и поэтому еще и неизвестно будет ли вообще ускорение разработки для больших программ, может из-за всех накладных факторов, переобучения и т. п. и замедление получится.
VD>Конечно есть скажем игры где много времени уходит на дизайн левелов и т.п., но и там скорость и качество разработки много стоят. Ведь и в уровнях много скриптов, и движок развивать надо. В итоге получаем по 3 года разработки, а потм софт вылетает, течет, глючит...
Влад у меня последний год кроме студии стояла единственная NET программа OmeaReader от JetBrains, в общем вполне качественная программа, конечно притормаживала, и иногда вылетала или задумывалась навсегда со 100% загрузкой процессора, но в целом вполне меня устраивала. И вот с месяц назад запускаю ее и получаю ошибку разрушена база, жму восстановить backup, он тоже разрушен, поиск по гуглю показывает что проблема нередкая и у многих людей эта основная причина отказа от использования даной программы. Насколько я знаю программа написана вполне квалифицированными людьми, так что не сильно уж и надежнее NET.
R>Моменты можно приводить любые от ядра языка и до инструментальных средств, но при этом накладываются следующие ограничения: R>1. Мешать это должно регулярно. Т.к. если это мешает эпизодически, например, раз в год, то это не интересно, т.к. раз в год можно и потерпеть, и на общей эффективности разработки это не сказывается. R>2. Это должно быть решено в других промышленных языках. Т.к. если это не решено хотя бы в одном другом промышленном языке, то это не интересно, т.к. это не проблема С++, а просто общая проблема. Если не очевидно, то желательно указывать языки, в которых это решено.
Мешает нагромождение темплейтов, там где их может не быть в старом (legacy) коде, который приходится мейнтейнить.
Отладка на промышленый серверах типа AIX, стандартными слабенькими отладчиками этого "счастья" угнетает.
А что то мощное не тянет по деньгам/сетке, так как сервера далеко.
Ну и в стандарте недостаточно четка прописана организация класса на системном уровне (реализуй как хочешь, тоже для отладки не гуд).
Это как раз оно, так и должны выглядеть шаблоны в низкоуровневом высокопроизводительном языке. Примером, который меня убедил, был regexp. Собственно, основная претензия к C++ — нельзя сделать так же. Небольшой, довольно жалкий набор операций над целыми числами — и всё. Маловато будет! А вот если можно читать строки — значит, можно сделать все, причем дешево.
Здравствуйте, De Veloper, Вы писали:
FR>>http://www.digitalmars.com/d/2.0/templates-revisited.html
DV> Это как раз оно, так и должны выглядеть шаблоны в низкоуровневом высокопроизводительном языке. Примером, который меня убедил, был regexp. Собственно, основная претензия к C++ — нельзя сделать так же. Небольшой, довольно жалкий набор операций над целыми числами — и всё. Маловато будет! А вот если можно читать строки — значит, можно сделать все, причем дешево.
Так ведь, насколько я понял, в C++09 запись SomeTemplate<"SomeString"> будет срабатывать, если template <class... Chars> SomeTemplate<Chars...>, т. е., будет раскрываться в SomeTemplate<'S', 'o', 'm', 'e', 'S', 't', 'r', 'i', 'n', 'g'>.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Так ведь, насколько я понял, в C++09 запись SomeTemplate<"SomeString"> будет срабатывать, если template <class... Chars> SomeTemplate<Chars...>, т. е., будет раскрываться в SomeTemplate<'S', 'o', 'm', 'e', 'S', 't', 'r', 'i', 'n', 'g'>.
Да. Это хорошо. Одно только плохо — нет пока никакого C++0x.
А так там очень много полезных и вкусных штучек обещается, я давно уже устал слюни пускать в ожидании.
Roman Odaisky пишет:
> MZ>1) хорошая стандартная кроссплатформенная build-система. > Стандартной системы сборки ни у какого языка нет. Тем более, что часто
Здравствуйте, MasterZiv, Вы писали:
MZ>Ужас бухгалтера пишет:
>> C>С одной функцией: "doSomething()"...
MZ>Очень смешно. Тут язык такой замечательный помирает, а им всё — хиханьки да MZ>хаханьки ...
Здравствуйте, VladD2, Вы писали:
VD>Казалось бы и правда, создать некий аналог С++ с точки зрения качества оптимизации кода и потребляемых ресурсов конечного приложения и можно избежать огромной части затрат на разработку и сопровождение, но зачем? Скажем, я уверен, что даже если бы для разработки драйверов использовался бы какой-нить ОКамл (а я не сомневаюсь, что для МС это не было бы проблемой реализовать), то надежность драйверо была бы куда вше. Но зачем? Можно же потратить море бабок на написание и вылизывание этих драйверов. Плюс еще море на создание разных драйвер-верифайров, которые один фиг всех ошибок не предотвращают. Ведь проблема в том, что если начать менять, то может измениться и расклад сил на рынке. А зачем это нужно тем, кто его уже успешно занимает?
Таких "аналогов" понаписано уже два вагона. От модулы до ады. И что и где? Кто-то на них прогает?
Жизнь такова, что бывают разные программы и разные задачи и разные требования как к средствам реализации, так и к качеству разработки, стоимости поддержки, требованиям к ресурсам и т. п.
Для одних ниш C# годится, для других нет.
В целом это, IMHO, не удивительно. Всё-таки и ява и C# разрабатывались для того, чтобы занять нишу а ля VB + переносимость. Типа пофиг скорость, пофиг память, главное, чтобы можно было что-то задёшево написать почти не проектируя, а потом задёшево развивать. Ещё важно обеспечеть лёгкость вызова библиотек, других приложений, сторонних компонент и т. п.
И это правильно, так как есть очень большой класс задач, которые всегда надо реализовать "уже вчера", и "совем задёшево". При этом вопрос о переиспользовании кода вообще не стоит.
А есть задачи, которые надо решить таки хорошо, эффективно по ресурсам, обеспечить эффективное переиспользование кода в течении десятков лет и т. д.
Тогда уже основная стоимость разработки переходит в проектирование, тестирование, мероприятия по удешевлению поддержки (например в адекватное документирование), и там преимущества C# таки растворяются. Зато проявляются недостатки. Вот на С++ и пишут. Даже ада не подходит, как оказалось
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, MasterZiv, Вы писали:
>> MZ>1) хорошая стандартная кроссплатформенная build-система. >> Стандартной системы сборки ни у какого языка нет. Тем более, что часто
MZ>В Java — есть. LISP — есть.
.
