Ada_Ru форум

Обсуждение языка Ада

Ada-2012 + Linux. Страница 4

Оставить новое сообщение

Сообщения

On Sat, 18 May 2013 09:17:33 +0400, you wrote:

 

Dmitry A. Kazakov пишет:

 

LaTeX, я пару статей в нем делал. Но чтобы документацию, это надо быть настоящим джедаем.

http://www.texmacs.org/tmweb/home/screenshots.en.html

:-)

Я, правда, очень давно пользовался. Но просто и удобно.

 

Могу порекомендовать MiKTeX.

 

http://miktex.org

 

1. Слишком сложно содержать документацию актуальной коду.

Врут.

В плане?

 

Есть такая вещь как процесс разработки софта. Документирование его интегральная часть. Когда говорят о сложности имеют ввиду писание документации потом, когда-нибудь, или что-то вроде того.

 

3. Неплохо бы создавать код из документации (а не документацию из кода)...

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

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

Говорят, что говорят вот про это:

http://www.literateprogramming.com/

1. Имеет ли смысл?

 

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

 

2. Имеет ли смысл, применительно к Ada?

 

Да, но с пониманием того, что это все-таки совсем не литература.

 

BASIC там нет вообще.

 

Зато, там есть С.

 

VisualBasic тянется не за счёт мифического "негативного

отбора", а исключительно за счёт платформы, которая на него завязана.

 

Как и в биологии, отбор - закон эмпирический. А механизмы могут быть разными. Например, религиозный: BASIC, С, PHP нам посланы за грехи наши, и знаменуют надвигающийся конец света. Так лучше? (:-))

Интел - самая плохая архитектура.

o.O Intel? В каком плане?

 

x86 выиграл и у PDP-11, и у 68к. Pentium у Alpha (который был первым 64-бит процессором, первым 500МГц процессором)

 

Окошки - самая плохая ОС. Они же самые популярные.

https://www.youtube.com/watch?v=e8M6S8EKbnU

Смотрите первый комментарий там.

Ранняя реклама, включая MS-DOS, настолько же истерична и крайне агрессивна.

 

См. выше. Но одной агрессивности не достаточно. Важна органичность. Сделать по-настоящему плохой продукт сложно. Это как Brainfuck - язык плохой, но как бы шутейно. Вы не верите в злые намерения его разработчиков. Вы думаете, что на самом деле, они добрые. Могут погладить бездомного котенка. Пропустить велосипедиста на перекрестке. А Brainfuck, ну, так получилось. А в продукты микрософта веришь на подсознательном уровне. И, потому, люди их покупают.

 

При том, несмотря на кучу недостатков, у Unix и подобных грамотно разработанная

архитектура.

 

Unix был самой плохой ОС до MS-DOS. Но был повержен.

 

У VMS тоже, полагаю, куча недостатков была.

Первое, что приходит в голову: закрытость интерфейсов, сложность, отсутствие полноценной документации на разных языках, нежелание компании делиться исходными

кодами, один интерпретатор и графическая среда, одно ядро и отсутствие драйверов

к множеству оборудования.

 

Да ладно Вам! DEC поставляла исходники и полную документацию, которая была великолепной, когда Unix Sys V приходил с уродскими man-ами.

 

Так что, насчёт некоего "отрицательного отбора", - сомневаюсь.

 

Социология - не наука. У каждого - своя картина мира.

Хм... Я не специалист, но не стал бы заявлять так категорично. По заверениям специалистов, для разных задач подходят разные языки.

 

Да, есть такая ложная теория...

Почему ложная?

Тезис 1. Специализированные языки не применимы в изоляции от областей где они не работают.

Так, любой язык применим в некоторой области.

 

Вопрос только в том, покрывает ли эта область область Вашей задачи.

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

И, при этом, критерии, по которым он признаётся "лучшим" и определяют область его применимости.

 

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

 

Тот же VHDL в своей области, наверное будет выгоднее использовать, чем пытаться

приспособить универсальный язык, типа Ada?

Нет?

 

Да, но см. пункт 1.

 

Если Вы можете изолировать проблему так, чтобы применять специализированный язык - отлично. Беда в том, что на практике так почти никогда не бывает. И тренд идет в эту сторону. Но решения о том, что вот тут-то это как раз так, принимаются на основе поверхностного анализа не осведомленными людьми, обычно ничего не смыслящими в разработке ПО, как то, менеджерами, инженерами и т.п. Они же одержимы идеей, что знать программирование не нужно. А заменить разработку ПО и квалифицированных программистов, всегда можно купив другой софт (каков полет мысли!) - "тулзу". Причем качество "тулзы" определяется ее стоимостью. А если не получается, то для старой "тулзы" приобретается новая. А для нее еще одна и т.д. Индустрия кормит саму себя. И заметьте, если бы весть этот софт делал бы свое дело, рынок бы рухнул.

 

Как Вам такой механизм отбора?

 

DEC этого не понимал, ему не было места в этом лучшем из миров.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Здравствуйте!

Тот же VHDL в своей области, наверное будет выгоднее использовать, чем пытаться

приспособить универсальный язык, типа Ada?

Нет?

>Да, но см. пункт 1.

Есть сторонники этой идеи - генерация HDL из Ada. Переодически я к ней сам возращаюсь (http://www.mediascan.by/index.files/lite-edit-papert.pdf , http://www.mediascan.by/index.files/issn_1814-4225_2012-6.pdf , http://www.mediascan.by/index.files/kh2009/doclad2009sim.pdf), но есть теоритические проблемы в частности автоматизация распаралеливания последовательных алгоритмов. VHDL - Язык описания параллельных процессов и как исключение последовательных, в то время как Ada наоборот.

На ВИТ-Ada 2013 которая пройдет в июне предполагается обсудить эту тему, в том числе и с заинтересованными представителями организаций.

К сожалению об этом (ВИТ-Ada 2013) до сих пор нет информации на www.Ada-ru.org

С уважением, Сергей.

mailto: [email protected]

www.mediascan.by

----- Original Message -----

From: "Dmitry A. Kazakov" <[email protected]>

To: <[email protected]>

Sent: Saturday, May 18, 2013 10:52 AM

Subject: Re: [ada_ru] Ada-2012 + Linux

On Sat, 18 May 2013 09:17:33 +0400, you wrote:

Dmitry A. Kazakov пишет:

LaTeX, я пару статей в нем делал. Но чтобы документацию, это надо быть настоящим джедаем.

http://www.texmacs.org/tmweb/home/screenshots.en.html

:-)

Я, правда, очень давно пользовался. Но просто и удобно.

Могу порекомендовать MiKTeX.

http://miktex.org

1. Слишком сложно содержать документацию актуальной коду.

Врут.

В плане?

Есть такая вещь как процесс разработки софта. Документирование его интегральная часть. Когда говорят о сложности имеют ввиду писание документации потом, когда-нибудь, или что-то вроде того.

3. Неплохо бы создавать код из документации (а не документацию из кода)...

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

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

Говорят, что говорят вот про это:

http://www.literateprogramming.com/

1. Имеет ли смысл?

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

2. Имеет ли смысл, применительно к Ada?

Да, но с пониманием того, что это все-таки совсем не литература.

BASIC там нет вообще.

Зато, там есть С.

VisualBasic тянется не за счёт мифического "негативного

отбора", а исключительно за счёт платформы, которая на него завязана.

Как и в биологии, отбор - закон эмпирический. А механизмы могут быть разными. Например, религиозный: BASIC, С, PHP нам посланы за грехи наши, и знаменуют надвигающийся конец света. Так лучше? (:-))

Интел - самая плохая архитектура.

o.O Intel? В каком плане?

x86 выиграл и у PDP-11, и у 68к. Pentium у Alpha (который был первым 64-бит процессором, первым 500МГц процессором)

Окошки - самая плохая ОС. Они же самые популярные.

https://www.youtube.com/watch?v=e8M6S8EKbnU

Смотрите первый комментарий там.

Ранняя реклама, включая MS-DOS, настолько же истерична и крайне агрессивна.

См. выше. Но одной агрессивности не достаточно. Важна органичность. Сделать по-настоящему плохой продукт сложно. Это как Brainfuck - язык плохой, но как бы шутейно. Вы не верите в злые намерения его разработчиков. Вы думаете, что на самом деле, они добрые. Могут погладить бездомного котенка. Пропустить велосипедиста на перекрестке. А Brainfuck, ну, так получилось. А в продукты микрософта веришь на подсознательном уровне. И, потому, люди их покупают.

При том, несмотря на кучу недостатков, у Unix и подобных грамотно разработанная

архитектура.

Unix был самой плохой ОС до MS-DOS. Но был повержен.

У VMS тоже, полагаю, куча недостатков была.

Первое, что приходит в голову: закрытость интерфейсов, сложность, отсутствие полноценной документации на разных языках, нежелание компании делиться исходными

кодами, один интерпретатор и графическая среда, одно ядро и отсутствие драйверов

к множеству оборудования.

Да ладно Вам! DEC поставляла исходники и полную документацию, которая была великолепной, когда Unix Sys V приходил с уродскими man-ами.

Так что, насчёт некоего "отрицательного отбора", - сомневаюсь.

Социология - не наука. У каждого - своя картина мира.

Хм... Я не специалист, но не стал бы заявлять так категорично. По заверениям специалистов, для разных задач подходят разные языки.

>

Да, есть такая ложная теория...

Почему ложная?

Тезис 1. Специализированные языки не применимы в изоляции от областей где они не работают.

Так, любой язык применим в некоторой области.

Вопрос только в том, покрывает ли эта область область Вашей задачи.

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

И, при этом, критерии, по которым он признаётся "лучшим" и определяют область его применимости.

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

Тот же VHDL в своей области, наверное будет выгоднее использовать, чем пытаться

приспособить универсальный язык, типа Ada?

Нет?

Да, но см. пункт 1.

Если Вы можете изолировать проблему так, чтобы применять специализированный язык - отлично. Беда в том, что на практике так почти никогда не бывает. И тренд идет в эту сторону. Но решения о том, что вот тут-то это как раз так, принимаются на основе поверхностного анализа не осведомленными людьми, обычно ничего не смыслящими в разработке ПО, как то, менеджерами, инженерами и т.п. Они же одержимы идеей, что знать программирование не нужно. А заменить разработку ПО и квалифицированных программистов, всегда можно купив другой софт (каков полет мысли!) - "тулзу". Причем качество "тулзы" определяется ее стоимостью. А если не получается, то для старой "тулзы" приобретается новая. А для нее еще одна и т.д. Индустрия кормит саму себя. И заметьте, если бы весть этот софт делал бы свое дело, рынок бы рухнул.

Как Вам такой механизм отбора?

DEC этого не понимал, ему не было места в этом лучшем из миров.

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

------------------------------------

Yahoo! Groups Links

18.05.2013 21:52, Sergey Kirkorov пишет:

К сожалению об этом (ВИТ-Ada 2013) до сих пор нет информации на www.Ada-ru.org

 

Пришлите, что нужно выложить на сайт, я выложу.

 

--

Maxim Reznik

Оффтопик оставлю, но перенесу вниз. :-)

 

18.05.2013 11:52, Dmitry A. Kazakov пишет:

On Sat, 18 May 2013 09:17:33 +0400, you wrote:

 

Dmitry A. Kazakov пишет:

 

LaTeX, я пару статей в нем делал. Но чтобы документацию, это надо быть настоящим джедаем.

http://www.texmacs.org/tmweb/home/screenshots.en.html

:-)

Я, правда, очень давно пользовался. Но просто и удобно.

 

Могу порекомендовать MiKTeX.

 

http://miktex.org

Спасибо.

 

1. Слишком сложно содержать документацию актуальной коду.

Врут.

В плане?

 

Есть такая вещь как процесс разработки софта. Документирование его интегральная часть. Когда говорят о сложности имеют ввиду писание документации потом, когда-нибудь, или что-то вроде того.

Угу, вот только, как пишут, не процесс, а процессы. Штук 100500 методик и методов, и всё-равно, что-то всё новые и новые появляются (и говорят о сложности

работы с документацией)...

Почему?

 

3. Неплохо бы создавать код из документации (а не документацию из кода)...

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

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

Говорят, что говорят вот про это:

http://www.literateprogramming.com/

1. Имеет ли смысл?

 

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

Хм... Звучит, конечно, хорошо. А на практике?

 

Несколько выдернутых цитат Кнута на этот счёт:

"Что до меня, литературное программирование — это самая важная вещь, которая вышла из проекта TeX. Оно не только позволило мне быстрее и надежнее, чем когда-либо, писать и поддерживать программы, оно было одним из самых больших источников радости с 1980-ых, и временами без него невозможно было обойтись. Некоторые из моих главных программ, таких как мета-симулятор MMIX, не могли бы быть написаны с помощью любой другой методологии о которой я когда-либо слышал. Они были

просто чересчур сложны для моего ограниченного мозга; без

литературного программирования подобное предприятие просто провалилось бы."

...

"Давайте изменим традиционные приоритеты в создании программ: вместо представления о нашей задаче как о создании инструкций «Что делать?» для компьютера сконцентрируемся на объяснении другим людям описаний нашего видения того, что под управлением программы должен делать компьютер."

...

"Я верю, что пришло время для существенно лучшего документирования программ, и что мы можем достигнуть этого сделав программы

литературными произведениями."

 

Является ли написание эссе о том, как программа работает (и, затем, генерация), решением проблемы документирования, как писал Кнут?

 

2. Имеет ли смысл, применительно к Ada?

 

Да, но с пониманием того, что это все-таки совсем не литература.

Т.е. всё-таки...

А вы какие-нибудь формальные методики для описания требований и, затем, генерации, например, модели используете?

И, если да, то какие инструменты?

 

BASIC там нет вообще.

 

Зато, там есть С.

Да, но C неплох и очень гибок. В отличие от Ada, его синтаксис практически не избыточен. Правда, у этого есть и другие стороны.

 

Хм... Я не специалист, но не стал бы заявлять так категорично. По заверениям специалистов, для разных задач подходят разные языки.

 

Да, есть такая ложная теория...

Почему ложная?

Тезис 1. Специализированные языки не применимы в изоляции от областей где они не работают.

Так, любой язык применим в некоторой области.

 

Вопрос только в том, покрывает ли эта область область Вашей задачи.

Согласен.

 

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

И, при этом, критерии, по которым он признаётся "лучшим" и определяют область его применимости.

 

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

Ну, если это абсолютная универсальность.

Говорить на универсальном языке я смогу?

 

Для чего мне то, что нельзя измерить?

Как я буду сравнивать, выяснять динамику изменений?

 

 

 

offtopic:

VisualBasic тянется не за счёт мифического "негативного

отбора", а исключительно за счёт платформы, которая на него завязана.

Как и в биологии, отбор - закон эмпирический. А механизмы могут быть разными. Например, религиозный: BASIC, С, PHP нам посланы за грехи наши, и знаменуют надвигающийся конец света. Так лучше? (:-))

Гы, а если в тёмной подворотне вам встретится WEB-программист, накурившийся манов PHP? ;-)

 

Во-первых, я не вижу причин для обобщения.

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

 

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

 

C - годы разработки, большое сообщество, огромные массивы кода, готовых решений для разных платформ.

C# - маркетинг, в большинстве своём, малограмотные разработчики, неустоявшаяся структура языка, избыточность конструкций, MSIL, если уж на то пошло... Ada - большие затраты на разработку, крупные специалисты и учёные, разработавшие

язык с большим опытом разработки широко применяемых языков (которые явно понимали, что они делали, для чего и почему), задачи, в которых требуется надёжность, при этом упрощение чтения в ущерб простоте написания и принуждение разработчика к определённому стилю.

 

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

Где-то вместе с этим, - общественное мнение, определяющее отношение к этому (которое может формироваться намеренно).

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

Затем, инструментальная поддержка.

 

VisualBasic распространён исключительно за счёт инструментальной поддержки: нет приемлемых альтернатив.

PHP: до этого были альтернативы, типа Perl, но по каким-то причинам они не удовлетворяли разработчиков (Perl как раз претендовал на универсальность).

Это я к тому, что "отбор" не нечто фатальное, а всего лишь система факторов, действующих на некий объект или класс объектов.

Типа, набора фильтров, процент прохождения через которые определяется степенью соответствия каждому.

 

Это как Brainfuck - язык плохой, но

как бы шутейно. Вы не верите в злые намерения его разработчиков. Вы думаете, что на самом деле, они добрые. Могут погладить бездомного котенка. Пропустить велосипедиста на перекрестке. А Brainfuck, ну, так получилось.

Честно говоря, я не мыслю такими категориями.

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

Кстати, говорили, что его на практике кто-то хотел использовать в сфере AI...

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

 

Их намерения никак не влияют на конечный продукт.

 

Окошки - самая плохая ОС. Они же самые популярные.

https://www.youtube.com/watch?v=e8M6S8EKbnU

Смотрите первый комментарий там.

Ранняя реклама, включая MS-DOS, настолько же истерична и крайне агрессивна.

 

См. выше. Но одной агрессивности не достаточно. Важна органичность. Сделать по-настоящему плохой продукт сложно.

:-)

Я имею ввиду не агрессивность Баллмера, а стиль политики.

"Если ты не можешь сделать что-то хорошо, по крайней мере, сделай так, чтобы это

выглядело хорошо."

Б. Гейтс.

 

Это один из факторов распространённости.

 

Интел - самая плохая архитектура.

o.O Intel? В каком плане?

x86 выиграл и у PDP-11, и у 68к. Pentium у Alpha (который был первым 64-бит процессором, первым 500МГц процессором)

Да, про Alpha я знаю. Я не силён в архитектурах. И немного представляю только архитектуру Intel.

Про Alpha слышал, хорошо отзывались, насчёт Intel, да - не очень. По крайней мере, его ассемблер ну тоже, мягко говоря, не очень, по-моему. Тут, конечно, они случайно удачно попали: их тоже вытащила платформа, которая была на них ориентирована.

 

Любопытно конечно: чем был Alpha так хорош?

 

А в продукты микрософта веришь на подсознательном уровне. И, потому, люди их покупают.

На каком уровне?

Я не верю.

 

При том, несмотря на кучу недостатков, у Unix и подобных грамотно разработанная

архитектура.

Unix был самой плохой ОС до MS-DOS. Но был повержен.

А почему Multics не взлетел?

Почему вообще кто-то стал заниматься Unix, если всё и так было хорошо?

Unix обладает достаточной стройной и прозрачной архитектурой.

 

У VMS тоже, полагаю, куча недостатков была.

Первое, что приходит в голову: закрытость интерфейсов, сложность, отсутствие полноценной документации на разных языках, нежелание компании делиться исходными

кодами, один интерпретатор и графическая среда, одно ядро и отсутствие драйверов

к множеству оборудования.

 

Да ладно Вам! DEC поставляла исходники и полную документацию, которая была великолепной, когда Unix Sys V приходил с уродскими man-ами.

http://lib.ru/MAN/DEMOS210/xenix.txt

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

В т.ч., про реальные, а не те, которые перечислены мною навскидку.

Так что, насчёт некоего "отрицательного отбора", - сомневаюсь.

 

Социология - не наука. У каждого - своя картина мира.

Не очень понял, что вы хотели этим сказать.

 

Тот же VHDL в своей области, наверное будет выгоднее использовать, чем пытаться

приспособить универсальный язык, типа Ada?

Нет?

 

Да, но см. пункт 1.

 

Если Вы можете изолировать проблему так, чтобы применять специализированный язык - отлично. Беда в том, что на практике так почти никогда не бывает. И тренд идет в эту сторону. Но решения о том, что вот тут-то это как раз так, принимаются на основе поверхностного анализа не осведомленными людьми, обычно ничего не смыслящими в разработке ПО, как то, менеджерами, инженерами и т.п. Они же одержимы идеей, что знать программирование не нужно. А заменить разработку ПО и квалифицированных программистов, всегда можно купив другой софт (каков полет мысли!) - "тулзу". Причем качество "тулзы" определяется ее стоимостью. А если не получается, то для старой "тулзы" приобретается новая. А для нее еще одна и т.д. Индустрия кормит саму себя. И заметьте, если бы весть этот софт делал бы свое дело, рынок бы рухнул.

 

Как Вам такой механизм отбора?

В РФ? Ну что-то похожее на реальность, я так думаю. Правда, программирование, мне кажется, частный случай.

Я ж не про это: меня интересует такой сферический случай в вакууме, когда всё рационально и оптимально, а не во имя распилов и откатов.

К тому же, ведь, наверное, ПО кому-то нужно, и не только государственным компаниям, которым нужно выбить бюджет, но и частным (тем частным, которые не дотируются государством), закупающим его на свои деньги для повышения эффективности и прибылей?

On Sun, 19 May 2013 23:20:43 +0400, you wrote:

18.05.2013 11:52, Dmitry A. Kazakov пишет:

 

Есть такая вещь как процесс разработки софта. Документирование его интегральная часть. Когда говорят о сложности имеют ввиду писание документации потом, когда-нибудь, или что-то вроде того.

Угу, вот только, как пишут, не процесс, а процессы. Штук 100500 методик и методов, и всё-равно, что-то всё новые и новые появляются (и говорят о сложности

работы с документацией)...

Почему?

 

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

3. Неплохо бы создавать код из документации (а не документацию из кода)...

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

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

Говорят, что говорят вот про это:

http://www.literateprogramming.com/

1. Имеет ли смысл?

 

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

Хм... Звучит, конечно, хорошо. А на практике?

 

Как бы там ни было на практике, это все равно лучше чем литература. Вы видели, чтобы хорошие книги писал коллектив авторов? (На Стругацких и Ильфа с Петровым просьба не ссылаться)

 

Несколько выдернутых цитат Кнута на этот счёт:

"Что до меня, литературное программирование — это самая важная вещь, которая вышла из проекта TeX.

 

Возможно для него. Для нас TeX, как система редактирования текстов, являет собой пример плохого, во многих отношениях, ПО. И принцип работы (язык), и реализация (огромен, неэффективен, чудовищная диагностика), и концепция развития (шиизм) не удовлетворительны.

 

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

 

"Давайте изменим традиционные приоритеты в создании программ: вместо представления о нашей задаче как о создании инструкций «Что делать?» для компьютера сконцентрируемся на объяснении другим людям описаний нашего видения того, что под управлением программы должен делать компьютер."

 

Это называется техническими требованиями, use-cases и т.д. Это - не программа.

 

"Я верю, что пришло время для существенно лучшего документирования программ, и что мы можем достигнуть этого сделав программы

литературными произведениями."

 

Является ли написание эссе о том, как программа работает (и, затем, генерация),

решением проблемы документирования, как писал Кнут?

 

Разумеется, если Вы Бог, Вы говорите "да будет свет!", и был свет. Смертные люди строят электростанции...

 

2. Имеет ли смысл, применительно к Ada?

 

Да, но с пониманием того, что это все-таки совсем не литература.

Т.е. всё-таки...

А вы какие-нибудь формальные методики для описания требований и, затем, генерации, например, модели используете?

 

Если клиент требует (и платит), то да. Иначе - нет. В генерацию я совсем не верю.

 

И, если да, то какие инструменты?

 

Rational Rose. Но не далее диаграмм.

 

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

И, при этом, критерии, по которым он признаётся "лучшим" и определяют область его применимости.

 

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

Ну, если это абсолютная универсальность.

Говорить на универсальном языке я смогу?

 

Мы рассматриваем написание программ. Универсальность, конечно,

относительна.

 

Для чего мне то, что нельзя измерить?

 

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

 

Как я буду сравнивать, выяснять динамику изменений?

 

Изменений чего?

 

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

 

Причины есть, но, как во всех эмпирических дисциплинах, они не являются производными от фундаментальных законов. Короче - "коллекционирование марок".

Это я к тому, что "отбор" не нечто фатальное, а всего лишь система факторов, действующих на некий объект или класс объектов.

 

Так и в смерти нет ничего фатального - набор факторов и гражданская панихида потом...

 

Типа, набора фильтров, процент прохождения через которые определяется степенью соответствия каждому.

 

Наукообразное объяснение непонятного явления. НепОнятость отрицает научность.

 

Это как Brainfuck - язык плохой, но

как бы шутейно. Вы не верите в злые намерения его разработчиков. Вы думаете, что на самом деле, они добрые. Могут погладить бездомного котенка. Пропустить велосипедиста на перекрестке. А Brainfuck, ну, так получилось.

Честно говоря, я не мыслю такими категориями.

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

Кстати, говорили, что его на практике кто-то хотел использовать в сфере AI...

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

 

Их намерения никак не влияют на конечный продукт.

 

Выбор продукта определяется не его объективными свойствами, и не

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

 

Интел - самая плохая архитектура.

o.O Intel? В каком плане?

x86 выиграл и у PDP-11, и у 68к. Pentium у Alpha (который был первым 64-бит процессором, первым 500МГц процессором)

Да, про Alpha я знаю. Я не силён в архитектурах. И немного представляю только архитектуру Intel.

Про Alpha слышал, хорошо отзывались, насчёт Intel, да - не очень. По крайней мере, его ассемблер ну тоже, мягко говоря, не очень, по-моему.

 

Alpha - RISC. Программировать его на ассемблере было бы странно. Ассемблер PDP и VAX не имел и не имеет себе равных до сих пор. Я на нем компиляторы писал.

 

Тут, конечно, они случайно удачно попали: их тоже вытащила платформа, которая была на них ориентирована.

 

Любопытно конечно: чем был Alpha так хорош?

 

http://en.wikipedia.org/wiki/DEC_Alpha

 

А в продукты микрософта веришь на подсознательном уровне. И, потому, люди их покупают.

На каком уровне?

Я не верю.

 

Так ведь на подсознательном же. Вы может и не верите, а ваше подсознание верит! (:-))

 

При том, несмотря на кучу недостатков, у Unix и подобных грамотно разработанная

архитектура.

Unix был самой плохой ОС до MS-DOS. Но был повержен.

А почему Multics не взлетел?

 

Я его плохо знаю.

 

Почему вообще кто-то стал заниматься Unix, если всё и так было хорошо?

 

Потому что люди (Thompson, Ritchie, Kernighan) не были делом заняты в AT&T, да еще и свободную машину получили (DEC-овскую, между прочим). Социализм рождает монстров, как известно. Потом Unix распространялся в университетах Штатов, опять же - бездельники, и вагон социализма. Идея охватила массы, как говорил Ильич. И нате! (:-))

Unix обладает достаточной стройной и прозрачной архитектурой.

 

Это как? fork стройная архитектура? Или может быть драйверы в виде файлов?

У VMS тоже, полагаю, куча недостатков была.

Первое, что приходит в голову: закрытость интерфейсов, сложность, отсутствие полноценной документации на разных языках, нежелание компании делиться исходными

кодами, один интерпретатор и графическая среда, одно ядро и отсутствие драйверов

к множеству оборудования.

 

Да ладно Вам! DEC поставляла исходники и полную документацию, которая была великолепной, когда Unix Sys V приходил с уродскими man-ами.

http://lib.ru/MAN/DEMOS210/xenix.txt

 

Это похоже на перевод с книжки Ritchie.

 

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

 

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

 

В отличие от Unix DEC давал отличное руководство по написанию драйверов. Я сам написал два драйвера: виртуального диска и эмуляции FPU для RSX.

Переводной документации не было ни у кого. И это не могло влиять на рынок США, который был определяющим и тогда и сейчас.

 

Интерпретатор, не знаю что. Командные строки? В Unix их много изза того, что все они - чудовищная дрянь. Сравнивать sh или csh с DCL просто смешно.

Графическая среда X11 и там, и там.

 

Зачем надо много ядер? VMS имел RT вариант (а Unix и рядом не стоял с RT).

Так что, насчёт некоего "отрицательного отбора", - сомневаюсь.

 

Социология - не наука. У каждого - своя картина мира.

Не очень понял, что вы хотели этим сказать.

 

Что все это, по гамбургскому счету, - треп. Не надо относиться к нему слишком серьезно.

Тот же VHDL в своей области, наверное будет выгоднее использовать, чем пытаться

приспособить универсальный язык, типа Ada?

Нет?

 

Да, но см. пункт 1.

 

Если Вы можете изолировать проблему так, чтобы применять специализированный язык - отлично. Беда в том, что на практике так почти никогда не бывает. И тренд идет в эту сторону. Но решения о том, что вот тут-то это как раз так, принимаются на основе поверхностного анализа не осведомленными людьми, обычно ничего не смыслящими в разработке ПО, как то, менеджерами, инженерами и т.п. Они же одержимы идеей, что знать программирование не нужно. А заменить разработку ПО и квалифицированных программистов, всегда можно купив другой софт (каков полет мысли!) - "тулзу". Причем качество "тулзы" определяется ее стоимостью. А если не получается, то для старой "тулзы" приобретается новая. А для нее еще одна и т.д. Индустрия кормит саму себя. И заметьте, если бы весть этот софт делал бы свое дело, рынок бы рухнул.

 

Как Вам такой механизм отбора?

В РФ? Ну что-то похожее на реальность, я так думаю. Правда, программирование, мне кажется, частный случай.

 

Почему же РФ? Я РФ как-то вообще не рассматриваю, в силу малой значимости. Но я не думаю, что в РФ сильно по-другому. Я там давно не был. Не знаю.

Я ж не про это: меня интересует такой сферический случай в вакууме, когда всё рационально и оптимально, а не во имя распилов и откатов.

 

Дело не в воровстве, а в том как устроен бизнес большой компании

разрабатывающей ПО. Везде одинаково.

 

К тому же, ведь, наверное, ПО кому-то нужно, и не только государственным компаниям, которым нужно выбить бюджет, но и частным (тем частным, которые не дотируются государством), закупающим его на свои деньги для повышения эффективности и прибылей?

 

И как Вы себе это представляете? Зубной техник оценивает эффективность программ бухгалтерского учета и регистрации пациентов для своей практики?

Рынка ПО просто не существует. Именно потому отрицательный отбор и работает. Был бы рынок, не было бы микрософта.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

2. Имеет ли смысл, применительно к Ada?

 

Да, но с пониманием того, что это все-таки совсем не литература.

Т.е. всё-таки...

А вы какие-нибудь формальные методики для описания требований и, затем, генерации, например, модели используете?

 

Если клиент требует (и платит), то да. Иначе - нет.

Я не про клиента.

Вы лично, чтобы ускорить и облегчить разработку, что применяете?

 

В генерацию я совсем не верю.

А подробнее?

Почему?

Чем плоха генерация (хотя бы каркаса) по сравнению с написанием вручную?

 

20.05.2013 12:25, Dmitry A. Kazakov пишет:

On Sun, 19 May 2013 23:20:43 +0400, you wrote:

18.05.2013 11:52, Dmitry A. Kazakov пишет:

 

Есть такая вещь как процесс разработки софта. Документирование его интегральная часть. Когда говорят о сложности имеют ввиду писание документации потом, когда-нибудь, или что-то вроде того.

Угу, вот только, как пишут, не процесс, а процессы. Штук 100500 методик и методов, и всё-равно, что-то всё новые и новые появляются (и говорят о сложности

работы с документацией)...

Почему?

 

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

Но для чего такой процесс разрабатывать учёным, которые не получат денег с манаджеров?

Может, просто люди ищут оптимальный подход?

 

3. Неплохо бы создавать код из документации (а не документацию из кода)...

В принципе, код на Аде сам по-себе документация. Это было одной из идей, создатели языка руководствовались. Отсюда некоторая многословность и

избыточность.

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

Говорят, что говорят вот про это:

http://www.literateprogramming.com/

1. Имеет ли смысл?

 

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

Хм... Звучит, конечно, хорошо. А на практике?

 

Как бы там ни было на практике, это все равно лучше чем литература. Вы видели, чтобы хорошие книги писал коллектив авторов? (На Стругацких и Ильфа с Петровым просьба не ссылаться)

Причём тут Стругацкие? "Стругацкие писали свои книги в стиле XP парадигмы". :-] Лучше взять тогда техническую литературу (хотя, опять же, как я представляю, литература весьма далека от того, что хотел показать Кнут).

Книги Олиферов, например, пишут муж с женой. Весьма неплохо пишут.

Но это отступление от оффтопика. В данном случае, пишется не книга, а алгоритм на человеческом языке (плюс руководство).

Что ж в этом плохого?

 

Несколько выдернутых цитат Кнута на этот счёт:

"Что до меня, литературное программирование — это самая важная вещь, которая вышла из проекта TeX.

 

Возможно для него. Для нас TeX, как система редактирования текстов, являет собой пример плохого, во многих отношениях, ПО. И принцип работы (язык), и реализация (огромен, неэффективен, чудовищная диагностика), и концепция развития (шиизм) не удовлетворительны.

Эээ... Поясните пожалуйста значение слова "шиизм", в данном контексте.

> Кнут - великий человек, но заурядный программист. Разработка алгоритмов и

программирование - вещи теперь уже мало связанные.

Кхм. Издеваетесь? Программа, в любом понимании, - не есть реализация алгоритма?

"Давайте изменим традиционные приоритеты в создании программ: вместо представления о нашей задаче как о создании инструкций «Что делать?» для компьютера сконцентрируемся на объяснении другим людям описаний нашего видения того, что под управлением программы должен делать компьютер."

 

Это называется техническими требованиями, use-cases и т.д. Это - не программа.

Это не use-case, если понимать под этим стандартный термин, который определяется, как "сценарий использования".

И указывает на то, как действует *пользователь*.

Т.е., это "сырьё" для фазы анализа требований.

О программе тут действительно речи нет.

 

А Кнут пишет про *компьютер*. Т.е., фактически, он говорит о фазе проектирования.

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

Во-вторых, пытается абстрагироваться от деталей реализации (в большей степени, за счёт изменения парадигмы).

В-третьих, он говорит о том, что программа - описание для людей (иначе надо было

бы писать в машинных кодах), в первую очередь, и лишь во вторую для компилятора.

Так почему бы не объяснять непонятные места на человеческом языке, раз имеется такая возможность?

 

Ну это моё понимание, конечно.

 

"Я верю, что пришло время для существенно лучшего документирования программ, и что мы можем достигнуть этого сделав программы

литературными произведениями."

 

Является ли написание эссе о том, как программа работает (и, затем, генерация),

решением проблемы документирования, как писал Кнут?

 

Разумеется, если Вы Бог, Вы говорите "да будет свет!", и был свет.

Нет пока. Ещё ищу курсы.

 

Смертные люди строят электростанции...

Ну да. Фукусиму?

 

И что настроили для того, чтобы проблему решить?

 

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

И, при этом, критерии, по которым он признаётся "лучшим" и определяют область его применимости.

 

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

Ну, если это абсолютная универсальность.

Говорить на универсальном языке я смогу?

 

Мы рассматриваем написание программ. Универсальность, конечно,

относительна.

Значит, универсальный язык имеет границы применимости?

Если уточнить каких программ..?

 

Для чего мне то, что нельзя измерить?

 

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

Согласен.

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

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

Но ваш главный программист Вася ушёл в запой, потому что уволили писательницу интерфейсов руками - Лену (универсальный язык же, теперь формочки тоже в нём кропать будем!), которая ему, ну прям очень помогала в работе.

 

Как посчитать корреляцию между временной неработоспособностью Васи и изменением скорости создания кода, при замене всего на универсальный язык и сокращении штата программистов, которые писали части системы на специализированных языках? Насколько это будет сложнее и достовернее измерения некоего конкретного параметра?

 

Может, стоит попробовать выяснить границы применимости..?

 

Это к тому, что говорили, про некую "абсолютную универсальность", которая, как мне кажется, особого практического смысла не имеет.

Следовательно, как и некий универсальный язык, который (опять же, как мне кажется) будет более монструозный, чем C++11.

 

Как я буду сравнивать, выяснять динамику изменений?

 

Изменений чего?

Любого показателя. Хотя бы той же скорости написания кода. "Везде" - неизмеримо и неконкретно.

 

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

 

Причины есть, но, как во всех эмпирических дисциплинах, они не являются производными от фундаментальных законов. Короче - "коллекционирование марок".

Ну да.

 

Это я к тому, что "отбор" не нечто фатальное, а всего лишь система факторов, действующих на некий объект или класс объектов.

 

Так и в смерти нет ничего фатального - набор факторов и гражданская панихида потом...

Если это не ваша смерть для вас.

Пока вы читали предыдущую строчку, в мире умерло где-то два человека. Сейчас уже где-то человек пять. :-)

Не считая тысяч, умерших сейчас, особей других видов.

Вы сильно опечалены?

 

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

Если меняют, значит имеются причины.

Да, не всегда рациональные, но не более того.

 

Типа, набора фильтров, процент прохождения через которые определяется степенью соответствия каждому.

 

Наукообразное объяснение непонятного явления. НепОнятость отрицает научность.

Нужно оставить попытки объяснить, чтобы это не выглядело наукообразно?

Это как Brainfuck - язык плохой, но

как бы шутейно. Вы не верите в злые намерения его разработчиков. Вы думаете, что на самом деле, они добрые. Могут погладить бездомного котенка. Пропустить велосипедиста на перекрестке. А Brainfuck, ну, так получилось.

Честно говоря, я не мыслю такими категориями.

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

Кстати, говорили, что его на практике кто-то хотел использовать в сфере AI...

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

 

Их намерения никак не влияют на конечный продукт.

 

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

Вы хотите сказать, что выбор - результат некоего эмоционального порыва? :-) Идут себе директора с инженерами по интернет-магазинам и смотрят: "Ой, какой симпатяжка этот RedHat! Мне так нравится красная шляпка. Давай купим и поставим его во все наши танчики, а?"

 

Почему же вы тогда пользуетесь Linux и Windows, а не OpenVMS?

 

А в продукты микрософта веришь на подсознательном уровне. И, потому, люди их покупают.

На каком уровне?

Я не верю.

 

Так ведь на подсознательном же. Вы может и не верите, а ваше подсознание верит! (:-))

Мда? Вы не преувеличиваете силу несознательного?

В чём же проявляется "вера моего подсознания"?

 

При том, несмотря на кучу недостатков, у Unix и подобных грамотно разработанная

архитектура.

Unix был самой плохой ОС до MS-DOS. Но был повержен.

А почему Multics не взлетел?

 

Я его плохо знаю.

Писали, что он был слишком сложен.

Да, работал:

"LCS research on Multics ended in the late 1970s, and Bull ended Multics development in 1985. MIT shut down its Multics service in 1988. The last Multics

system was deactivated in 2000."

[ http://web.mit.edu/multics-history/ ]

 

Но, увы. Unix его обогнал. Видимо, люди в университетах США оказались недостаточно умны, чтобы выбрать что-то лучше или написать что-то своё (не Unix-подобное)...

 

Почему вообще кто-то стал заниматься Unix, если всё и так было хорошо?

 

Потому что люди (Thompson, Ritchie, Kernighan) не были делом заняты в AT&T,

Каким же делом им нужно было заниматься: компьютеры перетаскивать? :-) Следуя вашей логике, почему, в таком случае, они не могли заниматься неделом в Multics, которую сами же и разрабатывали?

Ведь, раз всё было хорошо, возможно было бы найти занятия поинтереснее написания

другой своей ОС, не так ли?

 

да еще и свободную машину получили (DEC-овскую, между прочим). Социализм рождает монстров, как известно.

Слышал такое про "сон разума". А социализм, говорят, в Норвегии. И вполне нормально живут (шибко либеральная партия + Брейвик - не в счёт).

Потом Unix распространялся в университетах

Штатов, опять же - бездельники, и вагон социализма. Идея охватила массы, как говорил Ильич. И нате! (:-))

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

Unix обладает достаточной стройной и прозрачной архитектурой.

 

Это как? fork стройная архитектура?

И что такого плохого в fork?

 

Или может быть драйверы в виде файлов?

Драйверы в виде модулей?

Вы про устройства хотели сказать?

Что плохого в том, что я могу взять и подключить настоящий жёсткий диск к ВМ, как файл?

Или в том, что я могу читать из порта обычным read?

А такая удобная штука, как подключение файла, как блочного устройства, - это тоже последствия неграмотной архитектуры?

 

У VMS тоже, полагаю, куча недостатков была.

Первое, что приходит в голову: закрытость интерфейсов, сложность, отсутствие полноценной документации на разных языках, нежелание компании делиться

исходными

кодами, один интерпретатор и графическая среда, одно ядро и отсутствие

драйверов

к множеству оборудования.

 

Да ладно Вам! DEC поставляла исходники и полную документацию, которая была великолепной, когда Unix Sys V приходил с уродскими man-ами.

http://lib.ru/MAN/DEMOS210/xenix.txt

 

Это похоже на перевод с книжки Ritchie.

Ну вот, всё вам не нравится!

Это потому что ваше подсознание зомбировано DEC и OpenVMS: если бы в OpenVMS были маны, вы бы назвали их прекрасными. :-]

В любом случае, руководство от M$ для их ОС Xenix весьма неплохое (и не важно списанное ли откуда-то), как вы думаете?

 

А вообще, я читал у него только одну книжку, наиболее известную.

Подскажите, что за книжка, про которую вы говорили: хоть посмотрю на неё.

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

 

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

 

В отличие от Unix DEC давал отличное руководство по написанию драйверов. Я сам написал два драйвера: виртуального диска и эмуляции FPU для RSX.

Про драйвера ничего не могу сказать.

Особенно про Unix.

Но, говорят, что в Linux есть очень хорошая документация на этот счёт...

Переводной документации не было ни у кого. И это не могло влиять на рынок США, который был определяющим и тогда и сейчас.

 

Интерпретатор, не знаю что. Командные строки? В Unix их много изза того, что все они - чудовищная дрянь. Сравнивать sh или csh с DCL просто смешно.

Не согласен. В Unix их много потому, что разным людям нравятся разные вещи. Unix

даёт выбор.

Sh очень стар. Csh - неплох.

DCL, с первого взгляда мне не понравился.

Сравнивать же его с Bash (и, тем более, с Zsh) просто смешно.

 

Графическая среда X11 и там, и там.

 

Зачем надо много ядер?

Затем, что есть много задач и архитектур.

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

 

VMS имел RT вариант (а Unix и рядом не стоял с RT).

Ну да, говорят, что и не затачивался на это.

 

Так что, насчёт некоего "отрицательного отбора", - сомневаюсь.

 

Социология - не наука. У каждого - своя картина мира.

Не очень понял, что вы хотели этим сказать.

 

Что все это, по гамбургскому счету, - треп. Не надо относиться к нему слишком серьезно.

 

Тот же VHDL в своей области, наверное будет выгоднее использовать, чем пытаться

приспособить универсальный язык, типа Ada?

Нет?

 

Да, но см. пункт 1.

 

Если Вы можете изолировать проблему так, чтобы применять специализированный язык - отлично. Беда в том, что на практике так почти никогда не бывает. И тренд идет в эту сторону. Но решения о том, что вот тут-то это как раз так, принимаются на основе поверхностного анализа не осведомленными людьми, обычно ничего не смыслящими в разработке ПО, как то, менеджерами, инженерами и т.п. Они же одержимы идеей, что знать программирование не нужно. А заменить разработку ПО и квалифицированных программистов, всегда можно купив другой софт (каков полет мысли!) - "тулзу". Причем качество "тулзы" определяется ее стоимостью. А если не получается, то для старой "тулзы" приобретается новая. А для нее еще одна и т.д. Индустрия кормит саму себя. И заметьте, если бы весть этот софт делал бы свое дело, рынок бы рухнул.

 

Как Вам такой механизм отбора?

В РФ? Ну что-то похожее на реальность, я так думаю. Правда, программирование, мне кажется, частный случай.

 

Почему же РФ? Я РФ как-то вообще не рассматриваю, в силу малой значимости. Но я не думаю, что в РФ сильно по-другому. Я там давно не был. Не знаю.

А вы, полагаю, в Германии?

И там тоже всё плохо?

 

Я ж не про это: меня интересует такой сферический случай в вакууме, когда всё рационально и оптимально, а не во имя распилов и откатов.

 

Дело не в воровстве, а в том как устроен бизнес большой компании разрабатывающей ПО. Везде одинаково.

Разве они не стремятся максимизировать прибыль и уменьшить издержки?

К тому же, ведь, наверное, ПО кому-то нужно, и не только государственным компаниям, которым нужно выбить бюджет, но и частным (тем частным, которые не дотируются государством), закупающим его на свои деньги для повышения эффективности и прибылей?

 

И как Вы себе это представляете? Зубной техник оценивает эффективность программ бухгалтерского учета и регистрации пациентов для своей практики?

Вы утрируете.

Бухгалтерский учёт - отдельная тема, поскольку там практически нет выбора. Оценивать может эксперт. В регистратуре может вполне оценить персонал (в данном случае, конечно, не факт).

 

А в случае разработки ПО, разве не может оценить тот, кому предназначается закупаемый инструмент?

 

Рынка ПО просто не существует. Именно потому отрицательный отбор и работает. Был бы рынок, не было бы микрософта.

И, тем не менее, есть же конкуренция..?

On Tue, 21 May 2013 22:53:12 +0400, you wrote:

 

2. Имеет ли смысл, применительно к Ada?

 

Да, но с пониманием того, что это все-таки совсем не литература.

Т.е. всё-таки...

А вы какие-нибудь формальные методики для описания требований и, затем, генерации, например, модели используете?

 

Если клиент требует (и платит), то да. Иначе - нет.

Я не про клиента.

Вы лично, чтобы ускорить и облегчить разработку, что применяете?

 

Нет. Это существенно замедляет и осложняет. Формальные методы обеспечивают качество и/или сертификацию. А это - редко когда требуется.

 

В генерацию я совсем не верю.

А подробнее?

 

Если бы верил, то уволился и пошел бы учиться другому. Зачем нужны программисты, если программы можно генерировать.

 

Почему?

Чем плоха генерация (хотя бы каркаса) по сравнению с написанием вручную?

 

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

 

Есть такая вещь как процесс разработки софта. Документирование его интегральная часть. Когда говорят о сложности имеют ввиду писание документации потом, когда-нибудь, или что-то вроде того.

Угу, вот только, как пишут, не процесс, а процессы. Штук 100500 методик и методов, и всё-равно, что-то всё новые и новые появляются (и говорят о сложности

работы с документацией)...

Почему?

 

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

Но для чего такой процесс разрабатывать учёным, которые не получат денег с манаджеров?

 

Ученым надо публиковаться. Иначе - не дадут грантов. Менеджерам на эти писульки - плевать. Процессы, на которые им не плевать, разрабатывают учреждения и бюро стандартов для получения сертификации.

 

Может, просто люди ищут оптимальный подход?

 

В каком-то смысле да. Только подход менеджера проекта это - одно, подход системного архитектора - другое, а подход программиста - третье.

 

Но это отступление от оффтопика. В данном случае, пишется не книга, а алгоритм на человеческом языке (плюс руководство).

Что ж в этом плохого?

 

Алгоритм - хорошо, но это не программирование.

 

Несколько выдернутых цитат Кнута на этот счёт:

"Что до меня, литературное программирование — это самая важная вещь, которая вышла из проекта TeX.

 

Возможно для него. Для нас TeX, как система редактирования текстов, являет собой пример плохого, во многих отношениях, ПО. И принцип работы (язык), и реализация (огромен, неэффективен, чудовищная диагностика), и концепция развития (шиизм) не удовлетворительны.

Эээ... Поясните пожалуйста значение слова "шиизм", в данном контексте.

 

Схизма.

 

Одним из принципов дизайна Ады было, в частности, недопущение несовместимых вариантов.

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

Кхм. Издеваетесь? Программа, в любом понимании, - не есть реализация алгоритма?

 

А автомобиль - реализация метода горячей штамповки.

 

А Кнут пишет про *компьютер*. Т.е., фактически, он говорит о фазе проектирования.

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

 

В это я верю еще меньше. Кстати, декларативность - антитеза

алгоритмичности. Вы ничего там с Кнутом не напутали?

 

Во-вторых, пытается абстрагироваться от деталей реализации (в большей степени, за счёт изменения парадигмы).

 

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

 

В-третьих, он говорит о том, что программа - описание для людей (иначе надо было

бы писать в машинных кодах), в первую очередь, и лишь во вторую для компилятора.

 

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

 

Так почему бы не объяснять непонятные места на человеческом языке, раз имеется такая возможность?

 

Может должно быть меньше непонятных мест? И опять, непонятных кому? В отличие от литературного произведения, даже среднего размера программу никто не понимает, и не может понять. Это физически не возможно. Поэтому программы разрабатываются так, чтобы этого не требовалось.

 

Смертные люди строят электростанции...

Ну да. Фукусиму?

 

Там погибло меньше людей, чем в год гибнет от ветряков и солнечных батарей (пожарные не станут тушить Ваш дом, если у Вас на крыше батареи). Про уголь я вообще не говорю.

 

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

И, при этом, критерии, по которым он признаётся "лучшим" и определяют область его применимости.

 

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

Ну, если это абсолютная универсальность.

Говорить на универсальном языке я смогу?

 

Мы рассматриваем написание программ. Универсальность, конечно,

относительна.

Значит, универсальный язык имеет границы применимости?

Если уточнить каких программ..?

 

Любых.

 

Это к тому, что говорили, про некую "абсолютную универсальность", которая, как мне кажется, особого практического смысла не имеет.

 

Как раз практический смысл в наличии. На универсальных языках можно написать все, что написать вообще можно. И доказательство тому то, что трансляторы специализированных языков пишутся на универсальных языках. Вопрос в том, нужны ли эти трансляторы, или специализации можно достичь менее радикальными методами, например, через компоненты.

 

Как я буду сравнивать, выяснять динамику изменений?

 

Изменений чего?

Любого показателя. Хотя бы той же скорости написания кода. "Везде" - неизмеримо

и неконкретно.

 

Так оно и есть неизмеримо. Скорость написания кода тоже неизмерима. И даже метрики объема кода не есть измерение. Болото.

 

Это я к тому, что "отбор" не нечто фатальное, а всего лишь система факторов, действующих на некий объект или класс объектов.

 

Так и в смерти нет ничего фатального - набор факторов и гражданская панихида потом...

Если это не ваша смерть для вас.

Пока вы читали предыдущую строчку, в мире умерло где-то два человека. Сейчас уже где-то человек пять. :-)

Не считая тысяч, умерших сейчас, особей других видов.

Вы сильно опечалены?

 

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

 

И как вы собираетесь это совершить? На что и как?

 

Если меняют, значит имеются причины.

 

Возможно. Если да, то см. выше. Если нет, см. там же.

 

Да, не всегда рациональные, но не более того.

 

Что никак не меняет исходную позицию, она же - финальная.

 

Типа, набора фильтров, процент прохождения через которые определяется степенью соответствия каждому.

 

Наукообразное объяснение непонятного явления. НепОнятость отрицает научность.

Нужно оставить попытки объяснить, чтобы это не выглядело наукообразно?

 

Это глубокий вопрос. Попытки - хорошо. Но дурачить себя и других не следует. Иначе рождаются социальные "науки", нумерология, климатология и т.п.

 

Идут себе директора с инженерами по интернет-магазинам и смотрят: "Ой, какой симпатяжка этот RedHat! Мне так нравится красная шляпка. Давай купим и поставим

его во все наши танчики, а?"

 

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

 

Почему же вы тогда пользуетесь Linux и Windows, а не OpenVMS?

 

Я пользуюсь тем, за что платят. Наши клиенты хотят Windows, и получают его. VMS я вспомнил как пример хорошей ОС. Если бы в VMS была бы вложена, хотя бы малая толика того, что было угрохано на Linux или Windows... Но этого не случилось.

 

А в продукты микрософта веришь на подсознательном уровне. И, потому, люди их покупают.

На каком уровне?

Я не верю.

 

Так ведь на подсознательном же. Вы может и не верите, а ваше подсознание верит! (:-))

Мда? Вы не преувеличиваете силу несознательного?

В чём же проявляется "вера моего подсознания"?

 

Вы, например, верите в Debian. А я - нет.

 

Человек эволюционировал принимать сложные решения в максимально короткое время. Пытавшихся принимать рационально обоснованные решения съедали львы и другие милые зверушки, непривычные к интеллигентным беседам. Этот механизм быстренько в нас срабатывает, когда надо сделать неочевидный выбор. Уже потом, сидя на верхней ветке и немного отдышавшись, мы начинаем

анализировать и поучать менее удачливых коллег внизу, у львов.

 

Но, увы. Unix его обогнал. Видимо, люди в университетах США оказались недостаточно умны, чтобы выбрать что-то лучше или написать что-то своё (не Unix-подобное)...

 

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

 

Почему вообще кто-то стал заниматься Unix, если всё и так было хорошо?

 

Потому что люди (Thompson, Ritchie, Kernighan) не были делом заняты в AT&T,

Каким же делом им нужно было заниматься: компьютеры перетаскивать? :-)

 

Я - не менеджер в AT&T.

 

да еще и свободную машину получили (DEC-овскую, между прочим). Социализм рождает монстров, как известно.

Слышал такое про "сон разума". А социализм, говорят, в Норвегии. И вполне нормально живут (шибко либеральная партия + Брейвик - не в счёт).

 

И этот социализм Норвегию уже практически доканал. Она чуть задержалась за счет нефти и рыбы. А так, Швеция, Дания и Голландия рядом, там - каюк уже случился. Но это - совсем оффтопик.

 

Unix обладает достаточной стройной и прозрачной архитектурой.

 

Это как? fork стройная архитектура?

И что такого плохого в fork?

 

Я про стройность спрашивал. А fork плох примерно всем. Начиная с бредовой идеи копирования памяти и состояния ресурсов. Авторы Unix-а по-видимому ничего не знали ни про мультизадачность, ни про ресурсы, кроме файлов. Хотя в то время уже существовали достаточно развитые системы разделения времени и ресурсов.

 

Или может быть драйверы в виде файлов?

Драйверы в виде модулей?

Вы про устройства хотели сказать?

Что плохого в том, что я могу взять и подключить настоящий жёсткий диск к ВМ, как файл?

 

В том, что это не файл, и вы не можете. Монтировать диск все равно нужно.

Или в том, что я могу читать из порта обычным read?

 

Для этого не нужно делать порт файлом.

 

А такая удобная штука, как подключение файла, как блочного устройства, - это тоже последствия неграмотной архитектуры?

 

Разумеется. Блочное устройство - не файл, а вид доступа. Кстати поверх блочности живут следующие уровни абстракции. Например файловая система. Или RDBMS, или что-нибудь еще.

 

http://lib.ru/MAN/DEMOS210/xenix.txt

 

Это похоже на перевод с книжки Ritchie.

Ну вот, всё вам не нравится!

 

Почему не нравится? Просто вспомнил, что похоже на книжку. Я ее еще в Союзе читал. Кстати не Ritchie, а похоже Браун. Желтая такая книжка.

 

Это потому что ваше подсознание зомбировано DEC и OpenVMS: если бы в OpenVMS были маны, вы бы назвали их прекрасными. :-]

 

Там был контекстный help, которым я пользовался. Он был встроен в IDE. Вообще, я начинал на машинах, где манов быть просто не могло, по причине отсутствия для этого памяти, как дисковой, так и оперативной. И в первых Unix машинах, на которых я работал, маны были печатными. Тоже из-за места. И это была очень плохая документация. Зато очень удобный, по тем временам, справочник.

 

Но вы спрашивали про документацию. Так вот, именно документация всегда была сильным местом DEC. Например:

 

http://pdp-11.org.ru/info.pl

 

Ранний Unix тут и рядом не стоял. RSX-11M - предшественник VMS. Кстати, troff сильно напоминает roff из RSX-11M в котором документация поставлялась в электронном виде.

 

А вообще, я читал у него только одну книжку, наиболее известную. Подскажите, что за книжка, про которую вы говорили: хоть посмотрю на неё.

 

Вроде бы C. Браун, "Операционная система Unix".

 

Зачем надо много ядер?

Затем, что есть много задач и архитектур.

 

И?

 

А также, много пользователей, про отношение которых вы писали выше.

 

А ядра тут приче

(Message over 64 KB, truncated)

22.05.2013 02:06, Dmitry A. Kazakov пишет:

2. Имеет ли смысл, применительно к Ada?

 

Да, но с пониманием того, что это все-таки совсем не литература.

Т.е. всё-таки...

А вы какие-нибудь формальные методики для описания требований и, затем, генерации, например, модели используете?

 

Если клиент требует (и платит), то да. Иначе - нет.

Я не про клиента.

Вы лично, чтобы ускорить и облегчить разработку, что применяете?

 

Нет. Это существенно замедляет и осложняет. Формальные методы обеспечивают качество и/или сертификацию. А это - редко когда требуется.

Какие формальные методы вы имеете ввиду?

Автоматические доказательства?

 

Интересно было бы услышать про автоматическую/автоматизированную верификацию, реализованных требований.

Есть такое?

Что используете, если есть?

 

В генерацию я совсем не верю.

А подробнее?

 

Если бы верил, то уволился и пошел бы учиться другому. Зачем нужны программисты, если программы можно генерировать.

 

Когда вы пересаживались с ассемблера на ЯВУ, вы так же говорили?

А серьёзно?

 

Почему?

Чем плоха генерация (хотя бы каркаса) по сравнению с написанием вручную?

 

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

 

Чем плохо то, что он "пролезет в конечный продукт"? А эволюционное прототипирование?

 

Я пытаюсь интересоваться темой (как ничего не делать, но, чтобы всё, что захотел, делалось).

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

списка, но крайне желательно, чтобы на более ли менее человеческом языке, а не в

какой-нибудь Z-нотации).

2. Инструмент создавал каркас на разных языках. Как минимум: C++, Ada. 3. Была обратная синхронизация: всё, что дописывается, отображается на диаграмме

(естественно, хотя бы просто диаграмма классов, а не обратный инжиниринг алгоритмов).

4. При изменении диаграммы (к примеру, добавлении класса или связи), не было полного изменения кода, т.е., всё, что я понаписал вручную, сохранялось. 5. Инструмент был бесплатным и открытым.

 

Такое где-нибудь реализовано?

 

Это к тому, что говорили, про некую "абсолютную универсальность", которая, как мне кажется, особого практического смысла не имеет.

 

Как раз практический смысл в наличии. На универсальных языках можно написать все, что написать вообще можно.

Вы про Тьюринг-полные? Тогда почти все современные языки возможно назвать универсальными.

 

И доказательство тому то, что

трансляторы специализированных языков пишутся на универсальных языках. Вопрос в том, нужны ли эти трансляторы, или специализации можно достичь менее радикальными методами, например, через компоненты.

 

Был раньше Форт. Позволял легко и непринуждённо создать из его универсального диалекта специализированный проблемно-ориентированный язык.

Семантика которого отражала область применения, а синтаксис напоминал Форт. И какие недостатки у метода?

 

Разве на универсальном языке вы не будете создавать специализированные (как не реализуйте и назовите: компоненты, набор процедур, интерпретатор с новым синтаксисом), которые отражают предметную область, для того, чтобы разрабатывать

в терминах предметной области?

 

Есть такая вещь как процесс разработки софта. Документирование его интегральная часть. Когда говорят о сложности имеют ввиду писание документации потом, когда-нибудь, или что-то вроде того.

Угу, вот только, как пишут, не процесс, а процессы. Штук 100500 методик и методов, и всё-равно, что-то всё новые и новые появляются (и говорят о сложности

работы с документацией)...

Почему?

 

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

Но для чего такой процесс разрабатывать учёным, которые не получат денег с манаджеров?

 

Ученым надо публиковаться. Иначе - не дадут грантов. Менеджерам на эти писульки - плевать. Процессы, на которые им не плевать, разрабатывают учреждения и бюро стандартов для получения сертификации.

 

"Захман внес основной вклад в разработку архитектуры предприятия Министерством обороны США. Эта попытка была предпринята в 1994 г., а сама концепция получила название «Базовая архитектура технического обеспечения для управления информацией» (TAFIM) [03].

 

Преимущества, обеспечиваемые такими архитектурами предприятий, как TAFIM (например, приведение в соответствие технических проектов с потребностями бизнеса), не были отмечены никем, кроме Конгресса США. В значительной степени благодаря впечатлению, произведенному концепцией TAFIM, Конгресс в 1996 г. принял закон, известный как акт Клингера — Коэна от 1996 г. [04], а также как реформа управления информационными технологиями, в котором всем федеральным агентствам было предписано принять меры по повышению эффективности инвестиций в ИТ. Для надзора за выполнением этого закона был сформирован совет директоров по информационным технологиям, в который вошли директора по информационным технологиям из всех основных правительственных органов."

 

http://msdn.microsoft.com/ru-ru/library/ee914379.aspx

 

В тему менеджмента, связанного с ПО. Да, он не учёный, но тем более: ему не "надо публиковаться".

Данный случай - исключение?

Или конкретно методологии разработки, в данном ключе, чем-то выделяются?

Может, просто люди ищут оптимальный подход?

 

В каком-то смысле да. Только подход менеджера проекта это - одно, подход системного архитектора - другое, а подход программиста - третье.

Но это отступление от оффтопика. В данном случае, пишется не книга, а алгоритм на человеческом языке (плюс руководство).

Что ж в этом плохого?

 

Алгоритм - хорошо, но это не программирование.

Я это понимаю.

Или вы хотите сказать, что алгоритм не входит в программирование?

Схизма.

 

Одним из принципов дизайна Ады было, в частности, недопущение несовместимых вариантов.

 

Недопущение несовместимости чего с чем?

 

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

Кхм. Издеваетесь? Программа, в любом понимании, - не есть реализация алгоритма?

 

А автомобиль - реализация метода горячей штамповки.

 

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

А горячая штамповка - метод.

Автомобили могут иметь полимерные корпуса, которые не штампуются. Как и алгоритм может быть реализован, используя один из языков, выбранной парадигмы (с добавлением деталей, присущих готовому продукту).

 

А Кнут пишет про *компьютер*. Т.е., фактически, он говорит о фазе проектирования.

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

 

В это я верю еще меньше. Кстати, декларативность - антитеза

алгоритмичности. Вы ничего там с Кнутом не напутали?

 

Я описал своё понимание.

Да, насчёт декларативности, - правда.

Посмотрел: действительно, алгоритм, по определению, - есть последовательность шагов.

Что-то меня занесло.

 

Во-вторых, пытается абстрагироваться от деталей реализации (в большей степени, за счёт изменения парадигмы).

 

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

Мне представлялся Пролог, когда я это писал.

 

В-третьих, он говорит о том, что программа - описание для людей (иначе надо было

бы писать в машинных кодах), в первую очередь, и лишь во вторую для компилятора.

 

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

 

Порядок очерёдности, как раз, не странен.

Аудитория, в данном случае, преимущественно, - специалисты, которые, так или иначе, работают с кодом.

Хотя, конечно, не исключено, что документация для пользователя может содержаться

там же (хотя бы частично).

 

Я неправильно написал предыдущее. Меня понесло не в ту степь.

Скорее, по-другому. С помощью своей концепции он пытался описать систему целостно.

Т.е., человеку предоставляется описание того, как система работает. С иллюстрациями в виде частей системы. Это легко читается и позволяет сформировать у него целостное представление о системе (да, считается, что на понимание и анализ готовой системы, у инженера поддержки тратится от 40 до 60% времени в течение всего процесса поддержки).

Это достигается за счёт некоторой избыточности. Получается, что комментарии и код меняются местами: теперь код в комментариях. Конечно, они становятся гораздо

объёмнее.

Ещё один плюс: документация становится ближе к коду, что позволяет проще поддерживать её в актуальном состоянии.

 

Да, связность кода и документации возрастает (моя интуитивная и не подкреплённая

чем-либо оценка).

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

Здесь же, в любом случае, проще написать, что будет сделано и последовательно реализовывать это в коде.

 

Может, не такая и плохая штука?

 

Так почему бы не объяснять непонятные места на человеческом языке, раз имеется такая возможность?

 

Может должно быть меньше непонятных мест? И опять, непонятных кому? В отличие от литературного произведения, даже среднего размера программу никто не понимает, и не может понять. Это физически не возможно. Поэтому программы разрабатываются так, чтобы этого не требовалось.

 

(пожарные не станут тушить Ваш дом, если у Вас на крыше батареи).

Почему? Что, приедут и будут наблюдать, как горит? o.O И ещё на iPhone снимут..?

 

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

И, при этом, критерии, по которым он признаётся "лучшим" и определяют область его применимости.

 

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

Ну, если это абсолютная универсальность.

Говорить на универсальном языке я смогу?

 

Мы рассматриваем написание программ. Универсальность, конечно,

относительна.

Значит, универсальный язык имеет границы применимости?

Если уточнить каких программ..?

 

Любых.

Программ для человека не может, как выше выяснили.

Программ для компьютеров?

Для каких?

 

Как я буду сравнивать, выяснять динамику изменений?

 

Изменений чего?

Любого показателя. Хотя бы той же скорости написания кода. "Везде" - неизмеримо

и неконкретно.

 

Так оно и есть неизмеримо. Скорость написания кода тоже неизмерима. И даже метрики объема кода не есть измерение. Болото.

 

Лучше, чем ничего.

 

Это я к тому, что "отбор" не нечто фатальное, а всего лишь система факторов, действующих на некий объект или класс объектов.

 

Так и в смерти нет ничего фатального - набор факторов и гражданская панихида потом...

Если это не ваша смерть для вас.

Пока вы читали предыдущую строчку, в мире умерло где-то два человека. Сейчас уже где-то человек пять. :-)

Не считая тысяч, умерших сейчас, особей других видов.

Вы сильно опечалены?

 

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

 

И как вы собираетесь это совершить? На что и как?

Это происходит само.

И с операционными системами.

 

Если меняют, значит имеются причины.

 

Возможно. Если да, то см. выше. Если нет, см. там же.

 

Да, не всегда рациональные, но не более того.

 

Что никак не меняет исходную позицию, она же - финальная.

Это меняет отношение.

Вы говорили про "отрицательный отбор", что отдавало фатализмом и некой "тёмной волей".

А когда есть набор причин, с ними, хотя бы в теории, возможно работать.

Типа, набора фильтров, процент прохождения через которые определяется степенью соответствия каждому.

 

Наукообразное объяснение непонятного явления. НепОнятость отрицает научность.

Нужно оставить попытки объяснить, чтобы это не выглядело наукообразно?

 

Это глубокий вопрос. Попытки - хорошо. Но дурачить себя и других не следует. Иначе рождаются социальные "науки", нумерология, климатология и т.п.

 

Климатология:

http://xage.ru/-top-5-superkompjuterov/

 

На первом - тоже. Кстати, на всех - Linux.

 

Идут себе директора с инженерами по интернет-магазинам и смотрят: "Ой, какой симпатяжка этот RedHat! Мне так нравится красная шляпка. Давай купим и поставим

его во все наши танчики, а?"

 

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

Нет, это вряд ли.

Вы сами честно ответили почему:

"- Почему же вы тогда пользуетесь Linux и Windows, а не OpenVMS?

- Я пользуюсь тем, за что платят.

"

 

Потому что "Наши клиенты хотят Windows, и получают его."

Очевидно, потому, что сейчас для них это дешевле.

 

Причина вполне рациональна.

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

эмоции или доверие (в человеческом смысле).

Главное, что их возможно в денежном эквиваленте выразить.

 

В случае с RedHat - у меня есть предположение, что за дорогой контракт, возможно

себе больше напилить от государства.

 

VMS я вспомнил как пример хорошей ОС. Если бы в VMS была бы вложена, хотя бы малая толика того, что было угрохано на Linux или Windows... Но этого не случилось.

Я честно плохо представляю архитектуру VMS. Только в самых-самых общих чертах. И

не могу с вами в согласиться, что это хорошая ОС, как и не согласиться с этим. Хотелось бы изучить, но на всё, что я хочу, времени не хватит (хотя, я его и трачу отчасти попусту, но это уже другой вопрос). :-[

 

Unix обладает достаточной стройной и прозрачной архитектурой.

 

Это как? fork стройная архитектура?

И что такого плохого в fork?

 

Я про стройность спрашивал. А fork плох примерно всем. Начиная с бредовой идеи копирования памяти и состояния ресурсов. Авторы Unix-а по-видимому ничего не знали ни про мультизадачность, ни про ресурсы, кроме файлов. Хотя в то время уже существовали достаточно развитые системы разделения времени и ресурсов.

 

Вы точно про системный вызов fork()?

Или, всё-таки про реализацию вызова fork в некоем конкретном Unix?

Начиная с бредовой идеи копирования памяти и состояния ресурсов.

man fork:

'fork создает процесс-потомок, который отличается от родительского только

значениями PID (идентификатор процесса) и PPID (идентификатор родительского процесса), а также тем фактом, что счетчики

использования ресурсов установлены в 0. Блокировки файлов и сигналы, ожидающие обработки, не наследуются.

 

Под Linux fork реализован с помощью "копирования страниц при записи" (copy-on-write, COW), поэтому расходы на fork сводятся к копирования таблицы страниц родителя и созданию уникальной структуры,

описывающей задачу.'

 

Или может быть драйверы в виде файлов?

Драйверы в виде модулей?

Вы про устройства хотели сказать?

Что плохого в том, что я могу взять и подключить настоящий жёсткий диск к ВМ, как файл?

 

В том, что это не файл, и вы не можете. Монтировать диск все равно нужно.

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

Кстати поверх

блочности живут следующие уровни абстракции. Например файловая система. Или RDBMS, или что-нибудь еще.

 

Или в том, что я могу читать из порта обычным read?

 

Для этого не нужно делать порт файлом.

Хорошо: писать в порт с помощью echo из командной оболочки.

Это может быть удобно (первый пример: настройка модема через AT команды). В DOS надо писать в некое волшебное "псевдоустройство", что отвратительно, а как

в VMS-like?

 

А такая удобная штука, как подключение файла, как блочного устройства, - это тоже последствия неграмотной архитектуры?

 

Разумеется. Блочное устройство - не файл, а вид доступа.

И? Причём тут грамотность архитектуры?

Я имел ввиду более высокий уровень: представление файла в файловой системе, как устройства, которое я могу смонтировать (устройства /dev/loop*).

 

http://lib.ru/MAN/DEMOS210/xenix.txt

 

Это похоже на перевод с книжки Ritchie.

Ну вот, всё вам не нравится!

 

Почему не нравится? Просто вспомнил, что похоже на книжку. Я ее еще в Союзе читал. Кстати не Ritchie, а похоже Браун. Желтая такая книжка.

Я не знал, что Союзе печатали такие книжки... o.O

 

Это потому что ваше подсознание зомбировано DEC и OpenVMS: если бы в OpenVMS были маны, вы бы назвали их прекрасными. :-]

 

Там был контекстный help, которым я пользовался. Он был встроен в IDE. Вообще, я начинал на машинах, где манов быть просто не могло, по причине отсутствия для этого памяти, как дисковой, так и оперативной. И в первых Unix машинах, на которых я работал, маны были печатными. Тоже из-за места. И это была очень плохая документация. Зато очень удобный, по тем временам, справочник.

 

Но вы спрашивали про документацию. Так вот, именно документация всегда была сильным местом DEC. Например:

 

http://pdp-11.org.ru/info.pl

Любопытно. Будет время, - обязательно посмотрю. Штука весьма привлекательная: жаль, что всё не охватишь. :-(

 

Ранний Unix тут и рядом не стоял. RSX-11M - предшественник VMS. Кстати, troff сильно напоминает roff из RSX-11M в котором документация поставлялась в электронном виде.

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

А вообще, я читал у него только одну книжку, наиболее известную. Подскажите, что за книжка, про которую вы говорили: хоть посмотрю на неё.

 

Вроде бы C. Браун, "Операционная система Unix".

 

Оно:

http://mirknig.com/knigi/os_bd/1181515068-vvedenie-v-operacionnuyu-sistemu-unix.html

http://rutracker.org/forum/viewtopic.php?t=4084658

http://pay.diary.ru/~challenge999/p143520554.htm

?

Но, как я понял, смысла особого нет читать: там лишь основы работы для пользователя?

 

Зачем надо много ядер?

Затем, что есть много задач и архитектур.

 

И?

 

И за этим.

 

А также, много пользователей, про отношение которых вы писали выше.

 

А ядра тут причем?

 

А про какие конкретно ядра вы говорите?

 

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

 

Зачем? Каким образом пользователь А узнает, что сегодня утрецом ему надо как раз ядро Б? Как это связано с ПО? ПО поверх разных ядер разное? Если одно, то почему ядра надо иметь разные, а ПО нет. Если разное, то как достигается горизонтальная интеграция?

 

1. Пользователь A может создавать систему. Бюджета может быть достаточно на детальное изучение различных ОС и ядер, но недостаточно на создание своего ядра "с нуля". На основе своих изысканий он решает, что ядро Б подойдёт лучше, чем любое другое.

2. ПО по некоторым причинам может зависеть от ядра. Грубый пример: системы шифрования. Своя во FreeBSD, своя в Linux. По тем или иным причинам, пользователям может быть удобно работать с какой-то конкретной системой (да хотя

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

Также, существуют разные архитектуры, которые может не поддерживать Linux, но поддерживает FreeBSD.

Да, так исторически сложилось, что ядер VMS в этом списке нет, но есть ядро FreeBSD.

3. Если вы имели ввиду Debian. Я не знаю. Никогда не работал с ядром FreeBSD в Debian. Но я подозреваю, что они просто используют FreeBSD Linux ABI - интерфейс, обеспечивающий бинарную совместимость, который реализован во FreeBSD.

Таким образом, большая часть ПО - в точности такое же, как и в Linux. Про Mach - не знаю.

 

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

 

Эээ... В каком смысле - "бред"? Не очень понимаю: какая альтернатива? Ядра-то, кажется, всегда и везде были, есть и будут (и в QNX, и, наверняка, в VMS).

Стремятся, только это не имеет непосредственного отношения к рыночному механизму. Для того чтобы рынок работал надо чтобы цена товара включала в себя достаточно высокий процент затрат на его производство. Для ПО это совсем не так. Цена программного продукта, в этом смысле, совершенно произвольна.

 

Большой - это сколько? А, когда цена не включает достаточный процент затрат, что

происходит?

 

К тому же, ведь, наверное, ПО кому-то нужно, и не только государственным компаниям, которым нужно выбить бюджет, но и частным (тем частным, которые не дотируются государством), закупающим его на свои деньги для повышения эффективности и прибылей?

 

И как Вы себе это представляете? Зубной техник оценивает эффективность программ бухгалтерского учета и регистрации пациентов для своей практики?

Вы утрируете.

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

 

Эксперт, в данном случае, бухгалтер. Поверьте мне, наш бухгалтер ничего не смыслит в программах.

 

Нужен специально обученный бухгалтер.

А ваш может сказать лишь:

1. Падает программа или нет и как часто.

2. Обеспечивает ли программа достаточный функционал для работы.

3. Быстрее ли стало работать.

4. Легко ли было освоить.

5. Есть ли желание вернуться к работе без программы (с предыдущей) и почему.

Ну и т.д.. Программа же предназначена для автоматизации его деятельности.

Оценивать может эксперт. В регистратуре может вполне оценить персонал (в данном

случае, конечно, не факт).

 

А в случае разработки ПО, разве не может оценить тот, кому предназначается закупаемый инструмент?

 

Разумеется не может. Я, например, постоянно пользуюсь и сам пишу компиляторы, но я не возьмусь сравнивать затраты на разработку с использованием GNAT-а против ObjectAda.

 

Вы можете оценить удобство работы, скорость компиляции и т.п.?

 

А в продукты микрософта веришь на подсознательном уровне. И, потому, люди их покупают.

На каком уровне?

Я не верю.

 

Так ведь на подсознательном же. Вы может и не верите, а ваше подсознание верит! (:-))

Мда? Вы не преувеличиваете силу несознательного?

В чём же проявляется "вера моего подсознания"?

 

Вы, например, верите в Debian. А я - нет.

 

И я не верю.

Вы путаете причину со следствием.

Мне он нравится, но я его начал использовать не потому, что мне понравился логотип.

 

Человек эволюционировал принимать сложные решения в максимально короткое время. Пытавшихся принимать рационально обоснованные решения съедали львы и другие милые зверушки, непривычные к интеллигентным беседам. Этот механизм быстренько в нас срабатывает, когда надо сделать неочевидный выбор.

Механизм, о котором вы пишите, как говорят, проявляется в ситуациях, когда человек предполагает угрозу безопасности жизнедеятельности, и механизм имеет всего-то три способа проявления.

 

У вас в компании пытаются убить (опционально - прокусить большой палец руки, как

ирен в Спарте), если оппонент в кратчайший срок не ответит на любой сложный и неочевидный вопрос?

Весьма оригинальная европейская система менеджмента...

 

Уже

потом, сидя на верхней ветке и немного отдышавшись, мы начинаем

анализировать и поучать менее удачливых коллег внизу, у львов.

 

Но, увы. Unix его обогнал. Видимо, люди в университетах США оказались недостаточно умны, чтобы выбрать что-то лучше или написать что-то своё (не Unix-подобное)...

 

Университет не может ничего разработать.

Эээ... BSD, TCP/IP, Tor и ещё 1001 крупнейшая разработка, причём в разных областях, нет?

Такими заявлениями вы как-то вызываете у меня непонимание.

 

Для этого нет ни ресурсов, ни квалификации, ни надлежащей организации.

https://ru.wikipedia.org/wiki/%D0%90%D1%81%D1%81%D0%BE%D1%86%D0%B8%D0%B0%D1%86%D0%B8%D1%8F_%D0%B0%D0%BC%D0%B5%D1%80%D0%B8%D0%BA%D0%B0%D0%BD%D1%81%D0%BA%D0%B8%D1%85_%D1%83%D0%BD%D0%B8%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%82%D0%B5%D1%82%D0%BE%D0%B2

 

"MIT was elected to the Association of American Universities in 1934 and remains

a research university with a very high level of research activity; research expenditures totaled $718.2 million in 2009."

 

Один профессор, вроде Вирта, может

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

 

А профессор может привлечь к написанию других людей?

 

Почему вообще кто-то стал заниматься Unix, если всё и так было хорошо?

 

Потому что люди (Thompson, Ritchie, Kernighan) не были делом заняты в AT&T,

Каким же делом им нужно было заниматься: компьютеры перетаскивать? :-)

 

Я - не менеджер в AT&T.

 

И слава Unix. :-)

 

да еще и свободную машину получили (DEC-овскую, между прочим). Социализм рождает монстров, как известно.

Слышал такое про "сон разума". А социализм, говорят, в Норвегии. И вполне нормально живут (шибко либеральная партия + Брейвик - не в счёт).

 

И этот социализм Норвегию уже практически доканал. Она чуть задержалась за счет нефти и рыбы. А так, Швеция, Дания и Голландия рядом, там - каюк уже случился. Но это - совсем оффтопик.

 

Ну да, оффтопик. Только не сам по себе социализм, а либерастия, которую выдают за социализм. С другой стороны, в Швейцарии, говорят, всё нормально... А что, кстати, в Швеции и Дании плохо?

Свалить бы в такой каюк и уже оттуда говорить, что там плохо: жаль, что почти невозможно. :-(

 

 

--- In [email protected], "Dmitry A. Kazakov" <alt@...> wrote:

VisualBasic тянется не за счÑ`т мифического "негативного

отбора", а исключительно за счÑ`т платформы, которая на него завязана.

 

Как и в биологии, отбор - закон эмпирический. А механизмы могут быть

разными. Например, религиозный: BASIC, С, PHP нам посланы за грехи >> наши, и знаменуют надвигающийся конец света. Так лучше? (:-))

 

Никакой мистики, всÑ` сугубо материально. Механизм рыночный и психологический ( хотя психология и социология -- лженауки !-) ). На рынке выживают самые дешÑ`вые из продуктов, удовлетворяющие минимально допустимым требованиям, т.е. худшие.

 

На примере языков программирования. Ð' C нет таких вещей, как внутренние процедуры и перечилимый тип ( при объявлении его в вы на самом деле объявляете всего лишь глобальный набор констант, не обладающих никакими признаками типа, кроме объÑ`ма занимаемой памяти ). Это избавляет разработчиков компилятора от необходимости писать, увязывать и поддерживать модули компилятора, ответственные за поддержку этих черт языка. Как следствие, разработчик компилятора экономит на этом деньги и время, которые можно потратить на захват рынка. Таким образом, компилятор появится раньше и будет стоить меньше, чем начатый разработкой в то же самое время, допустим, компилятор Pascal'я, я уж не говорю про Ada'у. А после этого попробуйте убедить своего начальника, что нужно купить более дорогой компилятор, который только-только появился, а не тот, что дешевле и котрым "все пользуются". И кроме того, какой программист признается вслух перед своим начальником, что он будет делать больше ошибок в программе из-за того, что в языке нет перечислимого типа?

On Thu, 23 May 2013 22:56:47 +0400, you wrote:

 

22.05.2013 02:06, Dmitry A. Kazakov пишет:

2. Имеет ли смысл, применительно к Ada?

 

Да, но с пониманием того, что это все-таки совсем не литература.

Т.е. всё-таки...

А вы какие-нибудь формальные методики для описания требований и, затем, генерации, например, модели используете?

 

Если клиент требует (и платит), то да. Иначе - нет.

Я не про клиента.

Вы лично, чтобы ускорить и облегчить разработку, что применяете?

 

Нет. Это существенно замедляет и осложняет. Формальные методы обеспечивают качество и/или сертификацию. А это - редко когда требуется.

Какие формальные методы вы имеете ввиду?

Автоматические доказательства?

 

Да

 

Что используете, если есть?

 

Есть SPARK

 

http://en.wikipedia.org/wiki/SPARK

В генерацию я совсем не верю.

А подробнее?

 

Если бы верил, то уволился и пошел бы учиться другому. Зачем нужны программисты, если программы можно генерировать.

 

Когда вы пересаживались с ассемблера на ЯВУ, вы так же говорили?

 

Во-первых, я на Java не пересаживался, во-вторых, это совсем другое. Генератор и компилятор очевидно разные вещи. Речь шла о генераторах.

А серьёзно?

 

Если Вы не огенераторе а о языке, то я так же не верю и в 5GL, 6GL и т.п.

Почему?

Чем плоха генерация (хотя бы каркаса) по сравнению с написанием вручную?

 

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

 

Чем плохо то, что он "пролезет в конечный продукт"?

 

Вы самолетами летаете? А как насчет автомобиля? Опять возвращаясь к Аде, язык задумывался так, чтобы нефункциональный код не лез в серию.

 

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

списка, но крайне желательно, чтобы на более ли менее человеческом языке, а не в

какой-нибудь Z-нотации).

2. Инструмент создавал каркас на разных языках. Как минимум: C++, Ada. 3. Была обратная синхронизация: всё, что дописывается, отображается на диаграмме

(естественно, хотя бы просто диаграмма классов, а не обратный инжиниринг алгоритмов).

4. При изменении диаграммы (к примеру, добавлении класса или связи), не было полного изменения кода, т.е., всё, что я понаписал вручную, сохранялось. 5. Инструмент был бесплатным и открытым.

 

Такое где-нибудь реализовано?

 

Стоит вагон денег. Насчет позиции 5, не слышал.

Это к тому, что говорили, про некую "абсолютную универсальность", которая, как мне кажется, особого практического смысла не имеет.

 

Как раз практический смысл в наличии. На универсальных языках можно написать все, что написать вообще можно.

Вы про Тьюринг-полные? Тогда почти все современные языки возможно назвать универсальными.

 

Специализированные языки, если и полные, то имеют сильную тенденцию к тому, что некоторые стандартные задачи в них хоть решаются, но совершенно чудовищными способом.

 

И доказательство тому то, что

трансляторы специализированных языков пишутся на универсальных языках. Вопрос в том, нужны ли эти трансляторы, или специализации можно достичь менее радикальными методами, например, через компоненты.

 

Был раньше Форт.

 

Он и сейчас есть. Как любой, очень плохой язык, Forth - бессмертен. Я его еще под RSX-11M помню.

 

Позволял легко и непринуждённо создать из его универсального

диалекта специализированный проблемно-ориентированный язык.

Семантика которого отражала область применения, а синтаксис напоминал Форт. И какие недостатки у метода?

 

Создание диалектов языка и есть тот самый недостаток.

 

Разве на универсальном языке вы не будете создавать специализированные (как не реализуйте и назовите: компоненты, набор процедур, интерпретатор с новым синтаксисом), которые отражают предметную область, для того, чтобы разрабатывать

в терминах предметной области?

 

Компонента и синтаксис вещи весьма далекие. Синтаксис еще дальше, чем диалект. Диалект, по-идее, сохраняет синтаксис.

 

Есть такая вещь как процесс разработки софта. Документирование его интегральная часть. Когда говорят о сложности имеют ввиду писание документации потом, когда-нибудь, или что-то вроде того.

Угу, вот только, как пишут, не процесс, а процессы. Штук 100500 методик и методов, и всё-равно, что-то всё новые и новые появляются (и говорят о сложности

работы с документацией)...

Почему?

 

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

Но для чего такой процесс разрабатывать учёным, которые не получат денег с манаджеров?

 

Ученым надо публиковаться. Иначе - не дадут грантов. Менеджерам на эти писульки - плевать. Процессы, на которые им не плевать, разрабатывают учреждения и бюро стандартов для получения сертификации.

 

[...]

 

http://msdn.microsoft.com/ru-ru/library/ee914379.aspx

 

В тему менеджмента, связанного с ПО. Да, он не учёный, но тем более: ему не "надо публиковаться".

 

Тут я не силен. Не берусь коментировать.

 

Данный случай - исключение?

 

Исключение из чего? Бюрократы обожают процессы.

 

Или конкретно методологии разработки, в данном ключе, чем-то выделяются?

Алгоритм - хорошо, но это не программирование.

Я это понимаю.

Или вы хотите сказать, что алгоритм не входит в программирование?

 

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

 

Одним из принципов дизайна Ады было, в частности, недопущение несовместимых вариантов.

 

Недопущение несовместимости чего с чем?

 

Друг с другом.

 

Во-вторых, пытается абстрагироваться от деталей реализации (в большей степени, за счёт изменения парадигмы).

 

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

Мне представлялся Пролог, когда я это писал.

 

То что Prolog - не серьезно, все помимали еще в самом начале 90-х. Я запомнил одну статью в каком-то американском журнале с издевательским названием, "Если 5GL ответ, то что же было вопросом?". По моим

представлениям, тема nGL давно закрыта.

 

Я неправильно написал предыдущее. Меня понесло не в ту степь.

Скорее, по-другому. С помощью своей концепции он пытался описать систему целостно.

Т.е., человеку предоставляется описание того, как система работает.

 

Так это - архитектура, а совсем не код.

 

Может, не такая и плохая штука?

 

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

Так почему бы не объяснять непонятные места на человеческом языке, раз имеется такая возможность?

 

Может должно быть меньше непонятных мест? И опять, непонятных кому? В отличие от литературного произведения, даже среднего размера программу никто не понимает, и не может понять. Это физически не возможно. Поэтому программы разрабатываются так, чтобы этого не требовалось.

 

(пожарные не станут тушить Ваш дом, если у Вас на крыше батареи).

Почему?

 

От того, что они под напряжением. "Не влезай - убьет!"

 

Программ для компьютеров?

Для каких?

 

Тех, чторые можно купить.

 

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

 

Как я буду сравнивать, выяснять динамику изменений?

 

Изменений чего?

Любого показателя. Хотя бы той же скорости написания кода. "Везде" - неизмеримо

и неконкретно.

 

Так оно и есть неизмеримо. Скорость написания кода тоже неизмерима. И даже метрики объема кода не есть измерение. Болото.

 

Лучше, чем ничего.

 

Как измеряли что лучше? (:-)) Есть такой принцип - не навреди.

 

Это я к тому, что "отбор" не нечто фатальное, а всего лишь система факторов, действующих на некий объект или класс объектов.

 

Так и в смерти нет ничего фатального - набор факторов и гражданская панихида потом...

Если это не ваша смерть для вас.

Пока вы читали предыдущую строчку, в мире умерло где-то два человека. Сейчас уже где-то человек пять. :-)

Не считая тысяч, умерших сейчас, особей других видов.

Вы сильно опечалены?

 

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

 

И как вы собираетесь это совершить? На что и как?

Это происходит само.

И с операционными системами.

 

Это как? Windows рулит. Никакого прогресса в области ОС не наблюдается. Есть заметный регресс в плане чудовищного разбазаривания вычилительных ресурсов. Напомню, заезженную цитатку: "640K ought to be enough for anyone".

 

Да, не всегда рациональные, но не более того.

 

Что никак не меняет исходную позицию, она же - финальная.

 

Это меняет отношение.

Вы говорили про "отрицательный отбор", что отдавало фатализмом и некой "тёмной волей".

 

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

 

А когда есть набор причин, с ними, хотя бы в теории, возможно работать.

 

Также есть и причины, почему никто с ними работать не будет.

 

Идут себе директора с инженерами по интернет-магазинам и смотрят: "Ой, какой симпатяжка этот RedHat! Мне так нравится красная шляпка. Давай купим и поставим

его во все наши танчики, а?"

 

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

Нет, это вряд ли.

Вы сами честно ответили почему:

"- Почему же вы тогда пользуетесь Linux и Windows, а не OpenVMS? - Я пользуюсь тем, за что платят.

"

Потому что "Наши клиенты хотят Windows, и получают его."

Очевидно, потому, что сейчас для них это дешевле.

 

Никак не очевидно.

 

1. Платят /= дешевле.

 

2. Я уже писал, что цена ПО не отражает расходов на него. Отсюда сравнение цен - бессмысленно. Т.е. бессмысленно само употребление слова "дешевле".

Цена это эквивалент, как писал товарищ с черной бородой до ушей, - эквивалент качества, а не эквивалент цвета трамвайного билета, ТОЛЬКО при УСЛОВИИ, что последний фактор ислючен = статистически нерелевантен.

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

эмоции или доверие (в человеческом смысле).

 

Это предмет социологического исследования провести которое практически нереально.

 

Unix обладает достаточной стройной и прозрачной архитектурой.

 

Это как? fork стройная архитектура?

И что такого плохого в fork?

 

Я про стройность спрашивал. А fork плох примерно всем. Начиная с бредовой идеи копирования памяти и состояния ресурсов. Авторы Unix-а по-видимому ничего не знали ни про мультизадачность, ни про ресурсы, кроме файлов. Хотя в то время уже существовали достаточно развитые системы разделения времени и ресурсов.

 

Вы точно про системный вызов fork()?

 

Да

 

Или в том, что я могу читать из порта обычным read?

 

Для этого не нужно делать порт файлом.

Хорошо: писать в порт с помощью echo из командной оболочки.

 

Зачем?

 

Это может быть удобно (первый пример: настройка модема через AT команды).

 

Удобно? Ни разу не настраивал модем подобным способом.

 

В DOS надо писать в некое волшебное "псевдоустройство", что отвратительно, а как

в VMS-like?

 

Не помню, давно было. Под Windows есть COM API. Гораздо разумнее. Оно каменный век, другое - верхний мел.

А такая удобная штука, как подключение файла, как блочного устройства, - это тоже последствия неграмотной архитектуры?

 

Разумеется. Блочное устройство - не файл, а вид доступа.

И? Причём тут грамотность архитектуры?

 

Abstraction inversion

 

http://lib.ru/MAN/DEMOS210/xenix.txt

 

Это похоже на перевод с книжки Ritchie.

Ну вот, всё вам не нравится!

 

Почему не нравится? Просто вспомнил, что похоже на книжку. Я ее еще в Союзе читал. Кстати не Ritchie, а похоже Браун. Желтая такая книжка.

Я не знал, что Союзе печатали такие книжки... o.O

 

В Союзе печатали очень хорошие книжки и отбраковывали шлак. Кроме того, перевод в хороших издательствах был очень качественен, что включало и художественную литературу. Я потом читал моих любимых авторов в оригинале и с изумлением обнаруживал, что то многое из того, что из них не переводили был хлам.

 

Это ни в коем случае не оправдывает "совок".

 

Вроде бы C. Браун, "Операционная система Unix".

 

Оно:

http://mirknig.com/knigi/os_bd/1181515068-vvedenie-v-operacionnuyu-sistemu-unix.html

http://rutracker.org/forum/viewtopic.php?t=4084658

http://pay.diary.ru/~challenge999/p143520554.htm

?

Но, как я понял, смысла особого нет читать: там лишь основы работы для пользователя?

 

Про него вообще смысла читать нет, т.к. никаких интересных или полезных идей в плане ОС Unix не имел и не имеет, IMO, разумеется.

 

Зачем надо много ядер?

Затем, что есть много задач и архитектур.

 

И?

 

И за этим.

 

Как из этого следует необходимость многих ядер.

 

А также, много пользователей, про отношение которых вы писали выше.

 

А ядра тут причем?

 

А про какие конкретно ядра вы говорите?

 

Про их многочисленность в рамках одной системы.

 

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

 

Зачем? Каким образом пользователь А узнает, что сегодня утрецом ему надо как раз ядро Б? Как это связано с ПО? ПО поверх разных ядер разное? Если одно, то почему ядра надо иметь разные, а ПО нет. Если разное, то как достигается горизонтальная интеграция?

 

1. Пользователь A может создавать систему. Бюджета может быть достаточно на детальное изучение различных ОС и ядер, но недостаточно на создание своего ядра

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

 

Каких изысканий? Кто за это платит? Почему, скажем, разработчика текстового процессора должно волновать ядро, если даже меня, разработчика систем реального времени ядро не волнует никак?

 

2. ПО по некоторым причинам может зависеть от ядра. Грубый пример: системы шифрования. Своя во FreeBSD, своя в Linux. По тем или иным причинам, пользователям может быть удобно работать с какой-то конкретной системой (да хотя

бы прикладную программу для управления они лучше знают).

 

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

 

https://www.bsi.bund.de/DE/Home/home_node.html

 

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

 

3. Если вы имели ввиду Debian. Я не знаю. Никогда не работал с ядром FreeBSD в Debian. Но я подозреваю, что они просто используют FreeBSD Linux ABI - интерфейс, обеспечивающий бинарную совместимость, который реализован во FreeBSD.

 

В чем тогда разность если весь системный интерфейс один?

 

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

 

Эээ... В каком смысле - "бред"?

 

В смысле отсутствия оного.

 

Не очень понимаю: какая альтернатива? Ядра-то,

кажется, всегда и везде были, есть и будут (и в QNX, и, наверняка, в VMS).

 

Ядро системы было и есть. Непонятно, почему недостаточно параметрирования ОС, а необходимо менять ядра, при том, что весь интерфейс предлагается сохранить.

 

Стремятся, только это не имеет непосредственного отношения к рыночному механизму. Для того чтобы рынок работал надо чтобы цена товара включала в себя достаточно высокий процент затрат на его производство. Для ПО это совсем не так. Цена программного продукта, в этом смысле, совершенно произвольна.

 

Большой - это сколько?

 

Я не экономист. Но в принципе это легко оценить. Если процент равен x, то (1-x)*рыночная-цена-продукта есть максимальное внерыночное преимущество фирма А может иметь над фирмой Б.

 

А, когда цена не включает достаточный процент затрат, что

происходит?

 

Рынок разрушается.

 

Конкуренция возможна при необходимом условии равенства производителей по "неинтересным" факторам. Затраты на единицу продукта должны быть адекватны "интересным" факторам.

 

Другим, необходимым условием для того, чтобы отбор выбирал качественный продукт, нужно чтобы покупатель был способен его оценить по тем же "интересным" факторам.

 

И то, и другое отсутствует.

 

Оценивать может эксперт. В регистратуре может вполне оценить персонал (в данном

случае, конечно, не факт).

 

А в случае разработки ПО, разве не может оценить тот, кому предназначается закупаемый инструмент?

 

Разумеется не может. Я, например, постоянно пользуюсь и сам пишу компиляторы, но я не возьмусь сравнивать затраты на разработку с использованием GNAT-а против ObjectAda.

 

Вы можете оценить удобство работы, скорость компиляции и т.п.?

 

Объективно? Нет. В стоимостном выражении - три раза нет.

 

Университет не может ничего разработать.

Эээ... BSD, TCP/IP, Tor и ещё 1001 крупнейшая разработка, причём в разных областях, нет?

 

Нет. Я объяснил почему. Университетские проекты могут быть успешными если финансируются государством или фирмами. В этом случае они нанимают персонал на стороне, и тогда ничем не отличаются от обыкновенной фирмы.

 

Для этого нет ни ресурсов, ни квалификации, ни надлежащей организации.

https://ru.wikipedia.org/wiki/%D0%90%D1%81%D1%81%D0%BE%D1%86%D0%B8%D0%B0%D1%86%D0%B8%D1%8F_%D0%B0%D0%BC%D0%B5%D1%80%D0%B8%D0%BA%D0%B0%D0%BD%D1%81%D0%BA%D0%B8%D1%85_%D1%83%D0%BD%D0%B8%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%82%D0%B5%D1%82%D0%BE%D0%B2

 

"MIT was elected to the Association of American Universities in 1934 and remains

a research university with a very high level of research activity; research expenditures totaled $718.2 million in 2009."

 

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

предназначены. (А фирмы слвбы фундасентальных исследованиях.)

 

Один профессор, вроде Вирта, может

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

 

А профессор может привлечь к написанию других людей?

 

Если откроет фирму и станет ее владельцем. Фирма, где я работаю, именно такова.

 

да еще и свободную машину получили (DEC-овскую, между прочим). Социализм рождает монстров, как известно.

Слышал такое про "сон разума". А социализм, говорят, в Норвегии. И вполне нормально живут (шибко либеральная партия + Брейвик - не в счёт).

 

И этот социализм Норвегию уже практически доканал. Она чуть задержалась за счет нефти и рыбы. А так, Швеция, Дания и Голландия рядом, там - каюк уже случился. Но это - совсем оффтопик.

 

Ну да, оффтопик. Только не сам по себе социализм, а либерастия, которую выдают за социализм.

 

Ничего либерального в этом нет. В прочем, как и в "progressive", они - не за прогресс. Более корректный термин "lefty", хотя они и не левые. Лучше - "champagne socialists".

 

С другой стороны, в Швейцарии, говорят, всё нормально...

А что, кстати, в Швеции и Дании плохо?

 

Относительно того как было раньше - сильно плохо. Хотя наверное лучше, чем в России и Бурунди.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

On Fri, 24 May 2013 05:41:46 -0000, you wrote:

 

[... помехи на линии передач ...]

 

Не могу ответить, т.к. не читаемо. Исправьте кодировку, это явно никак не ISO-8859-1.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

А профессор может привлечь к написанию других людей?

Если откроет фирму и станет ее владельцем. Фирма, где я работаю, именно такова.

(в сторону) И компания AdaCore, кстати, тоже... (с заменой "профессор" на "группу профессоров") :)

ВФ

ЗЫ - Дискуссия конечно любопытная, но уж очень сильно по касательной к Аде по-моему.

Здравствуйте!

Читаемо в UTF-8

С уважением, Сергей.

mailto: [email protected]

www.mediascan.by

----- Original Message -----

From: "Dmitry A. Kazakov" <[email protected]>

To: <[email protected]>

Sent: Friday, May 24, 2013 11:52 AM

Subject: Re: [ada_ru] Re: Ada-2012 + Linux

On Fri, 24 May 2013 05:41:46 -0000, you wrote:

[... помехи на линии передач ...]

Не могу ответить, т.к. не читаемо. Исправьте кодировку, это явно никак не ISO-8859-1.

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

------------------------------------

Yahoo! Groups Links

Здравствуйте!

"Артем Н." очень похож на блогера или "кореспондента" откуда-то. С уважением, Сергей.

mailto: [email protected]

www.mediascan.by

----- Original Message -----

From: "Vasiliy Fofanov" <[email protected]>

To: <[email protected]>

Sent: Friday, May 24, 2013 12:14 PM

Subject: Re: [ada_ru] Ada-2012 + Linux

24.05.2013 13:14, Vasiliy Fofanov пишет:

А профессор может привлечь к написанию других людей?

 

Если откроет фирму и станет ее владельцем. Фирма, где я работаю, именно такова.

 

(в сторону) И компания AdaCore, кстати, тоже... (с заменой "профессор" на "группу профессоров") :)

 

 

ВФ

 

ЗЫ - Дискуссия конечно любопытная, но уж очень сильно по касательной к Аде по-моему.

Извините за оффтопик.

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

 

Не сильно ли я помешаю, если продолжу разговор?

24.05.2013 12:50, Dmitry A. Kazakov пишет:

В генерацию я совсем не верю.

А подробнее?

 

Если бы верил, то уволился и пошел бы учиться другому. Зачем нужны программисты, если программы можно генерировать.

 

Когда вы пересаживались с ассемблера на ЯВУ, вы так же говорили?

 

Во-первых, я на Java не пересаживался, во-вторых, это совсем другое.

Я такого и не писал. o.O

 

Генератор и компилятор очевидно разные вещи. Речь шла о генераторах.

Генератор тоже, в какой-то степени, возможно считать компилятором.

А серьёзно?

 

Если Вы не огенераторе а о языке, то я так же не верю и в 5GL, 6GL и т.п.

...

 

Почему?

Чем плоха генерация (хотя бы каркаса) по сравнению с написанием вручную?

 

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

 

Чем плохо то, что он "пролезет в конечный продукт"?

 

Вы самолетами летаете? А как насчет автомобиля? Опять возвращаясь к Аде, язык задумывался так, чтобы нефункциональный код не лез в серию.

А почему генерируемый код не должен быть функциональным?

К тому же, пусть это будет не код, а каркас: классы, методы, свойства. Чем это плохо?

 

К примеру:

http://www.ibm.com/developerworks/rational/library/10/developingsmarteradaapplicationsusingmodeldrivenapproach/

 

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

списка, но крайне желательно, чтобы на более ли менее человеческом языке, а не в

какой-нибудь Z-нотации).

2. Инструмент создавал каркас на разных языках. Как минимум: C++, Ada. 3. Была обратная синхронизация: всё, что дописывается, отображается на диаграмме

(естественно, хотя бы просто диаграмма классов, а не обратный инжиниринг алгоритмов).

4. При изменении диаграммы (к примеру, добавлении класса или связи), не было полного изменения кода, т.е., всё, что я понаписал вручную, сохранялось. 5. Инструмент был бесплатным и открытым.

 

Такое где-нибудь реализовано?

 

Стоит вагон денег. Насчет позиции 5, не слышал.

 

Rhapsody?

 

Это к тому, что говорили, про некую "абсолютную универсальность", которая, как мне кажется, особого практического смысла не имеет.

 

Как раз практический смысл в наличии. На универсальных языках можно написать все, что написать вообще можно.

Вы про Тьюринг-полные? Тогда почти все современные языки возможно назвать универсальными.

 

Специализированные языки, если и полные, то имеют сильную тенденцию к тому, что некоторые стандартные задачи в них хоть решаются, но совершенно чудовищными способом.

 

Например?

 

И доказательство тому то, что

трансляторы специализированных языков пишутся на универсальных языках. Вопрос в том, нужны ли эти трансляторы, или специализации можно достичь менее радикальными методами, например, через компоненты.

 

Был раньше Форт.

 

Он и сейчас есть. Как любой, очень плохой язык, Forth - бессмертен. Я его еще под RSX-11M помню.

 

Сейчас он не так распространён. Но почему ж он очень плохой?

Я бы сказал, что он концептуальный.

В нём присутствуют весьма интересные идеи.

Я, конечно, не агитирую за использование обратной польской нотации на практике, но как опытный язык, Форт имеет право на существование.

 

Позволял легко и непринуждённо создать из его универсального

диалекта специализированный проблемно-ориентированный язык.

Семантика которого отражала область применения, а синтаксис напоминал Форт. И какие недостатки у метода?

 

Создание диалектов языка и есть тот самый недостаток.

 

А вы, при написании кода, разбиваете его на компоненты, состоящие из модулей, которые, в свою очередь, содержат функции с понятными именами?

И чем вызов, типа turn_shaft(360) *принципиально* будет отличаться от 360 degree

turn_shaft, например?

 

Разве на универсальном языке вы не будете создавать специализированные (как не реализуйте и назовите: компоненты, набор процедур, интерпретатор с новым синтаксисом), которые отражают предметную область, для того, чтобы разрабатывать

в терминах предметной области?

 

Компонента и синтаксис вещи весьма далекие. Синтаксис еще дальше, чем диалект. Диалект, по-идее, сохраняет синтаксис.

 

Принципиальная разница здесь есть?

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

Зачем тогда разработчики игр включают в них языки сценариев, а не предоставляют игровому дизайнеру "всю гибкость универсального языка"?

 

Данный случай - исключение?

 

Исключение из чего? Бюрократы обожают процессы.

 

И поэтому они отменили одну методологию и начали создавать другую? Всё исчерпывается бюрократией?

 

Или конкретно методологии разработки, в данном ключе, чем-то выделяются?

Алгоритм - хорошо, но это не программирование.

Я это понимаю.

Или вы хотите сказать, что алгоритм не входит в программирование?

 

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

 

Вокруг чего всё крутится сейчас?

 

Во-вторых, пытается абстрагироваться от деталей реализации (в большей степени, за счёт изменения парадигмы).

 

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

Мне представлялся Пролог, когда я это писал.

 

То что Prolog - не серьезно, все помимали еще в самом начале 90-х. Я запомнил одну статью в каком-то американском журнале с издевательским названием, "Если 5GL ответ, то что же было вопросом?".

Статья немного отстала?

https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B8%D0%B7%D0%B8%D1%81_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F

 

По моим представлениям, тема nGL давно закрыта.

 

Да ладно вам.

http://www.mercurylang.org/

http://www.visual-prolog.com/

 

Я неправильно написал предыдущее. Меня понесло не в ту степь.

Скорее, по-другому. С помощью своей концепции он пытался описать систему целостно.

Т.е., человеку предоставляется описание того, как система работает.

 

Так это - архитектура, а совсем не код.

 

Как ни назовите. Пусть, словесное описание архитектуры модуля. Сути это не меняет.

Описывается архитектура, иллюстрируемая частями кода системы.

В разумных масштабах, конечно.

Далее, из описания архитектуры создаётся код.

Да, минус в том, что слишком высокий уровень детализации, на данном этапе. Но, с другой стороны, такой подход ведь не исключает более высокоуровнего описания архитектуры (в том же UML, например)?

 

Может, не такая и плохая штука?

 

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

 

Хорошо. В таком случае, как это делается правильно, объясните?

Если вы отрицаете этот подход, каков ваш подход?

 

Может должно быть меньше непонятных мест? И опять, непонятных кому? В отличие от литературного произведения, даже среднего размера программу никто не понимает, и не может понять. Это физически не возможно. Поэтому программы разрабатываются так, чтобы этого не требовалось.

Да, а что значит "понимание", в данном случае?

 

Программ для компьютеров?

Для каких?

 

Тех, чторые можно купить.

 

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

 

Т.е., "универсальный язык" уже подходит не для всех типов компьютеров?

Как я буду сравнивать, выяснять динамику изменений?

 

Изменений чего?

Любого показателя. Хотя бы той же скорости написания кода. "Везде" - неизмеримо

и неконкретно.

 

Так оно и есть неизмеримо. Скорость написания кода тоже неизмерима. И даже метрики объема кода не есть измерение. Болото.

 

Лучше, чем ничего.

 

Как измеряли что лучше? (:-))

 

Тут, пожалуй, не измерение, а выбор из варианта "нет ничего" и "есть хоть что-то".

 

Есть такой принцип - не навреди.

Согласен. Надеюсь, это не относится к полному отказу от метрик?

 

Это я к тому, что "отбор" не нечто фатальное, а всего лишь система факторов, действующих на некий объект или класс объектов.

 

Так и в смерти нет ничего фатального - набор факторов и гражданская панихида потом...

Если это не ваша смерть для вас.

Пока вы читали предыдущую строчку, в мире умерло где-то два человека. Сейчас уже где-то человек пять. :-)

Не считая тысяч, умерших сейчас, особей других видов.

Вы сильно опечалены?

 

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

 

И как вы собираетесь это совершить? На что и как?

Это происходит само.

И с операционными системами.

 

Это как? Windows рулит.

Ччч-е-м оно рулит? O_O

 

Никакого прогресса в области ОС не наблюдается.

Есть заметный регресс в плане чудовищного разбазаривания вычилительных ресурсов.

Напомню, заезженную цитатку: "640K ought to be enough for

anyone".

 

Эти претензии, как-раз к автору цитатки, продукты которого у вас там чем-то рулят. В Linux поддержку i386 только в 2012-м прекратили. Другое дело, что KDE4 с композитным менеджером и 3D эффектами, на таком железе, конечно, не взлетит.

Да, не всегда рациональные, но не более того.

 

Что никак не меняет исходную позицию, она же - финальная.

 

Это меняет отношение.

Вы говорили про "отрицательный отбор", что отдавало фатализмом и некой "тёмной волей".

 

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

 

Первые христиане стойко выносили пытки, по причине того, что они имели сильную волю?

Или на то была Божья Воля?

А, может, харизматичный лидер им навязал свою волю и модель поведения?

Что такое "воля", какое у неё определение?

Возможно ли её измерить?

Или стоит говорить о процессе принятия решения?

 

В данном контексте, рациональность - "здравый смысл".

Он предполагает наличие неких объективных причин, которые возможно представить в

каком-либо измеримом эквиваленте.

Нерациональость - это наличие субъективных причин, какой-то эмоциональной оценки.

 

А когда есть набор причин, с ними, хотя бы в теории, возможно работать.

 

Также есть и причины, почему никто с ними работать не будет.

 

Какие причины?

И никто не работает?

Маркетинг, PR в его контексте, рекламные методы, пропаганда, формирование мнения, - не действуют?

 

Идут себе директора с инженерами по интернет-магазинам и смотрят: "Ой, какой симпатяжка этот RedHat! Мне так нравится красная шляпка. Давай купим и поставим

его во все наши танчики, а?"

 

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

Нет, это вряд ли.

Вы сами честно ответили почему:

"- Почему же вы тогда пользуетесь Linux и Windows, а не OpenVMS? - Я пользуюсь тем, за что платят.

"

Потому что "Наши клиенты хотят Windows, и получают его."

Очевидно, потому, что сейчас для них это дешевле.

 

Никак не очевидно.

 

1. Платят /= дешевле.

 

2. Я уже писал, что цена ПО не отражает расходов на него. Отсюда сравнение цен - бессмысленно. Т.е. бессмысленно само употребление слова "дешевле".

Вы включили в цену переучивание персонала клиента, наладку оборудования, поддержку системы, убеждение их контрагентов (если такие имеются), что "OpenVMS

- не страшно" и прочие неочевидные затраты?

В данном случае, есть некая фиксированная цена, не важно как образованная, а важно, что есть и не ниже.

За одно им надо будет платить больше, при неочевидной выгоде, а за другое - меньше.

 

Цена это эквивалент, как писал товарищ с черной бородой до ушей, - эквивалент качества, а не эквивалент цвета трамвайного билета, ТОЛЬКО при УСЛОВИИ, что последний фактор ислючен = статистически нерелевантен.

А в какой-то области, где присутствует потребитель, такие факторы бывают нерелевантными?

 

Unix обладает достаточной стройной и прозрачной архитектурой.

 

Это как? fork стройная архитектура?

И что такого плохого в fork?

 

Я про стройность спрашивал. А fork плох примерно всем. Начиная с бредовой идеи копирования памяти и состояния ресурсов. Авторы Unix-а по-видимому ничего не знали ни про мультизадачность, ни про ресурсы, кроме файлов. Хотя в то время уже существовали достаточно развитые системы разделения времени и ресурсов.

 

Вы точно про системный вызов fork()?

 

Да

 

А почему-то мне показалось (в предыдущем письме), что про конкретную реализацию...

 

Или в том, что я могу читать из порта обычным read?

 

Для этого не нужно делать порт файлом.

Хорошо: писать в порт с помощью echo из командной оболочки.

 

Зачем?

 

Пример я приводил.

 

Это может быть удобно (первый пример: настройка модема через AT команды).

 

Удобно? Ни разу не настраивал модем подобным способом.

 

Не знаю удобно ли. Это надо было пару дней назад, но не мне. Удалённо настроить модем через AT-команды, когда 3.5 анонимуса, на другом конце, могут только тыкать кнопки на модеме. Похоже, так и не настроили (но это относится к модему, а не к Unix).

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

Писать программу, которая будет вызывать COM API, на старье, где нет даже компилятора, никто не будет - это бессмысленно. Если уж даже в винде не отказались от общения с портом через командный интерфейс...

Но там это сделано крайне неудобно.

 

В DOS надо писать в некое волшебное "псевдоустройство", что отвратительно, а как

в VMS-like?

 

Не помню, давно было. Под Windows есть COM API. Гораздо разумнее. Оно каменный век, другое - верхний мел.

 

Кхм. "COM API" - тоже самое файловое API, как и в Unix, плюс, полторы функции, которые вполне нормально реализуются через iocntl(), вроде?

 

А такая удобная штука, как подключение файла, как блочного устройства, - это тоже последствия неграмотной архитектуры?

 

Разумеется. Блочное устройство - не файл, а вид доступа.

И? Причём тут грамотность архитектуры?

 

Abstraction inversion

 

Где?

Где-то внутри ядра Linux был реализован этот функционал?

Альтернатива - навесить дополнительную функциональность на VFS или что?

Зачем надо много ядер?

Затем, что есть много задач и архитектур.

 

И?

 

И за этим.

 

Как из этого следует необходимость многих ядер.

 

Если заменить "необходимость" на "возможность использования", то следует.

А также, много пользователей, про отношение которых вы писали выше.

 

А ядра тут причем?

 

А про какие конкретно ядра вы говорите?

 

Про их многочисленность в рамках одной системы.

 

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

 

Зачем? Каким образом пользователь А узнает, что сегодня утрецом ему надо как раз ядро Б? Как это связано с ПО? ПО поверх разных ядер разное? Если одно, то почему ядра надо иметь разные, а ПО нет. Если разное, то как достигается горизонтальная интеграция?

 

1. Пользователь A может создавать систему. Бюджета может быть достаточно на детальное изучение различных ОС и ядер, но недостаточно на создание своего ядра

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

 

Каких изысканий? Кто за это платит? Почему, скажем, разработчика текстового процессора должно волновать ядро, если даже меня, разработчика систем реального времени ядро не волнует никак?

 

Причём здесь текстовый процессор (если это не скромный редактор Emacs)? Есть, например, конкретная аппаратура (не спрашивайте какая, это лишь вытянутый из пальца пример), драйвера для которой реализованы в ядре

FreeBSD (лучше, конечно, вспомнить NetBSD), но не реализованы в ядре Linux или наоборот.

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

 

Например, то с чем мы работаем сейчас, BSI

 

https://www.bsi.bund.de/DE/Home/home_node.html

 

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

 

Но ваша фирма - не центр Вселенной?

Могут ли существовать другие модели?

 

2. ПО по некоторым причинам может зависеть от ядра. Грубый пример: системы шифрования. Своя во FreeBSD, своя в Linux. По тем или иным причинам, пользователям может быть удобно работать с какой-то конкретной системой (да хотя

бы прикладную программу для управления они лучше знают).

 

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

Я вообще имел ввиду GEOM ELI и LUKS. Не все же заказчики - государство. Есть и поскромнее.

 

3. Если вы имели ввиду Debian. Я не знаю. Никогда не работал с ядром FreeBSD в Debian. Но я подозреваю, что они просто используют FreeBSD Linux ABI - интерфейс, обеспечивающий бинарную совместимость, который реализован во FreeBSD.

 

В чем тогда разность если весь системный интерфейс один?

 

В "нижнем слое", очевидно.

 

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

 

Эээ... В каком смысле - "бред"?

 

В смысле отсутствия оного.

 

Не очень понимаю: какая альтернатива? Ядра-то,

кажется, всегда и везде были, есть и будут (и в QNX, и, наверняка, в VMS).

 

Ядро системы было и есть. Непонятно, почему недостаточно параметрирования ОС, а необходимо менять ядра, при том, что весь интерфейс предлагается сохранить.

 

А, вы в этом смысле.

"15 января 2012 — релиз Linux 3.3 преодолел отметку в 15 млн строк кода." Как вы знаете, ядро модульное и очень хорошо параметризуется.

Но вот количество параметров и объёмы...

 

При этом, есть другие ядра. Они имеют возможности, которых не имеет ядро Linux. Чтобы эти возможности включить в ядро, надо их практически заново написать (ещё с учётом разных лицензий), а возможно, даже полностью поменять архитектуру ядра (Mach - микроядро).

И каков объём работ?

 

При этом, есть люди, которые готовы портировать ядра в Debian и поддерживать их,

и есть люди, которым может быть интересно использовать альтернативные ядра (в связи с тем, что ядро Linux ещё^W не предоставляет данной конкретной функциональности).

 

В чём вопрос?

 

Другим, необходимым условием для того, чтобы отбор выбирал качественный продукт, нужно чтобы покупатель был способен его оценить по тем же "интересным" факторам.

 

И то, и другое отсутствует.

 

 

А в случае разработки ПО, разве не может оценить тот, кому предназначается закупаемый инструмент?

 

Разумеется не может. Я, например, постоянно пользуюсь и сам пишу компиляторы, но я не возьмусь сравнивать затраты на разработку с использованием GNAT-а против ObjectAda.

 

Вы можете оценить удобство работы, скорость компиляции и т.п.?

 

Объективно? Нет. В стоимостном выражении - три раза нет.

 

И как же вы выбираете компилятор для конкретного проекта (если клиент не предписывает, хотя, в случае Ada, я так думаю, этого нет)?

Или просто решили купить оба?

 

Университет не может ничего разработать.

Эээ... BSD, TCP/IP, Tor и ещё 1001 крупнейшая разработка, причём в разных областях, нет?

 

Нет. Я объяснил почему. Университетские проекты могут быть успешными если финансируются государством или фирмами. В этом случае они нанимают персонал на стороне, и тогда ничем не отличаются от обыкновенной фирмы.

 

BSD был разработан внутри университета.

TCP/IP, как пишут, был разработан по заказу, но также внутри.

Tor разрабатывается университетами.

 

1. Где "персонал со стороны"?

2. Кто спонсировал разработку BSD?

3. Реализация TCP/IP должна была быть легко переносима

между платформами. Т.е., никто не заставлял реализовывать TCP/IP под "свой Unix".

4. OpenVMS к тому времени уже давно существовал и работал.

 

В случае разработки BSD, если архитектура Unix была так плоха, зачем они создали

свою Unix-подобную систему, по-вашему?

Зачем было создавать TCP/IP под BSD, когда вполне возможно было купить VMS (вопрос о финансировании, полагаю, не стоял остро)?

 

 

Для этого нет ни ресурсов, ни квалификации, ни надлежащей организации.

 

https://ru.wikipedia.org/wiki/%D0%90%D1%81%D1%81%D0%BE%D1%86%D0%B8%D0%B0%D1%86%D0%B8%D1%8F_%D0%B0%D0%BC%D0%B5%D1%80%D0%B8%D0%BA%D0%B0%D0%BD%D1%81%D0%BA%D0%B8%D1%85_%D1%83%D0%BD%D0%B8%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%82%D0%B5%D1%82%D0%BE%D0%B2

 

"MIT was elected to the Association of American Universities in 1934 and remains

a research university with a very high level of research activity; research expenditures totaled $718.2 million in 2009."

 

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

предназначены. (А фирмы слвбы фундасентальных исследованиях.)

 

Вы можете представить исследования без инженерной деятельности?

 

Вроде бы C. Браун, "Операционная система Unix".

 

Оно:

http://mirknig.com/knigi/os_bd/1181515068-vvedenie-v-operacionnuyu-sistemu-unix.html

http://rutracker.org/forum/viewtopic.php?t=4084658

http://pay.diary.ru/~challenge999/p143520554.htm

?

Но, как я понял, смысла особого нет читать: там лишь основы работы для пользователя?

 

Про него вообще смысла читать нет, т.к. никаких интересных или полезных идей в плане ОС Unix не имел и не имеет, IMO, разумеется.

 

Мда. Прям таки никаких "интересных и полезных идей" не имеет класс операционных систем, который развивается с 70-х по настоящее время и используется везде: от мобильников, до суперкомпьютеров, плюс на двух самых дорогих проектах человечества?

Конечно я соглашусь. :-&#92;

 

И эти тысячи людей:

https://upload.wikimedia.org/wikipedia/commons/7/77/Unix_history-simple.svg

Они впустую тратили своё время на системы, про которые не имеет смысла даже читать?

 

Да, я согласен с тем, что у Unix и последователей есть много проблем. Хотя, они не умаляют ценность её архитектуры.

Но у вас больше опыта и, вероятно, есть веские основания для того, чтобы отзываться об этой системе (архитектуре и реализациях) отрицательно.

К тому же, я использую системы-последователи Unix (кстати, даже Windows немало унаследовала).

 

Мне было бы интересно узнать (если, конечно, у вас есть время и желание это писать):

1. Что конкретно вы считаете плохим в данном классе систем (чем подробнее, тем лучше)? И это относится ко всем сходным системам?

2. Что было действительно хорошего в VMS и в RSX-11?

3. Как бы сделали вы и что бы поменяли?

 

Весьма интересно было бы взглянуть на архитектуру с другой стороны.

P.S.:

 

да еще и свободную машину получили (DEC-овскую, между прочим). Социализм рождает монстров, как известно.

Слышал такое про "сон разума". А социализм, говорят, в Норвегии. И вполне нормально живут (шибко либеральная партия + Брейвик - не в счёт).

 

И этот социализм Норвегию уже практически доканал. Она чуть задержалась за счет нефти и рыбы. А так, Швеция, Дания и Голландия рядом, там - каюк уже случился. Но это - совсем оффтопик.

 

Ну да, оффтопик. Только не сам по себе социализм, а либерастия, которую выдают за социализм.

 

Ничего либерального в этом нет. В прочем, как и в "progressive", они - не за прогресс. Более корректный термин "lefty", хотя они и не левые. Лучше - "champagne socialists".

 

С другой стороны, в Швейцарии, говорят, всё нормально...

А что, кстати, в Швеции и Дании плохо?

 

Относительно того как было раньше - сильно плохо. Хотя наверное лучше, чем в России и Бурунди.

 

До этого момента я даже не слышал о таком государстве.

 

(пожарные не станут тушить Ваш дом, если у Вас на крыше батареи).

Почему?

 

От того, что они под напряжением. "Не влезай - убьет!"

 

Это я понял. Но что они делать-то будут? Спасателей ждать или что? o.O

On Mon, 27 May 2013 21:42:59 +0400, you wrote:

 

24.05.2013 12:50, Dmitry A. Kazakov пишет:

 

Генератор и компилятор очевидно разные вещи. Речь шла о генераторах.

Генератор тоже, в какой-то степени, возможно считать компилятором.

 

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

 

Почему?

Чем плоха генерация (хотя бы каркаса) по сравнению с написанием вручную?

 

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

 

Чем плохо то, что он "пролезет в конечный продукт"?

 

Вы самолетами летаете? А как насчет автомобиля? Опять возвращаясь к Аде, язык задумывался так, чтобы нефункциональный код не лез в серию.

А почему генерируемый код не должен быть функциональным?

 

Потому что тогда он был бы исполняемым, по-определению.

 

К тому же, пусть это будет не код, а каркас: классы, методы, свойства.

 

Я уже объяснил, что полуготовые куски отвлекают внимание.

 

Rhapsody?

 

У IBM есть все, и все - дорого.

 

Это к тому, что говорили, про некую "абсолютную универсальность", которая, как мне кажется, особого практического смысла не имеет.

 

Как раз практический смысл в наличии. На универсальных языках можно написать все, что написать вообще можно.

Вы про Тьюринг-полные? Тогда почти все современные языки возможно назвать универсальными.

 

Специализированные языки, если и полные, то имеют сильную тенденцию к тому, что некоторые стандартные задачи в них хоть решаются, но совершенно чудовищными способом.

 

Например?

 

Язык: SQL

Задача: обращение матрицы

 

И доказательство тому то, что

трансляторы специализированных языков пишутся на универсальных языках. Вопрос в том, нужны ли эти трансляторы, или специализации можно достичь менее радикальными методами, например, через компоненты.

 

Был раньше Форт.

 

Он и сейчас есть. Как любой, очень плохой язык, Forth - бессмертен. Я его еще под RSX-11M помню.

 

Сейчас он не так распространён. Но почему ж он очень плохой?

Я бы сказал, что он концептуальный.

В нём присутствуют весьма интересные идеи.

 

Как то?

 

Я, конечно, не агитирую за использование обратной польской нотации на практике,

но как опытный язык, Форт имеет право на существование.

 

Там нет никакой предписанной нотации. Просто, что-либо более сложное чем польская было бы чудовищно медленно, для языка, который уже невозможно неэффективен.

 

Позволял легко и непринуждённо создать из его универсального

диалекта специализированный проблемно-ориентированный язык.

Семантика которого отражала область применения, а синтаксис напоминал Форт. И какие недостатки у метода?

 

Создание диалектов языка и есть тот самый недостаток.

 

А вы, при написании кода, разбиваете его на компоненты, состоящие из модулей, которые, в свою очередь, содержат функции с понятными именами?

И чем вызов, типа turn_shaft(360) *принципиально* будет отличаться от 360 degree

turn_shaft, например?

 

Функция - не компонента. А разница в том, что читатель кода не должен преодолевать барьер обучения новому языку каждый раз, когда он сталкивается с чужим или даже своим кодом.

 

Разве на универсальном языке вы не будете создавать специализированные (как не реализуйте и назовите: компоненты, набор процедур, интерпретатор с новым синтаксисом), которые отражают предметную область, для того, чтобы разрабатывать

в терминах предметной области?

 

Компонента и синтаксис вещи весьма далекие. Синтаксис еще дальше, чем диалект. Диалект, по-идее, сохраняет синтаксис.

 

Принципиальная разница здесь есть?

 

Синтаксис - наиболее консервативная часть любого языка, которая

перемалывает все, например, лексику. Это происходит именно потому, что разница есть и огромна. Она заложена в конструкцию человеческого мозга.

Или всё вышеперечисленное делается для того, чтобы создать инструмент, наиболее

полно соответствующий предметной области?

Зачем тогда разработчики игр включают в них языки сценариев, а не предоставляют

игровому дизайнеру "всю гибкость универсального языка"?

 

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

 

Данный случай - исключение?

 

Исключение из чего? Бюрократы обожают процессы.

 

И поэтому они отменили одну методологию и начали создавать другую? Всё исчерпывается бюрократией?

 

А как Вы на их месте оправдаете свое существование, существование отдела, расширение персонала, площадей и т.д.?

 

Или конкретно методологии разработки, в данном ключе, чем-то выделяются?

Алгоритм - хорошо, но это не программирование.

Я это понимаю.

Или вы хотите сказать, что алгоритм не входит в программирование?

 

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

 

Вокруг чего всё крутится сейчас?

 

Более сложные абстракции. Декомпозиция теперь не процедурна.

 

Во-вторых, пытается абстрагироваться от деталей реализации (в большей степени, за счёт изменения парадигмы).

 

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

Мне представлялся Пролог, когда я это писал.

 

То что Prolog - не серьезно, все помимали еще в самом начале 90-х. Я запомнил одну статью в каком-то американском журнале с издевательским названием, "Если 5GL ответ, то что же было вопросом?".

Статья немного отстала?

https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B8%D0%B7%D0%B8%D1%81_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F

 

Почему? Нет. Кризис с тех пор только обострился. Но речь шла не о кризисе, а о методах его преодоления. То, что в 90-е считалость более высоким уровнем языка, таковым не являлось. И уж совсем не вело к повышению производительности прграммистов. Кризис 90-х был компенсирован ОО, компонентами и т.п., но никак не Прологом.

 

По моим представлениям, тема nGL давно закрыта.

 

Да ладно вам.

http://www.mercurylang.org/

 

А почему Вы решили, что это следующий уровень GL?

 

http://www.visual-prolog.com/

 

И что?

Я неправильно написал предыдущее. Меня понесло не в ту степь.

Скорее, по-другому. С помощью своей концепции он пытался описать систему целостно.

Т.е., человеку предоставляется описание того, как система работает.

 

Так это - архитектура, а совсем не код.

 

Как ни назовите. Пусть, словесное описание архитектуры модуля. Сути это не меняет.

Описывается архитектура, иллюстрируемая частями кода системы.

В разумных масштабах, конечно.

Далее, из описания архитектуры создаётся код.

 

Это как? Давайте я Вам опишу архитектуру автомобиля. И?

 

Да, минус в том, что слишком высокий уровень детализации, на данном этапе.

 

Я не вижу никаких этапов. Какой этап следует дальше без построения настоящего ИИ? Все это - строение хрустального моста...

 

Но, с другой стороны, такой подход ведь не исключает более высокоуровнего описания архитектуры (в том же UML, например)?

 

Я считаю UML языком более низкого уровня, по сравнению с любым ОО языком, если рассматривать его именно в качестве ЯЗЫКА ПРОГРАММИРОВАНИЯ.

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

 

Может, не такая и плохая штука?

 

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

 

Хорошо. В таком случае, как это делается правильно, объясните?

 

Надо писать документацию.

 

Если вы отрицаете этот подход, каков ваш подход?

 

Я пытаюсь писать документацию руками параллельно с программой.

 

Может должно быть меньше непонятных мест? И опять, непонятных кому? В отличие от литературного произведения, даже среднего размера программу никто не понимает, и не может понять. Это физически не возможно. Поэтому программы разрабатываются так, чтобы этого не требовалось.

Да, а что значит "понимание", в данном случае?

 

Понимание означает, что заданный аспект проекта можно познать в разумное время прилагая разумные усилия. Локальное понимание, обеспечивается языком. Именно поэтому, языки остаются императивными. Более общие концепции описываются типами и классами. Еще более общие абтракции описываются словесно и графически.

 

Программ для компьютеров?

Для каких?

 

Тех, чторые можно купить.

 

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

 

Т.е., "универсальный язык" уже подходит не для всех типов компьютеров?

 

Тех типов, как предмета инженерной деятельности, пока еще нет. Будет утро, будет пища...

 

Тут, пожалуй, не измерение, а выбор из варианта "нет ничего" и "есть хоть что-то".

 

Как Вам такой: или нет денег, или есть гемморой?

 

Это как? Windows рулит.

Ччч-е-м оно рулит? O_O

 

А Билли-то, опять самый богатый человек на свете!

Да, не всегда рациональные, но не более того.

 

Что никак не меняет исходную позицию, она же - финальная.

 

Это меняет отношение.

Вы говорили про "отрицательный отбор", что отдавало фатализмом и некой "тёмной волей".

 

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

 

Первые христиане стойко выносили пытки, по причине того, что они имели сильную волю?

 

Воля римлян была слабее. 500 лет спустя пришли мусульмане и смели христиан, пока не уперлись в не менее диких северян. В противостоянии воль между варваром и цивилизованным человеком всегда побеждает варвар, пока у цивилизованного человека нет пулемета. Тогда побеждает пулемет...

В данном контексте, рациональность - "здравый смысл".

Он предполагает наличие неких объективных причин, которые возможно представить в

каком-либо измеримом эквиваленте.

Нерациональость - это наличие субъективных причин, какой-то эмоциональной оценки.

 

И то, и другое. Рациональность - попытка объяснения путем логических выводов. Объективность или субъективность исходных положений тут не важна. Субъективность просто предполагает участие индивидуального человека как источника информации.

 

Отбор языков программирования, процессоров, ОС на длинной дистанции безусловно является скорее иррациональным.

 

А когда есть набор причин, с ними, хотя бы в теории, возможно работать.

 

Также есть и причины, почему никто с ними работать не будет.

 

Какие причины?

 

Причина №1: зачем?

 

И никто не работает?

Маркетинг, PR в его контексте, рекламные методы, пропаганда, формирование мнения, - не действуют?

 

И что? Вы хотите методами маркетинга сделать что именно? Замените "язык программирования" на "космический корабль".

 

В данном случае, есть некая фиксированная цена, не важно как образованная,

 

Не важно для качества продукта. Именно так.

 

Цена это эквивалент, как писал товарищ с черной бородой до ушей, - эквивалент качества, а не эквивалент цвета трамвайного билета, ТОЛЬКО при УСЛОВИИ, что последний фактор ислючен = статистически нерелевантен.

А в какой-то области, где присутствует потребитель, такие факторы бывают нерелевантными?

 

Мы обсуждали почему отбор отрицателен.

 

Или в том, что я могу читать из порта обычным read?

 

Для этого не нужно делать порт файлом.

Хорошо: писать в порт с помощью echo из командной оболочки.

 

Зачем?

 

Пример я приводил.

 

Нет не приводили. Пример - приложение, где это использовалось бы.

В DOS надо писать в некое волшебное "псевдоустройство", что отвратительно, а как

в VMS-like?

 

Не помню, давно было. Под Windows есть COM API. Гораздо разумнее. Оно каменный век, другое - верхний мел.

 

Кхм. "COM API" - тоже самое файловое API, как и в Unix, плюс, полторы функции, которые вполне нормально реализуются через iocntl()

(Message over 64 KB, truncated)

28.05.2013 12:58, Dmitry A. Kazakov пишет:

 

 

On Mon, 27 May 2013 21:42:59 +0400, you wrote:

 

24.05.2013 12:50, Dmitry A. Kazakov пишет:

 

Генератор и компилятор очевидно разные вещи. Речь шла о генераторах.

Генератор тоже, в какой-то степени, возможно считать компилятором.

 

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

 

*Доработки* программистом.

Вы всё-равно напишите руками то, что сделал бы генератор.

Так зачем делать больше?

 

Почему?

Чем плоха генерация (хотя бы каркаса) по сравнению с написанием вручную?

 

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

 

Чем плохо то, что он "пролезет в конечный продукт"?

 

Вы самолетами летаете? А как насчет автомобиля? Опять возвращаясь к Аде, язык задумывался так, чтобы нефункциональный код не лез в серию.

А почему генерируемый код не должен быть функциональным?

 

Потому что тогда он был бы исполняемым, по-определению.

 

И что в этом плохого, при условии, что этот код делает то, что нужно и так, как нужно?

 

К тому же, пусть это будет не код, а каркас: классы, методы, свойства.

 

Я уже объяснил, что полуготовые куски отвлекают внимание.

Честно говоря, я подзабыл за это время. Пришлось перечитывать.

Вы объясняли здесь:

"Если каркас не компилируем, то куски, про

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

 

Т.е., внимание отвлекают сообщения компилятора, а не куски, как таковые? Если же, куски являются просто каркасом (класс с набором атрибутов и свойств и пустые методы), на которые компилятор не ругается, - это тоже плохо?

Может должно быть меньше непонятных мест? И опять, непонятных кому? В отличие от литературного произведения, даже среднего размера программу никто не понимает, и не может понять. Это физически не возможно. Поэтому программы разрабатываются так, чтобы этого не требовалось.

Да, а что значит "понимание", в данном случае?

 

Понимание означает, что заданный аспект проекта можно познать в разумное время прилагая разумные усилия. Локальное понимание, обеспечивается языком. Именно поэтому, языки остаются императивными. Более общие концепции описываются типами и классами. Еще более общие абтракции описываются словесно и графически.

 

1. Насколько эффективно такой подход (отсутствие автоматизации в виде генерации,

автоматической проверки и прочего) работает на практике?

2. Графически, насколько я понял, - UML. Словесно - в произвольной форме? 3. А про нечто подобное что скажете: http://cukes.info/ ?

 

Это к тому, что говорили, про некую "абсолютную универсальность", которая, как мне кажется, особого практического смысла не имеет.

 

Как раз практический смысл в наличии. На универсальных языках можно написать все, что написать вообще можно.

Вы про Тьюринг-полные? Тогда почти все современные языки возможно назвать универсальными.

 

Специализированные языки, если и полные, то имеют сильную тенденцию к тому, что некоторые стандартные задачи в них хоть решаются, но совершенно чудовищными способом.

 

Например?

 

Язык: SQL

Задача: обращение матрицы

 

o.O Месье, но зачем реализовывать *эту задачу* на SQL?

Это, не то, что несколько не в области его применения?

Примерно то же самое возможно сказать, например про Ada, в случае получения кортежей в цикле из СУБД.

В итоге, окажется, что вызов select быстрее, нагляднее и понятнее человеку. И ради чего? Уменьшения времени обучения?

 

Позволял легко и непринуждённо создать из его универсального

диалекта специализированный проблемно-ориентированный язык.

Семантика которого отражала область применения, а синтаксис напоминал Форт. И какие недостатки у метода?

 

Создание диалектов языка и есть тот самый недостаток.

 

А вы, при написании кода, разбиваете его на компоненты, состоящие из модулей, которые, в свою очередь, содержат функции с понятными именами?

И чем вызов, типа turn_shaft(360) *принципиально* будет отличаться от 360 degree

turn_shaft, например?

 

Функция - не компонента. А разница в том, что читатель кода не должен преодолевать барьер обучения новому языку каждый раз, когда он сталкивается с чужим или даже своим кодом.

 

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

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

Во втором случае, и так понятно: вы C++ хорошо знаете?

Снимается ли барьер?

 

В случае же специализированного языка (или диалекта, отражающего предметную область), предполагается, что тот, кто с ним будет работать уже имеет познания в

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

 

Что не правильно?

 

Программ для компьютеров?

Для каких?

 

Тех, чторые можно купить.

 

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

 

Т.е., "универсальный язык" уже подходит не для всех типов компьютеров?

 

Тех типов, как предмета инженерной деятельности, пока еще нет. Будет утро, будет пища...

 

А чем Бейсик, например, не универсальный язык?

Вполне подходит на эту роль.

И для PHP тоже возможно сделать компилятор...

http://habrahabr.ru/post/57000/

 

И доказательство тому то, что

трансляторы специализированных языков пишутся на универсальных языках. Вопрос в том, нужны ли эти трансляторы, или специализации можно достичь менее радикальными методами, например, через компоненты.

 

Был раньше Форт.

 

Он и сейчас есть. Как любой, очень плохой язык, Forth - бессмертен. Я его еще под RSX-11M помню.

 

Сейчас он не так распространён. Но почему ж он очень плохой?

Я бы сказал, что он концептуальный.

В нём присутствуют весьма интересные идеи.

 

Как то?

То, про что я уже писал: создание диалектов, прежде всего.

 

Я, конечно, не агитирую за использование обратной польской нотации на практике,

но как опытный язык, Форт имеет право на существование.

 

Там нет никакой предписанной нотации. Просто, что-либо более сложное чем польская было бы чудовищно медленно, для языка, который уже невозможно неэффективен.

 

Думаю, что из стекового языка, обратная нотация естественно вытекает.

Синтаксис - наиболее консервативная часть любого языка, которая

перемалывает все, например, лексику.

Это происходит именно потому, что

разница есть и огромна. Она заложена в конструкцию человеческого мозга.

А подробнее возможно?

 

Или всё вышеперечисленное делается для того, чтобы создать инструмент, наиболее

полно соответствующий предметной области?

Зачем тогда разработчики игр включают в них языки сценариев, а не предоставляют

игровому дизайнеру "всю гибкость универсального языка"?

 

Потому, что та часть о которой говорите Вы, а это не более 10-20% объема проекта, - хорошо изолирована для того, чтобы в ней можно было использовать специализированнный язык.

Так не проще ли выделить части проекта, которые могут быть качественнее и быстрее реализованы на спец. языках?

 

Я делал ИИ на Аде и не испытывал особой нужды в чем-то

другом. Но, традиционно ИИ делался на динамических языках типа Лиспа и декларативных языках, как Пролог и экспертные системы и т.п. Почему это не ушло до сих пор? Я думаю потому, что ИИ все еще экспериментальная область, где все делается на коленках и с нуля. В таких условиях специализация не самая большая проблема.

 

Говорят, что это из-за существования двух расшифровок данной аббревиатуры.

Данный случай - исключение?

 

Исключение из чего? Бюрократы обожают процессы.

 

И поэтому они отменили одну методологию и начали создавать другую? Всё исчерпывается бюрократией?

 

А как Вы на их месте оправдаете свое существование, существование отдела, расширение персонала, площадей и т.д.?

 

На месте Конгресса? А им надо?

 

Почему? Нет. Кризис с тех пор только обострился. Но речь шла не о кризисе, а о методах его преодоления. То, что в 90-е считалость более высоким уровнем языка, таковым не являлось. И уж совсем не вело к повышению производительности прграммистов. Кризис 90-х был компенсирован ОО, компонентами и т.п., но никак не Прологом.

 

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

 

По моим представлениям, тема nGL давно закрыта.

 

Да ладно вам.

http://www.mercurylang.org/

 

А почему Вы решили, что это следующий уровень GL?

 

Это частично декларативный язык. Гибрид Пролога и функционального языка. Типичный представитель этих ваших 5GL.

 

http://www.visual-prolog.com/

 

И что?

 

И жив.

 

Я неправильно написал предыдущее. Меня понесло не в ту степь.

Скорее, по-другому. С помощью своей концепции он пытался описать систему

целостно.

Т.е., человеку предоставляется описание того, как система работает.

 

Так это - архитектура, а совсем не код.

 

Как ни назовите. Пусть, словесное описание архитектуры модуля. Сути это не меняет.

Описывается архитектура, иллюстрируемая частями кода системы.

В разумных масштабах, конечно.

Далее, из описания архитектуры создаётся код.

 

Это как? Давайте я Вам опишу архитектуру автомобиля. И?

 

А у вас есть инструмент, который из кусков автомобиля и описания к ним соберёт автомобиль?

Разные вещи.

 

Но, с другой стороны, такой подход ведь не исключает более высокоуровнего описания архитектуры (в том же UML, например)?

 

Я считаю UML языком более низкого уровня, по сравнению с любым ОО языком, если рассматривать его именно в качестве ЯЗЫКА ПРОГРАММИРОВАНИЯ. Отсутствуют типы. Очень слабая модульность. Нет никакого разделения на спецификацию и реализацию. Отсюда невозможность анализа. Да просто, сравнить две программы - совершенно нетривиальная проблема.

 

А какие альтернативы?

 

Может, не такая и плохая штука?

 

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

 

Хорошо. В таком случае, как это делается правильно, объясните?

 

Надо писать документацию.

 

Надо. Но как писать?

 

Если вы отрицаете этот подход, каков ваш подход?

 

Я пытаюсь писать документацию руками параллельно с программой.

 

И хорошо получается поддерживать одно актуальным другому?

 

Тут, пожалуй, не измерение, а выбор из варианта "нет ничего" и "есть хоть что-то".

 

Как Вам такой: или нет денег, или есть гемморой?

 

Пожалуй, вы утрируете.

 

Да, не всегда рациональные, но не более того.

 

Что никак не меняет исходную позицию, она же - финальная.

 

Это меняет отношение.

Вы говорили про "отрицательный отбор", что отдавало фатализмом и некой "тёмной волей".

 

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

 

Первые христиане стойко выносили пытки, по причине того, что они имели сильную

волю?

 

Воля римлян была слабее.

И Муция Сцеволы?

 

500 лет спустя пришли мусульмане и смели христиан,

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

Это не воля. Воля бывает у отдельных людей. У народов воли нет.

 

Тогда побеждает пулемет...

 

Ну да...

 

В данном контексте, рациональность - "здравый смысл".

Он предполагает наличие неких объективных причин, которые возможно представить в

каком-либо измеримом эквиваленте.

Нерациональость - это наличие субъективных причин, какой-то эмоциональной оценки.

 

И то, и другое. Рациональность - попытка объяснения путем логических выводов. Объективность или субъективность исходных положений тут не важна. Субъективность просто предполагает участие индивидуального человека как источника информации.

 

Отбор языков программирования, процессоров, ОС на длинной дистанции безусловно является скорее иррациональным.

 

Да конечно, всё зависит от "длины дистанции". Естественно, имеется ввиду, выбор некоего "локального оптимума".

 

А когда есть набор причин, с ними, хотя бы в теории, возможно работать.

 

Также есть и причины, почему никто с ними работать не будет.

 

Какие причины?

 

Причина №1: зачем?

 

И никто не работает?

Маркетинг, PR в его контексте, рекламные методы, пропаганда, формирование мнения, - не действуют?

 

И что? Вы хотите методами маркетинга сделать что именно? Замените "язык программирования" на "космический корабль".

 

Методы маркетинга и есть причины "отрицательности" отбора. Причины, а не какая-то трансцендентная сущность.

 

В данном случае, есть некая фиксированная цена, не важно как образованная,

 

Не важно для качества продукта. Именно так.

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

Цена это эквивалент, как писал товарищ с черной бородой до ушей, - эквивалент качества, а не эквивалент цвета трамвайного билета, ТОЛЬКО при УСЛОВИИ, что последний фактор ислючен = статистически нерелевантен.

А в какой-то области, где присутствует потребитель, такие факторы бывают нерелевантными?

 

Мы обсуждали почему отбор отрицателен.

 

Точнее: наличие или отсутствие "отрицательного отбора" и что это такое.

Или в том, что я могу читать из порта обычным read?

 

Для этого не нужно делать порт файлом.

Хорошо: писать в порт с помощью echo из командной оболочки.

 

Зачем?

 

Пример я приводил.

 

Нет не приводили. Пример - приложение, где это использовалось бы.

Я привёл случай, когда требовалось.

 

В DOS надо писать в некое волшебное "псевдоустройство", что отвратительно, а как

в VMS-like?

 

Не помню, давно было. Под Windows есть COM API. Гораздо разумнее. Оно каменный век, другое - верхний мел.

 

Кхм. "COM API" - тоже самое файловое API, как и в Unix, плюс, полторы функции, которые вполне нормально реализуются через iocntl(), вроде?

 

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363194%28v=vs.85%29.aspx

 

Ну, про что я и говорю: не полторы, конечно, а три с половиной функции. А открытие-чтение-запись - файловое API, как и в Unix-like.

Вы же не TransmitCommChar() используете, для отправки данных в порт?

А такая удобная штука, как подключение файла, как блочного устройства, - это тоже последствия неграмотной архитектуры?

 

Разумеется. Блочное устройство - не файл, а вид доступа.

И? Причём тут грамотность архитектуры?

 

Abstraction inversion

 

Где?

 

Когда абстракиця нихнего уровня используется для представления абстракций верхнего уровня.

 

Подождите, где здесь инверсия?

Вид доступа - блочное устройство.

Файл для блочного устройства loopback - источник данных.

Само устройство, представленное файлом...

Пусть даже тут и есть некая инверсия, больше ли в ней минусов, чем плюсов?

Зачем надо много ядер?

Затем, что есть много задач и архитектур.

 

И?

 

И за этим.

 

Как из этого следует необходимость многих ядер.

 

Если заменить "необходимость" на "возможность использования", то следует.

 

Каким образом из "многих задач" следует "возможность"?

 

Многие задачи => разные требования => параметры инструмента.

 

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

 

Зачем? Каким образом пользователь А узнает, что сегодня утрецом ему надо как раз ядро Б? Как это связано с ПО? ПО поверх разных ядер разное? Если одно, то почему ядра надо иметь разные, а ПО нет. Если разное, то как достигается горизонтальная интеграция?

 

1. Пользователь A может создавать систему. Бюджета может быть достаточно на детальное изучение различных ОС и ядер, но недостаточно на создание своего ядра

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

 

Каких изысканий? Кто за это платит? Почему, скажем, разработчика текстового процессора должно волновать ядро, если даже меня, разработчика систем реального времени ядро не волнует никак?

 

Причём здесь текстовый процессор (если это не скромный редактор Emacs)?

 

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

 

Я не говорил, что ядра *должны* волновать пользователей и разработчиков (если, конечно, это не разработчики ядра).

В большинстве случаев, никто не задумывается о ядре.

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

оборудования (потому что, нет смысла чего-то переписывать), возможность тонкой настройки (например, возможность выбора планировщика ввода-вывода) и т.п.)? Идеально подходящего подо все задачи ядра на данный момент не существует (и к тому же Linux, поэтому иногда пытаются прикрутить Realtime расширения, потому что удобно было бы иметь одну среду в разных областях), если я не ошибаюсь? Поэтому, я считаю плюсом, *возможность* работать с разными ядрами в одном окружении (т.е., именно не думать о ядре).

 

Есть, например, конкретная аппаратура (не спрашивайте какая, это лишь вытянутый

из пальца пример), драйвера для которой реализованы в ядре

FreeBSD (лучше, конечно, вспомнить NetBSD), но не реализованы в ядре Linux или наоборот.

 

Перепишите драйвер.

 

"Драйвер" - расплывчатое понятие.

DRBD, например, - тоже драйвер.

Перепишите, если потребуется?

 

3. Если вы имели ввиду Debian. Я не знаю. Никогда не работал с ядром FreeBSD в Debian. Но я подозреваю, что они просто используют FreeBSD Linux ABI - интерфейс, обеспечивающий бинарную совместимость, который реализован во

FreeBSD.

 

В чем тогда разность если весь системный интерфейс один?

 

В "нижнем слое", очевидно.

 

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

Разницы не существует для интерфейса между приложением и ядром, хотя бы потому, что, как правило, пытаются использовать библиотеку.

 

2. ПО по некоторым причинам может зависеть от ядра. Грубый пример: системы шифрования. Своя во FreeBSD, своя в Linux. По тем или иным причинам, пользователям может быть удобно работать с какой-то конкретной системой (да хотя

бы прикладную программу для управления они лучше знают).

 

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

Я вообще имел ввиду GEOM ELI и LUKS. Не все же заказчики - государство.

 

BSI не заказчик. Он - бюро стандартов. Он предоставляет проект предписаний, и, в конечном итоге, Бундестаг его прописывает в закон. Но это - уже оффтопик оффтопика.

 

А, понял. Т.е., применение шифрования юридическими лицами или любыми коммерческими организациями требует лицензирования?

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

обязаны использовать предписанный стандарт?

Это к тому, что вы о частностях.

 

Не очень понимаю: какая альтернатива? Ядра-то,

кажется, всегда и везде были, есть и будут (и в QNX, и, наверняка, в VMS).

 

Ядро системы было и есть. Непонятно, почему недостаточно параметрирования ОС, а необходимо менять ядра, при том, что весь интерфейс предлагается сохранить.

 

А, вы в этом смысле.

"15 января 2012 — релиз Linux 3.3 преодолел отметку в 15 млн строк кода." Как вы знаете, ядро модульное и очень хорошо параметризуется.

Но вот количество параметров и объёмы...

 

И Вы для любой комбинации параметров разрабатываете новое ядро? Грандиозная идея!

 

Вы вытащили слова из контекста. Я как-раз говорил про обратное. Мало того, вы утрируете.

 

При этом, есть другие ядра. Они имеют возможности, которых не имеет ядро Linux.

 

Ненаблюдаемые возможности, следовательно - несуществующие.

 

Хех, Питер Хиггс посмотрел бы на вас угрюмо и с хитрым прищуром. :-)

При этом, есть люди, которые готовы портировать ядра в Debian и поддерживать их,

и есть люди, которым может быть интересно использовать альтернативные ядра (в связи с тем, что ядро Linux ещё^W не предоставляет данной конкретной функциональности).

 

В чём вопрос?

 

Вопроса нет, есть ответ - никому (в промышленности) это не нужно.

Да, в какой промышленности-то?

Какого государства?

Linux используют во всю.

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

Промышленность - ещё тот показатель.

 

Я видел барахло^W систему, в которой используется в связке Linux, FreeBSD и Windows Server на разных серверах. Честно говоря, я не знаю причин по которым это было сделано (да, согласен: вряд ли ядро), но предполагаю, что платить человеку, который имеет навыки работы с Linux и FreeBSD нужно больше (в теории),

чем тому, кто умеет работать только с Linux.

 

А в случае разработки ПО, разве не может оценить тот, кому предназначается закупаемый инструмент?

 

Разумеется не может. Я, например, постоянно пользуюсь и сам пишу компиляторы, но я не возьмусь сравнивать затраты на разработку с использованием GNAT-а против ObjectAda.

 

Вы можете оценить удобство работы, скорость компиляции и т.п.?

 

Объективно? Нет. В стоимостном выражении - три раза нет.

 

И как же вы выбираете компилятор для конкретного проекта (если клиент не предписывает, хотя, в случае Ada, я так думаю, этого нет)?

 

От балды, конечно.

O_O OMG!

 

TCP/IP, как пишут, был разработан по заказу, но также внутри.

 

Не продукт, а стандарт.

 

И продукт, в том числе. Реализация.

 

4. OpenVMS к тому времени уже давно существовал и работал.

 

OpenVMS не имеет к этому никакого отношения.

VMS.

 

DECnet был и существовал

примерно а тоже время, хотя это не аналог TCP/IP. Между прочим, именно DEC одним из первых стал поддерживать TCP/IP.

 

Но первый стек был реализован в BSD.

 

В случае разработки BSD, если архитектура Unix была так плоха, зачем они создали

свою Unix-подобную систему, по-вашему?

 

Их и спросите. А зачем Линус это делал? Хобби проекты. Unix прост как зубной порошок.

Так мало того, некоторые ещё исповедуют принцип KISS и держат за пазухой бритву.

 

Идеально для начинающих и университетов. Именно они стали

инкубатором этой заразы... (:-))

 

Знаете, столь вирулентная зараза стоит десятка самых лучших ОС. ;-)

Вы можете представить исследования без инженерной деятельности?

 

Еще как!

 

Да, я понял. Имелись ввиду большие исследовательские проекты университетов, в которых требуется создание оборудования, так или иначе.

 

Они впустую тратили своё время на системы, про которые не имеет смысла даже

читать?

 

А миллиарды людей вообще верят и занимаются черт знает чем.

 

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

 

Мне было бы интересно узнать (если, конечно, у вас есть время и желание это

писать):

1. Что конкретно вы считаете плохим в данном классе систем (чем подробнее, тем лучше)? И это относится ко всем сходным системам?

2. Что было действительно хорошего в VMS и в RSX-11?

 

1. Защищенность

 

В каком плане?

 

2. Надежность. ОС работала после отказа дисков. Я не мог даже загрузить ДЕМОС Unix на нашем железе (СМ), так как происходил по крайней мере один сбой. После чего носитель (ленту) нужно было заново переписывать (мастер блок был испорчен). Unix не имел самой мнимальной обработки сбоев оборудования.

 

Как защита от этого была реализована в RSX-11?

Многократное дублирование мастер-блока?

 

3. Малые требования к ресурсам, в частности из-за асинхронного ввода-вывода и возможности прямого доступа к буферам ввода-вывода. Там где Unix создавал надцать процессов и качал данные через сто буферов, RSX-11 использовала один процесс и один буфер.

 

Хм... Не совсем понял про это. Где создание процессов?

 

4. Развитые средства многозадачности

 

В каком плане?

 

5. Поддержка различных видов доступа к файлу, напрмер записей и т.п., на уровне системы.

 

Эээ... Как в z/OS? Тяжко.

 

6. Легкость подключения нового оборудования.

 

Какого оборудования? Жёстких дисков и процессоров? Разве это не обеспечивалось, прежде всего, аппаратной реализацией?

 

3. Как бы сделали вы и что бы поменяли?

 

ОО ОС, вообще без файлов.

 

Оно:

http://www.dz.ru/solutions/phantom

? :-)

 

Если серьёзно, вы про Оберон систему или подобное?

 

(пожарные не станут тушить Ваш дом, если у Вас на крыше батареи).

Почему?

 

От того, что они под напряжением. "Не влезай - убьет!"

 

Это я понял. Но что они делать-то будут? Спасателей ждать или что?

 

Будут ждать пока не догорит. Соседей поливать, чтобы те не загорелись.

o.O Как-то дико это...

On Mon, 17 Jun 2013 20:45:42 +0400, you wrote:

 

28.05.2013 12:58, Dmitry A. Kazakov пишет:

 

On Mon, 27 May 2013 21:42:59 +0400, you wrote:

 

24.05.2013 12:50, Dmitry A. Kazakov пишет:

 

Генератор и компилятор очевидно разные вещи. Речь шла о генераторах.

Генератор тоже, в какой-то степени, возможно считать компилятором.

 

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

 

*Доработки* программистом.

Вы всё-равно напишите руками то, что сделал бы генератор.

Так зачем делать больше?

 

Это уже совсем другой вопрос. На него есть ответ. NASA тренирует

космонавтов влезать на деревья. Зачем? На дереве ты ближе к Луне.

А почему генерируемый код не должен быть функциональным?

 

Потому что тогда он был бы исполняемым, по-определению.

 

И что в этом плохого, при условии, что этот код делает то, что нужно и так, как

нужно?

 

См. выше. Если он делает, то это не генерируемый, а транслируемый код. Следовательно он не делает.

 

Вы объясняли здесь:

"Если каркас не компилируем, то куски, про

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

 

Т.е., внимание отвлекают сообщения компилятора, а не куски, как таковые?

 

Сообщения о кусках.

 

Если же, куски являются просто каркасом (класс с набором атрибутов и свойств и пустые методы), на которые компилятор не ругается, - это тоже плохо?

 

Это совсем плохо, т.к. эти вещи относятся к архитектуре, что очевидно требует большего внимания чем техгические детали. Все тут поставлено с ног на голову. Сложные вещи генериркются, а простые нет. Почему если можно первое, но нельзя второе? Ответ прост, первое тоже не делается, просто за руку не поймать.

 

Может должно быть меньше непонятных мест? И опять, непонятных кому? В отличие от литературного произведения, даже среднего размера программу никто не понимает, и не может понять. Это физически не возможно. Поэтому программы разрабатываются так, чтобы этого не требовалось.

Да, а что значит "понимание", в данном случае?

 

Понимание означает, что заданный аспект проекта можно познать в разумное время прилагая разумные усилия. Локальное понимание, обеспечивается языком. Именно поэтому, языки остаются императивными. Более общие концепции описываются типами и классами. Еще более общие абтракции описываются словесно и графически.

 

1. Насколько эффективно такой подход (отсутствие автоматизации в виде генерации,

автоматической проверки и прочего) работает на практике?

 

Не знаю. Разумная методика измерения отсутствует.

 

2. Графически, насколько я понял, - UML. Словесно - в произвольной форме?

 

Да.

 

3. А про нечто подобное что скажете: http://cukes.info/ ?

 

Выглядит как XP (extreme programming). Дальше не вдавался.

 

Это к тому, что говорили, про некую "абсолютную универсальность", которая, как мне кажется, особого практического смысла не имеет.

 

Как раз практический смысл в наличии. На универсальных языках можно написать все, что написать вообще можно.

Вы про Тьюринг-полные? Тогда почти все современные языки возможно назвать универсальными.

 

Специализированные языки, если и полные, то имеют сильную тенденцию к тому, что некоторые стандартные задачи в них хоть решаются, но совершенно чудовищными способом.

 

Например?

 

Язык: SQL

Задача: обращение матрицы

 

o.O Месье, но зачем реализовывать *эту задачу* на SQL?

 

Вы просили пример. Я его привел.

 

Это, не то, что несколько не в области его применения?

Примерно то же самое возможно сказать, например про Ada, в случае получения кортежей в цикле из СУБД.

В итоге, окажется, что вызов select быстрее, нагляднее и понятнее человеку.

 

Сомневаюсь. select не сильно тянет на проблему. Проблема, скорее, - поиск в некоторм множестве. Обращение матрицы в каком-то смысле тоже поиск. Но и чистый поиск сгодится. Например, поиск ближайшего соседа, kd-деревья. Тут-то SQL и конец.

 

И ради чего? Уменьшения времени обучения?

 

Ради уменьшения риска (того, что задачу будет не решить приемлемым способом). Управление рисками - самая большая проблема разработки ПО.

Позволял легко и непринуждённо создать из его универсального

диалекта специализированный проблемно-ориентированный язык.

Семантика которого отражала область применения, а синтаксис напоминал Форт. И какие недостатки у метода?

 

Создание диалектов языка и есть тот самый недостаток.

 

А вы, при написании кода, разбиваете его на компоненты, состоящие из модулей, которые, в свою очередь, содержат функции с понятными именами?

И чем вызов, типа turn_shaft(360) *принципиально* будет отличаться от 360 degree

turn_shaft, например?

 

Функция - не компонента. А разница в том, что читатель кода не должен преодолевать барьер обучения новому языку каждый раз, когда он сталкивается с чужим или даже своим кодом.

 

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

либо минимален (в сравнении с размером областей применения), либо крайне громоздким.

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

Во втором случае, и так понятно: вы C++ хорошо знаете?

Снимается ли барьер?

 

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

 

В случае же специализированного языка (или диалекта, отражающего предметную область), предполагается, что тот, кто с ним будет работать уже имеет познания в

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

 

Что не правильно?

 

Вы иностранные языки знаете? Пробовали говорить одновременно на двух?

А чем Бейсик, например, не универсальный язык?

Вполне подходит на эту роль.

 

И "Запорожец" - автомобиль.

 

И доказательство тому то, что

трансляторы специализированных языков пишутся на универсальных языках. Вопрос в том, нужны ли эти трансляторы, или специализации можно достичь менее радикальными методами, например, через компоненты.

 

Был раньше Форт.

 

Он и сейчас есть. Как любой, очень плохой язык, Forth - бессмертен. Я его еще под RSX-11M помню.

 

Сейчас он не так распространён. Но почему ж он очень плохой?

Я бы сказал, что он концептуальный.

В нём присутствуют весьма интересные идеи.

 

Как то?

То, про что я уже писал: создание диалектов, прежде всего.

 

Вот диалектоа-то и не надо.

 

Я, конечно, не агитирую за использование обратной польской нотации на практике,

но как опытный язык, Форт имеет право на существование.

 

Там нет никакой предписанной нотации. Просто, что-либо более сложное чем польская было бы чудовищно медленно, для языка, который уже невозможно неэффективен.

 

Думаю, что из стекового языка, обратная нотация естественно вытекает.

 

Возьмите два стека вместо одного, и инфиксная нотация будет летать.

Синтаксис - наиболее консервативная часть любого языка, которая

перемалывает все, например, лексику.

Это происходит именно потому, что

разница есть и огромна. Она заложена в конструкцию человеческого мозга.

А подробнее возможно?

 

Посмотрите на то, что происходит с иностранными словами в Русском языке. Они обрастают суфиксами и приставками, получают род, меняют ударение и корни. Через пару десятков лет, любое слово будет отшлифовано гладко как галька. А синтаксис останется тем же.

 

Или всё вышеперечисленное делается для того, чтобы создать инструмент, наиболее

полно соответствующий предметной области?

Зачем тогда разработчики игр включают в них языки сценариев, а не предоставляют

игровому дизайнеру "всю гибкость универсального языка"?

 

Потому, что та часть о которой говорите Вы, а это не более 10-20% объема проекта, - хорошо изолирована для того, чтобы в ней можно было использовать специализированнный язык.

Так не проще ли выделить части проекта, которые могут быть качественнее и быстрее реализованы на спец. языках?

 

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

 

Данный случай - исключение?

 

Исключение из чего? Бюрократы обожают процессы.

 

И поэтому они отменили одну методологию и начали создавать другую? Всё исчерпывается бюрократией?

 

А как Вы на их месте оправдаете свое существование, существование отдела, расширение персонала, площадей и т.д.?

 

На месте Конгресса? А им надо?

 

Конгресс не имеет к бюрократии никакого отношения. Бюрократия - часть исполнительной ветви власти. Конгресс - законодательная ветвь.

 

Почему? Нет. Кризис с тех пор только обострился. Но речь шла не о кризисе, а о методах его преодоления. То, что в 90-е считалость более высоким уровнем языка, таковым не являлось. И уж совсем не вело к повышению производительности прграммистов. Кризис 90-х был компенсирован ОО, компонентами и т.п., но никак не Прологом.

 

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

 

Еще как компенсировало. Достаточно сравнить средний объем ПО тогда и теперь, чтобы понять, что производительность труда программиста многократно возросла. Но кризис продолжается.

 

По моим представлениям, тема nGL давно закрыта.

 

Да ладно вам.

http://www.mercurylang.org/

 

А почему Вы решили, что это следующий уровень GL?

 

Это частично декларативный язык. Гибрид Пролога и функционального языка. Типичный представитель этих ваших 5GL.

 

Так Пролог уже им был.

 

http://www.visual-prolog.com/

 

И что?

 

И жив.

 

Фортран тоже жив.

 

Я неправильно написал предыдущее. Меня понесло не в ту степь.

Скорее, по-другому. С помощью своей концепции он пытался описать систему целостно.

Т.е., человеку предоставляется описание того, как система работает.

 

Так это - архитектура, а совсем не код.

 

Как ни назовите. Пусть, словесное описание архитектуры модуля. Сути это не меняет.

Описывается архитектура, иллюстрируемая частями кода системы.

В разумных масштабах, конечно.

Далее, из описания архитектуры создаётся код.

 

Это как? Давайте я Вам опишу архитектуру автомобиля. И?

 

А у вас есть инструмент, который из кусков автомобиля и описания к ним соберёт автомобиль?

 

Именно что нет.

 

Разные вещи.

 

Тождественные. Из архитектуры собрать ничего нельзя. Дома собирают из кирпичей, автомобили из деталей, а ПО из компонент.

 

Но, с другой стороны, такой подход ведь не исключает более высокоуровнего описания архитектуры (в том же UML, например)?

 

Я считаю UML языком более низкого уровня, по сравнению с любым ОО языком, если рассматривать его именно в качестве ЯЗЫКА ПРОГРАММИРОВАНИЯ. Отсутствуют типы. Очень слабая модульность. Нет никакого разделения на спецификацию и реализацию. Отсюда невозможность анализа. Да просто, сравнить две программы - совершенно нетривиальная проблема.

 

А какие альтернативы?

 

Если и есть, то не UML.

 

Может, не такая и плохая штука?

 

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

 

Хорошо. В таком случае, как это делается правильно, объясните?

 

Надо писать документацию.

 

Надо. Но как писать?

 

Тщательно!

 

Если вы отрицаете этот подход, каков ваш подход?

 

Я пытаюсь писать документацию руками параллельно с программой.

 

И хорошо получается поддерживать одно актуальным другому?

 

Вполне. Как только я изменяю интерфейс, я тут же меняю документацию. Это полезно, как я уже писал, для двойного контроля.

 

Тут, пожалуй, не измерение, а выбор из варианта "нет ничего" и "есть хоть что-то".

 

Как Вам такой: или нет денег, или есть гемморой?

 

Пожалуй, вы утрируете.

 

Разумеется, в этом суть доказательства от-противного.

 

Да, не всегда рациональные, но не более того.

 

Что никак не меняет исходную позицию, она же - финальная.

 

Это меняет отношение.

Вы говорили про "отрицательный отбор", что отдавало фатализмом и некой "тёмной волей".

 

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

 

Первые христиане стойко выносили пытки, по причине того, что они имели сильную волю?

 

Воля римлян была слабее.

И Муция Сцеволы?

 

Он жил века до христиан. Не надо путать Рим республики и Рим Константина или даже флавиев. Республика порвала бы и христиан, и халифат, и монголов, и османов как Тузик тряпку.

 

500 лет спустя пришли мусульмане и смели христиан,

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

Это не воля. Воля бывает у отдельных людей. У народов воли нет.

 

Никто про народы не говорил.

 

И никто не работает?

Маркетинг, PR в его контексте, рекламные методы, пропаганда, формирование мнения, - не действуют?

 

И что? Вы хотите методами маркетинга сделать что именно? Замените "язык программирования" на "космический корабль".

 

Методы маркетинга и есть причины "отрицательности" отбора. Причины, а не какая-то трансцендентная сущность.

 

Понятно. А причина, почему методы маркетинга таковы, вот она-то уже трансцендентнальна. Я правильно ухватил Вашу мысль? (:-))

 

В данном случае, есть некая фиксированная цена, не важно как образованная,

 

Не важно для качества продукта. Именно так.

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

 

Двумя строками выше Вы писали, что цена - фиксирована.

Или в том, что я могу читать из порта обычным read?

 

Для этого не нужно делать порт файлом.

Хорошо: писать в порт с помощью echo из командной оболочки.

 

Зачем?

 

Пример я приводил.

 

Нет не приводили. Пример - приложение, где это использовалось бы.

Я привёл случай, когда требовалось.

 

Случай - не приложение (программа применяемая для решения какой-либо проблемы).

 

В DOS надо писать в некое волшебное "псевдоустройство", что отвратительно, а как

в VMS-like?

 

Не помню, давно было. Под Windows есть COM API. Гораздо разумнее. Оно каменный век, другое - верхний мел.

 

Кхм. "COM API" - тоже самое файловое API, как и в Unix, плюс, полторы функции, которые вполне нормально реализуются через iocntl(), вроде?

 

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363194%28v=vs.85%29.aspx

 

Ну, про что я и говорю: не полторы, конечно, а три с половиной функции. А открытие-чтение-запись - файловое API, как и в Unix-like.

Вы же не TransmitCommChar() используете, для отправки данных в порт?

 

Речь шла о настройках порта. Мне в страшном сне не приснится делать это руками. Наше ПО использует COM-порты для тучи разных индустриальных протоколов, особенно AK любим всякими промышленными анализаторами газов. Чтобы использовать ioctl - никогда.

 

Пусть даже тут и есть некая инверсия, больше ли в ней минусов, чем плюсов?

 

Инверсия всегда - плохо.

Зачем надо много ядер?

Затем, что есть много задач и архитектур.

 

И?

 

И за этим.

 

Как из этого следует необходимость многих ядер.

 

Если заменить "необходимость" на "возможность использования", то следует.

 

Каким образом из "многих задач" следует "возможность"?

 

Многие задачи => разные требования => параметры инструмента.

 

Как из многих параметров следуют многие ядра?

 

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

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

 

Стану. Особенно если есть оная возможность. Чем больше параметров, тем выше вероятность того, что Вы никогда их не подберете. VxWorks - яркий пример грандиозного геморроя подбора параметров. И Linux им был, до того, как пришли модули ядра. Хотя, конечно такого ужОса как в VxWorks, там никогда не было. Обычно все ограничивалось влючением тех или иных драйверов и компонент 20 экранов 80 на 24, и - готово. А в VxWorks это - сотни экранов.

Есть, например, конкретная аппаратура (не спрашивайте какая, это лишь вытянутый

из пальца пример), драйвера для которой реализованы в ядре

FreeBSD (лучше, конечно, вспомнить NetBSD), но не реализованы в ядре Linux или наоборот.

 

Перепишите драйвер.

 

"Драйвер" - расплывчатое понятие.

DRBD, например, - тоже драйвер.

Перепишите, если потребуется?

 

У нас для этого свое ПО (middleware). Но дело не в этом, а в том, что этой штуке и драйвером-то быть не надо. Оно отлично может работать в

пользовательском пространстве и работает.

 

А менять ОС из-за того, что лень написать драйвер или сервис это - сильно.

3. Если вы имели ввиду Debian. Я не знаю. Никогда не работал с ядром FreeBSD в Debian. Но я подозреваю, что они просто используют FreeBSD Linux ABI - интерфейс, обеспечивающий бинарную совместимость, который реализован во FreeBSD.

 

В чем тогда разность если весь системный интерфейс один?

 

В "нижнем слое", очевидно.

 

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

Разницы не существует для интерфейса между приложением и ядром, хотя бы потому,

что, как правило, пытаются использовать библиотеку.

 

q.e.d.

 

2. ПО по некоторым причинам может зависеть от ядра. Грубый пример: системы шифрования. Своя во FreeBSD, своя в Linux. По тем или иным причинам, пользователям может быть удобно работать с какой-то конкретной системой (да хотя

бы прикладную программу для управления они лучше знают).

 

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

Я вообще имел ввиду GEOM ELI и LUKS. Не все же заказчики - государство.

 

BSI не заказчик. Он - бюро стандартов. Он предоставляет проект предписаний, и, в конечном итоге, Бундестаг его прописывает в закон. Но это - уже оффтопик оффтопика.

 

А, понял. Т.е., применение шифрования юридическими лицами или любыми коммерческими организациями требует лицензирования?

 

Нет, это лицензирование требует шифрования, определенной архитектуры и многих других вещей. Нет лицензии (сертификата), нельзя продавать и устанавливать.

 

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

обязаны использовать предписанный стандарт?

Это к тому, что вы о частностях.

 

Жизнь это - частность. Грандиозные обобщения же, как, например, "все взять и поделить", рождаются иключительно религиозным опытом.

 

При этом, есть люди, которые готовы портировать ядра в Debian и поддерживать их,

и есть люди, которым может быть интересно использовать альтернативные ядра (в связи с тем, что ядро Linux ещё^W не предоставляет данной конкретной функциональности).

 

В чём вопрос?

 

Вопроса нет, есть ответ - никому (в промышленности) это не нужно.

Да, в какой промышленности-то?

Какого государства?

 

Мы работаем на медицину, автопром, энергетику в Германии. Ни разу, ни один клиент не спросил про ядра.

 

Linux используют во всю.

 

В промышленности - маргинально. А вот многие ядра - совсем нет.

 

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

Промышленность - ещё тот показатель.

 

Так Вы про персональные компьютеры, мобильные телефоны и игровые консоли? И где там многие ядра?

DECnet был и существовал

примерно а тоже время, хотя это не аналог TCP/IP. Между прочим, именно DEC одним из первых стал поддерживать TCP/IP.

 

Но первый стек был реализован в BSD.

 

Не знаю. Могу говорить только то, что знаю сам. В конце 80-х примерно половина DEC-совместимых машин была в локальных сетях, причем высокой степени интеграции, с сетевой файловой системой и т.п. А вот Unix Sys V пробавялся протоколами типа uucico.

 

Моя первая работа с Unix-ом была портированием uucico (под модем) и MS-DOS-ного PGP на Бесту (Циммерманн написал первые версии PGP для PC, по-моему на Turbo-С c ассемблером, уже не помню). Про сокеты тогда только что слухи ходили. И только когда появился Linux для PC, все очень быстро изменилось, буквально за год. Но это только мой личный опыт...

 

Идеально для начинающих и университетов. Именно они стали

инкубатором этой заразы... (:-))

 

Знаете, столь вирулентная зараза стоит десятка самых лучших ОС. ;-)

 

Разумеется, а СПИД стоит и того больше...

 

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

 

А еще широко применяются гамбургеры и картошка-фри. Что не мешает им оставаться изумительной дрянью.

 

Мне было бы интересно узнать (если, конечно, у вас есть время и желание это писать):

1. Что конкретно вы считаете плохим в данном классе систем (чем подробнее, тем лучше)? И это относится ко всем сходным системам?

2. Что было действительно хорошего в VMS и в RSX-11?

 

1. Защищенность

 

В каком плане?

 

DEC даже деньги предлагала за взлом VMS. Хотя, в RSX-11 помнится была нычка для получения привилегированного терминала.

 

2. Надежность. ОС работала после отказа дисков. Я не мог даже загрузить ДЕМОС Unix на нашем железе (СМ), так как происходил по крайней мере один сбой. После чего носитель (ленту) нужно было заново переписывать (мастер блок был испорчен). Unix не имел самой мнимальной обработки сбоев оборудования.

 

Как защита от этого была реализована в RSX-11?

Многократное дублирование мастер-блока?

 

А зачем было его переписывать во время загрузки!? Это - чисто Unix-овский бред.

 

Но в принципе да, файловая система Files-11 была редундантна и имела несколько точек чтобы добраться файлов. Например, удаленный файл можно было восстановить. А Unix-е это была беда! Работать было - как минером. На первом Solaris-е я root-ом запустил что-то вроде "rm .*." Не помню уже. Хорошо - диски были медленные и шумные, а я молодой был, реакция хорошая...

3. Малые требования к ресурсам, в частности из-за асинхронного ввода-вывода и возможности прямого доступа к буферам ввода-вывода. Там где Unix создавал надцать процессов и качал данные через сто буферов, RSX-11 использовала один процесс и один буфер.

 

Хм... Не совсем понял про это. Где создание процессов?

 

Не надо ничего создавать. По окончанию ввода-вывода использовалось т.н. асинхронное программное прерывание, которое исполнялось на контексте задачи. Что-то вроде callback-а, только с сохранением регистров и т.п.

Запрос ввода-вывода передавал пользовательский буфер драйверу. Этот кусок памяти проверялся на доступность и блокировался от выгрузки в своп. Драйвер отображал этот кусок реальной памяти в свое адресное пространство и читал-писал прямо из него. Так что RSX-11 была на порядок быстрее и меньше Unix-а.

 

4. Развитые средства многозадачности

 

В каком плане?

 

Почтовые ящики, разделяемая память и т.п.

 

5. Поддержка различных видов доступа к файлу, напрмер записей и т.п., на уровне системы.

 

Эээ... Как в z/OS? Тяжко.

 

Как в IBM-овских OS. На самом деле очень удобно, не надо заботиться о разделителях строк. Прямой доступ работает без дурацкого lseek. Это могло бы быть началом типизованой ОС, но наступили "темные века" микрософта и "униха".

 

6. Легкость подключения нового оборудования.

 

Какого оборудования? Жёстких дисков и процессоров? Разве это не обеспечивалось,

прежде всего, аппаратной реализацией?

 

Любого. RSX-11 и RT-11 использовались для измерительной аппаратуры. Когда я работал в Лаборатории Аэрометодов, мы делали всякую разную аппаратуру, например, для сканирования изображений, и подключали ее к машине. Еще переделывали монитор(Message over 64 KB, truncated)

19.05.2013 1:52, Sergey Kirkorov пишет:

 

Здравствуйте!

 

Тот же VHDL в своей области, наверное будет выгоднее использовать, чем пытаться

приспособить универсальный язык, типа Ada?

Нет?

 

Да, но см. пункт 1.

 

Есть сторонники этой идеи - генерация HDL из Ada. Переодически я к

ней сам возращаюсь

(http://www.mediascan.by/index.files/lite-edit-papert.pdf ,

http://www.mediascan.by/index.files/issn_1814-4225_2012-6.pdf ,

http://www.mediascan.by/index.files/kh2009/doclad2009sim.pdf), но

есть теоритические проблемы в частности автоматизация

распаралеливания последовательных алгоритмов. VHDL - Язык описания

параллельных процессов и как исключение последовательных, в то время

как Ada наоборот. На ВИТ-Ada 2013 которая пройдет в июне

предполагается обсудить эту тему, в том числе и с заинтересованными

представителями организаций. К сожалению об этом (ВИТ-Ada 2013) до

сих пор нет информации на www.Ada-ru.org

 

У Altera есть транслятор OpenCL в железо. Esterel можно транслировать и для CPU, и в железо. На первый взгляд, OpenCL круче всех: у GPGPU и FPGA больше общего, чем у CPU и FPGA.

 

-- If you want to get to the top, you have to start at the bottom

Новое сообщение:
< Страницы: 1 2 3 4 5

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти