Здравствуйте, Klatu, Вы писали:

K>Не совсем понимаю. Зачем нужно именно динамически?

Динамическое расширение по любому покрывает статическое. Раз можно сделать динамическое, то зачем нужно делать еще что-то?

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

Здравствуйте, Dym On, Вы писали:

DO>Данный тред напомнил мне одну историю. Пригласил меня мой бывший научрук прочитать лекцию о современных ЯП для преподавательского состава, а то "застряли они в своих 70-х". Я подготовил доклад страниц на 70, чтобы показать преемственность языков от алгола до C# и немерле, хотел показать как появлялись те или иные фичи, как переходили из поколения в поколение. Даже планкалькюль упомянул.

DO>И вот заканчиваю лекцию, расписывая клевые фичи немерле, и тут один убеленый сединами профессор вдруг спрашивает:
DO>- А вот микроконтроллер, например, ремиконт-201 можно на этом самом немерле запрограммировать?
DO>- Сейчас нет, но если ...
DO>- Ну зачем он нужен? Фигня, а не язык.
DO>- Да дело не в языке, если скомпилировать исходный код в байткод контроллера...
DO>- Все понятно (встал и ушел).

Скажи пожалуйста, чего ты ожиждал от него тогда ? Мне кажется это очевидно, что он не бросит свои микроконтроллеры ради твоего языка.

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

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

На примере:

Т.е. если ты подходишь и говоришь "ты застрял в 70х" это попытка изменить прошлое человека.

Если "сейчас есть вот такие языки/технологии" — это снова попытка изменить прошлое человека, только косвенная.

Пиши на своем "блабе" — аргумент в духе Влад2, агрессия направленая в прошлое человека.

"Обезьянкам"(индусам, быдлокодерам) нет места в программировании — аргумент в духе Wolfhound и снова агрессия направленая в прошлое человека

Я не программист и то смог выучить немерл — это вобщем то снова попытка повлиять на прошлое, но уже в духе Кочеткова.

В немерле нет ничего сложного — и это тоже попытка повлиять на прошлое.

А вот если "для ремиконт-201 немерл даёт возможности А, Б, В, Г и даже Д" — вот это уже нормальный, конструктивный подход.

Или так — "для того, что бы на реальном проекте удешевить(сократить сроки, избежать проблем А, Б, В, Г и даже Д) необходимо..."

Здравствуйте, hardcase, Вы писали:

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

H>VHDL, Verilog, Abel?

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

Здравствуйте, night beast, Вы писали:

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

Текст — это придаток речи, письменность т.е. Да, текстом можно многое передать, особенно если договориться о терминах. Если же рассуждать об удобстве, то текстовое представление иерархии классов, если их больше 3-5-ти, например, это неудобно. Схемы электрической принципиальной — тоже неудобно. И еще миллион примеров можно привести, где это неудобно. Человек банально больше в графике способен воспринимать, особенно когда вещь заходит о всяких структурных вещах, типа карт, схем, моделей и т.д. до бесконечности. А в тексте потом список св-в элементов удобно посмотреть, т.е. текст хорош как аннотация. Собственно, если инженерную графику не прогуливали, то все это вы проходили.

Здравствуйте, dimgel, Вы писали:

D>В этой ветке речь вроде шла про программирование, а не про рисование формочек, не?

Ну хорошо, как насчет рисования графов workflow?
По-твоему, рисование формочек — это не программирование? ИМХО, качественное ГУИ такая же редкость, как и остальной качественный код. Не понимаю твоего пренебрежения по этому вопросу.

D>Или по-твоему, это одно и то же?

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

D>Тебя уже тыкали носом, что в том же Офисе суммарное количество кода на порядки больше, чем кода формочек.

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

Понятное дело, что графические тулзовины должны бытьна чем-то написано, и универсальность текста не оспаривается. Но лично я, например, неоднократно разрабатывал дизайнеры для компонентной модели .Net, и они существенно ускоряли разработку и, самое главное — уменьшали кол-во мест, где можно допустить ошибку/описку. Особенно когда идет биндинг нескольких десятков полей, угу. Понятное дело, что код самих дизайнеров — это "плоский текст" программы, и сами дизайнеры генерят "плоский текст", но работа с ними идет в ГУИ.

Отсюда вывод: текст хорош своей универсальностью. И эта универсальность должны быть заточена, в первую очередь, на возможность создания других DSL, как текстовых, так и графических.

V>>Ты еще вот тут не ответил: http://rsdn.ru/forum/philosophy/4244388.1.aspx

Автор: vdimas
Дата: 21.04.11

D>Так кто из нас двоих, говоришь, ламер? А там отвечать не на что.

Ес-но, тебе там нечего ответить. Все и так прозрачно.

Здравствуйте, hardcase, Вы писали:

V>>Сделано неоднократно и примеры были приведены, например редактор форм для либы System.Windows.Forms. Попытайся доказать, что строить формочки в тексте будет удобнее, а я посмотрю.

H>Конкретно для WinForms это действительно может быть удобно

Автор: catbert
Дата: 13.12.10

Мне тут привести на несколько сот строк код инициализации формы тебе для разминки? Или сам у себя таких найдешь?

Небольшие формы из пары элементов я тоже в тексте делаю "по-месту", и без фичи with. Одно это выражение или несколько — не принципиально для таких масштабов.

Здравствуйте, hardcase, Вы писали:

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

H>VHDL, Verilog, Abel?

Кстати, подумалось вдруг. Наверно, как обычно, дело в том самом бабле. Еще в начале 90-х меня удивляла такая разница в кач-ве тулзов для программистов и для электронщиков. Все эти IDE и т.н. "пакеты инструментов" для программистов смотрелись как бедные родственники. Да еще с кучей багов. Я только в среде Turbo C в свое время нашел 4 бага компиляции, а их там гораздо больше, как выяснилось позже, в приходом интернета. И вот берем какие-нить для сравнения PCAD или ORCAD тех же лет. Вылизанные, очень шустро работающие с графикой на процах того времени... Какая там нафик BGI от Borland!

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

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, hardcase, Вы писали:

V>>>Сделано неоднократно и примеры были приведены, например редактор форм для либы System.Windows.Forms. Попытайся доказать, что строить формочки в тексте будет удобнее, а я посмотрю.

H>>Конкретно для WinForms это действительно может быть удобно

Автор: catbert
Дата: 13.12.10

V>Мне тут привести на несколько сот строк код инициализации формы тебе для разминки? Или сам у себя таких найдешь?

У меня такого кода нет. Либо XAML для серверлата, либо Razor под ASP.NET. Но вот в исходниках SharpDevelop, коие я излазил порядочно, что-то не замечал сильно сложной и продолжительной логики создания форм.

V>Небольшие формы из пары элементов я тоже в тексте делаю "по-месту", и без фичи with. Одно это выражение или несколько — не принципиально для таких масштабов.

А конкретно приведенный код это не финальная версия "with-а". Там сейчас локальные имена есть.

Здравствуйте, hardcase, Вы писали:


H>Либо XAML для серверлата, либо Razor под ASP.NET.

Тю, блин, так ты не застал "золотую пору" Windows.Forms? Да и пишешь под веб, насколько я понял.

H>А конкретно приведенный код это не финальная версия "with-а". Там сейчас локальные имена есть.

А чем принципиальное отличие от локальных переменных?

Здравствуйте, VladD2, Вы писали:

VD>Динамическое расширение по любому покрывает статическое. Раз можно сделать динамическое, то зачем нужно делать еще что-то?

А зачем делать статическую типизацию, если есть динамическая?

VD>А лично нам оно нужно для разработки следующей версии Nemerle. Там без динамической расширяемости ничего не поделать.

А зачем? Как оно должно работать?
Просто интересно.

Здравствуйте, VladD2, Вы писали:

VD>Что то я тебя не пойму. Если ее нет, то зачем ее нарушать?

В целом гигиена соблюдается, но все "портит" антикуотинг, там выше по ссылке есть такой пример:

open Camlp4.PreCast
open Syntax

EXTEND Gram
 expr: AFTER "apply"
   [[ f = expr; "o"; g = expr -> <:expr< fun x -> $f$ ($g$ x) >> ]];
END;;

Это простейший инфиксный оператор, комбинирующий функции.
Вот такой код с использованием этого оператора:

let a y = y + 1;;
let x y = y + 2;;

Printf.printf "%d\n" (a o x);;

дает такой выхлоп:

let a y = y + 1
  
let x y = y + 2
  
let _ = Printf.printf "%d\n" (fun x -> a (x x))

то есть неквотированная переменная x не была переименована. Если бы гигиена соблюдалась, то выхлоп был
бы примерно таким:

let a y = y + 1
  
let x y = y + 2
  
let _ = Printf.printf "%d\n" (fun _x123 -> a (x _x123))

Ну и так как на негигиеничность уже завязана куча кода никто это уже править не будет.

Здравствуйте, vdimas, Вы писали:

V>В принципе, ничего удивительного, коль одна лицензия PCAD обходилась десятки тысяч долларов. А в рабочее место программиста никто такие деньги инвестировать не будет, отсюда традиционная скудость инструментов для программистов.
IDEA стоит примерно $1000 на рабочее место. С остальными инстументами без всяких проблем может и ещё парочка тысяч добавиться.

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

Здравствуйте, vdimas, Вы писали:

V>Текст — это придаток речи, письменность т.е. Да, текстом можно многое передать, особенно если договориться о терминах. Если же рассуждать об удобстве, то текстовое представление иерархии классов, если их больше 3-5-ти, например, это неудобно. Схемы электрической принципиальной — тоже неудобно.
Это пока не научились их ещё в текст переводить в удобной форме.

Здравствуйте, Cyberax, Вы писали:

V>>Текст — это придаток речи, письменность т.е. Да, текстом можно многое передать, особенно если договориться о терминах. Если же рассуждать об удобстве, то текстовое представление иерархии классов, если их больше 3-5-ти, например, это неудобно. Схемы электрической принципиальной — тоже неудобно.
C>Это пока не научились их ещё в текст переводить в удобной форме.

ноты научились переводить в текст.. но всё равно неудобно..

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, vdimas, Вы писали:

V>>Текст — это придаток речи, письменность т.е. Да, текстом можно многое передать, особенно если договориться о терминах. Если же рассуждать об удобстве, то текстовое представление иерархии классов, если их больше 3-5-ти, например, это неудобно. Схемы электрической принципиальной — тоже неудобно.
C>Это пока не научились их ещё в текст переводить в удобной форме.

Может, всё наоборот? Текст удобен там, где не научились переводить в более удобное представление?

Здравствуйте, VladD2, Вы писали:

VD>В прочем, главное чтобы язык не был единственным. Это пол любому приводит к однобокости.

Однобокость может выражаться ещё и в святой уверенности в том, что всё решает один лишь язык. То есть "парадокс блаба" можно расширить.

Здравствуйте, VoidEx, Вы писали:

V>>>Текст — это придаток речи, письменность т.е. Да, текстом можно многое передать, особенно если договориться о терминах. Если же рассуждать об удобстве, то текстовое представление иерархии классов, если их больше 3-5-ти, например, это неудобно. Схемы электрической принципиальной — тоже неудобно.
C>>Это пока не научились их ещё в текст переводить в удобной форме.
VE>Может, всё наоборот? Текст удобен там, где не научились переводить в более удобное представление?
Это очень вряд ли. Так как процесс всё как-то более обратный идёт.

Здравствуйте, neFormal, Вы писали:

F>Презентации "Введение в Ceylon" и "Система типов Ceylon": http://blog.talawah.net/2011/04/gavin-king-unviels-red-hats-top-secret.html

Не вижу там рекламы производителей попкорна. Что за безобразие?

Здравствуйте, Klatu, Вы писали:

K>Здравствуйте, VladD2, Вы писали:

VD>>Динамическое расширение по любому покрывает статическое. Раз можно сделать динамическое, то зачем нужно делать еще что-то?

K>А зачем делать статическую типизацию, если есть динамическая?

Не нужно путать системы типов и парсеры

VD>>А лично нам оно нужно для разработки следующей версии Nemerle. Там без динамической расширяемости ничего не поделать.

K>А зачем? Как оно должно работать?
K>Просто интересно.

Это будет подключение правил к парсеру по мере разбора текста.

Здравствуйте, hardcase, Вы писали:

H>Это будет подключение правил к парсеру по мере разбора текста.

Все равно непонятно Разве нельзя составить список всех доступных в данном файле макросов и подключить их к парсеру статически?