M>>Define: популярная E>В % каких-нибудь не затруднит выразить популярность?
В процентах от чего?
M>>Define: мощная E>Тоже интересно бы почитать сранвнение с ораклом, или с MSSQL, хотя бы...
Как их сравнивать, если mnesia — не реляционная база данных?
M>>Влад правильно заметил, что обычно люди не вижят ничего дальше MSSQL, Orcale и DB2 только потому что они у всех на виду и на слуху E>Да ладно. Ты прниводи объективные преимущества, которых люди не видят. Потому, как "прога хорошая, но пользователи слишком тупы, чтобы этим пользоваться" -- это не преимущество, а недостаток... IMHO...
Здравствуйте, Mamut, Вы писали:
M>>>Define: популярная E>>В % каких-нибудь не затруднит выразить популярность? M>В процентах от чего?
Ну, например, в процентах инталляций от инсталляций баз данных вообще. Ты же что-то имел в виду, когда говорил "популярная"
M>Как их сравнивать, если mnesia — не реляционная база данных?
Ну тогда она вообще не при делах. Она не база данных, а просто некий кусок эрланга, который можно использовать и как базу данных.
M>Это не значит, что такая зажигалка или прога априори не нжна, не популярна и маломощна
Ну это не значит и обратного... А если ей сложно воспользоваться, это веский аргумент и против "нужна" и против "популярна"...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, FR, Вы писали:
FR>Это по моему проблема некритичная.
Хм... А по-моему, для языка Y, позиционирующегося как замена языка X, хороший интероп X с Y и наоборот — это достаточно критично. Но это, конечно, всего лишь мое мнение.
K>>Ну, ломающие изменения и внезапное разделение на две ветки, одна из которых с точки зрения потенциального пользователя выглядит мертвой, а вторая обещает разнообразные переживания из-за своей волнующей нестабильности, популярности не добовляет. FR>Угу, еще и слуха о D 3.0 тоже FR>Хотя заявления авторов другого языка о том что они потеряли интерес к своему детищу ничем ни лучше.
Имеется в виду письмо Скальски, в котором он говорит, что у него и Москаля нет времени для работы над компилятором, а сейчас, когда большую часть работы выполняют другие люди — то и мотивации нет?
Но ведь разница-то есть. С одной стороны, развитие, в отличие от D 1, продолжается, а с другой стороны ломающих изменений, в отличие от D 2, практически нет. Немаловажно, что это следствие того, что компилятор написан на разрабатываемом языке, так что с ломающими изменениями особо не развернуться, а не добрая воля разработчиков, которая может и измениться.
Вообще эта, как вы говорите, "политическая ж.." для этих языков имеет совсем разную природу. Проблемы у этих языков разные.
D, как мне кажется, несоизмеримо известнее, но что толку? C++ — программист может подписаться на рассылку и даже обсуждать ломающее изменение месяца на форуме, но будет ли он его использовать?
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, FR, Вы писали:
FR>Около года выпускали продукт, потом когда py2exe стал достаточно стабильным перешли на него. FR>Кроме того собирал так же немало небольших утилиток.
Меня интересуют проекты на python, не могли бы Вы привести ссылку на продукт.
Можно по почте.
Здравствуйте, CreatorCray, Вы писали:
VD>>Что ты рассказами о своих потребностях пытаешся уйти от разговора о сравнении компиляторов разных поколений. CC>Читай ветку внимательнее.
Очень внимательно читал. Вывод — сравнение не корректно.
CC>>>Теперь касательно С# VD>>Ты С#, что в рамках С# 1.1 используешь? CC>А какой смысл грузить старый проект на 1.1 в 2008ю чтобы подредактировать там чуть чуть и пересобрать? CC>Новые в 2008. Старые — в той, в которой разрабатывались.
А перевести старыне на 3.5-ый фрэймворк SP1 религия не позволяет? Они даже без изменений работать раза в полтора быстрее начали бы. А уж если заменить все ArrayList на List<T>, то можно и в разы выигрыш получить. Плюс надежность увеличить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gluk_Kazan, Вы писали:
G_K>>Отказоустойчивая InMemory DBMS пойдет ?
VD>Нет. Так как эта задача с успехом решается даже на интерпритируемом Эрлаге.
Я так понял, что это автоматом означает, что ее не нужно решать на C или C++ ?
Влад, за что Вы их так не любите ???
Здравствуйте, achmed, Вы писали:
A>Меня интересуют проекты на python, не могли бы Вы привести ссылку на продукт. A>Можно по почте.
К сожалению нет в этой отрасли (казуальные игры) большинство продуктов короткоживущие,
могу лишь дать ссылку на http://www.intenium.de/ они во всяком случае в 2006 году делали игры
на питоне, как сейчас не знаю, давно не общался.
Здравствуйте, Klapaucius, Вы писали:
K>Хм... А по-моему, для языка Y, позиционирующегося как замена языка X, хороший интероп X с Y и наоборот — это достаточно критично. Но это, конечно, всего лишь мое мнение.
Нет, более критично то, что язык никак ни устаканится. Если бы он стабилизировался у него было бы достаточно много пользователей даже если бы интероп с С++ (сишного бы хватило) полностью отсутствовал.
K>Имеется в виду письмо Скальски, в котором он говорит, что у него и Москаля нет времени для работы над компилятором, а сейчас, когда большую часть работы выполняют другие люди — то и мотивации нет? K>Но ведь разница-то есть. С одной стороны, развитие, в отличие от D 1, продолжается, а с другой стороны ломающих изменений, в отличие от D 2, практически нет. Немаловажно, что это следствие того, что компилятор написан на разрабатываемом языке, так что с ломающими изменениями особо не развернуться, а не добрая воля разработчиков, которая может и измениться.
Конечно разница есть, только популярность от обоих случаев падает.
По моему то, что язык пишется на самом себе совершенно не мешает делать ломающие изменения.
K>Вообще эта, как вы говорите, "политическая ж.." для этих языков имеет совсем разную природу. Проблемы у этих языков разные. K>D, как мне кажется, несоизмеримо известнее, но что толку? C++ — программист может подписаться на рассылку и даже обсуждать ломающее изменение месяца на форуме, но будет ли он его использовать?
Так с Немерле тоже самое, шарпист может зайти на rsdn и обсуждать сколько хочет Немерле, но за очень редким исключением (так же как и почитатель D) использовать для работы язык не станет.
Здравствуйте, VladD2, Вы писали:
VD>А перевести старыне на 3.5-ый фрэймворк SP1 религия не позволяет? Они даже без изменений работать раза в полтора быстрее начали бы. А уж если заменить все ArrayList на List<T>, то можно и в разы выигрыш получить. Плюс надежность увеличить.
Угу, и заодно пофиксить в здоровом (к тому же не нашего авторства) проекте все, что сломается после перехода с 1.1 — уже были случаи.
Там надо было всего то пересобрать его. Какой смысл возиться?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Угу, и заодно пофиксить в здоровом (к тому же не нашего авторства) проекте все, что сломается после перехода с 1.1 — уже были случаи.
Единичные и редкие. Янус переехал вообще без проблем. Большой рабочий проект — буквально десяток правок, в основном связанных с переездом пакета под новую студию.
CC>Там надо было всего то пересобрать его. Какой смысл возиться?
Чтобы получить выше производительность и значительно более удобный язык.
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Nuzhny, Вы писали:
N>Тут согласен. Но системы охранного видеонаблюдения всё равно относят к софт-реалтайм. В лаборатории МВД они тестируются на соответствие количеству fps. Редкий пропуск кадров допускается (не помню точно цифры), тут с тобой согласен.
Система видеонаблюдения не относится к реалатайм никак. Она просто должна снимать происходящее. Выподение отдельных кадров никак не влияет на ее работу. Ну, разве что они все выпадут. Но тогда уже надо говорить о работоспособности софта, а не о его "реалтаймности".
И писать подобные системы можно хоять на ЯваСкрипте. Высокая производительность требуется только от кода производящего сжатие видио, то есть кодеков. А они уже сто раз написаны и свободно доступны.
N>Если интересно, то скажу, что логика верхнего уровня в нашей системе задаётся на скриптовом языке (доступном и для конечных пользователей). Работает быстро, гибко и удобно. Например, по сработке детектора движения надо повернуть камеру, включить прожектор, звуковое оповещение и т.п. Можно и гораздо более сложную логику написать, работать с интерфейсом. Но это не касается критических участков: обработки видео, звука, работы с приёмно-контрольными приборами. И пока все довольны.
Все что ты описал кроме сжатия без проблем пишется на целом спектре языков в том числе и на Яве с дотнетом. Если вы используете там С++, то вы не более чем занимаетесь усложнением своей задачи. Риалтайма в ваших задачах по любому — 0. Это потоковые задачи и проблемы задержек в них спокойно решаются банальным кэшированием и использованием мощьных современных процессоров. Скажем на 486 машинах подобные задачи вообще решать было нельзя (если конечно не было аппаратного ускорения сжатия).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gluk_Kazan, Вы писали:
G_K>Я так понял, что это автоматом означает, что ее не нужно решать на C или C++ ?
Писать можно что угодно на чем угодно, если конечно денег и времени много. Вопрос был в том какой класс задач можно решать только на С++.
G_K>Влад, за что Вы их так не любите ???
С имеет права на жизнь, так как является высокоуровневым ассемблером. С++ же просто урод. И его использование за пределами мест жизненно требующих низкоуровневых оптимизаций является, на мой взгляд, не оправданным. Конечно если ты Майкрософт и у тебя безбрежные бюджеты на разработку софта, то можно создавать софт самым экстенсивным образом и нанимать тучи обезьян на его тестирование (в прочем не помогает, тот же Ворд уже 12 лет проходится по памяти). Если же задача сложная, а ресурсы ограничены выбор С++ — это идиотизм.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Не получилось проигнорировать в который раз этот неудачный пример с оффисной автоматизацией.
V>Влад, её во все времена делали на VB/VBA, и даже сейчас на VB.Net куда как удобней, чем на на C# или тем более на Java. Можно было бы переиначить фразу: "то, что C# не лучшее вр-во для офисной автоматизации ..." и далее по тексту.
Блин, еще один. Влез в разговор не спрося о чем он...
Офис — это не MS Office x.x.x, а здание такое где люди сидят и чем-то заниматся. А его автоматизация — это не написание скриптов к Экселю или Ворду, а разработка софта обеспечивающего автоматизацию деятельности работающего в нем народа.
Вопросы есть?
V>Валялся... и бинарное устройство COM-интерфейсов вовсе не из С++ сложилось, и все новые API виндов вовсе не в COM-виде идут... Ты, Влад, малость оторвался от реальности.
Да кого трогает что у кого там сложилось. Валяйся дальше...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, yumi, Вы писали:
Y>Здрасте, Scheme — это диалект Лиспа. Если ты про Common Lisp, то хотя бы Practical Common Lisp (это wiki перевод) загляни. Одно правда, SICP не учебник по Scheme, достаточно за пару вечеров почитать спеку по R5RS, благо всего 50 стр
Хорошая ссылка. Но!!!
1. Когда она появилась (на Русском языке)?
2. Где можно купить это произведение в бумажном виде?
3. Почему в списке описания книг (даже у нас, а мы один из самых либеральных сайтов в Рунете) практически нет описаний подобных книг?
В общем, существование информации и реальная ее доступность — это разные вещи. Люди изучают то, что лежит у них перед глазами. А перед глазами лежат учебники по С++, а со всех стороны им говорят, что "С++ — это круто!!!". Собственно сам именно так освоил С++.
Для меня, когда я учился программировать, разных Лиспов практически не существовало. Были С++, хххBase, Паскаль и еще что-то там. Так же все ругали Фортран и Кобол, хотя их я так же видел только на картинках. А вот С++ и С было выше крыши.
Ну, а как же иначе? Ведь самая передовая контора в области софтостроения для PC — Microsoft в основном писала на С и С++.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, skeptik_, Вы писали:
_>У меня на руках статистика фрилансерской биржи за все эти годы, и я могу абсолютно уверенно сказать, что Бейсика там никогда и близко не было, и что шарп хотя и начал догонять С++ начиная с 2005 года, но ещё далеко не догнал.
Видимо это потому что эти твои фрилансеры не имеют отношения тем кто работает в конторах и занимается их автоматизацией.
_>ЗЫ На немерле там до сих пор нет ни одного проекта.
А, ну — это конечно доказывает, что Неперле нет в природе.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Для меня, когда я учился программировать, разных Лиспов практически не существовало. Были С++, хххBase, Паскаль и еще что-то там. Так же все ругали Фортран и Кобол, хотя их я так же видел только на картинках. А вот С++ и С было выше крыши.
Когда я учился (конец 80 начало 90) были свободно доступны книги по лиспу, прологу и форту, я их изучал и даже сдавал лабораторки.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gluk_Kazan, Вы писали:
G_K>>Я так понял, что это автоматом означает, что ее не нужно решать на C или C++ ?
VD>Писать можно что угодно на чем угодно, если конечно денег и времени много. Вопрос был в том какой класс задач можно решать только на С++.
Абсолютно идиотская постановка вопроса. Правильнее будет какой класс задая выгодно решать на C++.
И окажется что такой класс задач очень широк и он кстати сильно пересекается например с классом задач которые выгодно решать например на шарпе.
Про деньги и время вы традиционно преувеличиваете преимущества управляемых сред.
G_K>>Влад, за что Вы их так не любите ???
VD>С имеет права на жизнь, так как является высокоуровневым ассемблером. С++ же просто урод. И его использование за пределами мест жизненно требующих низкоуровневых оптимизаций является, на мой взгляд, не оправданным. Конечно если ты Майкрософт и у тебя безбрежные бюджеты на разработку софта, то можно создавать софт самым экстенсивным образом и нанимать тучи обезьян на его тестирование (в прочем не помогает, тот же Ворд уже 12 лет проходится по памяти). Если же задача сложная, а ресурсы ограничены выбор С++ — это идиотизм.
У С++ есть сильное премущество перед си, он позволяет использовать уровни абстракции на си малодоступные.
Полно задач где Си/C++ на своем месте без всякой оптимизации, например как уже писал везде где требуется интенсивное "общение" с ОС.
Здравствуйте, VladD2, Вы писали:
VD>Система видеонаблюдения не относится к реалатайм никак. Она просто должна снимать происходящее. Выподение отдельных кадров никак не влияет на ее работу. Ну, разве что они все выпадут. Но тогда уже надо говорить о работоспособности софта, а не о его "реалтаймности".
VD>И писать подобные системы можно хоять на ЯваСкрипте. Высокая производительность требуется только от кода производящего сжатие видио, то есть кодеков. А они уже сто раз написаны и свободно доступны.
Ты уверен? А как ты на ЯваСкрипте будешь общаться с драйвером устройства захвата (например, PCI и PCI-E платы), писать эти самые драйвера, если их нет? Как будешь делать вывод видео + рисовать на кадрах различные примитивы? Передача видео по сети тоже на скрипте? Поиск видео в сотнях гига/тера байт архива? Детектирование движения, распознавание движущихся объектов, анализ траекторий их движения, поиск и распознавание лиц, работа с кучей внешнего железа по RS232, RS485, USB, ... Продолжать? Скрипты этого не выдержат.
VD>Все что ты описал кроме сжатия без проблем пишется на целом спектре языков в том числе и на Яве с дотнетом. Если вы используете там С++, то вы не более чем занимаетесь усложнением своей задачи. Риалтайма в ваших задачах по любому — 0. Это потоковые задачи и проблемы задержек в них спокойно решаются банальным кэшированием и использованием мощьных современных процессоров. Скажем на 486 машинах подобные задачи вообще решать было нельзя (если конечно не было аппаратного ускорения сжатия).
А если нам надо одновременно обрабатывать 16 видеопотоков с 25 fps разрешением 768х576 (современные PCI-E платы могут выдавать)? Это 500 Мбайт несжатого видео в секунду. Кешировать?
