LINUX.ORG.RU

C++ source checking tool


0

0

Привет всем!

Как-то недавно промелькнуло на linux.org.ru сообщение
о выходе новой версии программы для анализа исходников
на предмет выявления в них потенциальных дыр.
Не подскажет ли кто URL?

anonymous

По моему все эти средства, сплошное надувательство. Для выкачивания бабок у населения. Аля программы для решения проблеммы 2000 года.

temofey
()
Ответ на: комментарий от temofey

Oshibaissia. Kak raz C++ - naduwatel'stwo i sredstwo dlia obolwaniwanija takih, kak ty. Debil'nyj jazychok, hrenowo poddayushijsia formal'nomu analizu. Dazhe dlia ADA takih sredstw do figa, i wse DEJSTWITEL'NO RABOTAYUT.

vsl
()

Уж знаем твою любовь к С и С++, но во первых отчегож тогда unix, linux
и т.д. и т.п. написанны на С?
Во вторых насчет DEJSTWITEL'NO RABOTAYUT, если можно конкретный пример,
какого плана проблему в плане безопасности, эти средства DEJSTWITEL'NO
решают.
А насчет оболванивания то таким как ты , просто
клепок в одном месте не хватает чтоб в С и С++ разобратся. Теоретик
ты наш заформалиненный.

temofey
()

В чем-то, конечно, vsl прав - С++ не верх совершенства,
и вот поэтому подобные checking tools иногда бывают полезны
(в отличие от Java или, к примеру, Python, где такие средства
абсолютно не нужны).

P.S.
Так подскажет кто-нибудь URL или нет?

anonymous
()
Ответ на: комментарий от temofey

Kogda pisalsia unix, nichego luchshe (w plane balansa udobstwo/proizwoditel'nost') NE BYLO. Sejchas nowuyu OS pisat' na C++ mogut tol'ko idioty. Wot normal'nye, umnye lyudi napisali Inferno. Eto tak, dlia primera. Tak chto ne 3.14zdi, plyusowik zashorennyj. Ja ne goworil, chto ja ne znayu i ne ispol'zuyu C++. Ja lish zajawliayu, chto ANALIZU on ne poddaetsia po prichine wrozhdennoj ublyudochnosti. I woobshe, menia prosto zaebali urody-"praktiki" nawrode tebia. Udawis'. Ty slishkom bezgramoten, chtoby zhit'.

vsl
()

Прямо Шварцнегер какой, еще скажи 'АСТАЛАВИСТА БЕЙБИ'. Насчет анализа - так это твою психику анлизировать надо, а то чето у тебя не совсем адекватная реакция на происходящие, нервный какой то. Давится я не собираюсь, это может ты 'zaebaniy', от переизбытка эмоций обделаешься. Потому как токо брюзжать и можешь как старпер, а по делу ответить нет. Раз используешь плюсы так и не воняй. У него значит своя ниша есть, если даже ты его используешь. Теперь по делу: ты мне можешь привести пример проблемы котую подобные средства решают, скажем в АДЕ, а вот в С++ нет.

temofey
()

2vsl:ty durak, hotyaby po tomu chto pryvel xrenoviy primer. Kak
govorytsa slyshl zvon, no ne znaesh gde on.
Smotry http://www.lucent-inferno.com/inferno/VitaNuova-NTL.html,
a takge http://www.vitanuova.com/inferno/papers/bltj.html.
Vnimatelno chitayem, i ponymaem chto v otlichae ot tebya tam deystvitelno umnie
ludy. V opisanii Inferno postoyanno upominaetsa C,C++,Java sovmestimost plus
ix sobstvennoy zatochenniy pod seti i vstroennie ustroystva
'C-like programming language' - Limbo. I sudya po vsemu sam inferno na
C i pisalsa. Potomu kak sam inferno imeet v sostave 'C cross-compilers for 68000, 68020, ARM, Power PC, x86 and Sparc'. Vobshem do sih po luche C nichego ne pridumali.
PS: krome togo chto ty durak, tak ty esho i mudak. Ibo polnostyu podhodish
pod opredelenie http://izm.zamok.net/24.htm.

anonymous
()
Ответ на: комментарий от anonymous

Mudak - chelowek with balls. Po opredeleniyu. A ty, ochewidno, lishen etoj
wazhnoj detali tela, tak kak priacheshsia za anonymous-om. Tak chto, grazhdanin
Onanimus, wy sowramshi. C-like - eto wowse ne C. Pomeditiruj nad slowom "SAFE", i pochuwstwuj raznicu. A to
u tebia eshe i Java okazhetsia C-like...

Itak, chem gowenyj jazychok otlichaetsia ot prawil'nogo? Srazu opredelimsia:
gowenyj jazyk - C,C++,Pascal,Perl i wse takoe. Sredi prawil'nyh jazykow: ADA,
Java, SML, Ocaml, Scheme, Oberon, Python. Raznica w tom, chto gowenye
jazyki jawliayut soboj nagromozhdenie neswiazannyh logicheski idej, wwedennyh
lish w ugodu slishkom naglym i shustrym praktikam, kotorym nado "wse, i srazu", i
kotorom polozhit' na logichnost' sistemy i wozmozhnye oshibki. Powedenie programmy,
pisannoj na gowennom jazychke - ne predskazuemo. Prawil'nye jazyki ORTOGONAL'NY. Ne soderzhat
peresekajushihsia sredstw dlia reshenija odnoj zadachi. Ne soderzhat nepredskazuemyh
konstrukcij, nawrode ukazatelej. Samye prawil'nye iz nih - funkcional'nye - mozhno
obrabatywat' woobshe chisto formal'nymi metodami, ne zadumywajas', i poluchat' rezul'tat na poriadki
bystree. Odnako, pochemu-to "praktiki" ne zhelayut etim pol'zowat'sia. Prichina prosta.
Oni tupy i bezgramotny. Oni bojatsia odnogo tol'ko slowa "matematika". I prodolzhayut
proizwodit' naskwoz' glyuchnyj soft, nawrode togo zhe linux ili windoze...

A pro to, gde i kak rabotali awtomaticheskie werifikatory koda - chitajte pro
mission critical zadachi, nawrode realtime kontrolia proizwodstwennyh processow.
Odin iz naibolee izwestnyh primerow - sistema kontrolia metro w Parizhe. Na ADA pisannaja
i awtomaticheski dokazannaja. Soft dlia dokazatel'stwa byl napisan tam zhe, pod
etot proekt. Ne polenilis' towarischi, i rezul'tat wpolne okupilsia - ABSOLYUTNO
BEZGLYUCHNOJ SISTEMOJ.

vsl
()

Да же не понятно, как на такие заверения реагировать - я к сожалению не знаю всех тех языков, которые были упомянуту, но к твоему сожалению vsl - такие языки, как С и С++ будут существовать и развиаться, так как это general purpose языки - может они и не заточены под конкретные задачи и направления (математика и т.п.), но они являются инструментом _достаточным_ для решения многих задач из любых областей. И лучше пользоваться знакомым инструментом, чем пытаться для решения небольших задач разбегаться из-за того, что на каком-то другом языке - это будет просто идеально. Если со временем ты убеждаешся, что функциональность твоего инструмента уже тебе не подходит - только тогда на мой взгляд следует обращаться к чему-то еще.

Bauron
()
Ответ на: комментарий от Bauron

Естественно, C++ никуда не денется, как и бейсики всякие. Дерьмо не тонет. А про general purpose не надо. Не существует ни одного такого языка. Просто, в принципе не существует. А в качестве достаточного инструмента и бейсик или даже ассемблер подойдет. Короче, опять чувствуется гнилой подход практика, от которого надо бы избавляться. Ведь цель, на самом деле, не просто решить задачу, а решить ее ПРАВИЛЬНО. То есть - без ошибок. Тут все горазды виндовс ругать - и при этом сами не лучше, так же пользуют C++, так же плодят ошибки, так же считают, что debugger - это полезный инструмент для разработки софта. Гнило это. Грустно. Так мы и останемся в каменном веке, если не поменяем модель разработки софта на более правильную, если не отбросим исторически сложившиеся нелепости, и не поставим к стенке всех наглых интуитивщиков-практиков, настолько засравших всю софтовую индустрию, что теперь проще все начать с нуля, чем разгребать эту помойку.

Вот ты мне одно скажи: ты тоже, как и все эти кретины-практики, считаешь, что программ без ошибок быть не может?

vsl
()

Как раз собирался на эту тему поговорить :) Мое убеждение на данный момент слаожилось в пользу того, что надо просто грамотно разрабатывать и писать свои программы, чтобы свести к минимуму вероятность появления ошибок. Мне один мужик на прошлой работе постоянно пытался втереть - чтобы проверить софт на наличиие функциональных огрех, необходимо пройти по всем ветвям программы - во всех возможных вариантах и все будет путем. Так вот, почему-то мне кажется, что это бред - для маленьких алгоритмов и их реализаций - это уже трудно выполнимо, а для больших программ вообще не реально. Насколько мне известно, только Оракловские тесты доказывающие функциональность системы продолжаются по-моему около трех дней. И это только функциональность, теперь представь себе что ты должен проверить возможность неправильного функционирования. К сожалению я не имею информации о математически правильных языках (и отношусь к таким заявлениям с некоторым подозрением) - если можешь поделись в кратце информацией. Ну и напоследок, я попросил бы тебя, не быть таким категоричным в заявлениях про практиков :) ну хотя бы просто для того чтобы люди к тебе захотели прислушаться.

Bauron
()
Ответ на: комментарий от Bauron

Так вот как раз сведение вероятности ошибки к минимуму - неправильный подход. Да и что значит "грамотно" тоже так просто, на интуитивном уровне, столь любимом практюками, не определить - опять математика нужна. Ведь можно писать программы БЕЗ ОШИБОК ВООБЩЕ, а не с "минимальной вероятностью". Только не на C++, естественно. И нет надобности ТЕСТИРОВАТЬ. Опять неверный подход. Нужно доказывать СООТВЕТСТВИЕ ПОВЕДЕНИЯ МОДУЛЯ ДОКУМЕНТИРОВАННОМУ. Формально доказывать. И в других модулях использовать для доказательства информацию о поведении используемых модулей из документации. Доказывается все автоматически, без участия человека, если ввести средства документирования. За примером ПРАВИЛЬНОГО языка, а так же примером доказательства кода, рекомендую полистать эти лекции: http://www.cl.cam.ac.uk/Teaching/Lectures/funprog-jrh-1996/index.html А на самоуверенных безграмотных практюхов, поимевших наглость заявить, что им не нужна математика, я наезжал, и буду наезжать. Ибо не люди они, а уроды.

vsl
()

Товарищ vsl. Вот вы делаете заявления, что программы можно писать без ошибок вообще. Вы ошибаетесь, потому что появление ошибок это не есть свойство конкретного языка программирования, а свойство программиста. Никакой продвинутый язык программирования не помешает человеку сделать логическую ошибку или написать один термин вместо другого. Второе ваше утверждение - то, что правильность программы можно проверить аппаратно, без участия человека - также неверно. Насколько я понимаю, пока не существует средств, которые могут переводить разговорный язык в язык спецификаций. :) Поэтому человек - программист - должен реализовать спецификации программы на каком-то промежуточном языке. Чем сложнее задача, тем более общим и запутанным должен стать этот промежуточный язык. Здесь опять же растет вероятность появления ошибок. Вообще ваши заблуждения довольно известны. Прочитайте для начала параграф 24.2.4 последнего издания Страуструпа. И перестаньте так дымиться от напряжения. Вам дым застилает глаза.

Hamster
()
Ответ на: комментарий от Hamster

Не буду я читать Страуса. Страус мудак. Я же сказал, что я понимаю под отсутствием ошибок: ДОКАЗАННОЕ СООТВЕТСТВИЕ ПОВЕДЕНИЯ МОДУЛЯ ДОКУМЕНТИРОВАННОМУ. Документированному на том самом языке спецификаций, который простой, и даже ОЧЕНЬ ПРОСТОЙ. Почему ОЧЕНЬ ПРОСТОЙ? До по тому, что модули у нас МАЛЕНЬКИЕ. Сиплюсисту этого не понять, они все на классах зациклились, классы им модули заменили. Отсюда все их беды.

vsl
()

Уважаемый vsl. Насколько я знаю, доказательство (формальное или иначе математическое) правильности алгоритма для данной конкретной задачи не тривиальная задача и в общем виде вроде не решена ..
Хотел бы узнать у Вас, относите ли Вы к языку спецификаций UML диаграммы? Дело в том, что уже имеются инструменты, позволяющие переводить программные системы, созданые на базе UML непосредственно в чистый код на С.
Что касается замечаний относительно модулей и классов, то вы просто путаете совершенно разные понятия, которые в любом объектно-ориентированном языке спокойно уживаются. По-моему, данный ляп непростителен для представителя академической школы программирования, представителем которой вы по-моему являетесь.
P.S. Да, и попросил бы Вас не использовать ненормативную лексику, которую Вы так любите, в мой адрес. Мои знания в боксе и дзю-до с большой степенью вероятности позволяют мне надеяться, что всю эту лексику смогу вбить Вам обратно в глотку.


shama
()

To vsl: Есть определенный круг задач, которые хорошо
поддаются моделированию, т.е. построение мат модели для таких задач
является тривиальным. И я так предполагаю что соответственно
для такого рода задач возможно и построение верификаторов кода на соответствие
определенной мат модели. К таким задачам как раз относится различные
автоматизированные системы управления для построения которых
имеется готовый математический аппарат. Сюда, к примеру,
также можно отнести
компиляторы, интерпретаторы и иже с ними. Но опять таки скажем
если насчет лексических и синтаксических анализаторов все ясно,
они бес проблемно строятся на основе мат моделей, то с семантикой
уже сложнее,тут так сказать уже появляется человеческий фактор,
где многое зависит от кривизны рук.
Кроме того если кто строит исходную мат модель? ЧЕЛОВЕК. То бишь
если она будет ошибочна, то можно хоть до пенсии проводить
верификацию кода, доказывать ее математическую правильность, и
удивляться тому, что готовая система таки не работает, хотя она
с точки зрения мат аппарата она идеальна.
Кроме того не все можно представить с помощью мат аппарата.
Насчет правильных и неправильных языков, к числу правильных ты
отнес яву, хорошо, в нем, по твоему, есть все задатки для построения
безглючных систем, почему же они тогда не появляются, я даже скажу больше
на яве сплошь и рядом можно увидеть кривые программы, и это обусловлено
в том числе и тем что на данный момент нет безглючной реализации ява -машины,
и опять таки код может быть правильным, а из за ошибок в реализации
языка, правильность кода сводится к нулю.
To Bauron относится к таким заявлениям надо осторожно, потому
как это из оперы "Ученье Маркса всесильно потому, что оно верно",
вроде с первого взгляда совершенно логичная фраза, но к чему она привела-
все желающие могут лицезреть. Просто vsl считает себя мессией,
задачей которого спасти наши заблудшие души от ужасов С С++ и
других порождений дьявола. Он из серии тех
кто с дурнуватой улыбкой подходят на улице и начинают раскрывать за
бога, и приглашает посетить христианское собрание, уверяя что их
церковь - одна истинная, все другие порождения дьявола.
vsl - просто фанатик.

PS: vsl недавно сообщил нам что он 'Mudak - chelowek with balls'.
Теперь этим гордым званием он пытается наградить несчастного язычника
Страуструпа.
PS1: Ув. shama только не бейте vsl по голове, судя по всему -
это его больное место.
Вот по balls - это пожалуйста, может он перестанет быть тем кем он
есть 'Po opredeleniyu'.
А вообще непонятно чего там у vsl c грамотностью, но культура его
явно хромает.

temofey
()

Где МЫД (ой VSL) там спор какой-то и ни какого толку. Где не зайдешь он начинает воду лить. Ну не нравится не используй. Хороший программист напишет хорошую програмуу на любом языке даже на бэйсике. Форум для того чтобы отвечать на вопросы а не разводить флэйм. Ктому же этот гаврик наследил везде. У меня много работы и я не всегда могу шарится по доскам а не говоря уже о спорах, а VSL ..... Поэтому уж извините МЫД (Ой VSL) чем вы таки занимаетесь чо у вас так много свободного времени на всякие бесмысленные споры. Потому что толку от ваших слов нет ни на одном из форумов ( по крайней мере где был я) Извините Чтобы не казатся голословным сообщаю я программист-практик программирую почти 10 лет. Ну люблю я С++. Мне он нравится. Что касается АДА и подобных. Они тоже далеко не 'правильные' пожалуйста VSL не засоряйте эфир мусором. и не глупым спором. А отвечайте на вопросы. А то как в рекламе чучше иногда бывает жевать чем говорить Andrew D aydy@mail.ru

anonymous
()

Да, блин, собралась толпа упертых практюхов, и никто даже не пытается понять, о чем же тут речь. И еще меня обвиняют в оффтопике. Смешно. Итак, вспомним, с чего начался базар: с тулзеней для проверки сырцов. Что от такой тулзени требуется? Найти ошибки в КОДЕ. Никто и никогда не говорил про кривые руки и сиплюсплюсные мозги, которые порождают ошибки в самой логике. Так что не надо про сложность построения мат.модели для конкретной задачи - это ДРУГОЙ УРОВЕНЬ. Нам же надо только одно - выявить несоответствие того, что мы там накодировали, тому, что мы ожидаем. И пусть мы при этом ожидаем полнейшую лажу - не чекера это дело. Тут мы и сталкиваемся с проблемами сиплюсплюса - это нетипизированный язык, что сразу же запрещает нам использовать более половины известных методов проверки кода, он имеет массу побочных эффектов, и при этом - очень слабую модульность, что усложняет поиск этих самых побочных эффектов. По логике вещей (см. на Java) класс=модуль. И на C++ можно так писать. Но ведь в чем фигня - не пишут... И по этой причине суперкомпиляцию для Java уже практически реализовали, а для C++ ее не будет никогда. Представляю, как заорут любители плюсов, когда их главный аргумент - производительность - потеряет актуальность. Сейчас приходится использовать C++ исключительно благодаря высокой производительности получаемого кода (правда, я чаще использую Фортран, ибо для численных задач он лучше, и компилит оптимальнее), но с увеличением размера проектов и с развитием технологий верификации кода и суперкомпиляции C++ уйдет в историю. Про супер-пупер-практюха-со-стажем-в-десять-лет: ты просто слишком уперт, чтобы понять, о чем я говорю. Я тут давал уже множество ценных ссылок, и те, кому надо, ими воспользовались. Ты же, я уверен, даже читать не стал (см. чуть выше в этом треде, про лекции по FP, и там в конце про доказательство кода). Другие, кто не поленился прочитать, потом "спасибо" говорят.

Ну а про помахаться с оппонентами - это я завсегда готов. Сам не пальцем делан, так что положить мне на ваши боксы-дзюды. Надо бы открыть Fight Club для продолжения программерского флейма на более высоком уровне. Навроде Нескучника или Царицино у толканутых, но только для более серьезных разборок.

P.S. Про UML: это хорошее средство для построения КАРКАСА. И, я считаю, что им не код генерить надо (все равно сиплюсист его потом испоганит), а именно ту самую СПЕЦИФИКАЦИЮ, с которой нас будет сверять чекер. И, одновременно, human-readable документацию...

vsl
()

>Itak, chem gowenyj jazychok otlichaetsia ot prawil'nogo? Srazu opredelimsia:
>gowenyj jazyk - C,C++,Pascal,Perl i wse takoe. Sredi prawil'nyh jazykow: ADA,
>Java, SML, Ocaml, Scheme, Oberon, Python.
Vsl, ты как деревенский дурачок. Если C++ такой плохой, то чего ты его используешь ? Ты же сам не раз говорил, что ты пишешь на нем. Как это понимать ? Или для этой части кода не существует лучших альтернатив, и только и остается, что писать на говеном языке ? Ну так в таком случае все остальные языки еще более говеные, если все, что они позволяют - это флеймить по поводу их крутости.

timur
()
Ответ на: комментарий от timur

Я, кажется, уже объяснял, почему пишу на C++. 1) ROOT. Я не виноват, что меня забыли спросить, когда новый стандарт выдумывали в той индустрии, в которой я работаю. Теперь уже почти все поняли, что ошиблись, но исправлять уже поздно. 2) Библиотеки. Мне для мелких задач мне просто лениво делать биндинги к какой-нить сишной библиотеке. Этими двумя случаями и ограничивается мое использование сиплюсплюс. Там, где требуется предельная скорость, предпочитаю Фортран.

vsl
()

vsl почему ты льешь воду? Когда я тебя просил привести пример
какого рода проблему решает чекер к примеру в аде, тебя понесло в
формальный анализ, в конце концов ты очутился в парижском метро.
Теперь ты говоришь что 'это ДРУГОЙ УРОВЕНЬ. Нам же надо только одно -
выявить несоответствие того, что мы там
накодировали, тому, что мы ожидаем'.
Приведи пожалуйста _конкретный
пример_ что именно может накопать чекер в программе на Аде, а вот
С++ - нет.

Насчет сиплюсплюс - нетипизированный язык, то тут ты ошибаешся,
как раз он типизированный, с развитой системой конторля типов и
механизмом их преобразования.

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



temofey
()
Ответ на: комментарий от temofey

Я не говорил, что проверка для C++ невозможна. Она просто ЗАТРУДНЕНА. Очень сильно затруднена, так как мы все же не имеем контроля типов, имеем наличие присутствия указателей и темплейтов, и, что самое противное, присутствует полиморфизм. Для языков без этих недостатков все гораздо проще: тип каждой конструкции вычисляется в зависимости от контекста, для функциональных языков нам ВООБЩЕ не надо отслеживать изменение состояния, так как нет никаких мутабельных объектов, и каждая функция существует сама по себе, и при проверке не требует просмотра ничего окромя вызываемых ей таких же функций. Для C++ нам пришлось бы для каждого обращения в память смотреть, как это повлияет на другие функции, способные туда же обратиться. Как сие реализовать, я не понимаю ВООБЩЕ. И, судя по наличию отсутствия C++-чекеров, никто не понимает.

Про суперкомпиляцию для Java: ссылок пока не дам, информация из приватной беседы с людьми из РЕФАЛьной команды, которые сейчас этим занимаются.

Про нетипизированность C++ - БЛИН, НУ ЧТО ТЕБЕ СТОИТ ПРОЙТИСЬ ПО ТОЙ ССЫЛКЕ, ЧТО Я ТУТ ПРИВЕЛ. Прочитаешь - поймешь, что такое строгая типизация, и почему в императивных языках ее реализовать затруднительно. Разве что в ADA нечто близкое, но тоже не фонтан... Или по http://www.haskell.org/ пошастай, там похожая модель типов.

vsl
()

Уважаемый vsl, признаюсь очень приятно, что Вы сделаны именно тем чем надо, а не пальцем. Еще приятнее читать, что Вы способны излагать свои мысли, не перемежая фразы выражениями не употребляемыми в литературе. Что касается цели дискуссии, то я в некотором недоумении. Здесь что обсуждается возможность создания инструмента, способного выявить соответствие исходников и кода, из них создаваемому, некоему заявленному алгоритму поведения или возможность создания проги, которая, получив некий набор исходников, начнет их с нуля проверять на наличие каких-то мифических "дыр". Если первое, то всегда можно сделать (да и делается в Теркоме) инструменты, наличие которых позволит используя только язык SDL или UML диаграмм создать модель системы, ее поведение, некий конечный автомат переходов и сгенерировать на этой основе код, как я и говорил выше. При этом Вам ничего не мешает установить некие ограничения, типа четкого следования типам, можно просто не допустить полиморфизма и т.д. Таким образом - это конечно решение вынужденное и временное, но при этом ручками пишутся только драйвера для железа, а все остальное руками "упертых практюхов" не делается. Данная технология используется при создании систем реального времени, где ошибка стоит гораздо дороже чем в обычной программе. С уважением Шама. P.S. Было бы очень не плохо, чтобы vsl нашел время и изложил свое мнение по тому, что же можно считать нормальным языком программирования для промышленного использования. Дома можно писать хоть на Eiffel'e.

shama
()
Ответ на: комментарий от shama

Дело в том, что я не верю в человеческую доброту и сознательность. Слаб человек, и мерзок. Так что, если не выкрутить ему руки средствами самого языка, он обязательно (возможно даже, безо всякой злобной мысли за душонкой) напихает в код такого, что любой чекер профукает. Далее, UML все таки недостаточно. К примеру, я хочу описать в спецификации к интерфейсам модуля, что такая-то функция жрет свой численный параметр в таком-то диапазоне и не давится, а выход за пределы порождает такой-то exception. Я не представляю, как это изобразить на UML. Понятно, что UML - лучшее средство для отображения взаимосвязи промеж модулями и прочими сущностями, но вот параметры этих отношений там уже так просто не покрутишь.

На тему промышленного языка: ну, мериканские вояки свой выбор сделали - ADA. С риалтаймом там весьма неплохо, кстати. Но вообще следовало бы уточнить, что понимаем под "промышленным использованием". Если это язык, за кодирование на котором можно посадить 40 тысяч обезьян и одного инженера, то VisualBasic или C++ однозначно, что нам Microsoft и демонстрирует. Результаты такого подхода, опять же, у всех на виду. В других случаях "промышленное" программирование от программирования вообще отличается мало. Сейчас народ активно пытается сообразить, что надо сделать с OCaml, чтобы он поимел большее признание в индустрии, о чем рекомендую почитать архивы mailing-list на http://caml.inria.fr/ Там эта тема была обжеванна глобально и со всех сторон, и мне просто не хочется здесь повторяться. Краткое резюме: основная проблема, почему функциональные языки не так часто применяются в промышленности, заложенна не в самих языках, не от их недостатков проистекает, а исключительно от низкой грамотности и нежелания учиться у большинства нынешнего кодерского контингента. Там, где кодеров не водится, а одни только программеры, функциональные и прочие прогрессивные языки гораздо чаще находят применение и признание.

vsl
()

VSL вомногом прав но и не прав.
Но ты слишком теоретик. Это и хорошо и плохо.
С++(С) это просто языки

Вот ты меня ругаешь (или хвалишь ; -) )

"Про супер-пупер-практюха-со-стажем-в-десять-лет: ты просто слишком
уперт."

Теория хороша и супер-трупер компиляторы хорошо.
На рпактике часто бывает иначе.
Универсализация или ограничения ето не всегда плодотворно
влияет на конечный прдукт и на скорость его разработки.
Ксажеленью. С тобойбы попить пива и поговорить было бы
очень интересно.

Теперь про UML. Хорошая штука для описания кода но не для
генерации. Самое главное не сходить с ума. Здесь VSL прав
тоже в многом.

В идеале теория должна стать практикой, но пока имеем чо имеем.
Извини чо тм написал
"Потому что толку от ваших слов нет ни на одном из форумов ( по крайней мере где был я"
Полезное там было. Я нашел даже кой чего для себя. Спасибо.
Понимаешь здесь твоя ( не нравится мне это слово, не подходит оно здесь) теория голословна. Открой свою страничку или форум и
пожалуйса с примерами. Пообсуждаем. А так чисто болтовня. Кому брюнетки нравятся кому бландинки а кому и негры.

Ты согласен с мной?

aydy@mail.ru

Andrew D

anonymous
()

VSL вомногом прав но и не прав.
Но ты слишком теоретик. Это и хорошо и плохо.
С++(С) это просто языки

Вот ты меня ругаешь (или хвалишь ; -) )

"Про супер-пупер-практюха-со-стажем-в-десять-лет: ты просто слишком
уперт."

Теория хороша и супер-трупер компиляторы хорошо.
На рпактике часто бывает иначе.
Универсализация или ограничения ето не всегда плодотворно
влияет на конечный прдукт и на скорость его разработки.
Ксажеленью. С тобойбы попить пива и поговорить было бы
очень интересно.

Теперь про UML. Хорошая штука для описания кода но не для
генерации. Самое главное не сходить с ума. Здесь VSL прав
тоже в многом.

В идеале теория должна стать практикой, но пока имеем чо имеем.
Извини чо тм написал
"Потому что толку от ваших слов нет ни на одном из форумов ( по крайней мере где был я"
Полезное там было. Я нашел даже кой чего для себя. Спасибо.
Понимаешь здесь твоя ( не нравится мне это слово, не подходит оно здесь) теория голословна. Открой свою страничку или форум и
пожалуйса с примерами. Пообсуждаем. А так чисто болтовня. Кому брюнетки нравятся кому бландинки а кому и негры.

Ты согласен с мной?

aydy@mail.ru

Andrew D

anonymous
()

И еще под винду для плюсов есть нумеговский продукт BoundsChecker

а слова мистера shama - считаю полным бредом

И про упертых практиков ( Лучшая теория - это практика)
вот если ты докажешь теорию на практике то тогда ОК
С++ доказал это практике.
Кстати наша команда пишет проги на ++ и очень надежные и быстрые, этого требует наша область. И получаются.
Повторяю хорошо получаются. Проверино на практике.
А если кто не окуратен то уж извините shama такие программисты не нужны, пусть занимаются чемто другим.

aydy@mail.ru

Andrew D

anonymous
()

И еще под винду для плюсов есть нумеговский продукт BoundsChecker

а слова мистера shama - считаю полным бредом

И про упертых практиков ( Лучшая теория - это практика)
вот если ты докажешь теорию на практике то тогда ОК
С++ доказал это практике.
Кстати наша команда пишет проги на ++ и очень надежные и быстрые, этого требует наша область. И получаются.
Повторяю хорошо получаются. Проверино на практике.
А если кто не окуратен то уж извините shama такие программисты не нужны, пусть занимаются чемто другим.

aydy@mail.ru

Andrew D

anonymous
()

То vsl: то что ты `не понимаешь ВООБЩЕ` как это реализовать - это не
значит что этого нельзя реализовать ВООБЩЕ, а я понимаю что и для АДЫ
ты вообщем то, тоже не знаешь как ЭТО реализовать. А я не понимаю другого -
зачем ЭТО ВООБЩЕ надо, с этой точки зрения вообщемто и началась
вся дискусия.
Ты сильно кричал о формальных подходах - оказалось что это все только
слова, конкретного примера привести не можешь. Складывается
впечатление что ты нахватался обрывков информации из разных
областей, а сейчас сыплешь ими на право и на лево - общими словами,
боле конкретно обьяснить ничего не в состоянии. И делаешь вид крутуго
теоретика.
К примеру тебе не понравился почемуто полиморфизм, в качестве
альтернативы ты приводишь haskell который является....
`In particular, it is a _polymorphicly typed_, lazy,
purely functional language,`. Так я не понял 'polymorphicly typed'-
это есть хорошо или нет? Ты както определись.
Просто о том что ты говоришь надо иметь хотябы какоето представлене.
А `в приватной беседе` за бутылкой пива можно наговорить что угодно,
и `заниматься` - это не значит почти реализовать, тем более
суперкомпиляция интересна пока только с чисто теоретической
точки зрения.
С++ не строго типизированный язык, но это его плюс. Скажем в том же
С++ - есть ужастный оператор goto, так что с того, ставить С++ на
уровень бейсика? Вопрос стоит в стиле програмирования, а не в том
каких средств в языке нет. Право программиста выбирать чем он
будет пользоватся, а чем нет. И отсутствие _строгой_ типизации -
это плюс, а не минус , потому что есть ситуации где это
оказывается полезно. Но и С и С++ - типизированные языки, и не
надо мне доказывать обратное.
А убирать из языка некоторые возможности, для того
чтоб заставить нерадивого программера правильно писать программы,
это все равно что забрать у тебя комп - для безопасности, чтобы ты
вдруг его завтра с 10 этажа ненавистному соседу из соседнего
подьезда на голову не кинул.

Если ты даже не удосужился почитать Страуструпа, то о каком знании языка
ты можешь говорить, все твои мнения основанны опять таки на 'приваных беседах'.
Еще мне интересно что за `индустрия в которой ты работаешь`? И что это
за новый стандарт в ней выдумали? Ты вроде физик, так что
всем физикам в приказном порядке приказали писать на каком то,
ненавидимом тобой языке?

PS: Ты нашел своего слушателя - Andrew D, попей с ним пива и обясни
в приватной беседе состояние дел в индустрии.
PSS: Да еще заодно объясни ему как правильно сообщения в конференцию
отправлять, а то такое впечатление что он заикается.

temofey
()

to temofey

1. Не я заикаюсь, а и-нет.
2. Ин вино веритас (вчера было много и того и другова)

так чо не .....

Я С++ ужасно люблю. И пиво тоже.... ;) Чо больше ??
всему свое время. Так чо я стобой согласен на счет свободы.
А спор здесь излишен. Уж изззззвинииииии.

не наезжай. плсссссс

Андрей Д
aydy@mail.ru

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.