Кстати, у тебя там в первой ссылке какие-то нереальные результаты получились для VB6.
По моему опыту он отставал от С++ в обычных вычислениях примерно в 1.2-2 раза, но не в 10
за исключением ситуаций:
— запуск из среды (это выполнение P-кода вместо компиляции в двоичный код)
— использование нетипизированных значений (VARIANT)
— забыли поставить ByVal для числового параметра
— стоит ByVal для строкового параметра или объектного параметра
ну и всю оптимизацию надо включить и вырубить все проверки в релизе.
V>У многих С++ — программистов получается писать код на С++ не уступающий С. Тут не в языках дело, а в людях. На С тоже немало тормознутых и неоптимальных программ.
Опять вернулись на круги своя Решающим фактором в программировании остается человек (ака кривые ручки ака изобретатель велосипедов). И, увы, ни язык программирования, ни средства разработки не смогут излечить нас от этого. Они могут слегка подлечить симптомы — но не более.
... << RSDN@Home 1.1.4 beta 3 rev. 185>> ... <<Winamp is now playing "Silence">>
Здравствуйте, vdimas, Вы писали:
V>У многих С++ — программистов получается писать код на С++ не уступающий С. Тут не в языках дело, а в людях. На С тоже немало тормознутых и неоптимальных программ.
О, да! Я даже сам когда-то принимал участие в разработке таких чудес. Прикол в том, что код на C++, может не только не уступать по производительности коду на C, но и существено его превосходить. За счёт статического полиморфизма и строгой типизации, разумеется. Естественно, если это не случай передачи std::stdring по значению.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
V>>У многих С++ — программистов получается писать код на С++ не уступающий С. Тут не в языках дело, а в людях. На С тоже немало тормознутых и неоптимальных программ.
M>Опять вернулись на круги своя Решающим фактором в программировании остается человек (ака кривые ручки ака изобретатель велосипедов). И, увы, ни язык программирования, ни средства разработки не смогут излечить нас от этого. Они могут слегка подлечить симптомы — но не более.
Согласен. Только ситуация ещё хуже! Чем больше возможностей языка — тем более возможностей написать дикий код. Видел как пара физиков в МФТИ написала следующий код для расчётов:
Класс формулы с двумя методами — конструктором (в который загонялось более 40 параметров, причём с преобразованием типа от int к float, а потом к double), методом Compute (с двумя параметрами x и y); всё остальное делалось в коде main исключительно в стиле C.
Поскольку конструктор со всеми параметрами вызывался в цикле (и это при том, что из всей кучи менялись только три параметра), для каждой пары x,y, да и сама формула вычислялась далеко не оптимальным образом. Так как у них уже была программа на C, которая всё это вычисляла (как потом выяснилось, что и с исходниками) — оказалось, что она считала всё это примерно раз в 15 быстрее (около 4-х секунд, против минуты). Что они только не говорили про язык C++. После того, как я им её переписал, тоже самое стало считаться за 0,5 секунды, правда при этом исходный файл с данными я перевёл с помощью простенького конвертора из текстовой формы в двоичную. Но и до этого всё считалось быстрее (где то около 1,5 — 2 секунд). Они очень удивились.
Re[2]: Сложность современных средств разработки ПО
Здравствуйте, beroal, Вы писали:
B>Я думаю, по сравнению с богатством ЯП, в области IDE есть застой. Для программиста была бы удобной её более тесная интеграция с ОС, так, чтобы функции были first-class citizens в файловой системе, чтобы написанными функциями можно было бы сразу начинать полноценно пользоваться, а не заворачивая их перед этим в графический интерфейс. Средств разработки много, и они для самых разных задач: от конкатенации файлов с помощью copy (это тоже программирование) через БД и SQL к численным методам и графическим интерфейсам. Они как-то поразительно разобщены. Например, как в MS SQL Server загрузить файл в ячейку таблицы стандартными средствами SQL? Или выполнить на записи некоторые вычисления, которые можно задать только в другом ЯП, не проходя через геморрой с компиляцией DLL и под постоянным страхом, что она порушит работающий сервер? Я не знаю. (Я привожу просто пример, ибо у Microsoft больше всех шансов сделать среду более удобной, раз он владеет и ОС, и ЯП.) А например, найти в таблице функцию, применить её к файлу, и результат скормить другой программе, так, чтобы, когда исходный файл меняется, программа получала уведомление? Думаю, на интеграцию всех этих компонентов будет затрачено больше времени, чем собственно на программирование. А ведь это рядовая автоматизация повседневной работы, каких много. Может быть, ОС должна создавать для пользователя более декларативное (в смысле парадигмы программирования) окружение.
На самом деле, к IDE это имеет очень отдаленное отношение. Так же, как и к языкам. Основная проблема здесь — это проблема интеграции между языками, и как следствие — проблемы при интеграции программ. Я искренне надеюсь, что .NET/CLI постепенно решит большинство из этих проблем. Собственно, для этого он и создавался Но одно я могу сказать совершенно точно — Оберон этих проблем не решит никогда.
AVC>"Менее понятно, однако, как оценит ослабление контроля над программой и понимания происходящего со стороны программиста, когда размер заимствованного кода становится настолько большим, что отследить все нюансы становится невозможно. STL-версия — это как раз тот самый случай: ее производительность непредсказуема, и нет простых способов с этим разобраться."
непредсказуема — это не значит, что она обязательно будет хуже. Хрестоматийный пример — это std::sort, который рвет сишный qsort на немецкий крест
Собственно, "ослабление контроля" — это как раз то, для чего STL создавался. Я не понимаю, зачем его нужно за это ругать
Здравствуйте, AndreyFedotov, Вы писали:
AF> Как сделать нотацию в которой самый компактный C++ (С#, Java или даже Oberon) — я показал.
А Вы так уверены в мощности С++? Думаете на нем все можно выразить? А можно попросить Вас задуматься как на С++ объявить тип функции, возвращаемым значением которой является переменная ее собственного типа?
TYPE
SelfReplicatindMachine = PROCEDURE (): SelfReplicatindMachine;
Вот так это записывается на Component Pascal.
VAR m: SelfReplicatindMachine;
BEGIN
m := m0;
WHILE m # NIL DO m := m() END
Здравствуйте, Сергей Губанов, Вы писали:
СГ>А Вы так уверены в мощности С++? Думаете на нем все можно выразить? А можно попросить Вас задуматься как на С++ объявить тип функции, возвращаемым значением которой является переменная ее собственного типа?
В C++ для таких вещей обычно используют функторы, и никаких проблем здесь не будет.
А если использовать указатель на функцию, то это, уважаемый, будет уже plain C
PS Вот хоть убейте меня — не вижу ни одной реальной задачи, в которой такая конструкция действительно необходима.
Похоже, Оберон — настоящий кладезь странных и спорных конструкций программирования
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Однако в плане программирования встроенных систем на Обероне мне интересен другой вопрос: насколько я понимаю, такие системы должны тесно взаимодействовать с "железом". А насколько это просто организовать, учитывая, что адресной арифметики и многих других "низкоуровневых" возможностей в Обероне и аналогах нет?
Да, очень интересный вопрос, не правда ли? Как люди смогли сделать пилу по металлу из более прочного металла, ведь для этого нужна другая пила из еще более прочного металла и т.д. А как в алмазе дырки сверлят, ведь он же самый твердый? Подумайте, если не найдете ответа, то я потом напишу.
Здравствуйте, AndreyFedotov, Вы писали:
AF> Догадайтесь, что случилось бы если бы (чур-чур-чур! ) Оберон стал бы столь же распространён? Через 2-3 года его напичкали бы шаблонами. И опять выстраивались бы очереди из ленивцев, которые не могли бы потратить пару часов своего времени, что бы разобраться как же работает список из OberSTL
Вы правы. Таких ленивцев пруд пруди. Я в интернете однаждый видел реализацию оберона с генериками. Ссылка, правда, сейчас стала битой, поэтому дать не могу. Мерещится, что это был какой-то из вариантов OOC, O2C.
Здравствуйте, VladD2, Вы писали:
AVC>>Кроме того, что Вы имеете в виду под промежуточным кодом "в точности как в Обероне"? Насколько я понимаю, Оберон-система состоит из модулей (а не stand-alone программ), и каждый модуль представлен объектным, а не промежуточным кодом.
VD>Промежуточный код — это то что находится в нутри модулей оберона (и дотнета).
В модулях оберона находится, к Вашему сведению, не промежуточный код, а уже готовый к употреблению объектный код — машинные команды целевого процессора, быть может слегка разбавленные командами обращающимися к run-time системе (если таковая предусмотрена на данном конкретном оборудовании).
Здравствуйте, Дарней, Вы писали:
Д>непредсказуема — это не значит, что она обязательно будет хуже. Хрестоматийный пример — это std::sort, который рвет сишный qsort на немецкий крест
А рукопашная реализация sort, точно так же рвет std::sort потому что std::sort использует O(N*Log(N)) алгоритмы, в то время как для ряда частных случаев существуют O(N) алгоритмы. Тривиальный пример — сортировка массива целых чисел. А ведь именно массив целых чисел наиболее часто и встречается.
C++ std::sort 3.835 сек
Delphi поразрядная 2.354 сек
Скорость поразрядной сортировки прямо пропорциональна скорости памяти. То есть если в два раза увеличить скорость памяти (с 133 до 266 МГц), то и скорость увеличится примерно в 2 раза: На P4 1800Mh 512Kb, 256Mb DDR266 10'000'000 4-байтовых чисел сортируются за 1.312 сек. При переходе с 266 на 400 Мгц память скорость опять увеличивается пропорционально увеличению скорости памяти +40%.
Коллеги, а вам не кажется, что здесь можно провести прямую аналогию с естественными языками?
Никто не спорит, что чем меньше в языке слов и грамматических конструкций, тем он проще для изучения. Но вот только и возможности выразить свою мысль, как можно точнее передать желаемую информацию другому человеку такой язык предоставляет гораздо меньше. Так и с языками программирования: чем проще язык, тем проще и безопаснее с ним работать, но и тем менее гибким инструментом он является.
Здравствуйте, Дарней, Вы писали:
Д>PS Вот хоть убейте меня — не вижу ни одной реальной задачи, в которой такая конструкция действительно необходима.
Что значит необходима? Вопрос не в необходимости, а в максимальной простоте. Именно такая конструкция является самым простым способом для программирования конечного автомата. Следующей, уже более усложненной конструкцией, будет конструкция с переменной-номером состояния и switch-ем по ней. Еще более сложной конструкцией будет использование ООП, а еще более сложной — функторы.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>в то время как для ряда частных случаев существуют O(N) алгоритмы. Тривиальный пример — сортировка массива целых чисел. А ведь именно массив целых чисел наиболее часто и встречается.
Как раз для такого случая существует частичная специализация шаблонов
А вообще — говорили мы совсем не об этом.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Что значит необходима? Вопрос не в необходимости, а в максимальной простоте. Именно такая конструкция является самым простым способом для программирования конечного автомата. Следующей, уже более усложненной конструкцией, будет конструкция с переменной-номером состояния и switch-ем по ней. Еще более сложной конструкцией будет использование ООП, а еще более сложной — функторы.
Как здесь уже говорилось, иной раз простота бывает хуже воровства.
Аналогия с естественными языками тоже хороша. И правда, зачем нужен жутко сложный английский, когда есть ну очень простой пиджин-инглиш?
Здравствуйте, Дарней, Вы писали:
Д>Как здесь уже говорилось, иной раз простота бывает хуже воровства. Д>Аналогия с естественными языками тоже хороша. И правда, зачем нужен жутко сложный английский, когда есть ну очень простой пиджин-инглиш?
Аналогия не верна. Пиджинг-инглиш — это что-то типа VB script, а не полноценный язык.
Здравствуйте, Mink, Вы писали:
M>Коллеги, а вам не кажется, что здесь можно провести прямую аналогию с естественными языками? M>Никто не спорит, что чем меньше в языке слов и грамматических конструкций, тем он проще для изучения. Но вот только и возможности выразить свою мысль, как можно точнее передать желаемую информацию другому человеку такой язык предоставляет гораздо меньше. Так и с языками программирования: чем проще язык, тем проще и безопаснее с ним работать, но и тем менее гибким инструментом он является.
Сомнительная аналогия. Для естественных языков характерна тенденция к упрощению. В частности, исчезают лишние времена глаголов, становится меньше исключений в изменениях форм слов, унифицируется лексика и т.п. В частности, в русском когда-то существовало несколько прошедших времен, двойственное число (кроме единственного и множественного), еще один падеж. По твоей логике мы сейчас разговариваем на гораздо более примитивном языке, а на самом-то деле язык просто избавился от дублирующих конструкций и стал понятнее и проще для использования. Точно также на смену монструозным языкам программирования типа С++ приходят более легкие, где несмотря на отсутствие наворотов задачи решаются более просто и прямолинейно. Замечателен также тот факт, что самые древние языки, которые продолжают развиваться до сих пор, обычно довольно просты — самый яркий пример — Лисп, исключительно простой язык, который явно не умрет никогда и который породил кучу идей для других языков программирования.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Дарней, Вы писали:
СГ>Что значит необходима? Вопрос не в необходимости, а в максимальной простоте.
Какой смысл искать простые решения несуществующих проблем?
СГ>...Именно такая конструкция является самым простым способом для программирования конечного автомата. Следующей, уже более усложненной конструкцией, будет конструкция с переменной-номером состояния и switch-ем по ней. Еще более сложной конструкцией будет использование ООП, а еще более сложной — функторы.
Но сложную конструкцию, возможно, гораздо легче использовать, чем простую. Повторюсь, термины "легкий" и "простой" — не синонимы.
Повторю еще раз пример, чем проще выкопать котлован — лопатой или экскаватором.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>в то время как для ряда частных случаев существуют O(N) алгоритмы. Тривиальный пример — сортировка массива целых чисел. А ведь именно массив целых чисел наиболее часто и встречается.
Д>Как раз для такого случая существует частичная специализация шаблонов
Вот именно. На каждое средство в С++ есть противосредство. Даже на шаблоны придумали противошаблоны — частичную специализацию.
Д>А вообще — говорили мы совсем не об этом.
Как же не об этом если именно об этом!!! Смысл шаблона состоит в том что он одинаков для всех случаев. А если писать специализацию, то спасибо, я и без шаблона ее могу написать. Мне такие шаблоны не нужны.
Решающим фактором в программировании остается человек (ака кривые ручки ака изобретатель велосипедов). И, увы, ни язык программирования, ни средства разработки не смогут излечить нас от этого. Они могут слегка подлечить симптомы — но не более.
