что-то мне все это Объект.Метод vbs напомнило(
что-то мне все это Объект.Метод vbs напомнило(
Только тут это не Объект.Метод, а Библиотека.Процедура. :)
дажеЦитата:
Сообщение от Reobne
G.InitGraph(KD, MD, "");
?
это не среда разработки а fucking shame какой-то..
Не согласен, и вот почему. Допустим, есть две библиотеки с одноимёнными процедурами. Как их использовать вместе?
В Си это проблема, иногда даже трудно устранимая (если наложились стандартные имена, их нельзя переопределить ввиду невмешательства в сторонний код и т.д.)
В Дельфи это можно сделать так:
ИмяМодуля.ИмяПроцедуры (ИмяМодуля необязательно, и только для уточнения из какого именно модуля брать. Возникает вопрос: из какого будет браться, если ИмяМодуля опущено? Это совсем неочевидный момент).
В Обероне имеем обязательную квалификацию, но квалификатор ИмяМодуля можно сокращать даже до однобуквенного алиаса. При этом сразу видно из какого модуля пришла сущность. Это чрезвычайно удобно.
Могу ещё сказать, что вопросы привычности очень влияют на такого рода мнения. Никого не хочу обидеть, просто наблюдайте за собой.
Reobne, спасибо. Что-то по кругу есть в Basic, писано на Си и неоптимально. А ещё помню у меня где-то завалялась процедурка быстрого круга на асме, разрешающая рисовать круги, которые могут выйти за пределы экрана, могу подкинуть.
На это отвечу отдельно. Что есть “живой язык”.Цитата:
Сообщение от Q-Master
Уточняется ли Оберон по сей день? Да. Восьмидесятилетный дедушка Вирт охотно переписывается по поводу Оберона, кстати, считая Оберон своим основным достижением на поприще информатики. Не только как дисциплину программирования, но и как подходящее средство для реализации сложных проектов маленькими коллективами.
Появляются ли новые компиляторы Оберона? Да. Например, AyaCompiler и OberonJS.
Используется ли Оберон в образовании? Да, например, см. проект Информатика 21.
Есть ли современные диалекты Оберона? Да. Например, Компонентный Паскаль.
Разрабатывается ли коммерческий софт на Обероне? Безусловно. И что? Язык жив пока помогает решать задачи. Для меня мёртв C#. По той же причине. Я его не использую.
Не понимаю движухи вокруг осинового кола, вбиваемого в грудь Паскаля. Это эпоха. Половина моего любимого софта написана на Delphi – Total Commander, KMPlayer, RNQ. Это живой, развивающийся софт. Может у сишников только одна радость в жизни, кроме зарплаты конечно, – хоронить Паскаль? Я могу это понять как излияние чувства глубокой неполноценности тех средств, с которыми программисты вынуждены работать исключительно потому, что за это платят.
Глупо отбрасывать эту эпоху, особенно если ты выскочка, прочитавший пару книг про "C# за 21 день". Кстати, для подобных пассажиров как раз и характерны подобные высказывания. Опытные же программеры обычно воздерживаются от них, особенно если не в курсе. Когда я упомянул в разговоре с А.Боковиковым Оберон и сказал, что побочным эффектом от переноса библиотеки ACL на Оберон будет появление 64-битной версии – он начал распрашивать. И признался, что ничего не знает об этом языке. А это старый программер, начинал сто лет назад.
Оберон – это квинтэссенция Паскаля, Дельфи, Модулы-2. Это отличные красивые языки, которые нисколько не теряют исключительно потому, что появился раздутый язычишка C#, прикреплённый к фирме, переживающей не самые лучшие времена. Точно также и про всякую мудотень с динамической типизацией на основе интерпретации. Да, мы вынуждены это использовать, но не от хорошей же жизни.
XDev же современна, ибо прогрессивна в духе Haxe или Monkey X. Пришло время таких средств.
А бесит именно неадекватное представление об Обероне и огульное его опускание. Я могу лишь пожелать таким пассажирам более благодарных юзеров, чем они сами.
Цитата:
Сообщение от Oleg N. Cher
Фанатизм какой-то. Не скажу за Оберон и FreePascal, но Delphi уже давно пребывает в агонии, а сотни софта на нем пишется потому что есть неимоверная туча унаследованного кода, написанного во времена его - Delphi - расцвета в начале 2000-х. На последние поделки Embarcadero и наследников без слез смотреть невозможно. Многие компании заплатили бы сотни золото за то, чтобы проснуться и обнаружить весь свой код на C или C# вместо Object Pascal. Ну и собственно перенос функционала на C/C# и наблюдается как бы в данный момент. Сам-то по себе паскаль неплох, но Borland/Inprise/Embarcadero сделали с ним то, что в приличном обществе и назвать стыдно. Про скорую смерть M$ и C# тоже все надумано.Цитата:
Сообщение от Oleg N. Cher
Перевожу сообщение на нормальный язык. "Я на Си работаю, поэтому это рулез, потому что я молодец".
Я тебя сурово расстрою. Дельфи с 2009г труп вместе с борландом. В проде без поддержки он умер почти в то-же время. Все конторы которые писали на дельфи под винду перешли либо на жабу, либо на точканет. В продакшне дельфи существуют лишь как поддержка без развития. Программеров на дельфи приблизительно с тех-же пор не делают. Про оберон я вообще от тебя про использование услышал впервые. КОБОЛ и то живее, на нем хотя-бы в проде что-то есть, особенно в США.Цитата:
Сообщение от Oleg N. Cher
Теперь насчет выскочек и 21 дня. Что-то мне кажется что нельзя быть таким категоричным, ибо на твои утверждения (голословные кстати) могут наткнуться на аналогичные в твою сторону уже.
То что ты развиваешь язык это хорошо, но топтаться на месте нельзя и принимать советы куда более опытных чем ты людей тоже стоит. К тому-же советы тебе даются нифига не вредные и местами очень даже полезные. То что ты что-то в них не понимаешь, ну таки прочитай ту самую волшебную книжку про С за 21 день и сразу начнешь все понимать.
Про мой C: Я как собачка, понимаю, но сказать не умею. Тока если со словарем. И да - Delphi был моим языком основным разработки с 1999 по примерно 2009. Все Delphi и RAD-студии пощупал лично и даже в тех местах, что тебе и не снились. Но примерно в 2007-2008 году пришло понимание, что Delphi умерло (после бурного расцвета, признаю), его просрали, и ничего существенного на нем не напишешь, не порвав попу на британский флаг. Жизнь затсавила учить C#.Цитата:
Сообщение от Oleg N. Cher
Но, секундочку, Олег. Во-первых, я ничего не говорю про FreePascal и Lazaurus - знакомство с ним у меня было мимолетным и ответных чувств не возбудило (это нормально). Во-вторых, сам по себе Pascal и Object Pascal - нормальные языки программирования. Не без недостатков, но и Вирт сам это признал, выпустив Модулу и Оберон. По поводу C, признаюсь честно - меня напрягают вот эти вот выражения из одних знаков пунктуации и переменных, выражения Pascal хоть и длиннее, но показательнее. Но адептам и последователям этих языков надо сказать "спасибо" Borland сначала за монополизацию этого языка (соглашусь, в честной конкурентной борьбе, Visual Basic от M$ - *****), а потом заоткровенный просёр этого языка в той же конкурентной борьбе.
PS Недавно попытался скачать и поставить StarTeam (если вы понимаете о чем я), отказался от идеи сразу после получения письма от Borland о доставке триальной лицензии. Могу запостить текст - поржем всей толпой.
Конечно запости.
Нет вопросов, конечно борманы просрали Дельфи. И конечно из-за конъюнктуры не выпустили ТурбоМодулу. И конечно развивали язык, я бы сказал, не совсем в том направлении - можно было бегины убрать как в Модуле/Обероне. Но речь не о том какой сейчас язык позволяет выстроить более короткий путь от денег к вашему кошельку. Ситуация такова, ибо так сложилось.
Остаются языки, которые просто нравятся. Безо всяких шкурных интересов.
Q-Master, твои советы резать исходник на кусочки по функциям и пихать в отдельные файлы - отстой. И я повторю это ещё много раз если будешь упорствовать.
я повторю свой вопрос - каково практическое применение оберона?
Да хоть обповторяйся. Помойка, которая потом еще и кромсается тулзой с тупым приклеиванием заголовка везде - *****. И я повторю это еще много раз если будешь упорствовать.(с) ТыЦитата:
Сообщение от Oleg N. Cher
---------- Post added at 14:15 ---------- Previous post was at 14:14 ----------
Никакого. Это мертвый язык не используемый уже нигде вообще. Софта на нем написанного за последние 20 лет я не видел ни разу. Ни опенсорца, ни коммерческого. На гитхаб ссылках 4 коммитера. Компаний которые его используют - 3 в лучшем случает. Причем все 3 похоже юзают только из серии "так исторически сложилось".Цитата:
Сообщение от denpopov
Ты забыл добавить, что это проблема не очень умных компиляторов Си, которая имеет место.Цитата:
Сообщение от Q-Master
Я не занимаюсь разработкой компиляторов Си. Мне эта проблема также неприятна, как и тебе (надеюсь). Здесь наилучшее, что вообще можно придумать, - это лишить SDCC данного недостатка. Но с этим всё не так просто. Сам жду исправления двух багов SDCC, причём уже долгое время. Но кромсать свои исходники и ставить их раком просто в угоду тупой утилите - *****. (ц) почти ты
попову. Ты мне всё равно не поверишь, так что иди отсюдова родной. Не забывая повторять мантру "а я на асме круче сделаю".
слив защитан. ты даже путно ничо сказать неможешь, повторяя мантру"Оберон!". Кстати, в чятике это слово почти матерное.Цитата:
Сообщение от Oleg N. Cher
Ден, ты тред читаешь или троллишь только? Олег уже отвечал на этот вопрос.Цитата:
Сообщение от denpopov
туплю, наверное. ссылку я не видел и форум не читал.Цитата:
Сообщение от Alex Rider
Просто дело в чем - столкнулся с тем, что алгоритм переписывался на Си и после SDCC вылезло такое, что взглянуть страшно, пришлось перепиливать полученный исходник. вот мне и стало интересно..
попов, у тебя на лбу написано "я обосру любой твой ответ", поэтому как-то не вдохновляет гуглить вместо тебя. А даже если и есть такие фирмы - Q-Master скажет что их четыре штуки, и все неудачники. Сколько их штук - я точно не знаю. Но абсолютно точно знаю, что есть фирмы, использующие Оберон, но не кричащие об этом на всех углах.
Здесь поднят был вопрос о том, что многие фирмы были бы рады, если б их софт был написан на Си/C# вместо Дельфи. У меня риторический вопрос: почему выбор языка программирования для проекта - сродни ставке на лошадиных бегах? Где здесь наука, дисциплина или эстетика, наконец? Кобол архаичен, Оберон же актуален. Оберон это лодочка. Если ты плывёшь на лайнере - ты зависишь от расписания, маршрута или, в конце концов, от благополучия компании-владельца. Я не отрицаю значение лайнеров. Я подчёркиваю необходимость маленьких лодочек, которые можно просмолить в гараже. И выбрав Оберон сегодня - я не буду грызть локти завтра, а смогу добавить в язык ту фишку, которая мне понадобится, без того, чтобы порушить весь каркас. Кстати, хочу подчеркнуть, что 90% семантики C# взято из Дельфи, да и разработчик тот же. Циферка наобум, но всё же.
Черниченка, бубубу, блаблабла.
фу таким быть.
Ответ на этот вопрос - рынок разработчиков.Цитата:
Сообщение от Oleg N. Cher
Это дорого.Цитата:
Сообщение от Oleg N. Cher
Олег, уйми свой бред.Цитата:
Сообщение от Oleg N. Cher
Ты сам лично можешь добавить фичу в Оберон? Добавь тогда умную линковку для ZXDev.Цитата:
Сообщение от Oleg N. Cher
Поскольку ZXDev опирается на SDCC, эта задача - для разработчиков SDCC.
Или же нужно подключить другой бэк-энд (компилятор Си).
Кстати, возможностей смартлинковки, заложенных сейчас в ZXDev, мне хватает с головой. Работать на публику только затем, чтобы меня лишний раз обосрали, - увольте.
---------- Post added at 22:53 ---------- Previous post was at 22:49 ----------
90% семантики императивных языков — общие, о чём заметил Андреас Хейлсберг. Автор (ну или по крайней мере соавтор) Дельфи и C#.Цитата:
Сообщение от Alex Rider
Ссылка.
http://zx.oberon2.ru/forum/viewtopic...99&p=336&#p336
---------- Post added at 22:59 ---------- Previous post was at 22:53 ----------
Alex, там знаешь сколько всего можно добавить. Глаза разбегаются. И добавляю. Почти каждый день. А если ты намереваешься поработать с ZXDev - свяжись приватно, обсудим. Но ведь нет, просто на понт берёшь. Так что я уж буду добавлять в первую очередь то, что нужно мне, а не зачем-то кому-то может быть.
Цитата:
Сообщение от Oleg N. Cher
Это одно и то же?Цитата:
Сообщение от Oleg N. Cher
да брось ты кусателя локтей:) полистал я статьи по ссылке, что ты привел, одни buzz-words и ничо путного. Олегатор не в состоянии даже нагуглить и объяснить, зачем Оберон. Вывод - Оберон для того, чтобы громогласно продемонстрировать, чей писюн толще. а я покидаю этот тред, спец.Олимпиада уже приелась.Цитата:
Сообщение от Alex Rider
Второе высказывание, я бы сказал, даже посуровее.Цитата:
Сообщение от Alex Rider
---------- Post added at 12:24 ---------- Previous post was at 12:04 ----------
Но не дороже, чем переписать проект (возможно, очень большой) на другой язык.Цитата:
Сообщение от Alex RiderЭто дорого.Цитата:
Сообщение от Oleg N. Cher
Контролировать полностью свой рабочий инструментарий, не отдавая эту роль в чужие руки, может иметь свой смысл. Многие ценят Оберон именно за то, что он маленький. В случае изменения коньюнктуры легче переориентировать на другую платформу и т.д. Но это сродни натуральному производству. Да, огород не конкурент магазину, но в деревнях и на дачах люди огородничают. По разным причинам. Кто для души, кто чтобы разнообразить жизнь, а кто - для экономии.
В язык Оберон - не могу. Это парадигма с устоявшимся стандартом. В транслятор - могу. Я уже добавил много фич в Ofront. С добавлением фич в Си-компилятор уже посложнее... Как видишь, я вынужденно завишу от Си-компиляторов, на которые сделал в своё время ставку.Цитата:
Сообщение от Alex Rider
Но не значит, что семантика C# была почерпнута в основном из Delphi.Цитата:
Сообщение от Oleg N. Cher
Это становится дороже когда со средой разработки происходит то, что произошло с Delphi. Ибо пользователи хотят 64 бита, .NET, новые технологии, а Delphi и RAD Studio долго этого не предоставляют. А заказчик голосует рублем, и, если он проголосует против, не на что будет поддерживать проект. Поэтому переписать в грамотно развивающиемся IDE даже на другом языке затратно, но спасает бизнес. Иначе получается вот это:Цитата:
Сообщение от Oleg N. Cher
Цитата:
Сообщение от Oleg N. Cher
Поддерживать IDE для разработки тоже дорого. Одно дело, когда разработка идет на уникальном самопридуманном языке или наборе библиотек (например, конфигурационный скрипт), другое дело - поддерживать свою IDE для давно существующего языка. Для ZXDev можно же взять C-компилятор для Z80 с открытым кодом и сделать свою ветку со всеми хотелками? Да, но тяжело (в коммерческих условиях это то, что называется "дорого").Цитата:
Сообщение от Oleg N. Cher
Q-Master, если хочешь пощупать язык, попробуй Vishap Oberon Compiler (voc):Цитата:
Сообщение от Q-Master
Свободный (GPLv3) компилятор языка Оберон-2 для GNU/Linux (x86-64, x86, ppc, armv{4-7}). Сделан на базе транслятора Ofront, так что может быть легко перенесён на другие платформы, для которых есть транслятор Си. Содержит набор библиотек, портированных с других реализаций Оберона: ooc, POW!, ETH Oberon, Ulm Oberon System
http://oberon.vishap.am
Возможно на ppc пойдёт Ulm Oberon System?
Oberon compiler for multiple architecture including m68k, SPARC, and x86 under UNIX and GNU/Linux + Ulm Oberon Library
http://www.mathematik.uni-ulm.de/oberon/
Также вот XOberon. Это целая ОС, внутри - компилятор Оберона для ppc:
ОС реального времени для процессоров архитектуры PowerPC, написанная на языке Оберон-2. Разработка Швейцарского института робототехники (EHTZ).
http://www.ifr.mavt.ethz.ch/research/xoberon/
С ZXDev же - увы - никто не будет проделывать такой объём работы, чтобы ты просто "посмотрел". Если тебя интересует Оберон для ZX - должен делать какие-то шаги сам. Я могу только помочь советом. Например, начни с транслятора Ofront, собери его для ppc, потесть. Потом прикрути к нему SDCC, собранный для ppc. Удивись как всё вместе работает. Библиотеками можешь пока поживиться с проекта ZXDev. Остальное - то, что на базе BlackBox Component Builder - это IDE, раскраска синтаксиса. Оно может и не нужно тебе. Редактор прикрутишь другой.
Побольше личных усилий, никто не обязан напрягаться только ради того, чтобы ты"обосрал""посмотрел". Зато, сделав личные усилия, ты начнёшь ценить то, во что вложил их. А то, я смотрю, мои усилия тебя как-то не впечатляют.
---------- Post added at 15:26 ---------- Previous post was at 13:58 ----------
Q-Master, в крайнем случае, если не сладишь с Ulm или voc, - можешь посмотреть GPCP (Gardens Point Component Pascal) - диалект (надмножество) Оберона-2:
http://gpcp.codeplex.com
Он для JVM, но это ведь не проблема. Для твоего ppc есть реализация JVM?
А вот инструкция как квикстартовать GPCP под Linux, правда, я пробовал под Ubuntu, а не Debian, но ничего, принцип тот же.
Как работать с Gardens Point Component Pascal под Linux
10%, и то если за уши притягивать.Цитата:
Сообщение от Oleg N. Cher
C# - это джава, в которой поправили все корявости и вычистили костыли.
Если не нужно париться за производительность, то C# - это просто идеальнейший язык. Компилируемый, строго типизированный (и с выводом типов!), с интроспекцией, с широким применением функционального подхода (о лямбды, как мне вас в джаве не хватает!), с фичами для написания параллельного кода... Безумно красивый и лаконичный язык. Ничего общего с уродливым Delphi.
Единственный ЯП, который сравним по красоте - это эппловский Swift. И то не факт, т.к. на Свифте я ничего не писал, просто прочёл мануал.
А это получается не "иначе", а "всё время". Потому что любая программа зависит от кучи факторов - от стратегии развития ОС, от парка железа и прихотей заказчика. То, что я для краткости называю "конъюнктура". Однако очень заманчиво иметь больше возможностей чтобы контролировать успешность своего проекта.Цитата:
Сообщение от Alex RiderИначе получается вот это:Цитата:
Сообщение от Oleg N. Cher
Можно конечно. Но я соразмерил силы и решил не морочиться с кодогенерацией. Кстати, разработкой SDCC уже много лет занимается больше 20 основных разработчиков, не считая тех юзеров, кто не ленится давать баг-репорты. Оптимизирующий компилятор Си - это слишком сложный проект для маленьких коллективов.Цитата:
Сообщение от Alex Rider
Ну бог с вами, пусть будет 10. ;)Цитата:
Сообщение от Eltaron
Ну так и появился позже ведь. И в пику джаве.Цитата:
Сообщение от Eltaron
Кстати, и джава ведь во многом слизана с Оберона. Да-да, семантика императивных языков - чудная вещь в своей повторимости. Кстати, а что такое лямбды что без них жить нельзя? Это как дворецкий, отгоняющий мух и наливающий чай, от услуг которого трудно отказаться? Или как пара гантелей, которая держит в форме твою мускулатуру, но требует ежедневно напряга?
Это новый способ мышления. Возможность изящно описать действие, которое нужно сделать с каким-то списком. Простейшая вещь, которая даёт возможность писать в одну строку то, что без неё писалось бы в 10.Цитата:
Сообщение от Oleg N. Cher
Найти в массиве объект с Id=58
list.First(i => i.Id == 58);
Отсортировать список людей по фамилии, взять первых трех
list.OrderBy(p => p.LastName).Take(3)
Сконвертировать массив строк в массив чисел
list.Select(p => int.Parse(p))
Любая степень вложенности. Найти всех солдат, у которых есть Heavy Laser
list.Where(p => p.Backpack.Any(i => i.Type == Weapon.HeavyLaser))
В тыщу раз короче, чем вложенные циклы+вспомогательные массивы, и в миллион раз понятней.
Это не какая-то свистелка-перделка, это ключевая фича, без которой современный язык не может считаться полноценным. Лямбды есть везде. В C#, python, ruby, C++11. В джаве только нету.
Спасибо за такое объяснение.
А может быть это достигнуто библиотечным путём? Подобно тому как транслятор функционального или логического ЯП может быть написан на императивном.
Ведь пользуемся мы языком запросов SQL. А программа на Обероне, императивная, описывает, например, данные, т.е. по сути является декларативной.
Нас здесь может смущать только последовательность исполнения. Кстати, на Обероне возможно и мета-программирование. Об этом есть статья Йозефа Темпла, кстати, автора транслятора Ofront.Код:BEGIN (* Декларируем команды в конфигурационном файле: *)
Lad.Section("[Desktop]");
(*============================================*)
Lad.CmdBool("UseRecycleBin", IsRecycleBin, SetRecycleBin,
Win.IsWinVer( {Win2000..Win2003} ), {Lad.NeedLogOff}
);
...
END Desktop.
Ага. А если нужно париться за производительность, то C# - тоже идеальнейший язык.Цитата:
Сообщение от Eltaron
С первой частью я соглашусь. Действительно, хочется верить, что начатый проект будет всегда развиваться по мере появления новых технологий, и эти технологии будут поддержаны инструментарием. До Delphi 7 включительно у Object Pascal все было с этим хорошо. А вот вторая часть - спорная. Хватит ли сил чтобы поддерживать инструментарий в темпе развития технологий? У Oracle и Microsoft пока хватает, Borland показал, что не справился. Ясно, что, если загнется Microsoft, миллиарды производителей ПО будут мечтать, чтобы их код завтра утром магическим образом перевелся на Java или кросс-платформенную версию C++. В этом смысле, конечно, хорошо иметь "свое". Особенно, если это "свое" не раздуто до размеров слона и поддерживаемо даже в ограниченных условиях. но, повторюсь, стоят ли инструменты коммерческой разработки того, чтобы разрабатывать и поддерживать их самостоятельно? Что будет с проектом если он отстанет от технологий?Цитата:
Сообщение от Oleg N. Cher
Ага. Он делается как хобби. Для коммерческого применения есть много хороших оптимизирующих компиляторов C, которые и эффективнее, и выходят дешевле.Цитата:
Сообщение от Oleg N. Cher
В терминах Pascal-подобных языков лямбда-выражение - это возможность записать выражение процедурного типа вместе с телом самой процедуры не присваивая его переменной процедурного типа, и, например, передать его в качестве параметра процедуры. В основном используется для передачи алгоритмов в процедуры и назначения в качестве обработчиков событий не процедур, а непосредственно алгоритмов. Очень удобно, лаконично и наглядно.Цитата:
Сообщение от Oleg N. Cher
---------- Post added at 22:48 ---------- Previous post was at 22:46 ----------
Нет, для этого язык должен поддерживать запись выражений процедурного типа вместе с телом процедуры.Цитата:
Сообщение от Oleg N. Cher
Значит это может быть достигнуто путём использования встроенного интерпретатора, но написанного библиотечным способом. Я начинаю думать, что лямбда-исчисление доступно для Оберона. Вот смотрите, возьмём для примера BlackBox Component Builder. В нём есть подсистема Dev, содержащая компилятор Компонентного Паскаля. Он вызывается с помощью команды активации компиляции из меню. Не составит никакой проблемы вызывать компилятор из своего собственного модуля. Не составит и никакой проблемы переориентировать компилятор брать входной текст (на Компонентном Паскале) не из текстового окна, а прямо из вызывающего кода. Это может выглядеть так (код условный):
Данный подход конечно пользуется компилятором и ядром, но зато - никакой интерпретации.Код:MODULE Lambda;
IMPORT Dev, Kernel;
CONST
MyCode = "MODULE MyCode; IMPORT Out; BEGIN Out.String('Hello, integrated World!') END MyCode;";
BEGIN
Dev.CompileText(MyCode);
Kernel.LoadModule("MyCode");
Kernel.RunModule("MyCode");
END Lambda.
---------- Post added at 23:42 ---------- Previous post was at 22:10 ----------
Так можно сделать лямбды если они понадобятся оберонщику. Мне пока не понадобились. Наверное я не очень продвинутый.
Просто Дельфи- или Си-программист воспринимает компилятор как нечто совершенно отчуждённое от его личного кода. В Оберон-системе компилятор - такой же компонент, как и любой другой. И точно также ему можно посылать сообщения и получать ответы. Точно так же обстоят дела и с IDE, документами, окнами и любыми другими контролами.
Именно поэтому в Оберон-системе как правило не нужен внутренний скриптинг на другом, отличном от Оберона языке. Т.е. это конечно возможно, но зачем, если Оберона во многом достаточно. И всё это - без использования виртуальной машины. Или с ней, если понадобится.
А указатели на функции в Обероне есть? Скомпилировать в рантайме кусок кода - это одно дело, но его же надо ещё и передать в функцию, выполняющую сортировку или поиск.Цитата:
Сообщение от Oleg N. Cher
В любом случае, когда код записан строкой - он не типобезопасен. Он вообще не безопасен, там и опечатки могут быть, и что угодно ещё. В C# и C++11 очень круто то, что все эти конструкции проверяются ещё на этапе компиляции.
Так в них теряется смысл. Потому что выражение i => i.Id == 58 лаконично и понятно. Ты же не напишешь код запуска компилятора в качестве фактического параметра? Тогда зачем оно вообще нужно? Кстати сказать, лямбда-выражения в основном применяются к generic-коллекциям, без них я тоже от лямбд смысла не вижу.Цитата:
Сообщение от Oleg N. Cher
А мне пока ЯВУ (кроме Бэйсика) для Спектрума не понадобились. Представляю себе свой уровень в сравнении... Тебе не понадобились потому что не пробовал. :)Цитата:
Сообщение от Oleg N. Cher
Общий вопрос:
Как обстоят дела с INTEGER 64bit в языке ОБЕРОН ?
Коим образом можно "перенести" работу с битовыми полями с С на Оберон ?
Как обстоят дела с объединениями ?
union {
u16_t var1;
struct {
u8_t aaa;
u8_t bbb;
}
}
var1 = 0x1122;
tmp = aaa + bbb;
Конечно есть:Цитата:
Сообщение от Eltaron
Код:PROCEDURE Fn(): INTEGER; BEGIN RETURN 0 END Fn;
...
VAR fn: PROCEDURE (): INTEGER;
BEGIN
fn := Fn; ...
...
END ...
Ну собсно обработку ошибок я опустил для упрощения. А так - почему бы не проверить вывод компилятора и не отреагировать соответствующим образом.Цитата:
Сообщение от Eltaron
Я опасаюсь, что ново-программисты будут использовать такое средство как лямбды, для которого конечно можно придумать хорошее применение, втуне. Т.е. не понимая чётко всего механизма. А оно как - компилируется? А потом? Куда-то загружается и запускается? Т.е. вся эта тянучка из компилятора и рантайма присутствует в конечном продукте. И накладные расходы соответствующие. Для сортировки списка или поиска элемента - это уже слишком.
В зависимости от реализации. В стандарте Оберона/Оберона-2 размеры типов не зафиксированы. Традиционно (ETH Oberon, A2/AOS, XDS) INTEGER = 16 бит; LONGINT = 32 бита. Для 64 битов в некоторых реализациях есть тип HUGEINT.Цитата:
Сообщение от AlexG
В Component Pascal, XDev/WinDev INTEGER = 32 бита; LONGINT = 64 бита. Есть ли возможность использовать именно 64-битный INTEGER? В XDev/WinDev - да. Размер всех типов задаётся в специальном файле-конфигураторе Ofront.par, выглядящем примерно так:
Код:CHAR 1 1
BOOLEAN 1 1
SHORTINT 2 2
INTEGER 4 4
LONGINT 8 8
SET 4 4
REAL 4 4
LONGREAL 8 8
PTR 4 4
PROC 4 4
RECORD 1 1
ENDIAN 1 0
Для работы с битовыми полями предлагается тип SET, что во многом снижает потребность в логических операциях AND, OR, XOR. Несмотря на некоторую громоздкость записи, логические операции для целых в Обероне всё-таки можно использовать.Цитата:
Сообщение от AlexG
Вирт Н. SET: Недооцениваемый тип данных и его компиляция для ARM
Объединения в Оберон-парадигме считаются опасным низкоуровневым средством. В некоторых реализациях есть возможность использовать объединения в биндингах (например, в BlackBox).Цитата:
Сообщение от AlexG
Какая альтернатива предлагается для замены объединений? Расширяемые записи.
Оберон строг в проверке типов и на этапе компиляции, и в рантайме. Он спроектирован так чтобы по максимуму обезопасить работу с указателями. Соответственно нет смысла кастить объект типа Son в объект типа Daughter и пытаться работать с полями сына как с полями дочки. Вместо этого применяется охрана типа:Код:TYPE
Father = (*EXTENSIBLE*) RECORD
a, b, c: INTEGER; (* Это общие для всех потомков поля *)
END;
Son = RECORD (Father)
d, e: CHAR; (* Это только данные сына *)
END;
Daughter = RECORD (Father)
d, e: SET; (* Это только данные дочери *)
END;
Я думаю, понятно по аналогии как именно предлагается безопасно работать с расширяемыми записями вместо объединений.Код:obj: POINTER TO Father; (* Это указатель на отца и др.членов семьи *)
BEGIN
IF obj IS Son THEN ... END; (* Проверка того, что это сын *)
WITH obj: Daughter DO (* Гарант того, что объект - дочь *)
(* Если объект не дочь - ловится ошибка исполнения или исключение *)
END
В принципе, мне объединения ещё ни разу не понадобились, кроме как в биндингах к SDL 1.3 (там есть их два штуки).
Хочу подчеркнуть, что Оберон - маленький язык. Если хочется увидеть в нём прямые аналоги всех сишных возможностей, то этого нет. Но зато, например, компилятор ARM Oberon-07 занимает ~ 3 000 строк исходника. OP2 (Oberon Portable Compiler) ~ 10 000 строк.
Так что присуща некоторая аскетичность. Но, в принципе, возможностей хватает, просто нужно слегка перестроить мышление.
Плохой программист будет одинаково плохо использовать возможности любого языка/библиотеки. Бояться тут нечего. Многократно убеждался, что на более простых языках *****кодить можно с большим успехом.Цитата:
Сообщение от Oleg N. Cher
Не, слишком - это написание 20 отдельных процедур (методов) для сортировки массива записей из 20 полей по каждому полю. Про сортировку по нескольким полям и фильтрацию по сложным условиям я молчу. Да, вариант из 20 ветвлений в одном методе для сортировки тоже выглядит нехорошо.Цитата:
Сообщение от Oleg N. Cher
Это, вероятно, есть плюс для маломощных компьютеров.Цитата:
Сообщение от Oleg N. Cher
Опять же, в специфических условиях. На рынке коммерческой разработки это - большой минус. Во-прервых, из-за самого по себе перестроения мышления, во-вторых, из-за большей трудоемкости разработки и поддержки кода, и, как следствие, его удорожания.Цитата:
Сообщение от Oleg N. Cher
Здесь нужно уточнить - смотря какие возможности предоставляет язык. На простом Форте можно написать такое, что убицагалавойапстенку. Оберон строг и надёжен. Он даёт хорошие абстракции, которыми оперирует программист. Массив это точно массив. А не адрес, к которому можно по ссылке обращаться. И т.д.Цитата:
Сообщение от Alex Rider
Зато внутренне выглядеть это будет статически скомпилированным. А не тянущим за собой бог весть какой рантайм. Недостаток этого подхода в том, что программист часто даже не представляет себе сколько слоёв будет задействовано и насколько эффективным будет код. Это просто бич больших систем. Программист не представляет что в них происходит. Нас это конечно устраивает, но только до тех пор пока не появляется ошибка, которую можно искать месяцами. А некоторые ошибки вообще никогда не будут исправлены, просто будут проявляться очень редко у кого.Цитата:
Сообщение от Alex Rider
Я бы сказал, что Оберон - это наиболее простая из современных прослоек между машинными кодами и человеческим мышлением. Притом в сторону человека. Спорить об этом можно, но мы исходим из разных позиций. Тебе надо абы быстро домой, а я занимаюсь свободным творчеством. Вообще очень сложно сравнивать Оберон и C#. Потому что я беру Оберон как нотацию для записи алгоритмов. А ты берёшь C# как готовое и очень проработанное средство для коммерческого программирования. Мы говорим абсолютно на разных языках. И исходя из абсолютно различных потребностей.
Ceres, на котором была запущена первая Оберон-система (ETH Oberon), если я не запамятовал, имел 1 Мб ОЗУ. JVM или .NET в таком объёме вообще не выстрелят. Но плюс не только в экономности. Плюс в простоте и скорости переориентировки. Я упомянул 3 000 строк кода. Допустим, замысел .NET как многоязыковой платформы не вполне удался, а микрософту это и не было особенно нужно. Это действительно так - все используют преимущественно C#. Да, можно писать для .NET и на Компонентном Паскале, но кто это делает? Фактически .NET моноязычен. И C# - язык одной платформы - .NET. Допустим, платформа провалилась. Все в массовом порядке ломанулись переписывать свой код, если он, разумеется, ещё актуален. На язык, который пропихивает какая-то новая фирма, например, гугле. Вместе с тем, появилась новая архитектура, допустим, мобильная, со своим другим языком. Оберонщик со своим кодом просто перепишет свой компилятор Оберона на другую архитектуру. И его код будет актуален. Возможно, это достоинство не покажется тебе таким уж существенным. Но это повышает ценность нашей работы. Она не нивелируется с провалом того слоя, на котором целиком она была выстроена. А слой, на который мы сделали ставку, весьма мал и подъёмен. И даже относительно независим от нижележащей архитектуры.Цитата:
Сообщение от Alex Rider
Я бы подчеркнул, что средства в духе XDev, Haxe и Monkey-X, о которых я упоминал, - это реакция программистов на множество языков, платформ и архитектур. И на их бурную, но недолгую жизнь. Это реакция не огромных фирм, которым надо запустить свою машину, чтобы все потом пришли к ним и работали на их средствах. А они просто определяли дальнейшую стратегию их развития. И пожинали плоды (кто девушку гуляет - тот её и танцует; также и юзверей имеет).
Философия Оберона - ничего лишнего. Если тебе это по вкусу, то это для тебя. Мне это не совсем по вкусу, я не такой большой минималист и очень болезненно воспринимаю урезанность такого диалекта как Оберон-07. Мне он кажется очень сильно минималистичным. Поэтому я взял Оберон-2 и Компонентный Паскаль за основу своего диалекта. И наращиваю его возможностями, которые мне кажутся необходимыми.
Alex'у G, если он хочет слезть с Си, вероятно, лучше подойдёт Modula-2, в которой есть тип BITSET и объединения. Хотя я забыл упомянуть о низкоуровневых возможностях Оберон-реализаций, которые даже не стандартизированы. Всё перечисленное может быть реализовано с их помощью. В первую очередь это конечно возможности низкоуровневого псевдомодуля SYSTEM - SYSTEM.PUT(adr, value), позволяющая заслать по любому адресу простую переменную любого типа. Так что, получив адрес записи с помощью SYSTEM.ADR(rec), мы можем спокойно записывать по любому смещению от него любое значение. Но Оберон не очень поощряет такой стиль. Мне особенно нравится, что низкоуровневые моменты в Обероне обычно очень изолированы от остального кода. И проще отслеживать ошибки в них. А вспомним, основные претензии сишников к Оберону "а тут низя по этому адресу поместить вот этот массив байтов". Конечно низя! Но если очень надо, то мона. ;) Зато когда будешь переписывать это - увидишь что все низкоуровневые приблуды у тебя в одном модуле как-то сами сконцентрировались. И не очень этот модуль и большой. Переписал его - и порядок. А высокоуровневый слой настолько хорошо проработан, что его мало колышет даже разрядность ОС.
Для вкуривания в философию Оберона предлагаю пробежать глазками статьи на сайте compact-programming.narod.ru. Если вставляет - значит тема, иначе не стоит Оберон юзать.
Я, слава богу, не занимаюсь сейчас коммерческим программированием. Так что могу позволить себе делать то, что мне нравится. В отличие от большинства коммерческих программистов-невольников.Цитата:
Сообщение от Alex Rider
Во-первых, форт не так прост и имеет другую парадигму разработки. Во-вторых, хреновй программист и на минималистичном Обероне-07 напишет такое, что дргой программист сломает голову при попытке понять.Цитата:
Сообщение от Oleg N. Cher
А что значит "массив - не адрес"? То, что он всегда в стеке живет, а не в динамической памяти? Ну так это ограничение жесткое, а не благо. Разработчику в 99% должно быть пофиг как организован массив внутри, зато не пофиг на максимально возможный размер этого массива.Цитата:
Сообщение от Oleg N. Cher
Рантайм тянут не лямбда-выражения, это - неотъемлемая часть .NET и Java, дающая много полезных плюшек для коммерческой и любительской разработки. Про скорость разработки этого я уже писал. Про сложность понимания такого кода, думаю, писать не имеет смысла. И да, лямбда-выражения тоже статически компилируются.Цитата:
Сообщение от Oleg N. Cher
Хороший программист представляет.Цитата:
Сообщение от Oleg N. Cher
Не очень понимаю как заворачивание кода в метод компилятором дает дополнительные поводы для ошибок. Зато представляю себе что такое дебажить "рыхлый" и многословный код и насколько это сложнее отладки лаконичного кода.Цитата:
Сообщение от Oleg N. Cher
Простая технически - слоглашусь. Простая для эффективной разработки - вряд ли.Цитата:
Сообщение от Oleg N. Cher
Оно и то, и то есть нотация для записи алгоритмов. Но да, я соглашусь, что C# удобнее для быстрой и дешевой коммерческой разработки. А для души можно и на Brainfuck писать, это не принципиально.Цитата:
Сообщение от Oleg N. Cher
Я согласен, что языки с виртуальными машинами для "больших" систем.Цитата:
Сообщение от Oleg N. Cher
Наличие дестяков .NET-языков (в том числе, и детищ Borland с о.NETчиванеим VCL) как бы опровергает этот факт. Micfosort'у надо, чтобы покупали Visual Studio.Цитата:
Сообщение от Oleg N. Cher
Ну как минимум VB.NET- и Object Pascal-проекты достаточно популярны.Цитата:
Сообщение от Oleg N. Cher
Да, подобная штука случилась с Delphi и создала проблему разработчикам. Но у Delphi не было пригодных для использования аналогов. Гарантировать, что Windows + .NET + C# не загнется, конечно, не могу, но C#, как удачный язык, имеет не одну IDE (в том числе, бесплатные) и работает не для одной платформы, так что шансы напороться на фокус, аналогичный Borland'овскому, существенно ниже.Цитата:
Сообщение от Oleg N. Cher
На данный момент, напомню, ZXDev не компилит из Оберона в машкод. Так что "просто" не переписывается. А компиляция-через-С доступна для любого языка.Цитата:
Сообщение от Oleg N. Cher
C и UNIX как бы опровергают тезис про "бурную, но недолгую жизнь" всех без исключения платформ и языков.Цитата:
Сообщение от Oleg N. Cher
Означает ли это, что семейство Оберон-подобных языков древовидно, при этом код на языках с "соседних" уровней несовместим?Цитата:
Сообщение от Oleg N. Cher
Ну, если ты не живешь на наследство богатого дяди, то тебе приходится зарабатывать чем-то деньги и тоже быть невольником. Меня лично разует тот факт, что мое хобби и работа находятся в одной плоскости. Может быть, я бы с радостью писал по работе на ассемблере Z80, но увы, не могу. При этом и я, и работодатель, и заказчики как правило выбирают для разработки наиболее подходящий для задачи язык, а не тот, который знает некий Вася Пупкин, принимающий решенияЦитата:
Сообщение от Oleg N. Cher
Мне немного непонятно ради чего ты тратишь время на наш диалог. Либо "хочу лучше узнать Оберон", тогда почему бы чего-нить про него не прочитать? Либо "навожу порядок в мозгах Oleg'а N. Cher'а, которые мне кажутся вывихнутыми, но зато публика меня читает". Но да ладно, продолжаем.
Прост он, прост. Относительно. Впрочем, про Форт можешь не рассказывать, я на нём довольно много программировал в своё время. Но посыл тот же - императив и поверх уже - чего угодно другое. При ацком (и в смысле простоты тоже) синтаксисе.Цитата:
Сообщение от Alex Rider
Это всё верно, но на простом Обероне-07 ему будет сделать это трудновато. Я скажу страшные для половины читающих пост вещи. Там возвращение из процедуры возможно только в конце. Из цикла выйти нельзя. То есть иначе как выполнив условие контракта - пост- или предусловие. И т.п. Но философии и подоплёки всего этого касаться, пожалуй, не будем.Цитата:
Сообщение от Alex Rider
Позволь простой пример. Сишник пишет:
Это парадигма Си. И половина читающих этот пост сишников будет с умилением радоваться возможностям такого кодинга - потому что это свобода. Как на асме. На Обероне без импорта псевдомодуля SYSTEM нельзя так сделать. Недостаток? С точки зрения сишника - огромный.Код:void fn() {
int *a; a = 1234; *a = 1234; // я выстрелил себе в ногу - ура!
}
А почему Си не взлетел для веб-программирования? Наверное потому что строки в нём не так удобно обрабатывать? Да нет, ничего подобного. Потому что стиль такого кодинга, каковой показан выше, прочно вгрызся в эту парадигму. Менять ничего нельзя, исправлять-дополнять - тоже. Совместимость важна. Комом растут возможности. Есть, правда, повод откреститься от части устаревших средств с выходом нового стандарта, но и здесь есть проблемы. Мне в связи с этим нравится подход Оберон-парадигмы. Подмножество Оберон-1 - общее для Компонентного Паскаля, Активного Оберона, Oberon-X и ещё пары меньше известных диалектов. Соответственно, модуль на первом Обероне - кандидат на переносимость между диалектами. Нужны возможности - позиционируем новый диалект с полной или частичной поддержкой какого-то из существующих. Всё делается чётко под задачи. Ненужные, опасные устаревшие, возможности исчезают из языка. Про переписывание программ я знаю, но язык остаётся живым, а не покрывается плесенью, а как же.
Так вот для веб-программирования важна безопасность. Чтобы ошибка кодера веб-сайта не завешивала намертво комп посетителя сайта. И чтобы злонамеренно не тырили его данные. Нужны ограниченные языки. Привносится виртуализация, это более или менее понятно. Как бы можно было сделать на Обероне? Очень просто - запретить приходящим из инета модулям импортировать SYSTEM, а в качестве обвязки - разрешить только безопасные средства, препятствующие вредоносной деятельности. Если нужно ограничить память под работу этого модуля - опять же, нет проблем - в ядре прописывается квота.
Это только один пример того как Оберон предвосхитил своё время. Это было более 25 лет назад, и возможности, которые вы сейчас мне нахваливаете в жаве и .нет, не казались такими уж нужными, но, тем не менее, в Обероне уже были.
Неверно.Цитата:
Сообщение от Alex Rider
Живёт он и в динамической если динамически выделен, и в статической - если статически. Массив не адрес - в понимании программиста. Адрес массива получить легче лёгкого. Я уже писал про SYSTEM.ADR, так оно для этого хорошо подходит. Массив не адрес в том смысле, что в голове у разработчика нету путаницы передачи по ссылке или же указателя.
И конечно же разработчику на Обероне пофиг как организован массив внутри, зато максимально возможный размер массива он может получить с помощью:
LEN(mas)
Пофигу ему и какая модель вызова у функций, и инлайнятся они или нет - это низкоуровневые особенности, пусть они лучше колышут компилятор. Впрочем, я слегка лукавлю.
Про brainf*ck не будем, мы про языки для разработки, а не для выноса мозга.
Да распрекраснейший в мире программист не представляет в какой именно момент поступит прерывание. Тебя никогда не удивляла логика работы твоего кода по мере его отладки? О, тогда ладно. ;)Цитата:
Сообщение от Alex Rider
Твоя "эффективная" разработка - она в первую очередь в той среде, в которой ты умеешь работать. Ручаюсь, я освою IDE сишарпов куда быстрее, чем ты интерфейс ETH Oberon. ;) Оберон меня положительно удивлял, а иногда даже очень сильно. Просто я до этого на Си и Дельфи много работал. Удивлял не тем, что автодополнял в текстовый редактор окончание метода, а тем, что избавлял от таких ошибок, которые я раньше ловил, бывало, целую неделю. При всей своей непритязательности - разрыв между средствами огромный - я понимаю что Оберон - это ядро, для насаживания на него дальнейших возможностей. Ядро моего идеального императивного языка. Оно минимально конечно, но в этом и минусы, и плюсы. Я сейчас имел ввиду, скорее, не Оберон, а Компонентный Паскаль.Цитата:
Сообщение от Alex Rider
Ну конечно. На Обероне нет такого огромного количества компонентов и исходников, такого большого сообщества и поддержки фирм. Но это не так важно для хобби. Можно кое-что сделать самому и получить эстетическое удовольствие.Цитата:
Сообщение от Alex Rider
Да знаю я про эти языки. Однако кого ни спрошу - на C# строгает. Ничего другого не приемлют. Даже в связке с C#. А кто-то из шарпачей сказал, что C# идеально использует возможности рантайма .NET, другим языкам это вроде как не очень удаётся.Цитата:
Сообщение от Alex Rider
По моему скромному мнению Дельфи это замечательная среда разработки. При этом я имею ввиду где-то Дельфи 6-7. Туча недостатков, некроссплатформенный. Потом правда это маленько поправили в FreePascal. Но этот Титаник всё-таки слишком огромен. Я делал на нём софт для клиентов и остался удовлетворён. Быстро работается, удобно, много информации. Но переориентировать его не так было просто. Оберон (опять Компонентный Паскаль) - сильно проще. Поэтому моя ставка - на него. Но с Дельфи - масса общего, очень. Просто сильно уменьшенный язык.Цитата:
Сообщение от Alex Rider
Можно интимный вопрос? ;) Тебе не всё равно каким образом получается там машкод? "Раз не натив, значит смотреть не буду" - позиция понятна, даже с сочувствием. Но я по правде говоря сильно надеялся на поддержку. А так - приходится всё делать самому. Направление ZXDev я сейчас почти и не трогаю. Может ковырну, если будет настроение. Не нужно никому. Скукота.Цитата:
Сообщение от Alex Rider
А кто-то пробовал? И поясни, пожалуйста, смысл заниматься такой работой для получения компилятора, который делает то, что умеет SDCC, только намного хуже. К коду придирок будет столько - все в какашках утонут. Зато прямо в натив, та божежмой какое щастье! ;)Цитата:
Сообщение от Alex Rider
Ну это как сказать.Цитата:
Сообщение от Alex Rider
Как бы UNIX менялся. И Си менялся. Это просто название осталось. Сам предмет же - менялся много раз. И на него делали и продолжают делать ставку, делают надмножества - Титаники. C++, Objective C. Нормально получается, многим ничего лучше и не нужно. Но я читал хорошие статьи, разговаривал с людьми, писал код и думал. Я хорошо понимаю недостатки Си. И говорю об этом не затем, чтобы сказали что я голословно обсираю Си. Нет. Си неплох. Просто на своём месте.Цитата:
Сообщение от Alex Rider
UNIX просто был раньше других портабельной ОС. Впрочем, взять Linux. Что было бы если бы Торвальдса заинтересовал, например, ETH Oberon? Ничего не было бы. Торвальдс сделал ставку на юзеров в первую очередь. А даже не на программеров. ZXDev сделал ставку на ностальгирующих кодеров, 90% из которых ничего кроме асма не признаёт, а другие просто уже не кодят. Да и первые тоже. Короче говоря, делай всё сам и нам показывай. Да без короны. Иначе не так поймём. Господа, я не хочу ничего делать, делайте сами, если вам нужно.
Да их не так и много, диалектов. Да и про совместимость мало кто думает. Ну вот зачем тебе совместимость твоего проекта с AOS если ты делаешь проект под ядро BlackBox? Она возможна, но зачем трудиться понапрасну. Есть веб-сервер O3, совместимый с GPCP и BlackBox, собирается под Windows, .NET и JVM (если бы мне пришлось разрабатывать подобный проект - я бы выбрал только Компонентный Паскаль - не знаю ничего аналогичного).Цитата:
Сообщение от Alex Rider
Но вот зато ковырялся в исходниках на Амига-Обероне, парочку скомпилил в XDev без проблем. Правда, пришлось кое-что по мелочёвке поменять - & вместо AND, например. Хотя размер типов разный. Вобщем, о формальной совместимости между диалектами речи нет. Они и создавались обычно под разные нужды. И средства для биндингов в них реализованы разные. GPCP, к примеру, нужно биндить под JVM .class-ы, а XDS - под WinAPI.
Богатого дяди нет, не завидуй. ;) Работаю тоже по компьютерной части, но без программинга. Можно сказать "что-то типа админ". Думаю, если бы работал программистом - не было бы духу на хобби, все мозговые ресурсы забирали бы рабочие проекты. Свойство профессии - трудно переключаться между разными проектами.Цитата:
Сообщение от Alex Rider
Хорошо если хоть программисты выбирают, а не дядя манагер, который краем уха слышал, что M$ - это круто.Цитата:
Сообщение от Alex Rider