User Tag List

Страница 7 из 18 ПерваяПервая ... 34567891011 ... ПоследняяПоследняя
Показано с 61 по 70 из 173

Тема: Разработка программ и игр для ZX Spectrum на языках Оберон-семейства

  1. #61

    Регистрация
    19.01.2005
    Адрес
    Санкт-Петербург
    Сообщений
    11,551
    Спасибо Благодарностей отдано 
    205
    Спасибо Благодарностей получено 
    188
    Поблагодарили
    83 сообщений
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Oleg N. Cher Посмотреть сообщение
    Pure – не знаю.
    Pure не сложнее ZX бейсика, сужу об этом написав десяток игр на том и другом.

    Pure просто чуток современнее, со всеми этими Case, структурами, локальными/глобальными переменными, списками, картами...

    Но прелесть в том, что перелезая со спектрума, можно все это не юзать, а писать старинке с goto/gosub и забыв о навязчивых let/then.

  2. #61
    С любовью к вам, Yandex.Direct
    Размещение рекламы на форуме способствует его дальнейшему развитию

  3. #62

    Регистрация
    24.08.2007
    Адрес
    Днепропетровская обл.
    Сообщений
    1,681
    Спасибо Благодарностей отдано 
    2,711
    Спасибо Благодарностей получено 
    170
    Поблагодарили
    130 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от alone Посмотреть сообщение
    Посмотрел. Внятного решения там не предложено. Проблема остаётся. Любой более-менее сложный проект имеет условную компиляцию, и в ветках далеко не константы.
    Ты согласился бы со мной, что ifdef это частный случай if?

    Господа.
    Даже без наличия ifdef’ов в базовой поставке Оберона-2 “из коробки” мощности различных Оберон-диалектов хватает для написания ОС, компилятора, браузера (чему в инете много примеров, даже с исходниками), сетевых сервисов и динамических веб-сайтов, работы с БД, сяк-так GUI-приложений (хотя решений для традиционных ОС ощутимо меньше, чем для Оберон-ОС) и даже бортовой системы для управления безпилотным вертолётом. Я-то и занялся им чтобы понять пределы возможностей этой крохотульки. Но тут ещё невспаханное поле работы, есть к чему приложить усилия.

    Мы пока ищем, исследуем. Как обходиться без препроцессора. Но заметьте, есть “Дубовые требования” для Oberon-2, в них предусматривается препроцессор и условная компиляция. Никто вобщем-то не мешает реализовать в нашем компиляторе Оберона даже столь любимый ifdef.

    Я буду говорить о метасреде BlackBox Component Builder. В ней уже наблюдаются некоторые направления, позволяющие несколько отойти от чисто текстового представления программ. Вы наверное уже видели скриншоты процесса портирования Дурака на Спектрум? Там уже представление программы не чисто текстовое. И можно щас тут разтеять флейм, охаивая и поругивая недостатки такого подхода, но, как любое друге направление, облечающее софтостроение, оно имеет право на жизнь. Вообще тут наблюдается постепенное совершенствование подхода: сначала был просто текст программы, потом кто-то придумал его раскрасить. Не сразу придумал, но получилось красивше и более выразительно. Сейчас в моде фолдинг – сворачивание части кода внутри, так скажем, BEGIN и END. Тоже шаг. Далее, видимо, ещё что-нибудь придумают. Но в BlackBox кое-что уже есть. Но это сразу не видно, когда новоскачавший BlackBox Component Builder видит "Меню+лог". Это надо разбираться. Вникать. А зачем, если линукс всё равно мощнее. Примерно так думают.

    Помимо механизма слотов, в которые могут включаться различные реализации одного модуля, есть механизм, называемый селекторы (DevSelector), это вкладки в тексте, куда можно помещать какой-либо другой текст (или внедряемые объекты, например, рисунки) с неограниченной вложенностью. Помимо этого, есть возможность пометить любую вкладку меткой, скажем, ZxSpec, Win32 или Linux, и открывать все нужные нам вкладки (или ветвь) с выбранной меткой одномоментно. Скажем, открыли вкладку ZxSpec и сделали реализацию процедуры для Спека, открыли Win32 – и сделали её же реализацию для Win32. В свете такого решения потребность в ifdef’ах значительно уменьшается, если не исчезает совсем. Но это мы коснулись только Оберон-системы BlackBox.

    В далёких 90-х мне доставляло большое удовольствие писать на Hisoft Pascal. Компилятор, правда, занимал почти всю память, кодогенерация была ужасная, а строчный редактор – жутко неудобный. Но всё это затмевалось красотой языка. Чувствовалась мощь, солидность эдакая, уверенность что написанное заработает. И работало. Сегодня я уверенно утверждаю, что Оберон значительно красивее Паскаля, а уж если его усовершенствовать. Как сказал оберонщик Илья Ермаков: “Каркас идеального минимального императивного языка высокого уровня уже есть, можно спокойно сосредоточить все усилия на проблемах вышележащего уровня”. За точность цитаты не ручаюсь, но где-то так. C#-то чем берёт? Тем, что бухгалтерии клепать легко и быстро.

    А почему Оберон такой минималистичный? Видите ли, мэтр Вирт считает, что добавить новые средства в язык всегда можно и никогда это не поздно, а вот добавленное изъять – нельзя уже никогда. Отсюда появление таких монстров как Delphi, Ada и C#. А куда движется вообще мэйнстрим? Ну не надо быть высоким профессионалом, чтобы узреть в Java кастрированный C++. А ведь сколькими эпитетами её восхваляли сие новейшее слово в девелоперском деле, да и продолжают это делать. А Java – это испоганенный Оберон с сишным синтаксисом.

    Кстати, как правило, критики Си его как минимум использовали и хорошо знают, критики же Оберона все на одно лицо: “А, так в Обероне нельзя аггрегировать перегрузку шаблонов дружественного виртуального метода класса? Фтоппку! А ещё и нельзя написать a-=--(**c*(**a++)*--&b--)*(**c++)++ ? Фи, негибко получаецца. А ещё и ифдефов нет! Так это вообще капец! Так вы, наглецы, ещё и забыли, что такая серьёзная штука как ядро линукса написана не на вашем Обероне, так что выбросьте-ка его вы наффих и идите парить себе моск в универ и читать “Just for Fun”. Тьху, а тут ещё и устаревшие архаичные BEGIN и VAR? Это вообще плевок в лицо, ибо Паскаль умер миллион лет назад”. А вы разве не знали? Ага, мы тоже не знали. И умирал он долго и тяжело, и по сей день умирает. Сродни Спеку. А те, кто помогают его хоронить, могильщики от науки и искусства, сначала похоронив кроссплатформенное программирование (такого мощного разгула UNIX-подобных систем никакой майкрософт не предполагал), потом высчитывают сверхприбыли, не считая троллей, которые гнут ель, ибо тот, кто выбирает на чём и под что будут программировать, тот и имеет. Всех остальных. “Что у вас сегодня в меню, официант?” “Андроид, сэр!”

    Ещё замечу чистого любопытства ради, что серьёзные разработчики, даже не зная Оберона, в отличии от неофитов вовсе не спешат его огульно хулить. “Этта сделано капустными академическими головами шобы парить моск и шобы было, а не шобы делать ядро линуха”. Примеры навскидку. Sam Lantinga, автор библиотеки libSDL. Andreas Schiffler, автор SDL_gfx, а также Philipp Klaus Krause, мэйнтенер SDCC-кодогенератора для Z80. Люди достаточно далёкие от Оберонов. Но они разрабатывали. Много и долго. Поэтому научились уважать чужие идеи и любые средства разработки. Ибо если их зачем-то разрабатывали, значит зачем-то они нужны. Это вопрос личностного и профессионального роста. Я не жду этого от всех, ибо наивно.

    Цитата Сообщение от newart Посмотреть сообщение
    Мы тут о спектруме разговариваем, а значит предполгается что мы кодим на Асме и Бейсике. Какие нафиг Явы, СИ и Дельфи?
    Если смущает факт разработки для Спека на чём-то ещё, кроме асма и Бейсика, то лично мне (как, надеюсь, и вам) никак не претит с удовольствием поиграть в ускоренного Дурака от CoppeFeet, Moggy или Phantomas Saga – Infinity или (вы удивитесь!) Cauldron. Мне кажется, отрицать пользу высокоуровневой разработки для Спека – это сознательно сужать область его применения. Для хорошо реализованных кросскомпиляторов с языков высокого уровня польза для Спека – для быстрого макетирования, в банальном облегчении трудоёмкости при создании утилит и кроссплатформенной (Спектрум в связи с другими платформами) разработки, создании обёрток с нижайшим оверхедом вокруг асм-библиотек, с последующей разработкой на них в качестве структурно-модульного клея. А может этот барьер умов в неприятии ЯВУ для Спектрум-разработки – хороший повод пойти покодить на асме, оставив высокоуровневое направление для тех, кому оно интересно? Всё же лучше, чем забить тем и другим на Спек вообще.

    Ещё меня привлекает возможность, как и 15 лет назад (а помнишь, Alone, как ты меня упрекал в желании скрестить ПЦ и Спек? ), разрабатывать на одном языке для Спектрума тако же, как и для других платформ. Уникальные алгоритмы, реализованные на Спеке, красивейшие по задумке и блестящие по реализации игры. Всё это можно и нужно использовать на других платформах. Но Бейсик и асм тут вряд ли годятся. А в эмуле кодить – это вы уж извольте. Да, на Си тоже можно, но Оберон лучше. Более высокий уровень. В связке Оберон + Си + асм, впрочем, можно получить лучшее от каждого из этих средств, то, в чём их сила. Асм – низкоуровневые подпрограммы для скорости и мощности, сама реализация, уровень “КАК это реализуется на Спеке”, Си – … гм, ну, применение найдётся. Например, в качестве связующего звена между Обероном и асмом. Ну и его величество – Оберон (уровень “ЧТО надо сделать”). Прошу любить и жаловать. Заметьте, уровень не подразумевает лишь только Спек. Мне удалось настолько хорошо абстрагировать Даш от платформы, что уши Спека из основного алгоритма, сердца и логики, не торчат аж вообще никак. Без ifdef'ов. Вот-с. Да вы можете это заметить хотя бы по исходнику процедуры Play.
    Последний раз редактировалось Oleg N. Cher; 09.03.2012 в 15:22.

  4. #63

    Регистрация
    19.01.2005
    Адрес
    Санкт-Петербург
    Сообщений
    11,551
    Спасибо Благодарностей отдано 
    205
    Спасибо Благодарностей получено 
    188
    Поблагодарили
    83 сообщений
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Oleg N. Cher Посмотреть сообщение
    Если смущает факт разработки для Спека на чём-то ещё, кроме асма и Бейсика
    Смущает необходимость изучать новый язык и среду разработки.

    Я на пц обхожусь PureBasic / PHP / JS / C, на спектруме Ассемблером.
    Куда логичнее перенести на спектрум, что то из перечисленного чем изучать новое.

  5. #64

    Регистрация
    16.02.2006
    Адрес
    Новосибирск
    Сообщений
    3,280
    Спасибо Благодарностей отдано 
    17
    Спасибо Благодарностей получено 
    91
    Поблагодарили
    54 сообщений
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    не хотелось бы вдаваться в палемику, но всё же:
    #include не устарели нисколько и актуальны хоть даже сейчас?
    не устарели и ещё долго не устареют, т.к. другого способа включить в собираемый проект какие то нужные части пока не придумали. если в оберне нельзя делать подгрузку таких кусоков, зачем он тогда нужен?
    Ага, значит “:=” это уродство, а “==” – признанная всеми
    нет не всеми. в том же пуре бесике или в том же blitz basic`е оператор сравнения не отличается от оператора присвоения. на си его отделили. теперь уже поздно говорить о том, что верно это было решение или нет.
    языке C программист может написать конструкцию x+++++y, загадку, а не выражение
    не может. такие конструкции являются особенностями отдельных компиляторов.
    А ещё и ифдефов нет!
    ифдефы очень помогают, когда нужны условия компиляции или сделать макросы. очень жаль временами бывает, что в том же блице нет таких штук.
    устаревшие архаичные BEGIN и VAR? Это вообще плевок в лицо
    какие плевки, вы о чём? товарищ кроме бегловго взгляда смотрел ещё на какие то языки? конструкции с участием бегинов и варов существует великое множество. причём не только в языках программирования, но и в отдельных скриптовых языках. например в том же lua, например в том же папирусе..да много где. загляните в игры, таже серия игр от бетезды - фаллауты (3 и нью вегас), обливион, скайрим. можно заглянуть в в язык mel который используется в autodesk maya.
    языков существует привеликое множество. мне вот например импонирует отдельно блиц за его простоту, си за возможности...ну пожалуй луа за унивирсальность. любой язык можно применить к спектруму и любой другой платформе. что, точнее чем так выделяется оберон, пока не понял. по виду типичный бейсик, судя по синтаксису,с примесью паскаля/дельфи.
    Последний раз редактировалось Sayman; 09.03.2012 в 17:43.
    0A заповедей:
    I. Не удаляй каталог свой.
    II. Не удаляй до времени ни одного файла.
    III. Не кради файлы.
    IV. Не желай программы ближнего своего.
    V. Почитай BDOS и BIOS как родителей своих ...
    ---
    Sprinter resurrect:
    Telegram
    Discord
    Repo
    Forum

  6. #65

    Регистрация
    24.08.2007
    Адрес
    Днепропетровская обл.
    Сообщений
    1,681
    Спасибо Благодарностей отдано 
    2,711
    Спасибо Благодарностей получено 
    170
    Поблагодарили
    130 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от farewell Посмотреть сообщение
    А вот мне оберон (да и все остальные паскали) не нравится тем, что переменные процедуры нужно в отдельной секции описывать. На процедурах размером по 400+ строк, имеющих несколько десятков переменных удобнее концепция фрейма.
    Вряд ли Вам щас понравится, если я начну про засратые сями и явой мозги парить, правда? То-то же.

    Цитата Сообщение от farewell Посмотреть сообщение
    int a = 10; // фрейм 0
    if (true) {
    int b = 10; // фрейм 1
    }
    // здесь переменные фрейма 1 уже не видны.

    Надеюсь, понятно объяснил. Не совсем по науке, но суть такая.
    Такие вещи в Виртовской линейке языков обычно решаются вложенными процедурами, что примерно то же, но Ваш "фрейм" штука анонимная, а процедура позволяет показать что Вы имели ввиду, решив построить код именно таким образом.
    Код:
    PROCEDURE A;
    VAR
      z, x: INTEGER; (* Это общие для "фреймов" переменные *);
    
      PROCEDURE Frame1; VAR a, b (* Это личные переменные "фрейма" Frame1 *)
      END Frame1;
    
      PROCEDURE Frame2; VAR a, b (* Это личные переменные "фрейма" Frame2 *)
      END Frame2;
    
    BEGIN ...
    END A;
    Цитата Сообщение от Valen Посмотреть сообщение
    Интересует возможность поюзать Оберон для работы с объектами ООП.
    Оберон-2:
    Код:
    TYPE
      ElemType = INTEGER;
      Stack = RECORD
        a, b ... (* это внутренняя реализация, снаружи не видно – инкапсуляция *)
      END;
    
    PROCEDURE (VAR s: Stack) Push* (elem: ElemType);
    ...
    
    PROCEDURE (VAR s: Stack) Pop* (): ElemType;
    (* Здесь s – это поименованный self, снова не анонимный. Это удобно *)
    ...
    
    VAR
      stack1, stack2: Stack;
    BEGIN
      stack1.Push(123); stack2.Push(stack1.Pop());
    В Active Oberon малость посложнее, там есть милые сердцу OBJECT и SELF, но принцип в целом тот же.

    А вот наследование:
    Код:
    TYPE
      ExtendedStack = RECORD (Stack)
        (* Запись унаследована от расширяемой записи Stack *)
        a, b, c: SomeType; (* Это дополнительные поля *)
      END;
    
    PROCEDURE (VAR es: ExtendedStack) SomeProc1 ...
    PROCEDURE (VAR es: ExtendedStack) SomeProc2 ...
        (* Это доп. методы *)
    http://forum.oberoncore.ru/viewtopic.php?f=8&t=2121
    http://forum.oberoncore.ru/viewtopic.php?f=29&t=2125

    Цитата Сообщение от newart Посмотреть сообщение
    Я на пц обхожусь PureBasic / PHP / JS / C, на спектруме Ассемблером.
    Куда логичнее перенести на спектрум, что то из перечисленного чем изучать новое.
    Перенести на Спек PHP или JS? Ор-ригинально, батенька. Уже кажется Java переносили, тока 32-битность помешала. Но попробуйте, чего ж. А раз освоили PHP (и особенно JS), то Обероны пустячок, уверяю-с.

    А Вы вот это видели?

    ZX BASIC compiler v1.2.5, by Jose Rodriguez.
    Allows you to write a BASIC program on your PC and convert it to TZX to run on your real Speccy/emulator. The compiler works in all of PC/Windows, Linux and Mac OS X.
    http://www.boriel.com/software/the-z...piler/?lang=en

    Z80 Advanced Forth Compiler build 8 (PC/Windows), by Dumitru Florin Gabriel.
    http://www.worldofspectrum.org/utilities.html (оф.сайт не открылся)

    The ccz80 language
    CCZ80 v2.0.5 (PC/Windows), by Emilio Guerrero.
    The ccz80 language has a syntax based on the C language and produces assembler code - an assembler is integrated in the compiler.
    http://www.telefonica.net/web2/emili...z80/ccz80.html

    Вобщем, осталось только Обероны освоить. И сделать компилер. Всё остальное для Z80 уже есть.

    Цитата Сообщение от Kakos_nonos Посмотреть сообщение
    Поддерживаю создание компилятора Оберон'а для спектрума.
    Цитата Сообщение от ZEK Посмотреть сообщение
    Oberon который чистый практически полностью ложится LL1 грамматики (там одно или два исключения, не помню уже), Active Oberon чуть хуже ложится на LL1 из за "атрибутов", но все равно на порядок лучше чем тот же С.
    Значит этот язык естественным образом ложится за один проход на стековую машину (скорость компиляции!), а ей не присущи проблемы планирования ресурсов как в компиляторах под регистровые машины, в итоге код сгенеренный в лоб под стековую машину и разложенный на регистры Z80 (тож в лоб), будет если не быстрее, то уже точно не будет катастрофически отставать от цепочки oberon->ofront->C->sdcc->z80, sdcc тож не подарочек в кодогенерации
    Не подарочек, однако его достоинство в том, что он есть! И развивается.

    Господа, прошу покорнейше в ветке http://zx.pk.ru/showthread.php?t=18387 раскрыть своё видение каким по-Вашему должен быть компилятор Оберона для ZX.

    ---------- Post added at 16:22 ---------- Previous post was at 16:11 ----------

    Цитата Сообщение от Sayman Посмотреть сообщение
    не хотелось бы вдаваться в палемику, но всё же
    Не хочется впадать в маразм, но всё таки… Вы про модульность когда-нибудь слышали? Хорошо, посмотрим на проблему по-иному. ЗАЧЕМ включать кусок текста программы в кусок текста программы?

    Реальный пример из реальной жизни. У меня в проекте Дурак есть тип BOOLEAN, внутри SYSTEM.h, не то что мне так захотелось, так по задумке создателей Офронта назван стандартный тип. Теперь мне понадобилось при портировании под Win32/GCC подключить другой стандартный "модуль" windows.h, в нём тоже есть тип BOOLEAN. При инклюживании они оба накладываются друг на друга, #undef’ить один из них нельзя, так как это не #ifdef’ное определение, а тип. Вот Вам пагубность включения плоского куска текста в плоский кусок текста, без учёта накладок. Какая там к чёрту модульность. Но однако же вбилось в голову как шило, что никак иначе нельзя. Без этого сыр не настолько остр. Sayman, подобны же и Ваши другие претензии. Мы уже давно всё это обсосали на форуме OberonCore, я с Вами теряю время.

    в том же пуре бесике или в том же blitz basic`е оператор сравнения не отличается от оператора присвоения. на си его отделили. теперь уже поздно говорить о том, что верно это было решение или нет.
    Сравнение и присваивание это всё-таки разные вещи? В классическом Бейсике они помечались одинаковым "=", но отличались LET или IF.

    Плевок тут в том, что Вы сразу схватились за клавиатуру охаить малонравящуюся Вам Дельфи-подобную муть, малопохожую на ту муть, в которой варитесь Вы, и подобные Вам идут за Вами, попирая Ваш шаг; имя им легион.
    Последний раз редактировалось Oleg N. Cher; 10.03.2012 в 11:56.

  7. #66

    Регистрация
    16.02.2006
    Адрес
    Новосибирск
    Сообщений
    3,280
    Спасибо Благодарностей отдано 
    17
    Спасибо Благодарностей получено 
    91
    Поблагодарили
    54 сообщений
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    я вижу что с языками вы слабо знакомы, особенно с языком си.
    так как это не 3ifdef’ное определение
    #ifndef __BOOL
    typedef unsigned int bool;
    #define __BOOL
    #endif
    соответственно никто вам не мешает и инклуды в линухах подправить аналогичным образом. но только зачем, ведь проще обоSрать, чем понять.
    вы даже не понимаете разницу между синонимом и макросом. почитайте внимательно мануал и тогда поймёте.
    Плевок тут в том
    плевок тут в том, что человек купив книгу и прочитав 10 или 20 страниц понимает, что такое ему не асилить и начинает на одном и другом и т.д. форумах громогласно возмущаться сложностью и навороченностью того или иного языка.
    я не противник дельфи, когда то пробовал понять и изучить и паскаля и дельфи. но понял что асилить не смогу. переехал на си. однако то что изучил, помогло в дальнейшем понимать чужие исходники на паскале.
    кроме того, есть ещё один момент - если нельзя "ундефить" тип, значит можно использовать тот что уже есть на той платформе, под которую портируете свой проект. в крайнем случае, никто не мешает создать свой, например uboool. это плата за портируемость. если язык не позволяет делать кроссплатформенные программы (пусть даже с какими то переделками),то у такого языка мало шансов на выживание. если, например, у такого типа как int на пц разрядность 32 бита, то на спектруме у него 16 бит разрябность и при портировании это учитывается. очень сомневаюсь что в обероне такие детали учтены.
    могу привести пример - я взял исходники программы mkfs под мсхдос и портировал под профи. пришлось поработать над библиотекой, избавиться от функционала мсх, однако сама прога собралась замечательно, даже фирменные баги перешли на профика. единственное, я там убрал одну единстенную функцию, которая делал обращение к мсхдос и вызывала низкоуровневое форматирование. а вот fsck вапще не меняя просто скомпилил и она сразу заработала. я лично сомневаюсь в том, что можно взять исзодники под оберона и собрать так же просто на нашем брате. но спорить не буду. удаляюсь...
    0A заповедей:
    I. Не удаляй каталог свой.
    II. Не удаляй до времени ни одного файла.
    III. Не кради файлы.
    IV. Не желай программы ближнего своего.
    V. Почитай BDOS и BIOS как родителей своих ...
    ---
    Sprinter resurrect:
    Telegram
    Discord
    Repo
    Forum

  8. #67

    Регистрация
    25.06.2009
    Адрес
    Таганрог
    Сообщений
    151
    Спасибо Благодарностей отдано 
    1
    Спасибо Благодарностей получено 
    0
    Поблагодарили
    0 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    для хобби синтаксис наверно и не важен

    для серьезной работы важно:
    время выполнение работ по разработке ПО;
    надежность кода;
    сопровождаемость кода ( уволился программист или в отпуск пошел ).

    наличие излишеств вроде VAR, BEGIN, END и т.п. уже сами по себе
    для большинства программистов снижают читаемость кода, ухудшают сопровождаемость, увеличают сроки разработки. А все это - стоимость... Более длинный код тяжелее проверить.

    := почему плохо?
    большинство программистов уже привыкло ставить '=' и '=='. И уже неважно 'правильно' это или нет. Это уже есть. Применив в разработке язык с присвоением ':=' получишь сразу увеличение сроков и стоимости. Только за счет такой мелочи!


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

    На мой взляд, оптимум с точки зрения синтаксиса сейчас Python 2.x. Заодно заставляет программистов аккуратно исходник форматировать. И большие проекты на нем очень хорошо делать - быстрее в 2-3 раза чем аналогичный код на C/C++.

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

    Такое хобби как oberon-2 можно уважать, но БОЛЬШИНСТВУ программистов-профессионалов его синтаксис не понравится. Можно порассуждать и обосновать с 'научной' точки зрения почему они дураки, а Вирт умный но это будет уход от реальности

    мое мнение - Вирт с самого начала разрабатывал языки, с удобным для него лично синтаксисом. Он ведь много их разработал (в том числе Algol W, Pascal, Modula, Oberon ), широко применялся только Pascal, причем его основное назначение - обучение студентов. Лично я вздохнул с облегчением, когда перешел с него на C. Уже за одни фигурные скобки спасибо Ричи можно сказать. И я не один такой. Т.е. Вирту удобно, мне нет. И большинству - нет.

    PS ' ; ' - это тоже архаизм и излишество
    ZX Spectrum 48 issue 2, A600, Балтика, Commodore 64 + 1541-II

  9. #68

    Регистрация
    07.02.2008
    Адрес
    г. Рязань
    Сообщений
    2,928
    Спасибо Благодарностей отдано 
    37
    Спасибо Благодарностей получено 
    124
    Поблагодарили
    44 сообщений
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Ветка превратилась в очередное соревнование "язык, который я удосужился выучить, лучше, чем тот, который знаете вы" (фаллометрию). Мне приходилось по жизни писать на 36 разных языках (включая диалекты, правда). Язык что выучить, что использовать - это сущие пустяки. Основная трудность - набор библиотек к ним. Язык выбирается исходя из простоты решения задачи на нем. Мой любимый яхык - это тот, с помощью которого я зарабатываю деньги. В остальном все языки одинаковы. Не зависимо от == и :=, например. Я этого просто не замечаю, автоматичемки использую нужные конструкции где надо. Так что учите языки (это, повторюсь, пустячная задача), используйте их на практике, и переставайте наезжать на VAR, ';' или #define - это смешно.

  10. #69

    Регистрация
    24.08.2007
    Адрес
    Днепропетровская обл.
    Сообщений
    1,681
    Спасибо Благодарностей отдано 
    2,711
    Спасибо Благодарностей получено 
    170
    Поблагодарили
    130 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Sayman Посмотреть сообщение
    #ifndef __BOOL
    typedef unsigned int bool;
    #define __BOOL
    #endif
    Я вижу, Вы слабо вникли в высказанную мною проблему. Я ещё раз повторюсь: оба "модуля" – стандартные, править их крайне дурной тон. Я просто хотел бы воспользоваться ими одномоментно, включить их в один свой модуль сразу оба, как библиотечные, но они мешают друг другу, потому что не знают ничего друг о друге. Тут же умники придумали затычку – пространства имён. И тут же возвели её в культ. А другие умники потихоньку к ней привыкли и разучились видеть какие-то другие решения.

    никто не мешает создать свой, например uboool.
    Эхехе. Меня кажется не слышали. Эгей, товарищ! Оба "модуля" стандартные!!!

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

    если язык не позволяет делать кросскак int на пц разрядность 32 бита, то на спектруме у него 16 бит разрябность и при портировании это учитывается. очень сомневаюсь что в обероне такие детали учтены.
    О, представьте себе, в Обероне сделано ещё лучше, в нём при написании одних модулей разрядность платформы можно учитывать, а при написании других – игнорировать.

    Всё же мне кажется, на Обероны Вам не хватит терпения.

    Ладно, продолжаем ликбез.

    В Оберонах уже довольно давно вместо тупого включения куска текста в кусок текста программы, порождающего массу проблем зависимости между разными частями программы, предусмотрена модульность, и даже не только статическая, но и динамическая. Ближайший аналог этой концепции – механизм .SO/DLL в Linux/Windows.

    Осмелюсь утверждать, что Оберон-концепт более совершенен, ибо динамические Оберон-модули не зависят от базовой платформы и хост-системы, оставаясь Оберон-модулями, они – возможность языковая, не имеющая аналога на уровне языка ни в Си, ни в Паскале, кроме того, в отличии от .SO/DLL модули могут включать, помимо процедур, ещё и типы, константы и переменные.

    Особенности поддержки концепции модуля
    в языках Delphi (Object Pascal), Modula-2 и Оберон
    http://www.oberon2005.oberoncore.ru/qa261005.html

    Динамическая модульность в BlackBox - OberonCore
    http://oberoncore.ru/wiki/динамическая_модульность

    Модульное программирование: Terra Incognita
    http://oberon2005.oberoncore.ru/qa191005.html

    могу привести пример - я взял исходники программы mkfs под мсхдос и портировал под профи. пришлось поработать над библиотекой, избавиться от функционала мсх, однако сама прога собралась замечательно, даже фирменные баги перешли на профика. единственное, я там убрал одну единстенную функцию, которая делал обращение к мсхдос и вызывала низкоуровневое форматирование. а вот fsck вапще не меняя просто скомпилил и она сразу заработала. я лично сомневаюсь в том, что можно взять исзодники под оберона и собрать так же просто на нашем брате. но спорить не буду. удаляюсь...
    Вероятно, готовые программы, содержащие ошибки проектирования, будет переносить так же непросто, как и программы на Си, если модули очень плотно к платформе приклеены, буквально в каждой процедуре подразумевается, что платформа именно такая. Обероны же могут помочь в получении более чисто спроектированной программы. Кстати, выработать кроссплатформенную логику библиотек, достаточно экономичную для разворачивания как на Спеке, так и на других платформах, ИМХО достойная задача. Можно поработать в этом направлении.
    Последний раз редактировалось Oleg N. Cher; 09.03.2012 в 19:49.

  11. #70

    Регистрация
    24.08.2007
    Адрес
    Днепропетровская обл.
    Сообщений
    1,681
    Спасибо Благодарностей отдано 
    2,711
    Спасибо Благодарностей получено 
    170
    Поблагодарили
    130 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Я бы предпочёл более осмысленно вести диалог, помогая желающим научиться писать проги на Обероне для Спека. И только это. Но увы. Обсуждение вылилось в то, во что оно вылилось.

    Если возник вопрос – зачем программировать на Обероне для Спека, если можно на Си? Си популярен. Оберон малоизвестен. Си опробован. Оберон наверняка содержит подводные камни. Когда-нибудь я опишу, возможно, здесь на форуме, как я пришёл к Оберонам, однако пока могу только попросить желающих программировать на Си вместо Оберона не уподобляться господину, который Толстого не читал, но произведения оного ему определённо не нравятся.

    Если сомневаетесь в моей квалификации, надо вспомнить, что моя первая игра для Спека – Tiny Tetri$ на Бейсике и асме – разработана в 1995 году. Это, наверное, должно значить, что Бейсик и асм для меня давно не являются чем-то новым, а раз так, то, наверное, если я говорю о преимуществах Оберона перед Бейсиком, то есть смысл прислушаться, тако же когда я буду говорить об Оберон-разработке для Спека. Хотя я не собираюсь ничего никому навязывать. Бейсик был хорош тем, что его интерпретатор влез в ПЗУ. Это от бедности. Форт там тоже бы красиво смотрелся. Наверно.

    А ещё – есть люди-создатели и люди-потребители. И спектрумисты, как никто, должны понимать между ними разницу. При этом создатель создаёт и делает что-либо доступным, включая идеи, а потребитель обливает всё *****м и кричит ”давай ещё, и побольше”, угнетая и без того хрупкие и чувствительные натуры создателей.
    Последний раз редактировалось GriV; 16.03.2012 в 12:09.

Страница 7 из 18 ПерваяПервая ... 34567891011 ... ПоследняяПоследняя

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. Разработка ZXOOM
    от Andrew771 в разделе Игры
    Ответов: 666
    Последнее: 16.08.2011, 17:22
  2. Разработка ZXOOM
    от Andrew771 в разделе Графика
    Ответов: 666
    Последнее: 16.08.2011, 17:22
  3. Разработка БК-0101-10
    от CodeMaster в разделе БК-0010/0011
    Ответов: 61
    Последнее: 21.04.2011, 21:13
  4. Подскажите пожалуйста, На каких языках пишутся игры.
    от sevol в разделе Программирование
    Ответов: 168
    Последнее: 14.01.2011, 15:42

Ваши права

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