Здравствуйте, Real 3L0, Вы писали:
0>>Потому, что эти "кубики" не устраняли главной сложности в программировании, они решали не ту проблему. R3>А какую проблему они решали?
Они пытались упростить синтаксис, сделать так, что бы он *выглядел* как нечто знакомое.
0>>Точно по той же причине провалились попытки сделать программирование простым, приблизив синтаксис языков к английскому. R3>Про это я ничего не говорил.
Это я уже подбрасываю угля в тему
Здравствуйте, Real 3L0, Вы писали:
FR>>Наоборот что-то простое из кубиков получается быстро, красиво и выразительнее текста, чуть сложнее текст оказывается на порядок и проще и выразительнее.
R3>Мы живём в разных реальностях.
R3>Пример 1. R3>Давай я тебе дам исходники, а ты не компилируя их, сможешь рассказать, что делает программа? Сколько времени у тебя на это уйдёт? R3>А теперь посмотрим на какой-нибудь бизнес-процесс, представленный в виде какой-нибудь модели (какой-нибудь нотации)? Сколь времени уйдёт на это? И заметь, я даже не уточнял — какую именно нотацию брать, что абсолютно невозможно опустить при просмотре исходников.
Неудачный пример, исходники можно все же скомпилировать и получить программу. Модель скомпилировать нельзя, там явно недостаточно информации. Как только начинается попытка довести ее до достаточной на реальных задачах — все оказывается плачевно. Для каждого кубика приходится писать кучу кода, который читать и поддерживать гораздо сложнее чем те исходники.
R3>Пример 2. R3>Я уже как-то писал. Мне понадобилось в программу вставить проверку email-ящика. Просто — тупо открыть письмо и прочитать текст. ... Узнал много "офигенно полезной и нужной мне в данный момент" информации, типа MIME.
Плохой пример, кубик тут бы помог настолько же, насколько поможет любая нормальная библиотека. Но шаг влево, шаг вправо кубик пришлось бы выкинуть и писать в рукопашную.
R3>Или другой пример. Мне надо было подготовить данные, вставить их в контролы на форме, после чего показать форму пользователю. ... Узнал много "офигенно полезной и нужной мне в данный момент" информации, типа handle окна.
Хороший пример. Для дизайна форм кубики прижились, хотя html/xaml люди предпочитают делать опять же в коде.
L>>- Реализовать хотелось бы на javascript + sql (web kit html5), так как интересно сделать L>>конструктор на чистом браузере (для тачскринов).
VD>sql то ту причем? Как он с броузерам может быть связан?
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, lseder, Вы писали:
L>>Привет, может кто-нибудь находил в инете инфу по метапрограммированию. L>>Интересуют принципы выделения и организации низкоуровневой структуры, и L>>методы конструирования мета-конструкций на основе предыдущего (нижнего) слоя понятий. 0>Идея средства программирования, которое бы позволяло пользователю "складывать" программы из "кубиков" по аналогии с конктруктором LEGO витает очень давно. Однако все попытки сделать это провалились. 0>Вопрос — почему?
а я знаю! а я знаю! но не скажу!!!!!!
Тут есть монго формулировок других: почему не получается разбить задачу на составные части так, чтобы части можно было изменять независимо друг от друга.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, Real 3L0, Вы писали:
R3>>Вероятно потому, что всё это было не юзабельно. Кубики — они из названия подразумевают "лёгкость", но я ещё не встречал простого средства разработки. 0>Потому, что эти "кубики" не устраняли главной сложности в программировании, они решали не ту проблему. 0>Точно по той же причине провалились попытки сделать программирование простым, приблизив синтаксис языков к английскому.
100% — именно эта причина, у естественного языка получится бесконечная грамматика если попытаться создать компилятор.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, 0x7be, Вы писали:
0>>Вопрос — почему?
R3>Вероятно потому, что всё это было не юзабельно. Кубики — они из названия подразумевают "лёгкость", но я ещё не встречал простого средства разработки.
Да ладно. COM + VB — отличный кубики, все очень легко и просто.
Или Дельфи с ее компонентами.
Кубики писать — да, геморрой, а из имеющихся кубиков все очень легко собирается.
Здравствуйте, Ziaw, Вы писали:
Z>Неудачный пример, исходники можно все же скомпилировать и получить программу. Модель скомпилировать нельзя, там явно недостаточно информации. Как только начинается попытка довести ее до достаточной на реальных задачах — все оказывается плачевно. Для каждого кубика приходится писать кучу кода, который читать и поддерживать гораздо сложнее чем те исходники.
Это потому, что нет хорошего конструктора кубиков (КК). Ты описываешь проблемы, присутствующие в существующих КК. Но почему они должны быть в будущих (ещё не созданных) КК?
Например, проблема недостатка информации. Почему её нельзя решить? Вспомни какой-нибудь процесс (последовательность действий), выполненный много раз на компьютере. Думаю, при выполнении этого процесса ты вводил какие-то данные. Почему компьютер не сохранил эти данные при первом вводе, чтобы автоматически ввести их при повторном запуске процесса? Чтобы ты мог ввести (выбрать) другие данные. Но зачем тебе вводить другие данные? Потому что изменились начальные данные. Так почему начальные данные не предоставляют информацию о том, что с ними можно сделать?
Я очень сильно сомневаюсь, что проблема недостатка информации существует. Вот проблема получения информации — существует.
R3>>Я уже как-то писал. Мне понадобилось в программу вставить проверку email-ящика. Просто — тупо открыть письмо и прочитать текст. ... Узнал много "офигенно полезной и нужной мне в данный момент" информации, типа MIME. Z>Плохой пример, кубик тут бы помог настолько же, насколько поможет любая нормальная библиотека. Но шаг влево, шаг вправо кубик пришлось бы выкинуть и писать в рукопашную.
Библиотека — это и есть кубик, но в мире программирования. Либо пишешь код руками (без КК; узнавая, что такое MIME), либо используешь библиотеку (с КК; не узнавая, что такое MIME). Так что нормальный пример.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, jazzer, Вы писали:
J>>Кубики писать — да, геморрой, а из имеющихся кубиков все очень легко собирается.
R3>Отсутствует механизм поиска нужного кубика
гугл?
R3>следовательно лёгкость отсутствует в принципе.
странная логика
Здравствуйте, Sinix, Вы писали:
S>Угу. Так предложите
Ещё не доделал.
S> Проблема в том, что обычный код уже подошёл к пределу выразительности и даже уполз за него (если мы говорим о хардкорном ФП). Попробуйте выразить это S>
S>в виде кубиков. А теперь — метод, в котором подобных строк — штук 5. А теперь — код, который оперирует парой сотен таких методов
А зачем нужно создавать кубик, который будет аналогичен одной строки кода?
Я исхожу из идеи, что кубик должен выполнять полноценное действие.
S>Ну так тачскрин остаётся весьма узконишевой нишей. В качестве основного устройства управления он оччень неудобен, особенно — на больших экранах.
На больших экранах — это потому, что устаёшь рукой махать. Возможно имеет смысл выделить "область управляния", которая будет меньше экрана, и через которую будет осуществляться управление.
S> Со всякими workflow-движками ситуация абшолютно аналогичная: не взлетят
Ну, пока вроде бы летают.
R3>>Так что, будем сильнее натачивать лопату или будем придумывать новую технику? S>Увы, лучше затариться археологическими кисточками. Лопата — слишком грубый инструмент
Нее, это не мой путь. Думаю, лень в итоге всё равно победит.
S>Ну будет онлайн магазин — что, появится контент? Неа, пара-тройка полезных вещей (о которых и так все кому надо знают) просто потонет под тонной багоподелок. И так — в любом магазине, спасает только поиск (если уже знаешь что искать).
Проблема с тонной багоподелок решаема.
S>Неа. Потому что на все случаи жизни кубиков не напасёшься. Особенно для экзотики наподобие гусеничных ужоежей.
На все — нет. На 99% (сам же использовал слово "экзотика" ) — да.
R3>>Если же этот кубик состоял бы из других кубиков, то ты бы просто заменил ненужный кубик на правильный. S>Угу. Тем самым взяв на себя обязанность сопровождать ещё и чужой кубик — следить за обновлениями, разруливать конфликты, править костыли... Ба, мы опять вернулись к тому, от чего убегали
Эээ, с чего это? Ты сопровождаешь только свой кубик.
Здравствуйте, jazzer, Вы писали:
R3>>Отсутствует механизм поиска нужного кубика J>гугл?
Он тут не помощник.
Кстати, на днях искал инфу по определённому файлу: вбил название — гугель выдал мне 3 страницы ссылок на ресурсы, которые за денюжку починят мне все проблемы с этим файлом.
Т.е. для поиска кубиков нужен поисковик, заточенный на поиск кубиков. Потому что параметров у этих кубиков будет немало.
R3>>следовательно лёгкость отсутствует в принципе. J>странная логика
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, jazzer, Вы писали:
R3>>>Отсутствует механизм поиска нужного кубика J>>гугл?
R3>Он тут не помощник. R3>Кстати, на днях искал инфу по определённому файлу: вбил название — гугель выдал мне 3 страницы ссылок на ресурсы, которые за денюжку починят мне все проблемы с этим файлом. R3>Т.е. для поиска кубиков нужен поисковик, заточенный на поиск кубиков. Потому что параметров у этих кубиков будет немало.
Я к тому, что поиск кубика ортогонален языку.
А то так можно договориться до того, что трудно найти сотрудников, дешевый офис и страну с низкими налогами.
R3>>>следовательно лёгкость отсутствует в принципе. J>>странная логика
R3>А оно так.
Здравствуйте, Real 3L0, Вы писали:
S>> Проблема в том, что обычный код уже подошёл к пределу выразительности и даже уполз за него (если мы говорим о хардкорном ФП). Попробуйте выразить это
var customer = customers.Where(c => c.Age > 18 && c.NotBanned).Skip(123).FirstOrDefault();
S>>в виде кубиков. А теперь — метод, в котором подобных строк — штук 5. А теперь — код, который оперирует парой сотен таких методов R3>А зачем нужно создавать кубик, который будет аналогичен одной строки кода?
В таком случае вам будут нужны миллионы слабоотличающихся кубиков.
S>>Ну так тачскрин остаётся весьма узконишевой нишей. В качестве основного устройства управления он оччень неудобен, особенно — на больших экранах. R3>На больших экранах — это потому, что устаёшь рукой махать. Возможно имеет смысл выделить "область управляния", которая будет меньше экрана, и через которую будет осуществляться управление.
И мы получаем обычный тачпад, только руку на весу держать надо.
S>> Со всякими workflow-движками ситуация абшолютно аналогичная: не взлетят R3>Ну, пока вроде бы летают.
Но низэнько-низэнько(с)
S>>Ну будет онлайн магазин — что, появится контент? Неа, пара-тройка полезных вещей (о которых и так все кому надо знают) просто потонет под тонной багоподелок. И так — в любом магазине, спасает только поиск (если уже знаешь что искать). R3>Проблема с тонной багоподелок решаема.
Ни в одном онлайн-каталоге её не решили. И решать не будут, т.к. это требует привлечения на порядок больших расходов и только мешает основной цели существования сайа — продать/привлечь побольше посетителей.
S>>Неа. Потому что на все случаи жизни кубиков не напасёшься. Особенно для экзотики наподобие гусеничных ужоежей. R3>На все — нет. На 99% (сам же использовал слово "экзотика" ) — да.
80-20%
R3>>>Если же этот кубик состоял бы из других кубиков, то ты бы просто заменил ненужный кубик на правильный. S>>Угу. Тем самым взяв на себя обязанность сопровождать ещё и чужой кубик — следить за обновлениями, разруливать конфликты, править костыли... Ба, мы опять вернулись к тому, от чего убегали R3>Эээ, с чего это? Ты сопровождаешь только свой кубик.
Неа, раз уж взялся лезть во внутренности чужого кода — будь добр сам нести ответственность за последствия.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Vaako, Вы писали:
V>>а я знаю! а я знаю! но не скажу!!!!!!
S>Да не надо гадать, рано или поздно любая система начинает работать на скотче, клее и побочных эффектах. Эволюция
Ураган просто после такого начинаешь думать о естественном язык как самом непонятном языке на свете. Менеджер произнес фразу из ТЗ с другим акцентом и программист уже решил, что от него требуется совсем другое Тут нужна экспертная система не уступающая человеческому интеллекту, чтобы понять что хочет заказчик (какие кубики), а только потом переходить к задачке: как же нам эти кубики порасставлять чтобы получить желаемое.
У меня была одна кубическая задача которая произвела на меня сильное впечатление. Начальник моего начальника нарисовал прямоугольник, это была сложная система много-много строчек кода, потом добавил еще один прямоугольничек — это была другая система еще сложнее. Соединив их он произнес "вот так это происходит сейчас". Потом стер линию и нарисовал вместо нее третий приямоуголник соединив его с первыми двумя. Вердикт был следующим: "написать программное обеспечение чтобы некоторые функции первых двух прямоугольником изменились". На вопрос "но это потребует некоторой модификации первой системы (прямоугольничка)" был получен исчерпывающий ответ "ну что вы задаете глупые вопросы, я же все нарисовал понятным языком".
Позвольте уточнить.
Никаких новых кубиков сверх тех которые вводятся в курсе
программирования в школе — переменная, условный переход, циклы, функции.
Вспомните правило — семь плюс минус два. Больше чем 7 разнородных элементов
показывать в окне выбора возможных элементов смысла нет. Все что больше, надо
группировать, и давать возможность искать по словам.
Мета-структуры нужны лишь мне, как разработчику пользовательского интерфейса.
>Удар на копейку!
Это прототип. Толку от идей на бумаге немного.
>Потратив время на понимание концепций потом можно быстрее понять >программу целиком. Но это не тоже самое что понижение планки вхождения в язык.
Смысл конструктора в абстрагировании от синтаксиса ввода конкретного языка.
Знакомство с основными концепциями программирования подразумевается как базовое условие
для любого программиста.
Мне показалось возможным разделить синтаксис языка на два элемента, которые лучше соответствуют
целям того самого синтаксиса. 1) Ввод программы, 2) Чтение программы.
Для первой задачи надо синтаксис покороче, вводить только то что необходимо — данные и структуру.
Для второй надо синтаксис по нагляднее и понятней, как пример тот же паскаль, разработанный
для обучению программирования.
>Мне кажется вам нужно в первую очередь доработать свои идеи. >А для этого имеет смысл познакомиться с теми идеями, что есть у других.
Если есть информация — давайте.
Здравствуйте, lseder, Вы писали:
>>Мне кажется вам нужно в первую очередь доработать свои идеи. >>А для этого имеет смысл познакомиться с теми идеями, что есть у других. L>Если есть информация — давайте.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, jazzer, Вы писали:
J>>А то так можно договориться до того, что трудно найти сотрудников, дешевый офис и страну с низкими налогами.
R3>А резве не так?
Так, конечно, но какое это отношение имеет к языку программирования? Мы же, вроде, о программировании тут говорим
Здравствуйте, Sinix, Вы писали:
R3>>А зачем нужно создавать кубик, который будет аналогичен одной строки кода? S>В таком случае вам будут нужны миллионы слабоотличающихся кубиков.
Сейчас не нужны, и потом не будут нужны. Кому нужен второй кубик, если есть первый, делающий тоже самое?
R3>>На больших экранах — это потому, что устаёшь рукой махать. Возможно имеет смысл выделить "область управляния", которая будет меньше экрана, и через которую будет осуществляться управление. S>И мы получаем обычный тачпад, только руку на весу держать надо.
Это было всего лишь моё предположение.
Но всё равно не надо думать, что тачскрин на больших экранах не нужен совсем.
S>>> Со всякими workflow-движками ситуация абшолютно аналогичная: не взлетят R3>>Ну, пока вроде бы летают. S>Но низэнько-низэнько(с)
Ага, и дорого. Т.е. кто-то готов платить, что бы ты не говорил.
R3>>Проблема с тонной багоподелок решаема. S>Ни в одном онлайн-каталоге её не решили. И решать не будут, т.к. это требует привлечения на порядок больших расходов и только мешает основной цели существования сайа — продать/привлечь побольше посетителей.
Не решили, потому что и не начинали решать.
И расходы нужны не большие. По крайней мере в моём решении этой проблемы. Но да — "привлечение" у меня страдает.
S>>>Неа. Потому что на все случаи жизни кубиков не напасёшься. Особенно для экзотики наподобие гусеничных ужоежей. R3>>На все — нет. На 99% (сам же использовал слово "экзотика" ) — да. S>80-20%
Абсолютное большинство необходимых функций уже реализована. Твою "экзотику", думаю уже тоже кто-то реализовал.
R3>>Эээ, с чего это? Ты сопровождаешь только свой кубик. S>Неа, раз уж взялся лезть во внутренности чужого кода — будь добр сам нести ответственность за последствия.
Чужой код и замена одного кубика — это разные вещи.
Кубики — они из названия подразумевают "лёгкость", но я ещё не встречал простого средства разработки.
Тут нужна экспертная система не уступающая человеческому интеллекту, чтобы понять что хочет заказчик (какие кубики), а только потом переходить к задачке: как же нам эти кубики порасставлять чтобы получить желаемое.
