Мой LINZIK еще не ZEMAX, но ...

[datumn]

Валера, не засоряй тему.

[paparazzo]

Данный продукт в данном виде может существовать пока только как бесплатный - иначе конкуренты съедят (тот же Zemax). Тем более автору много чего нужно дорабатывать (расчет допусков, pickup, расширение оптимизатора, возможность непоследовательной трассировки, покрытия и т.д.), и считать реальные системы на нем пока рановато.
Вспомните тот же FRED - выхолощенный ASAP (история - часть команды разработчиков ASAP покинула фирму и создала свой продукт), который несмотря на то, что продается за деньги, имеет кучу недостатков.
Но с другой стороны Zemax начинался также.
Надеюсь в будущем, возможно, и удастся добится успеха, если автор не забросит это дело...
Уже и критики появились (VD) - это радует...

P.S. Вспоминается история математического продукт Maple. В свое время когда было много софта (Maple, Matematica, Derive, Maxima и т.п.) и Мatematica стала претендовать на монополию, компания WaterlooMaple сделала MapleVR4 бесплатным, своеобразный маркетинговый шаг. Из-за этого число пользователей выросло, и теперь Maple 11 и Matematica 6 практически равны и соблюдается некий баланс.   Остальные же пакеты благополучно отошли в мир иной....
Хотя MapleV R4 достаточно мощный и даже сейчас с успехом используется математиками.

[serega2007]

Мне кажется ты попутал. Никого это, кроме тебя самого, никак не заботит

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

[datumn]

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

Ну, справедливости ради, скажу, что pickup есть в Линзике с самого начала. А так, конечно, работы впереди очень много. Но и ведь и версия еще 0.x 


Новая версия: http://www.linzik.com/download/linzik_0_21_Rus_Setup.exe

Исправлены ошибки, спасибо Сергею. Подробности: https://astronomy.ru/forum/index.php/topic,37720.0.html

[VD]

Мне кажется ты попутал. Никого это, кроме тебя самого, никак не заботит

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

Дык вроде бы Зимакс демо все делает, но не сохраняет результаты. Сохранять с графиками можно принт-скрином. 

[drv]

Дык вроде бы Зимакс демо все делает, но не сохраняет результаты. Сохранять с графиками можно принт-скрином. 

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

[VD]

Проявлю ка я интерес по настоянию автора. Вопрос: это более или менее мощный оптический калькулятор, чем ATMOS ?

[datumn]

Проявлю ка я интерес по настоянию автора. Вопрос: это более или менее мощный оптический калькулятор, чем ATMOS ?

Спасибо, Валера, за твой интерес, который ты скрыть таки не можешь Еще мне понравился термин "оптический калькулятор". Тут тебе плюс за введение нового термина. Только вот LINZIK я бы назвал "программируемым оптическим калькулятором ..." с "... дополнительными, по-сути прорывными, возможностями"    По существу вопроса:

1) Если ты когда-нибудь самостоятельно запускал ATMOS, то ты видел, что там
  1.0) нет возможности считать самому. Нет того самого калькулятора, это раз. Нет языка, на котором можно написать форму и спросить у нее результат выполнения. Все зависит от конкретной версии. Есть в версии фича, значит будет предложен соотв. окошко; а нет - и не будет никогда.
  1.1) оптимизатор выглядит как диалог, который каждый раз требует полного переоформления цели и переменных для оптимизации. Ограничения заданы достаточно косвенно. Цель в оптимизаторе единственная - минимум пятна. Оптимизатор циклится в локальных минимумах.
  1.2) метод оптимизации один, и без управления кол-вом итераций и точностью.

2) Если ты когда-нибудь самостоятельно запускал LINZIK, то ты видел, что там
  2.0) всегда под рукой язык Линзик: от запроса как пройдет тот или иной луч, прямо в калькуляторе, до написания на нем формы, как геометрической, так и волновой.
  2.1) оптимизатор выглядит как диалог, который зависит не только от наполнения своего окошка, а от назначенных сразу на таблицу переменных, pickup'ов, это все сохраняется вместе со схемой. Целевая функция, как и функция ограничений могут быть сколь угодно сложными, все на языке Линзик.
  2.2) методов оптимизации уже три: simplex, Broyden и отжиг. При этом simplex выполняет роль "вышибателя" ((c)Белкин) из локальных минимумов; при этом он еще и красиво вообще со своей работой справляется. А отжиг (Annealing) верно и не очень медленно делает глобальный поиск.
  2.3) возможностей языка достаточно для того, чтобы пользователь написал собственный оптимизатор в виде формы. При этом можно как окружить сценарием вызовы трех встроенных методов, так и вообще оптимизировать по-своему, самостоятельно вызывая функции трассирования лучей и оценивая их ответы.

То есть, в плане собственно чистого смысла слова calculation, то тут все значительно мощнее.

Линзик просто еще молод, и не оброс многими необходимыми формами. Но в генетическом плане, так сказать, ATMOS ему не конкурент; просто приятный предок так сказать, достаточно сравнить возраст и номер версий

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

P.S. A eсли ты когда-нибудь самостоятельно запускал ZEMAX, то ты сейчас мог бы видеть, что LINZIK значительно ближе к ZEMAX, чем к ATMOS - по "мощности". И даже не совсем понятно с какой стороны - снизу или сверху Плюс интерфейс пользователя у Линзика хорошо заточен на продуктивную работу, а не блукания по множеству меню - уже сейчас, сразу после рождения, а не через 18 лет развития 

[VD]

Аркадий,

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

По моему вопросу ты должен был понять, что ни атмос, ни линзик я не запускал. Я потому и спросил как эти два калькулятора соотносятся. Ты ведь обоими ими пользовался.

И все же общее такое замечание.  Ты определись на кого ориентирован продкут на инженеров или на программеров.  Это две совершенно разные ниши.  Пока такое впечатление, что на программеров-ЛА. 

[Дрюша]

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

В своё время я работал (на стезе программирования) с Авто КЭДом, потом (и сейчас иногда) приходится работать с оффисом (вордом, эксцелем и т.п.) именно в плане программирования под конкретного заказчика. Заказчик хочет понятно чего. Чтобы, скажем, какие-то детали или конструктивно-технологические элементы в его понятиях (ну, там, всякие отверстия, выемки, шлицы, фаски...) выбирались из базы данных и вставлялись в чертёж, и тут же шло образмеривание (по нашим правилам ЕСКД, а не "ихним"-откуда родом тот же АвтоКЭД) и т.п. И автоматически составлялись технические требования по типовым техническим требованиям, чтобы только вписывались куда надо конкретные циферки, взятые из базы данных, а так - всё типовое, чтобы не набирать руками каждый раз с нуля. Это в АвтоКэде всё было. А в ворде-эксцеле - там тоже уйма всяких-разных форм - заявок, платёжных поручений, выписок, отчётов... Всё это реализуется через шаблоны, макросы и т.п., но это как раз дело программиста - через что это всё делать. А для инженера или бухгалтера (аудитора или кого ещё) хочется иметь дело с программой, которая работает в его понятиях, и попутно вызывает АвтоКЭД, Ворд или Эксцель, управляет им через программный OLE-интерфейс и делает там всё что надо и позволяет дальше работать стандартными средствами. Выводить на печать, передавать кому-то этот документ в элекронном виде (тем у кого есть стандартное ПО, тот же АвтоКЭД или Оффис, но нет этого специализированного ПО с базами данных, надстройками и т.п., но им уже и не надо).

Так вот, насколько я ковырялся с Земаксом или Ослом (с Атмосом не ковырялся), то там лично мне остро не хватало средств автоматизации. Можт быть, правда, они там есть, но я до них не докопался (русский док, прилагаемой к пиратке, сильно кастрирован, а по-аглицки глубоко вникать - как-то западло).

Я не знаю как формат данных, используемый Земаксом, Ослом, Атмостм, Линзиком или код-файвом, приспособлен к тому чтобы можно было легко и без напряга работать с отдельными линзами или их блоками. Например, вставлять их из другого дизайна, в том числе из базы данных (если надо, то можно без проблем скинуть во временный файл и импортировать из этого файла или наоборот, экспортировать в файл и записывать его в БД). По-хорошему хотелось бы иметь
а) группировку чего-то там (предменых сущностей: поверхностей или деталей: линз, призм, зеркал...) в логически целостные блоки. Чтобы такие блоки можно было импортировать и экспортировать, активировать и деактивировать, что-то с ними делать ещё (например, важная операция - обращение: например, окуляр разрабатывается, тестируется и оптимизируется сам по себе в обратном ходе лучей, а в систему входит с прямым, то при вставке его целостную систему следовало бы обратить). Блоком может быть линза (две поверхности), склейка, объектив, окуляр, оборачивающая система...
б) блок может быть активизирован или деактивизирован. То есть, временно как бы убран из системы "на задний план", но с возможностью быстрого восстановления, чтобы не перенабирать его заново.
в) Условия оптимизации (варьируемые параметры, целевая функция, метод оптимизации и т.п.) тоже должны быть оформлены как единый логический объект, коих в системе (дизайне) может быть представлено много. Положим, только один из них может быть в данный момент "активным" ("текущим"), а все другие - временно неактивны (отключены), но помнятся и чтобы на них можно было бысто переключиться (а не затирать старый и не набирать снова). Причём, свой объект "условия оптимизации" (один или несколько) мог бы быть связан с блоком (см. выше) и относиться именно к нему (и экспортируется/импортируется вместе с ним). Или должна поддерживаться иерархия "условий оптимизации". Например, система состоит из объектива (скажем, ахроматической или апохроматической склейки), оборачивающей системы (блока призм, в т.ч. м/б с "крышей") и окуляра (Плёссл, Эрфле, ортоскоп, ГОИ и т.п.). Каждый из них - оформлен как блок. Например, мы имеем право "жонглировать" разными окулярами: у нас их заведено несколько, но в каждый момент активизирован только один окуляр, а остальные - "на заднем плане" не активны. У объектива и окуляра есть свои "условия оптимизации" (и даже по нескольку штук как целостных логических объектов - вариантов оных). Общий (действующий) объект "условия оптимизации" для всей системы может строиться иерархически. Или частично-иерархически. Например, целевая функция и метод оптимизации для него определяется своя (именно для него), а какие параметры варьируются - может браться из соответствующих объектов для блоков (например, разрешается варьировать только воздушные промежутки), а так же быть ещё и свои (например, воздушные зазоры или взаимные растояния между блоками), которые не могут быть присущи никакому блоку, а относятся к системе в сборе. Потом я могу, например, зафиксировать параметры объектива или окуляра... Но не совсем, а как бы временно исключить из числа варьируемых... Разумеется, если некий блок деактивизируется (временно исключается, уходит на задний план), то и та часть условий оптимизации, которые присущи ему (более конкретно, набор варьируемых параметров) - автоматически деактивизируется. Но не забывается совсем и навсегда.

Ещё неплохо бы описание языка Линзик начиная с основных понятий.

[datumn]

Аркадий,

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

Валера. Как говорят, "чья бы мычала". В общем, Валера, я высоко оценил и то, что ты уже не называешь меня Берлагой. Даже спонтанное "вы" проскочило чуть выше. Хорошо, значит начинаем как сейчас стало принято - с "чистого листа"
 

По моему вопросу ты должен был понять, что ни атмос, ни линзик я не запускал. Я потому и спросил как эти два калькулятора соотносятся. Ты ведь обоими ими пользовался.

Выяснились факты. Зачем же ты говорил:

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

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

И все же общее такое замечание.  Ты определись на кого ориентирован продкут на инженеров или на программеров.  Это две совершенно разные ниши.  Пока такое впечатление, что на программеров-ЛА. 

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

[datumn]

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

Спасибо за поддержку точки зрения!

Я не знаю как формат данных, используемый Земаксом, Ослом, Атмостм, Линзиком или код-файвом, приспособлен к тому чтобы можно было легко и без напряга работать с отдельными линзами или их блоками. Например, вставлять их из другого дизайна, в том числе из базы данных (если надо, то можно без проблем скинуть во временный файл и импортировать из этого файла или наоборот, экспортировать в файл и записывать его в БД).

Линзик не имеет формата данных как такового. Если посмотреть в файл *.lnz, то там будет видно примерно следующее:


VER 0.22
NEWSYSTEM
DESCRIPT 
ANGLE 0.25
RAYS 4
REFERENCE 0
AIRY 1
SCALE 20
LASCALE 0.500
WAVE 1,0
WAVE 2,0
WAVE 3,0
WAVE 4,1
WAVE 5,0
WAVE 6,0
INSERT
INSERT
DIAM2 1, 100
CURVR 1, 0
THICK 1, 0
GLASS 1, 1
CONIC 1, 0
DIAM2 2, 100
CURVR 2, 0
THICK 2, 1200
GLASS 2, 1
CONIC 2, 0
DIAM2 3, 100
CURVR 3, -2000
THICK 3, -999.999999906868
GLASS 3, MIRROR
CONIC 3, -1.02882490205
VARIABLE 3, 5
DIAM2 4, 100
CURVR 4, 0
THICK 4, 0
GLASS 4, 1
CONIC 4, 0
LAYOUT 1, 4
BYLENGTH
COND 1
GOAL [maxr 0,0] +10*[maxr [angle],4]
CALC 
RECALC
ERROR


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

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

Целевая и ограничительная функции задаются либо ручным вводом в поля "Goal" и "Cond" соотв., либо выполнением форм, размещенных в файлах *.lnz или *.an. В тексте функций можно ссылаться на собственные функции, определенные в файле library.lib (тоже просто текстовый файл). Собственные функции могут иметь сколь угодно сложные тела, составленные из любых операторов Линзика.

Другими словами, смена "единого логического объeкта" может быть выполнена путем запуска формы.

Ещё неплохо бы описание языка Линзик начиная с основных понятий.

Как сказано в Help'e (доступен без установки здесь: http://www.linzik.com/manual_rus/manual.htm ) - Линзик есть бэйсикоподобный язык. Чтобы передать его несложный дух, покажу как устроена форма OPD.an из дистрибутива; здесь фрагмент:


form [lx]+5, [ly]+100, 750, 500

wa=1
d2=[diam2 2]
a=[angle]

-               OPTICAL PATH DIFFERENCE, Waves

for w=1 to 6

  c=[wave w]
  if c
    eval [opd 0, w, x, 0]
    color c
    plot 1, 20,     30,     200,150, -d2,d2, -wa, wa
    color 0
    move 20, 30
- 0 Deg
    move 20+100+5, 30
-1W
    move 20+205, 25+73
-Y
  endif
......


Ну, в общем можно разобраться

P.S. Для "инженеров", не желающих (поначалу!) программировать, Линзик в ближайшем будущем предоставит большой список готовых *.an (вариации спот-диаграмм, PSF, MTF, ...). И всегда можно будет вмешаться в эти самые *.an, проверить как они сделаны и переделать по-своему.

[Дрюша]

Ну, пожелания насчёт программируемости - это одно, а насчёт блочности и модульости (иерархичности и т.п.) - это несколько другое. дно другому не противоречит, а дополняет. И вообще, это, сорее, были бы мои пожелания к разработчикам Земакса... Чего, на мой взгляд, там резко не хватает.

Всякие ворды и эксцели - они тоже могут программироваться весьма бэйсико-подобным языком, собствено, он бэйсик и есть (VBA). Но касаемо модульности... На тм же Бэйсике составляются модули, в модулях реализуются макросы... Макрос можно использовать дважды, трижды... Можно из одного вызывать другой... Ну, короче, как юзать его подпрограмму (типа процедуры). Ну, вот, если, скажем, сделать так (в будущих версиях, хотя бы), чтобы файл *.lnz (о, чёрт, у меня тоже это расширение .lnz называется, и оно даже заегестрировано в винде на мой пускач OPENLNZ.EXE, который запускает AutoCAD с загрузкой OPTIC.LSP и этой модели.lnz которая по сути сама тоже есть аналог *.LSP, то есть являет собой текстовый файл, написанный на языке АвтоЛИСП), ну, коточе, тот LNZ, который для Линзика, он бы содержал не просто последовательность операторов языка Линзик, а определения некоторых объектов (аналогов процедур или функций), которые только загружаются в память, но не выполняются сразу. А потом там может идти собственно "тело", которое, например, являет собой последовательность операторов вызова чего-то в определённом порядке. И даже не обязательно вызывать абсолютно все объекты (процедуры?), которые там определены. Таким образом можно сделать "скрытые объекты". Ведь если в library.lib что-то определяется и не обязательно сразу задействуется, то почему бы эту возможность не распространить на *.lnz?

[VD]

Аркадий,

Выбор ориентации продукта придется все же сделать как можно скорее. 

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

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

[paparazzo]

Если кому-то, как, например, Дрюше, хочется возиться с прогами, их отладкой, короче, играться в свое удовольствие, то нынешняя возможность - Линзик - как раз для них.
У Зимакса есть свой язык тоже. Но им редко пользуются, т.к.  почти все необходимое уже сделано.  Есть и другие специализированные программы, много более мощные в своих направлениях.  Так что профи их имеют у себя и направляют свои усилия на исследования или проектирование систем, а не на улучшение самих программ. Не все же Дрюши и Аркадии.

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

Из личного опыта - большинству инженеров (и особенно женского пола) - программирование, как кость в горле... Они могут знать теорию расчета, иметь понятие о технологиях, знать стандарты, но НЕ ЗНАТЬ численных методов и, и всех остальных нюансов реализуемости теории в софте, т.к. они инженера.
Zemax позволяет использовать Dll - пользовательские объекты, покрытия, источники. Но для написания Dll (либо макроса) нужны специальные знания. Например, для меня не составляет труда написать dll, т.к. я по образованию больше физик-математик и программист, чем оптик. Но простой инженер этого делать не будет. Хотя те же Dll (макрос) напишет тебе служба поддержки Zemax за небольшую плату в случае необходимости и необходимость такая возникает крайне редко.
И софт, основанный ТОЛЬКО на программировании и имеющий СВОЙ язык, будет только отпугивать потенциальных пользователей и широкой популярности не приобретет, уж поверьте, Аркадий.

[Stepa]

Может тут дело в очень специфической области, но опыт САПР микроэлектроники говорит об обратном.
Просто есть специальные люди, которые осваивают этот язык, и пишут на нем специфические программы для своих инженеров. И наличие языка играет за программу, поскольку она гибче, чем все эти dll. Dll - надо знать API, надо знать Win32 тонкости... А тут - чистенький интерпретируемый язык. К нему, Аркадий, например, добавит возможность UI (Дрюша, по-моему, об этом говорил тоже) и все.

И там какой-нибудь "расчет окуляров Эрфле" под специфику местного производства делается забитием трех цифр в соответствующую форму. Хочешь - руками "добей".

P.S. Наличие AutoLisp в AutoCAD настолько расширяет его возможности, что AutoCAD без AutoLisp как-то уже совсем не AutoCAD. :-) Auto - нет :-))

P.P.S. Микросхемные САПР - так там вообще без этого automation никак. Не каждому же клиенту Dll'ы писать. ;-)

[Дрюша]

А кто сказал, что ТОЛЬКО на программировании? Там же всё-таки есть возможность просто начать заполнять форму конкретными данными и делать конкретные интерактивные действия... А как это всё реализовано внутри... А кому какая разница?

Вот что чисто СВОЙ язык (будь взят хотя бы Бэйсик или какой-нибудь язык, близкий к общераспространённым - было бы не так страшно) - это действительно отпугивает. Чисто психологически. Хотя я по себе знаю, что только процентов 5 "знания языка" заключено в знании базовых правил синтаксиса и операторов самого языка, встроенных типов и операторов, а остальные 95% приходятся на "стандартные" библиотеки, в том числе библиотеки классов, компонентов и т.п. То есть того, чтопо идее можно было бы наработать и воспроизвести самому базовыми средствами "с нуля" (только на фиг надо), но что уже есть, и чем можно пользоваться. А чего-то сам не воспроизведёшь. Например, Win32 API - не будешь же писать свой Windows... С другой стороны, API - он и в Африке API, хоть на С++, хоть на Паскале (Дельфи)...

А касаемо того, какой продукт быть "должен", а какой "не должен"... Он - что, взаймы у кого-то брал, что оказался "должен"? На самом деле если есть свободная ниша, которая кому-нибудь зачем-нибудь может быть нужна, то эту нишу надо побыстрее занять. И ценность продукта будет именно в том, ЧЕГО НЕТ во всех этих Земаксах и Атмосах. Потому что пытаться потеснить Земакс на том же самом поле, которое занимает тот, не добавляя к нему ничего - это гиблое дело. Ниша уже занята. Это чисто моё мнение.

[paparazzo]

Может тут дело в очень специфической области, но опыт САПР микроэлектроники говорит об обратном.

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

[datumn]

Может тут дело в очень специфической области, но опыт САПР микроэлектроники говорит об обратном.

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

А разве построение в Zemax подходящей для проекта merit-функции - не программирование? Чем в принципе отличается заполнение таблицы от написания формулы? Ничем. Тем более, что в колонках merit следует вносить имена функций и знать их назначение. Конечно, можно сказать, что там есть кнопка "функции по умолчанию". Но это только заготовка, в реальном проекте ее все равно надо дополнять и/или переделывать.

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

[datumn]

Ну, вот, если, скажем, сделать так (в будущих версиях, хотя бы), чтобы файл *.lnz ... ну, короче, тот LNZ, который для Линзика, он бы содержал не просто последовательность операторов языка Линзик, а определения некоторых объектов (аналогов процедур или функций), которые только загружаются в память, но не выполняются сразу. А потом там может идти собственно "тело", которое, например, являет собой последовательность операторов вызова чего-то в определённом порядке. И даже не обязательно вызывать абсолютно все объекты (процедуры?), которые там определены. Таким образом можно сделать "скрытые объекты". Ведь если в library.lib что-то определяется и не обязательно сразу задействуется, то почему бы эту возможность не распространить на *.lnz?

Да так и есть с самого начала. Все в лучших традициях Бэйсика образца 1965-го

Тело файла *.lnz или *.an есть список строк, что исполняются последовательно. Последовательность может прерываться управляющими операторами IF, GOTO, FOR, WHILE, CALL, RETURN. Ну и вызовы функций тоже здесь прерывают выполнение по-своему - как CALL, но и результат приходит, если он задан в RETURN как выражение в скобках.

"Объектно-ориентированное" программирование здесь отсутствует: как вроде его еще не было и не будет никогда. Только "модульное" - в пределах файла и library, и "структурное" - как возможность избежать GOTO. Против GOTO я тоже ничего не имею  Ну, функция или подпрограмма может иметь локальные переменные, определенные оператором LOCAL. Рекурсия разрешена.

При таком подходе удобно все процедуры и функции (подпрограммы) концентрировать в конце файла (или, наиболее употребительные - в library). Перед "разделом" подпрограмм тогда должен идти STOP. Как Вы понимаете, их можно и сначала поместить - только обскочить вступительным GOTO.

* * *

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