разработка через моделирование

Hello Vladimir Vassilevsky!

AK>> Проведи параллель между языками программирования и человеческими AK>> языками (в том числе мёртвыми :-) - и успокойся.

VV> Hам отвратительны глупые попытки очередных эсперантистов, а также VV> происки пидарасов от программирования.

ЖB} Вольдемар, вам не надоело мелким провокаторством заниматься ?

AK>> ЗЫ Общение нетехнического планя я лично предпочитаю на различных AK>> "диалектах Великого и Могучего" 8-)

VV> А вот народный академик Шепелев отрицает великий и могучий язык C.

Hу и что ? 8-)

Hello,Vladimir !

VV> Есть такая дурная болезнь - страсть к придумыванию языков и скриптов. VV> Потому что очень увлекательное занятие. Искусство ради искусства. VV> Этой слабости подвержено довольно много разработчиков, и иногда им даже VV> удается убедить начальство в том, что это необходимо. В результате появляются VV> недосредства программирования которыми никто никогда не пользуется VV> и не будет пользоваться. Причем и в коммерческих продуктах тоже. VV> Примеров много. VV> Мое мнение: подобные проявления выжигать каленым железом.

Я бы не стал так обобщать. Имею опыт эффективного "придумывания" такого языка, правда, еще тогда эхотагом не занимался, на СМ-4. Делали измерительную систему для МО под ключ - вот вам 3 десятка блоков, сделайте систему для пр.-сдат. испытаний. Первую версию сделали тупо - резидентная часть и N оверлеев на каждый проверяемый дивайс на Фортране Когда выдали следующее ТЗ на уже почти сотню блоков - мы взвыли. И решили слепить простенький интерпретатор, как теперь бы сказали, скриптового языка ( я тогда слова такого не знал :-). Процесс ускорился раза в 2. Более того, был получен побочный результат : этот интерперетатор передали в виде подарка заказчику. И у заказчика женщины !! в конструкторском отделе, в жизни ни написавшие ни строчки кода даже на Бейсике, писали осмысленные программы контроля, которые сразу работали. Единственная трудность была - ни за что не догадаетесь какая : ввести написанную прогу в машину они не могли, ибо не владели никаким текстовым редактором ! Приглашали для этой цели оператора Свету :-)) Кажется, я об этом уже писАл, тады звиняйте.

WBR G.G.

Mon Sep 05 2005 18:06, Dmitry Ponyatov wrote to Vladimir Vassilevsky:

VV>> Мое мнение: подобные проявления выжигать каленым железом. DP> из-за недокументированности ?

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

Бывают средства, ориентированные на ограниченный класс задач. Это должен быть либо мышизм (LabView), либо что-то тривиальное (MathLab). В любом случае за языком должна стоять поддержка большой организации.

VLV

"Спешите делать добро, пока его не сделали вам"

Hello, Dmitry Ponyatov! You wrote in conference fido7.ru.embedded to Vladimir Vassilevsky on Mon, 05 Sep

VV>> Мое мнение: подобные проявления выжигать каленым железом.

DP> из-за недокументированности ?

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

dima

Hello Vladimir.

VV>>> Мое мнение: подобные проявления выжигать каленым железом. DP>> из-за недокументированности ?

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

VV> Бывают средства, ориентированные на ограниченный класс задач. VV> Это должен быть либо мышизм (LabView), либо что-то тривиальное VV> (MathLab).

yacc куда отнесешь? :}

VV> В любом случае за языком должна стоять поддержка большой организации.

ага, Вася пупкин и 1000 дистрибуторов :) (на современных генераторах новый язык можно слепить за час. Конечно, всякую фигню лепить не обязательно :) )

Vladimir

Thu Sep 08 2005 07:15, Vladimir V. Teplouhov wrote to Vladimir Vassilevsky:

VV>> Бывают средства, ориентированные на ограниченный класс задач. VV>> Это должен быть либо мышизм (LabView), либо что-то тривиальное VV>> (MathLab). VVT> yacc куда отнесешь? :}

Вова, вы узнали новое умное слово. Поздравляю.

VVT> (на современных генераторах новый язык можно слепить за час.

Да. А в cовременном текстовом редакторе за час можно написать "Войну и мир". VLV

"Спешите делать добро, пока его не сделали вам"

Hello Vladimir.

VV>>> Бывают средства, ориентированные на ограниченный класс задач. VV>>> Это должен быть либо мышизм (LabView), либо что-то тривиальное VV>>> (MathLab). VVT>> yacc куда отнесешь? :}

VV> Вова, вы узнали новое умное слово. Поздравляю.

я узнал его еще когда тырил доку на него на русском с електроники-85. Да-да, юникс в переводе еще демоса :) Вы в это время наверно тоже сидели в каком-нить совковом инсритуте и вели себя гораздо скромнее? ;}

А из нового... Hу вот например прикольная штучка - усе-в-одном...

ftp://ftp.stratego-language.org/pub/stratego/docs/sdfintro.pdf 18K

А вообще, можете еще вот тут покапаться, мож чего и полезного найдете :)

VVT>> (на современных генераторах новый язык можно слепить за час.

VV> Да. А в cовременном текстовом редакторе VV> за час можно написать "Войну и мир".

VV> "Спешите делать добро, пока его не сделали вам"

;)

Vladimir

Привет, Andrey !

DP>> Форт -- метаязык, С статичен и не модифицируем пользователем

AS> С++

У с++ тоже есть некоторые пределы и ограничения. Hапример, ни одна объектная обвязка не позволит компилировать выражения вида dummy= "foo" + "bar"; без принудительной типизации по крайней мере одного из литералов.

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... башни-виртуалы

Привет, *Nickita*!

/суббота, 10 сентября 2005/ *Nickita A Startcev* писал(а) к *Andrey Solomatov* по поводу *разработка через моделирование:*

NA> У с++ тоже есть некоторые пределы и ограничения.

Да, конечно.

NA> Hапример, ни одна объектная обвязка не позволит компилировать выражения NA> вида dummy= "foo" + "bar"; без принудительной типизации по крайней мере NA> одного из литералов.

char*const operator + (char*const; char*const) ? ;)

Привет, Andrey !

NA>> У с++ тоже есть некоторые пределы и ограничения.

AS> Да, конечно.

NA>> Hапример, ни одна объектная обвязка не позволит компилировать NA>> выражения вида dummy= "foo" + "bar"; без принудительной типизации NA>> по крайней мере одного из литералов.

AS> char*const operator + (char*const; char*const) ? AS> ;)

(Тупо) А внеклассовые операторы разве допустимы?

. С уважением, Hикита. ... С сегодняшнего дня этот вопpос y нас - наболевший.

Hello Nickita.

NA>>> Hапример, ни одна объектная обвязка не позволит компилировать NA>>> выражения вида dummy= "foo" + "bar"; без принудительной NA>>> типизации по крайней мере одного из литералов.

AS>> char*const operator + (char*const; char*const) ? AS>> ;)

NS> (Тупо) А внеклассовые операторы разве допустимы?

А почему бы и нет ? "operator+" это просто имя функции, перегружай как хочешь.

Да вот только что с этим вышеописаным добром делать ? :) Использовать внутри статический буфер - чревато: - перерасход памяти, если строки короткие - проблемы с размером буфера, что делать, когда он короче, чем надо ? - проблемы с мультитредностью

Dmitry

Привет, Dmitry !

NA>>>> Hапример, ни одна объектная обвязка не позволит компилировать NA>>>> выражения вида dummy= "foo" + "bar"; без принудительной NA>>>> типизации по крайней мере одного из литералов.

AS>>> char*const operator + (char*const; char*const) ? AS>>> ;)

NS>> (Тупо) А внеклассовые операторы разве допустимы?

DL> А почему бы и нет ? DL> "operator+" это просто имя функции, перегружай как хочешь.

DL> Да вот только что с этим вышеописаным добром делать ? :) Использовать DL> внутри статический буфер - чревато: - перерасход памяти, если строки DL> короткие - проблемы с размером буфера, что делать, когда он короче, DL> чем надо ? - проблемы с мультитредностью

И обычные проблемы с "когда и кто должен это освобождать".

. С уважением, Hикита. ... I'm going slightly mad... very slightly mad ...

Привет, *Dmitry*!

/понедельник, 12 сентября 2005/ *Dmitry Lyokhin* писал(а) к *Nickita A Startcev* по поводу *разработка через моделирование:*

DL> Да вот только что с этим вышеописаным добром делать ? :) Использовать DL> внутри статический буфер - DL> чревато: DL> - перерасход памяти, если строки короткие DL> - проблемы с размером буфера, что делать, когда он короче, чем надо ? DL> - проблемы с мультитредностью

Ну, я просто привёл пример. Утверждать, что он рабочий - я не собирался. ;)) Хотя можно поизголяться - особенно, если определить class string, а не просто char[]. Ну или ещё вариант - переопределить char*const operator+=(char*const, const char*const); на пару с соотв. "operator =" в семантике strcpy().

Привет Dmitry!

AS>>> char*const operator + (char*const; char*const) ? AS>>> ;)

NS>> (Тупо) А внеклассовые операторы разве допустимы?

DL> А почему бы и нет ? DL> "operator+" это просто имя функции, перегружай как хочешь.

DL> Да вот только что с этим вышеописаным добром делать ? :)

Hичего не делать. Вышеотквоченная конструкция в C++ недопустима.

DL> Использовать DL> внутри статический буфер - чревато: - перерасход памяти, если строки DL> короткие - проблемы с размером буфера, что делать, когда он короче, DL> чем надо ? - проблемы с мультитредностью

Это как раз не проблема - можно использовать динамический буфер.

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Синяки рождаются в споре куда чаще, чем истина...