видимо сложность записи алгоритма на C++ резко выше сложности записи в виде K-кода.
+ наверное за счет тех же сил, что сделали реализацию регекспов на CL быстрее регекспов сишной либы и перла, в котором регекспы -- одна из важнейших и часто используемых частей языка, а следовательно, обязана быть быстрой: http://lisper.ru/forum/thread/328 (там обсуждение и ссылки на бенчмарки) 

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


http://kx.com/Customers/end-user-customers.php

и что вы там увидели? На тех же компах в этих институциях и косынка, верно, установлена. Не нужно путать корпоративные пресс-релизы и реальность. "Швейцарские банки они предпочли kdb"  ...чему, блокноту? Для каких задач? Не нужно быть таким доверчивым.

Добавлено через 12 минут и 29 секунд

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

о да, сравним C++, Haskell, Common Lisp и Prolog например?


K и есть заточенный, профессиональный язык для работы с массивами данных, как SQL -- язык для работы с РСУБД, как Perl для работы с текстовыми данными с помощью регулярных выражений

Это сообщение отредактировал(а) k0rvin - 16.3.2011, 21:06

ну я говорил о языках, которые существуют за пределами университетских аудиторий, и на которые существует бизнес интерес со стороны заказчиков.  
"Haskell, Common Lisp и Prolog " ... очень-очень нишевые, потому мне не интересные.



гм. Какими массивами? Любой язык манипулирует данными, памятью то бишь. К если и заточен, то под определенную парадигму. Эффективен ли он за ее пределами?
Ибо любая стандартная задача имеет и стандартное решение, давно уже реализованное. А нестандартные проблемы могут ли быть решены в рамках заданной парадигмы? В с++ или Delphi нет сильных перекосов в сторону какого -либо стиля программирования или круга задач. Этим он ценен.
 А заточенные языки... не дают свободы. Я не хочу быть ограничен, даже если с ограниченностью приходит удобство или эффективность решения некоторых специальных задач. Не хочу быть админом, кропающим скрипты, хочу быть художником.

---
Поэтому для десктопа по настоящему релевантны лишь C++, Delphi и .Net. В них есть некая универсальность. Хотелось бы узнать от тех, кто оставил Delphi (будучи профи) в пользу скажем c# .NET или C++ QT, почему они это сделали. Без общих фраз, конкретные причины.

Это сообщение отредактировал(а) AlekXL - 17.3.2011, 00:09

Не "валилась безобразно", а делала нормальный отчёт об ошибке и на рестарт. 

Исключения, несомненно, должны быть частью работы программы. Но есть существенная разница между AV и EFileFormatError.

Добавлено через 1 минуту и 32 секунды


Иными словами: сравнили два разных алгоритма на разных языках и сделали вывод, что интерпретируемый язык - производительнее.

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

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

lolwut?

Добавлено @ 07:07

man абстракция, структуры данных

Добавлено @ 07:09

man проблемно-ориентированное программирование / предметно-ориентированное программирование

Добавлено @ 07:11

ээ есть -- процедурное программирование и ООП, ну в C++ еще "обобщенное программирование", как они сами называют шаблоны. больше в этих языках ничего не доступно, либо крайне затруднено в реализации и неудобно в последующем использовании. особенно в делфи

Добавлено @ 07:12

иными словами никто не осилил переписать алгоритм с K на C++

Это сообщение отредактировал(а) k0rvin - 17.3.2011, 07:14

А что непонятного? Не видно для них вакансий на фрилансерских ресурсах. А значит я не стану на них тратить время.


да ну! Мне хватает объектной парадигмы.




Потому что этого достаточно. В дельфи есть и шаблоны и анонимные методы. Выше крыши для потребностей большинства. Операционные системы написаны при помощи процедурного и объектного программирования. Мой браузер написан при помощи той же парадигмы. Да и весь софт которым я активно пользуюсь
И тут приходит "проповедник", втюхивающий мне про другие парадигмы, на що мне надо? Не буду обсуждать языки, чья коммерческая эффективность стремится к нулю 
---
для этой ветки вообще оффтоп. Тут джихад DELPHI vs Microsoft/Java



блин, ну детский сад


Это сообщение отредактировал(а) AlekXL - 17.3.2011, 13:36

в делфи нет шаблонов, в делфи есть generics, это несколько разные вещи

Добавлено через 1 минуту и 15 секунд

нет, просто факт

Добавлено через 4 минуты и 3 секунды

"а мужики-то не знают" =(

вы же о парадигмах речь вели. С высоты парадигмы разница реализаций несущественна.


факт, что никто не удосужился это сделать. А что "ниасилил", так это вранье. Потому что те же знатоки этих нишевых языков наверняка знакомы с  с++.


 И что это было?  Это не Oracle, не MS, даже не Embarcadero. Кто-то что кропает на лиспе, а остальные 99.9% делают то же на сях. Какова у рядового кодера получить вакансию в той компании? Стремится к нулю? Ну и нах тогда!
 А в итоге выбор сужается до указанных выше традиционных более-менее средств разработки.

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

  

Не совсем догнал, что вы имеете в виду под "списком формы" - вероятно компоненты owned by TForm, тут вообще кроме утечки ничего не вижу страшного.
Но да, вероятность разрушения данных есть! Вопрос в том, насколько велика эта вероятность а также каков круг задач приложения. Если вебсервер или банковский биллинг - то да ... нужно аварийно завершать, а если десктопное приложение - тут от специфики приложения зависит.
 Вероятность порчи данных не так велика. К слову сказать, порча данных вообще может произойти тихо, и притом никакого исключения не сгенерируется. Поймите, уверенности нет никогда.
У меня было несколько заказных проектов по поводу автоматизации программ, которые эту автоматизацию не поддерживают. Там внедняется dll перехватчик, который манипулирует интерфейсом и данными этого приложения. В такой ситуации подавление всех исключений, например вполне оправданная тактика.
 Или вот есть проблема в другом моем приложении. Там TVirtualDrawTree со сложной отрисовкой, и данные,  ассоциированные с каждой веткой в виде структур. Дерево часто обновляет содержимое, поэтому в событии onfreenode происходит высвобождение памяти ассоциированных  с нодом данных, и иногда у меня ошибка вылетает:типа я пытаюсь освободить то, что уже освобождено или что-то такое.  И эта проблема хуже AV, потому что под вопрос ставится целостность кучи.
Причину я пока не выяснил. Может, для некоторых нодов событие вызывается дважды. Пока я просто давлю исключение. И факт тот, что у приложения сотни пользователей, и ни у кого нет жалоб на вылеты или "странное" поведение за месяцы существования проблемы. Потому что приложение это хоть и довольно сложное, но некритичное. Лучше так, чем безобразный вылет, или отключение функций приложения, которые кажутся пользователям очень полезными.



Это сообщение отредактировал(а) AlekXL - 17.3.2011, 21:05

ну если не догоняете, это НЕ ввод с командной строки. Под вводными данными я подразумеваю контекст сложного алгоритма, работа которого зависит от  от кучи вещей. 
Знаете, иногда хочется прыгнуть выше головы, и ты создаешь алгоритм, работу которого представляешь лишь общем смысле, а поведение в каких - то необычных ситуациях не можешь спрогнозировать. Хочешь чтобы он был к тому же быстрым, то есть кодишь небезопасно. И это работает! - в большистве случаев. Юзерам нравится умная и быстрая программа! Но порой - происходят неожиданности. Ну и что?
Разве Windows не так запрограммирована? Я помню времена Windows 9x и Delphi 5, когда синий экран каждые два часа вылетал. Но код постепенно отладили. Жуков повылавливали. Но подход не изменился : новая версия- сырая, SP1 - более менее стабильная, SP3/4 - продукт. Это бизнес модель.
И с ней несогласны лишь студенты и их преподы.



 

Это сообщение отредактировал(а) AlekXL - 17.3.2011, 21:32

DXE, оптимизация включена:


И смотрим как скукоживается форма (SL.Add передаёт управление на TWinControl.CanAutoSize). Очень приятное и предсказуемое поведение, вселяющее пользователям твоей программы уверенность в её надёжности. 

Т.е. сначала мы всеми силами достигнем неведомой ёбаной хуйни в программе, а потом полгода будем искать причину.

Добавлено @ 01:19


Вероятность попасть в аварию на автомобиле невелика. Значит ли это, что нужно не пристёгиваться?

Добавлено @ 01:22


Не любой фолт, а неизвестное необработанное исключение. Ещё раз: AV - это не то же самое что EFileOpen или EConvertError. Для EFileOpen и EConvertError ты можешь предложить алгоритм восстановления: к примеру для файла ты можешь показать сообщение об ошибке с причиной - пусть пользователь проверит файл (если это был документ). Для EConvertError ты должен указать пользователю на ошибку в его данных.

Для AV ты НЕ МОЖЕШЬ предложить алгоритм восстановления. Чувствуешь разницу?

Добавлено через 10 минут и 41 секунду


Мне вот нравится ситуация, когда человек по жизни занят написанием ###-кода, а потом пропагандирует эти методы, как образец для подражания. Так придём к светлому будущему, товарищ.

Это сообщение отредактировал(а) CodeMonkey - 20.3.2011, 01:23