OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 10 Декабрь, 2019 10:22

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 67 ]  На страницу 1, 2, 3, 4  След.
Автор Сообщение
СообщениеДобавлено: Воскресенье, 09 Август, 2009 16:35 

Зарегистрирован: Вторник, 04 Август, 2009 19:50
Сообщения: 33
Есть такая бесплатная программа (российского разработчика) под названием HiASM.
Это визуальный (графический) конструктор программ.
Конструктор не привязан к какому либо языку программирования, на данный момет умеет генерировать код: Делфи/FPC (основной пакет), С++, VBS, FASM, Python, PHP, приложения для PocetPC (PDA).
HiASM можно использовать для написания программ без знания языков программирования.
Если у кого нибудь есть желание, можно самостоятельно сделать пакет для своего любимого языка программирования.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 09 Август, 2009 18:21 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9163
Откуда: Россия, Орёл
Сама по себе разработка (давно наслышан) - как just for fun разработчиков - любопытная. Вполне может быть, что в каком-то звене сборочной разработки или конфигурирования готовых приложений она могла бы найти своё место.

Как инструментарий программиста её позиционировать нельзя. Она вводит жёсткий барьер между работой в ней и непосредственно уровнем программирования ниже. На определённом этапе сложности задач не будет возможности мягко и постепенно (в нужных местах) уходить на слой абстракций ниже. Т.е. с точки зрения любых долгосрочных целей - просто тупик (ровно по той же причине, по какой тупик - Scratch-и, "Алисы", Флеши в школах... Кстати, эту проблему при обсуждении на недавней конференции в Новосибе многие педагоги поняли и согласились).

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 10 Август, 2009 08:25 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1040
Откуда: Россия, Чебоксары
А можно обосновать необходимость перехода "на слой абстракций ниже"?
Не практически (потому что "как всегда"), а теоретически?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 10 Август, 2009 13:08 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 573
Откуда: Россия, Санкт-Петербург
Alexey_Donskoy писал(а):
А можно обосновать необходимость перехода "на слой абстракций ниже"?
Не практически (потому что "как всегда"), а теоретически?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 10 Август, 2009 14:37 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9163
Откуда: Россия, Орёл
Alexey_Donskoy писал(а):
А можно обосновать необходимость перехода "на слой абстракций ниже"?


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

Представьте себе проектирование сложного сетевого сервиса. Тут Вам и сверхвысокоуровнево проектировать захочется, и иметь возможность спускаться до самых деталей (какой именно структурой данных реализована вот эта очередь сообщения; как именно передаётся вот это событие; какое управление страницами поставлено под вот это хранилище...).
Цитата:
В моём понимании-опыте, "сложное серверное ПО" - это иерархическая система, где каждая подсистема имеет независимое поведение. Слово "независимое" может на уровне технической реализации отображаться в разные формы параллелизма. Hardaware-isolated processes, software-isolated processes, threads, light-weight processes/threads (программное диспетчирование).

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

На некотором уровне зрения нет принципиальных различий между понятиями алгоритма, протокола, спецификации поведения во времени... Все эти понятия можно понимать как грамматику на "язык" некоторой системы в алфавите элементарных событий. Грамматику поведения во времени.
Я воспринимаю и использую ДРАКОН именно как форму записи таких грамматик.

(мой ответ на Компьютерре)


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 12:07 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Илья Ермаков писал(а):
Как инструментарий программиста её позиционировать нельзя. Она вводит жёсткий барьер между работой в ней и непосредственно уровнем программирования ниже

Мне вот интересно, а что навело на такой вывод :?:
Нет, мне действително интересно :)

Вообще-то HiAsm (в частности, и визуальное программирование - вообще)- это прежде всего FrontEnd.
А именно, ЛЮБАЯ конструкция скриптового языка может иметь визуальное представление.
Если некоторой сегодня и нет (это далеко не законченный проект, в моем понимании), то она может легко появиться завтра.
Ну не знаю, неужели очень хочется спуститься ниже конструкций IF, WHILE, REPEAT :?:

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


Илья Ермаков писал(а):
Т.е. с точки зрения любых долгосрочных целей - просто тупик

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


Илья Ермаков писал(а):
Кстати, эту проблему при обсуждении на недавней конференции в Новосибе многие педагоги поняли и согласились

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 12:20 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3124
Откуда: Астрахань
Galkov писал(а):
Илья Ермаков писал(а):
Т.е. с точки зрения любых долгосрочных целей - просто тупик

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

Блочное программирование воспринимается как блочное панельное строительство. Да, из панелей можно очень быстро построить вполне добротный дом. Но никогда не построить того, что МОЖНО построить из кирпича (хотя из последнего строить дольше). Поэтому для профессионального программиста крупные блоки должны быть однозначно способны разбираться на "кирпичи". Если этого нет, то дальше "панельных домов" мы не продвинемся.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 12:48 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2933
Откуда: г. Ярославль
Раз уж часто приводится hiasm как пример, позвольте вбросить пять копеек (взято с главной странички сайта hiasm.com):

Цитата:
На кого рассчитан данный продукт?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 13:21 

Зарегистрирован: Вторник, 04 Август, 2009 19:50
Сообщения: 33
Кстати, чем "блочное" программирование в HiASM - не компонентное программирование?
Каждый блок(кубик) - это отдельный файл с кодом - компонент.
Каждый такой компонент взаимодействует с другими отдельными компанентами по определенным правилам.
Компоненты можно писать самостоятельно, можно редактировать существующие т.е. опускаться на нужный уровень абстракции.
Паралелей можно найти множество между компонентным и графическим программированием.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 13:22 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Иван Кузьмицкий писал(а):
позвольте вбросить пять копеек (взято с главной странички сайта hiasm.com)

Позвольте вернуть сдачу: на заборе тоже кое-что написано. Я попробовал - а там гвоздь :D
А если серьезно - у проекта есть некая история. Сначала это был некий "проигрыватель" скриптов, в которых отражалась схема, потом возникла некая простая кодогенерация (схема => коды для D4), потом эта кодогенерация была вынесена в отдельную dll с открытыми кодами (грубо говоря - любой пользователь может сделать свой Super-Puper-BackEnd), как следстве у появились разные схемы генерации кода и под разные языки (и каждая со своими тараканами естественно).

А вот что мне интересно, как все-таки из этого вытекает, что это ТУПИК :?: :?: :?:
Грубо говоря, я никак бы не реагировал, если бы кто-то сказал, что Oberon - forever. Но когда говорят, что HiAsm - это тупик, и что таковое решение принято где-то на конференции - хочу аргументацию.

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

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


Валерий Лаптев писал(а):
Но никогда не построить того, что МОЖНО построить из кирпича (хотя из последнего строить дольше)

Ну если это элемент волновой трассировки (MatrixWave например), тогда соглашусь - это относительно крупная панель.
Но рискну повторить вопрос: элементы дистрибутива If_Else, For, Repeat - это крупные панели, или кирпичи :?:
И какой ЯВУ представляет более мелкую гранулярность :?:
И почему некий инструмент (ЛЮБОЙ :!: ) скриптового языка не может иметь визуального представления.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 14:24 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9163
Откуда: Россия, Орёл
Galkov писал(а):
Грубо говоря, я никак бы не реагировал, если бы кто-то сказал, что Oberon - forever. Но когда говорят, что HiAsm - это тупик, и что таковое решение принято где-то на конференции - хочу аргументацию.


Нет, уважаемый коллега, я не это имел в виду.
Я не считаю HiAsm - как проект, как исследование, как работу... - тупиком. САПР над языками программирования - это, по моему мнению, хороший путь, хотя конкретно абстракции HiAsm несколько однобоки (а они одинаковы, кстати, в таких САПР - и в Lab View, и в Microsoft Robotics Studio, и в российском имитационном пакете AnyLogic - потоки данных. Dataflow - это очень хорошо. Как один из срезов описания системы. Но - только один. К тому же эти инструменты чрезмерно поощряют - психологически поощряют "кобминаторику", сборку методом тыка и экспериментов, лично я бы хотел видеть САПР, которая буквально вынуждает к постепенному систематическому проектированию, пошаговой детализацией с уточнением).

Возвращаясь к тупику: надо понимать моё выссказывание так. Выбор инструмента класса HiAsm (а это целый класс достаточно по идеологии похожих) для школьного образования - тупиковый. Нет, на кружках, just for fun, сколько угодно. В условиях ограниченности ресурсов - времени, сил педагогов и т.п. - основной инструмент должен быть "на вырост" на много лет вперёд, вплоть до середины ВУЗа. Он должен быть один, универсальный, расширяемый, сквозной. Остальное может довешиваться сбоку, если условия конкретного уч. заведения позволяют. Мне незачем тут повторять тезисы [url=http://www.inr.ac.ru/~info21]Информатики-21[/quote], они отшлифованы годами и выношены из опыта людей - стратегического опыта, т.е. предполагающего организацию долгосрочного дела в очень изменчивой и неблагоприятной среде.

Касательно Новосибирска - там речи про ХайАсм вообще не шло. Я имел в виду обсуждение детских сборочных сред типа Scratch.

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

P.S. Кстати, у нас же на форуме обсуждается визуальный язык ДРАКОН - viewforum.php?f=62 - это может быть Вам интересно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 15:36 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Илья Ермаков писал(а):
лично я бы хотел видеть САПР, которая буквально вынуждает к постепенному систематическому проектированию, пошаговой детализацией с уточнением)
Что занимательно, я - тоже :D
Одна из бед проекта как раз и состоит в том, что в нем очень мало (мягко говоря) участников (точнее - developer-ов), имеющих аргументированное мнение о необходимом инструментарии для профессинальной работы.
Которые БЫ более подробно изложили бы понимание "однобокости", и т.п...
Именно потому, что первая фаза (тестирование восприятия визуального FrontEnd-а) должна же когда-то закончиться, и перейти во вторую фазу - профессионального продукта. Законченный инструментарий, высококлассный BackEnd..............
Да, этого сегодня еще нет. Из этого можно делать вывод, что это - тупик, а можно - как направление для работы.
Категорически настаиваю на правильности именно второго :)


Galkov писал(а):
они отшлифованы годами и выношены из опыта людей - стратегического опыта, т.е. предполагающего организацию долгосрочного дела в очень изменчивой и неблагоприятной среде
Ну скажем так, и у нас не один год тестирования идет. И есть наблюдения, что мы-то как раз учим программированию (и уже не один год), в отличие от кодинга. Да, это трудно было предсказать 6 лет назад, конечно же. Но сегодня это просто экспериментальный факт - свидетельства людей котрые таки ушли в "скриптовое программирование" (скажем, по причине того, что продукт ЕЩЕ не является профессинальным).
Да, кодинг и у нас есть (ну надо же схему нарисовать как-то), но затраты на него как-то мало кто замечает.
Ну а "простые задачи".... Ну не знаю... Все-таки это не только Hello Word, в большей степени это определяется образованием программиста, чем средой.

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

Я уж даже и говорить не буду, что у нас ООП-подход с самого зарождения, и другого подхода просто и нет как-то (во FrontEnd-е, разумеется)
Всякая схема изнутри есть определение класса, а снаружи - его многими (в т.ч. и единственной) реализациями. Вот вам и вся наука.

Илья Ермаков писал(а):
Кстати, у нас же на форуме обсуждается визуальный язык ДРАКОН

Угу, обратил внимание, спасибо. Конечно, я изучу этот вопрос очень подробно.
С налету, пока такое:
Скажем профессионально я, в т.ч., и программирую AVR-ки. И пользуюсь там аналогичной средой Algorithm Builder. Они похожи с Драконом тем, что, в отличие от HiAsm - визуализируют только поток исполнения. А где данные, какие данные, почему именно эти данные - держим в уме. Конечно, это серьезно облегчает задачи BackEnd-а.... Но все-таки мы жизни должны диктовать свои условия, а не она нам (мне так кажется :) )
В общем, по поводу визуализации - у меня уже очень тонкий вкус, я спокойно различаю градации :D


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 15:56 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Galkov писал(а):
Собственно, мне наверное лучше всех известно, что сегодня не дает писать мега-коды (хотя не в размерах вопрос, конечно же), но как-то не вижу почему так должно быть всегда...
Методы "электротехнического" проектирования освоил мелкософт ещё в DirectX(graphedit.exe, вроде как..). Явно не идеал. Повторять это с VCL-ками, конечно можно, но непродуктивно. Хотя бы с эргономической точки зрения.

В электронике недаром разделены функциональное и конструкторско-технологическое обозначение компонента. Первые используются на схемах, а вторые - на топологиях печатных плат. К чему это я? При взгляде на HiAsm возникает впечатление макетки, на которой отдельными "проводами" соединяем компоненты. Вроде как и не схема, но и не печатная плата. Забудем на секунду о HiAsm. В натуральном виде макетка на сотню многоногих корпусов выглядит настолько "монолитно" с паутиной настоящих проводов, что никакой речи о структурности, наглядности или ремонтопригодности быть не может. Но прототип сделать всё же можно было, и достаточно быстро. Хорошо, что на сегодня корпуса электронных компонентов стали настолько малы, что собирать их "путанкой" на макетку может только настоящий аскет.
Но вернёмся к HIasm'у: не нашёл я в нём способа структурировать потоки данных и исполнения. И второе - слишком уж жёстко он заточен под ООП. Поэтому и не увидел я перспективы с HiAsm'ом. Это, конечно, всего лишь личное мнение.

Galkov писал(а):
элементы дистрибутива If_Else, For, Repeat - это крупные панели, или кирпичи :?:
Самые мелкие кирпичи, по-любому - это синтаксис целевой платформы. Ниже не провалитесь :) Если генерите под какой-либо ЯВУ, то If_Else, For, Repeat - кирпичи. Если под промежуточное представление, то уже крупные панели.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 17:27 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2933
Откуда: г. Ярославль
Galkov писал(а):
Иван Кузьмицкий писал(а):
позвольте вбросить пять копеек (взято с главной странички сайта hiasm.com)

Позвольте вернуть сдачу: на заборе тоже кое-что написано. Я попробовал - а там гвоздь :D

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

Если это шутка, то у авторов hiasm довольно интересное чувство юмора :)

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

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

P.S. Плохого ничего не хочу сказать про hiasm, конечно :) Вот только что попробовал в нём сделать пустую форму для PocketPC и запустить на своём коммуникаторе. Запустилось :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 20:33 

Зарегистрирован: Вторник, 04 Август, 2009 19:50
Сообщения: 33
Иван Кузьмицкий писал(а):
Вот только что попробовал в нём сделать пустую форму для PocketPC и запустить на своём коммуникаторе. Запустилось :)

Удивительно было бы если не запустилось :)


Вложения:
Комментарий к файлу: Попробуйте сделать это и восхищению не будет предела :) Все просто как 1-2-3!
hiasm.jpg
hiasm.jpg [ 50.32 КБ | Просмотров: 15014 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 22:26 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Pirr писал(а):
Удивительно было бы если не запустилось :)
Ну я бы на твоем месте не горячился, всякое бывало :D


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 22:27 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Рэйлвэй Каген писал(а):
Методы "электротехнического" проектирования освоил мелкософт ещё в DirectX(graphedit.exe, вроде как..). Явно не идеал. Повторять это с VCL-ками, конечно можно, но непродуктивно. Хотя бы с эргономической точки зрения
Напомню Вам, коллеги, что моей целью не является холивар. НО является - возразить против признания тупиковыми средства визуального программирования вообще, и HiAsm - в частности.
Т.е., в мои намерения не входит спор - насколько это идеал
Ну не нравится кому-то чего-то - ну и слава богу.

Но вот что мне показалось дополнительно: Вы путаете FrontEnd и BackEnd :!:
Делать вывод о потенциальных качествах BackEnd-а, исходя из некоторого FrontEnd-а - неправильно :idea:
Кстати о птичках, в пакете Дельфи (старейшем и наиболее обкатанном) используется не VCL, а KOL.
Между прочим, это земляк Кладов научил меня великой истине: использование ООП во FrontEnd-е - БЛАГО, а в BackEnd-е - ЗЛО. И не просто продекларировал (теоретиков-то много), но и доказал это своей библиотекой.
Кодогенерация древнейшего пакета Дельфи: да, это так, не фонтан с точки зрения эффективности. Грубо говоря Call на Call-е сидит, и им же погоняет.
Но это не мешает пакету выполнять главную задачу - тестировать восприятие FrontEnd-а пользователями.
И имеются экспериментальные факты: за какое время школота сможет создавать прожки, типа показанной Pirr-ом, с полного и абсолютного нуля, без подсказок. Кажется а.к.а. Астрамак экспериментировал.... Один день. Урок - грубо говоря. ((btw: в Help начинают лезть только на 2-3-й день))

Но на ту же самую схему (что кажется Вы назвали супер-ООП) уже сегодня существуют и иные схемы кодогенерации - это полная противоположность, супер-inline. Это проекты FASM, и любые другие в технологии FTCG.
Тоже легко понимаешь, что дурдом достигается довольно быстро... Хотя тут уже проблем с эффективностью - никаких.

Оптимального (я бы сказал - правильного) варианта сегодня еще нет. Мое главное возражение - нет никаких оснований утверждать что его не будет завтра.
Будет. Не, ну может - послезавтра... Как фишка ляжет...
И, обратите внимание - никакой фундаментальной связи между FrontEnd-ом и BackEnd-ом не существует. Она может существовать в чьих-то головах, но уж точно - не в реальности....


Рэйлвэй Каген писал(а):
Но вернёмся к HIasm'у: не нашёл я в нём способа структурировать потоки данных и исполнения
Не все еще сделано.
Должно быть так: всякая структура данных - это объект. Определение класса объекта - это схема. Выглядит это снаружи как мультик (MultiElementEx). Множественное создание объектов пользовательского класса - сегодня это либо массив этих мультиков, либо т.н. линки. Здесь сегодня тоже не все еще гладко... Далее - они (имеют) нижнюю точку хэндл. И после создания визуальной поддержки объектоуказания (что будет возможно уже видимо на днях) возникает возможность создания любой "хитросплетенной" системы объектов.

Так должно быть или несколько по иному (в визуальном аспекте) - вопрос обсуждаемый.... Ну а дальше я уже все сказал, вроде: обсуждать эдакий полет мыслей не со всеми - есть эффективное занятие.... :)
Тут у нас есть проблемы


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 23:24 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Честно говоря, ни разу не подразумевал backend. Батон крошил только на front и VCL'и помянул в общепринятом смысле.
Galkov писал(а):
Не все еще сделано...
Вот это и смущает. То, что Вы идёте "от реализации". И зачем нужна "возможность создания любой "хитросплетенной" системы объектов", когда выгоднее иметь структурированное и понятное решение?

Galkov писал(а):
..кажется Вы назвали супер-ООП
не было такого.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Август, 2009 23:59 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Рэйлвэй Каген писал(а):
Батон крошил только на front и VCL'и помянул в общепринятом смысле
Тогда нужны разъяснения к "общепринятому смыслу".
Вы писали: "Повторять это с VCL-ками, конечно можно, но непродуктивно. Хотя бы с эргономической точки зрения"
"Не продуктивность VCL" в общепринятом смысле - это 300К на пустую форму. Что, в свою очередь, является прямым следствием применения методов ООП в BackEnd-е
Чистая логика, ничего личного :)

Рэйлвэй Каген писал(а):
Вот это и смущает. То, что Вы идёте "от реализации"
Давайте вместе с Вами устроим полный рефракторинг. Обсудим правильный путь, да и пойдем по нему, но уже вооруженные некоторым опытом :D
Но честное слово, это уже даже и для меня будет полным offtop-ом в этой теме.
Если в тему - ну никак такие соображения не могут являться выводом про тупиковость визуальных сред

Рэйлвэй Каген писал(а):
И зачем нужна "возможность создания любой "хитросплетенной" системы объектов", когда выгоднее иметь структурированное и понятное решение?
Ну не нужна - не делай. Кто ж заставляет
И чем существующая структура не устраивает-то
Создал схему (читай - класс объекта), разместил в ней две строки, один стрим, два битмэпа, плюс пользовательский объект (в простонародии - мультик). Который тоже может содержать некоторое личное разнообразие. В т.ч. и мультики. Разве это не структура :?:
Как до всего этого добра добраться - рисуем соответствующие методы. ООП все-таки
Где проблемы :?:
Ну и главное: кто-то разве возражает против конструктивных предложений :?:
И опять про тупик - читаем выше :lol:

Рэйлвэй Каген писал(а):
не было такого
Зато было такое: "И второе - слишком уж жёстко он заточен под ООП"
Как бы я позволил себе вольность: заменил "слишком уж жестко" на "супер". Простите, если что...
Ну и, конечно же, считал что ЗЛО от ООП может быть только в BackEnd-е.
Да и сейчас тоже так считаю.......


Последний раз редактировалось Galkov Среда, 12 Август, 2009 01:22, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 12 Август, 2009 00:14 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Иван Кузьмицкий писал(а):
Не понял юмора

Ну и ладно :D
Давайте говорить абсолютно формально
1) Можно ли рисовать простые программы ??? МОЖНО
2) Сказано ли, что нельзя создавать сложные программы ??? НЕ СКАЗАНО
3) Кто-то утверждает на главной странице проекта, что никогда целевым назначением не будет "создание программ любой сложности" ??? НЕТ
4) Почему сегодня на главной страничке не стоит в качестве назначения "создание программ любой сложности" ??? Потому-что сегдня это еще не так

Мне представляется все предельно логичным....
А про юмор... Понимание действительно происходящего (которое можно достигнуть и экспериментальным путем) - гораздо важнее написанного.
ГОРАЗДО. Хотите верьте, хотите нет, но я в MSDN нахожу аж три разные формулы для одного и того же:
Цитата:
The size of the file is equal to
1) (nFileSizeHigh * MAXDWORD+1) + nFileSizeLow
2) (nFileSizeHigh * MAXDWORD) + nFileSizeLow
3) (nFileSizeHigh * (MAXDWORD+1)) + nFileSizeLow
Уверяю Вас - мне их искать и в голову не приходило, и так все ясно было вроде бы... Просто как-то по жизни случился диспут с "Мастерами Дельфи", какая из них правильная.
Трудно конечно возражать написанному (они еще и 32-битную арифметику для формул применяли), но у меня есть опыт :lol:
Ну это так, развлекся....


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 67 ]  На страницу 1, 2, 3, 4  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


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

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB