`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Крепость на руинах FORTRAN

Статья опубликована в №21 (638) от 3 июня

+22
голоса

«Как, опять еще один язык программирования?» – возмутится читатель. Увы. Вернее да. Но действительно еще один язык. Правда, более чем заслуживающий самого пристального внимания. Потому что по количеству и уровню новых (для «языкостроения») идей, похоже, равных ему пока нет.

Крепость на руинах FORTRAN
В традиционной для программистов разных платформ среде редактора Emacs код Fortress выглядит более чем консервативно и без всяких неожиданностей

Нет ничего более интересного, чем внимательно разбираться с «очевидными вопросами». Хотя бы потому, что ответы на эти вопросы чаще всего далеко не очевидны. К очевидным можно отнести и вопрос «Что такое язык программирования?». На самом деле язык программирования является всего лишь одной разновидностью программных инструментов, которые предоставляют пользователю некоторые интерфейсы к низкоуровневым возможностям вычислительной машины. Не больше и не меньше. Соответственно, когда мы говорим о программных инструментах, мы должны сразу интересоваться самыми общими характеристиками предоставляемых ими интерфейсов – их особенностями и природой, удобством для пользователя (не обязательно человека, кстати), и наконец, скрывающейся за интерфейсом функциональностью и способом ее реализации. Так как язык программирования – инструмент специфический, эти общие вопросы для него можно уточнить: каковы структура и смысл языковых конструкций (синтаксис и семантика соответственно), насколько эффективны эти конструкции при разработке программ (очевидно, что это в немалой мере субъективная оценка), и наконец, какими способами, приемами и кодом реализована главная функциональность языка как инструмента, т. е. транслятор. Собственно говоря, этими вопросами мы очертили, если так можно выразиться, и «области повышенного интереса», в которых следует искать новизну в «языкостроении». К слову, этот неформальный термин, также несмотря на очевидность (синтетические языки именно «строятся»), скрывает в себе еще одну область повышенного интереса. Но об этом чуть позже.

Несмотря на изобилие языков, существенных событий во всех указанных выше областях повышенного интереса было совсем не много. Первым «взрывом» в синтаксисе и семантике в свое время прогремел знаменитый FORTRAN – он приблизил форму записи и смысл математических выражений на языке программирования к привычным для математиков, инженеров, физиков. Удивительно, но по прошествии стольких лет ничего более существенного в этом смысле сделано не было. Так, множество «интерфейсных символов» по сей день в подавляющем большинстве языков ограничено куцым множеством ASCII (для чего в 2008 г. трудно придумать оправдание), что существенно ограничивает близость форм записи в языке программирования к принятым, например, в прикладных науках. И если современные текстовые процессоры (скажем, Microsoft Word 2007) уже позволяют с помощью множества соответствующих символов Unicode великолепно работать, в частности, с математическими формулами, в языках программирования подобная «роскошь» остается недоступной. У кого-то, естественно, возникнет вопрос – а так ли это важно? Это важно. Хотя бы потому, что следующее утверждение очевидно – сокращение дистанции между языком спецификаций и языком реализации всегда означает уменьшение количества источников ошибок. А язык спецификаций – это естественный для прикладных специалистов язык, в том числе и формулы в их естественном, математическом представлении. Странно, что со времен FORTRAN о такой очевидной вещи мало кто задумывался, тем более когда речь шла о разработке систем повышенной надежности, например бортового программного обеспечения в авиации, где формул, мягко говоря, немало, они далеко не уровня школьного учебника, и в большом проекте только проверка соответствий между математической записью и ее аналогом на языке программирования – задача очень далекая от тривиальности (а значит, весьма недешева в решении).

Крепость на руинах FORTRAN
А это уже действительно нечто новое даже в названии – утилита «рендеринга» исходных текстов Fortify

Вторым «взрывом» стали языки Lisp и Algol, появившиеся примерно в одно время. Они принесли и новые механизмы реализации функциональности, и новые синтаксические и семантические конструкции. Рекурсивные функции и процедуры в них поддерживались механизмом управления памятью, основанном на концепции стека. Lisp пополнил перечень новых программистских конструкций высокоуровневыми функциями (higher-order functions) – способными принимать в качестве аргументов другие функции и возвращать результатом функции, а к механизмам добавил сборщик мусора (тут уместно напомнить, что речь идет о 1960-х годах). Algol же в программистский арсенал привнес развитую систему типов и способы структурирования данных и программ.

После Lisp и Algol наступило продолжительное затишье. Его нарушил язык C реализацией идеи максимального отделения «сугубо языкового ядра» от чуть ли не всех разновидностей функциональности, ранее считавшихся сугубо языковой прерогативой. Язык C «освободился» от операций ввода-вывода, математических функций, операций со строками, в общем, чуть ли не от всего, все это было вынесено в независимые, по большому счету, от языка библиотеки. Идея оказалась удивительно плодотворной и во многом предопределила высочайшую живучесть C.

Пожалуй, последними серьезными событиями «языкостроения» стали определяемые программистом типы (классы) и системы типов.

Несмотря на кажущуюся скудность, этот перечень нововведений стал основой множества вариаций, модификаций и дальнейших развитий базовых идей. Настолько большого множества, что, кажется, удивить чем-то новым в «еще одном языке программирования» (YAPL уже стала расхожей аббревиатурой, Yet Another Programming Language) трудно. Но, похоже, разработчикам из Sun Microsystems это удалось.

Fortress

Первое, что мы сделаем, – забудем о позиционировании. В свое время язык C позиционировался как язык системного программирования, а стал чуть ли не самым универсальным, Simula и CLU – как специфические инструменты моделирования систем, а превратились в «полигоны», на которых обкатывались основные идеи и приемы объектно-ориентированного программирования. Так что мы не будем обращать внимание на тот факт, что Fortress («крепость») разрабатывается при частичном финансировании DARPA для замены знаменитого FORTRAN в высокопроизводительных научных вычислениях. Из нашего небольшого обзора будет понятно, почему.

Основная задача проекта Fortress – создание одновременно перспективного инструмента и живучей технологии, способной не просто сохранять актуальность, а и повышать ее на продолжительном (по меркам индустрии) временном интервале начиная с 2010 г. Для этого разработчики Fortress предусмотрели многое. В том числе и максимальную открытость проекта – и спецификации языка, и его реализация доступны всем желающим на основании одной из самых либеральных лицензий (BSD). Но все же главное, что должно обеспечить достижение цели, – идеи, заложенные в язык.

Один из девизов команды создателей Fortress – «Сделать с FORTRAN то, что Java сделала с языком C». А именно, снизить или полностью избавиться от рисков так называемых «глупых ошибок» (таких как печально знаменитый выход индекса массива за допустимые границы), максимально на инструментальном уровне поддержать и безопасность создаваемых с помощью языка программных систем (это обширная задача, решения которой включают в себя и низкоуровневые механизмы, такие как безопасная система типов), и многопотоковое и параллельное программирование. В этих больше девизах, чем задачах, ничего «взрывного», конечно, нет. Но вот главная идея, которая призвана обеспечить или соответствие этому (если вы склонны воспринимать вышесказанное как девизы), или решение этого (если вам кажется, что перечисленное все-таки больше является задачами), в любом случае очень интересна. Потому что главная идея Fortress – не создавать сверхъязык (как это было, например, с Ada), а разработать набор механизмов, позволяющих «выращивать» язык (точнее, даже множество языков с общими принципами) эволюционным путем. Подобных задач в «языкостроении» пока никто перед собой не ставил. А если учесть, что в проекте Fortress постановщик задачи – Гай Стил (Guy Steele), признанный мастер «языкостроения» (а также просто культовая персона, автор оригинальной системы команд редактора Emacs и параллельной версии языка Lisp, разработчик первого порта системы TeX, редактор знаменитого хакерского словаря «The Hacker's Dictionary», один из самых влиятельных специалистов в процессе стандартизации языка C и т. д.), заслуги которого отмечены престижнейшей в программировании наградой журнала Dr. Dobbs, и что Fortress развивается очень быстро, проект становится особо интересным.

Стратегия реализации главной идеи – доведенная до совершенства стратегия разработчиков языка C: «там, где возможно реализацию любой языковой конструкции выносить в библиотеку, выносить ее в библиотеку». Это означает, что не только сложные типы, такие как списки, векторы и множества, реализуются в Fortress на уровне библиотек, но и близкие к традиционным низкоуровневым целые числа или, например, числа с плавающей точкой, имеющие физическую размерность (да, в Fortress 20.2 kg – это отдельный тип, «число с плавающей точкой, размерность – килограммы»).

На низких, более близких практикующему программисту уровнях, Fortress строится на двух базовых концепциях – объекта и особенности (trait). Объект в Fortress – весьма близкое к традиционному объединение множеств полей (fields) и методов. Особенность (trait) же для большинства программистов – понятие новое. Оно заимствовано из малораспространенного языка Self и обозначает именованную программную конструкцию, определяющую параметризованный набор методов. Потребность в такой конструкции лучше всего описывается следующей фразой: «Множественное наследование – отличный механизм, но пристойных реализаций его не существует». Хоть она и прозвучала на международной конференции по объектно-ориентированному программированию, системам языкам и приложениям OOPSLA в далеком 1987 г., с тех пор, по сути, ничего не изменилось – в большинстве современных ОО-языков от множественного наследования отказались.

Итак, особенность (trait) – это: множество методов, реализующих некоторые аспекты поведения, причем сами методы могут являться параметром особенности; особенность не может специфицировать переменных и ни один ее метод не может обращаться к переменным напрямую, классы и особенности могут конструироваться из особенностей способом композиции, при этом семантика класса не зависит от того, как описаны его методы – традиционно ли, непосредственно в классе, или набором особенностей; точно так же особенности, составленные из других особенностей, ничем не отличаются от отдельно описанного множества всех их методов. Теория особенностей очень хорошо и строго проработана, и с ее помощью сравнительно давно доказано превосходство такого подхода над традиционными механизмами наследования, механизм поддержки особенностей реализован для многих языков программирования (в частности, для Perl 5, Squeak/Smalltalk, C#, Scala).

К низкоуровневым свойствам Fortress следует отнести полноценную поддержку Unicode. Речь идет не о возможности оперировать в программах Unicode-символами и их множествами (в 2008 г. называть ее полноценной не поворачивается язык), а о фундаментальном базировании всего языка на всем множестве символов Unicode c поддержкой ряда правил форматирования, предусмотренных для отдельных Unicode-подмножеств (в первую очередь математического).

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

Чтобы на ознакомительном уровне попробовать Fortress «на вкус», давайте рассмотрим решение следующей задачи – вывести на устройство вывода две повторяющиеся последовательности цифр от 1 до 100, т. е. результатом работы программы должно быть следующее: 1 2 3 ... 99 100 1 2 3 ... 99 100. Можно попробовать решать задачу следующим фрагментом кода на Fortress:

for j <- 1#100 do
print(j " ")
print(j " ")
end

В нем специфическая конструкция 1#100 – так называемый генератор, в общем виде N#M формирующий последовательность целых чисел начиная с N длиной M (в Fortress реализованы разные генераторы, например N:M – последовательность целых чисел от N до M). Остальные конструкции очевидны для знакомых с любым языком программирования и больше похожи на псевдокод. Вот только результат исполнения программы будет более чем неочевидным – случайной от запуска к запуску последовательностью. Дело в том, что все генераторы и циклические конструкции в Fortress по умолчанию автоматически распараллеливаются. Естественно, если необходимо, распараллеливание можно временно (для одной циклической конструкции) отключить с помощью ключевого слова sequential. Если от частного примера перейти к общим принципам языка, Fortress создан так, чтобы программист в явном виде решал не сложную задачу распараллеливания кода, а только контролировал критические к последовательности выполнения фрагменты.

К списку особенностей Fortress следует отнести стрелочный тип (arrow type) и связанный с ним встроенный механизм статического контроля типов с развитым анализом и системой логического вывода. Стрелочный тип в Fortress – статический тип выражения, вычисление которого приводит к результату типа «функция» (что означает – функции в Fortress, как и, например, в Lisp, – высшего порядка). Семантически стрелочный тип – три набора типов, описывающих типы параметров выражения, возвращаемого значения и множества исключительных ситуаций, которые могут быть сгенерированы в ходе исполнения выражения. Синтаксически стрелочный тип имеет довольно очевидную форму. Так, следующая запись означает «функция, принимающая параметры 32-битовое целое и 64-битовое действительное число, возвращающая 64-битовое действительное число и способная генерировать исключительную ситуацию ошибка ввода-вывода»:

f(Z32, R64) -> R64 throws IOFailure

Алгебра стрелочных типов и механизм логического вывода Fortress позволяют статически (до исполнения программы) проверять формальную законность используемых в ней конструкций. Благодаря этому Fortress практически ни в чем не уступает модным развитым функциональным языкам (например, Haskell) и предлагает программисту большую свободу за счет полноценной поддержки разных парадигм программирования – императивного, объектно-ориентированного, функционального и, в общем, какого еще вздумается разработчику, лишь бы у него хватило запала и грамотности дополнить язык соответствующей библиотекой c набором необходимых компонентов.

Крепость на руинах FORTRAN
Это не фрагмент научной статьи, а легальный код Fortress. C помощью современных текстовых процессоров с таким кодом потенциально можно работать интерактивно

В технологической части Fortress – большой проект, реализованный на Java. Кроме собственно компилятора, библиотек и среды времени исполнения, он предлагает программисту также средство «рендеринга» Fortress-программ в красивую математическую форму (с помощью Emacs и TeX/LaTeX). Весьма интересна открывающаяся возможность интеграции Fortress-компилятора с пакетом Microsoft Word 2007 – учитывая мощные возможности встроенной интерактивной математической подсистемы Word 2007, использующей вместо сложного языка разметки соответствующие Unicode-символы, и открытый характер спецификаций формата данных docx, задача создания транслятора текст Word – исходный текст Fortress становится, по большому счету, тривиальной и несоизмеримо более простой, чем реализация полноценной интерактивной среды разработки.

Вернемся к общей архитектуре реализации Fortress. Ключевые понятия, использованные в ней разработчиками, – неявный параллелизм и фундаментальная атомарность операций над объектами за счет специальной архитектуры подсистемы памяти. И именно благодаря им можно говорить о Fortress как о проекте очень перспективном. Ведь эффективные реализации обоих понятий на самом деле уже сегодня нужны далеко не только тем, кто занимается научными вычислениями. К реалиям сегодняшнего дня, с одной стороны, можно отнести очевидные доступные многоядерные процессоры, дешевую оперативную память и широкополосные каналы связи. С другой – высокую сложность и дороговизну борьбы с «унаследованным последовательным кодом», в ходе которой кропотливо и небезопасно последовательная программа вручную адаптируется к возможностям современных вычислительных средств.

Атомарные операции над объектами как свойство языка – идея не новая. Вот только от идеи до ее воплощения в языке неисследовательского характера прошло немало времени. В 1993 г. двое ученых из DEC и Массачусетского университета опубликовали статью «Транзактная память – архитектурная поддержка неблокируемых структур данных». В ней шла речь о механизмах, поддерживающих работу программ с разделяемыми данными, для которых не требуются семафоры. Достоинств у таких механизмов для параллельных вычислительных систем много, их трудно переоценить, а главное – вообще можно объяснить «на пальцах». Предположим, в традиционном параллельном вычислителе нескольким потокам исполнения требуется один и тот же диапазон адресов оперативной памяти, состояние которого защищено семафором. Один из потоков в данный момент времени победил в борьбе за этот разделяемый ресурс, установил семафор в состояние «занято», получил доступ к ресурсу, после чего его исполнение было прервано, например по инициативе операционной системы. Пока прерванный процесс не исполняется, все остальные потоки, претендующие на доступ к разделяемому ресурсу, использовать его не могут – это ограничение в системах с семафорами является фундаментальным. Транзактная память же, обеспечивающая атомарность операций с объектами в ней, таких ограничений не налагает – в случае ее применения операция или может полностью выполниться, или не может выполниться вообще. Соответственно, в нашем умозрительном примере прерванный поток не изменит состояния разделяемого ресурса (транзакция не выполнена) и не «захватит» этот ресурс, предоставляя право на выполнения с ним атомарных операций другим потокам. Такой подход существенно упрощает решение массы задач параллельного программирования. В нынешней редакции языка Fortress транзактная память реализована программно, с помощью Java-библиотеки DSTM2, впоследствии же разработчики собираются утилизировать в ней и возможности массово доступных аппаратных средств. Практикующему программисту же важно знать, что оплата удобств транзактной памяти (выраженная в машинных ресурсах, естественно) – не такая уж и обременительная для современных процессоров. Когда-то давно принцип умышленного отказа от первостепенности решения задачи повышения производительности кода в пользу «сомнительной мобильности» (которая на деле и со временем оказалась живучестью) уже превратил один язык в долгожителя (естественно, речь идет о C). И вполне возможно, что транзактная память Fortress – компромисс куда более удачный.

Неявный параллелизм, второе фундаментальное понятие Fortress, буквально «пронизывает» весь язык. И не только упомянутые ранее генераторы и циклические команды Fortress автоматически распараллеливаются, в языке распараллеливается практически все, что подлежит исполнению. Естественно, распараллеливается без усилий со стороны программиста в фазе исполнения – на однопроцессорной машине исполнение того же самого «параллельного» кода автоматически станет последовательным и детерминированным. В основе скрытого процесса распараллеливания лежит алгоритм «кражи задач» (для заинтересованных – «ABP work-stealing»), отработанный в проекте адаптированного к нуждам высокопроизводительных параллельных вычислений клона языка C под названием Cilk. Желающие могут легко отыскать материалы об этом алгоритме, прикладному же Fortress-программисту достаточно уверенности в том, что проверенный многократно алгоритм и высокие показатели качества основанного на нем кода доказаны как теоретически, так и практически.

Естественно, в рамках одной статьи трудно даже мельком рассмотреть все стороны такого большого проекта, как Fortress. Но организационный аспект любого открытого и претендующего на продолжительный период развития проекта – вещь исключительно важная. Fortress, как ориентированный на научное сообщество инструмент, имеет свою аудиторию, но благодаря особенностям разработки и ее доступности заслуживает куда большую. Сейчас Fortress-сообщество, например, нуждается в расширении библиотек развитых структур данных, вычислительных алгоритмов, биндингов с языками высокого уровня. Многие из этих задач являются классической учебной партой осваивающего язык программиста.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+22
голоса

Напечатать Отправить другу

Читайте также

Добрый день.

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

В общем на мой взгляд язык не выдерживает никакой критики. И по сути является библиотекой получившейся в результате определённого умножения ForTran на Pascal, с некоторым развитием по инерции. Причём эта инерция дополняет определение определённого умножение, так сказать. Странно почему-то в начале когда описывали историю языка Java то это походило на один из фильмов Френсиса Форда Копполы, где фигурировали исключительно инициативные молодые люди. Теперь уже в некотором логическом продолжении появляется DARPA. Но похоже что создавалась DARPA по наставлениям которые писал Bush, а языки и Fortress, и Java делались уже когда действовал документ который подписал Clinton. (Нет Clinton это не ещё один "инженер столетия",
это был такой претендент демократически избираемый пост в США. И говорят документ позволял брать без разрешения интеллектуальную собственность у всех, кто формально определялся как не политически корректный.) Как видим окончание "-ess" обычно сопровождает эмансипацию, и является сопутствующим "позитивной дискриминации". Может быть это и есть елемент той синтетичности. Форт созвучно то ли с именем упомянутого режесёра то ли с автором книг о машинах и о людях, которого эти люди в чем-то там обвиняли.

Но вернёмся ко всему по порядку, когда-то язык программирования Java (такая марка кофе ещё была) имел прототип называемый Oak. На самом деле когда я решил отказаться от указательного типа в своем языке программирования то новый язык хотел назвать по названию кофейного напитка из жёлудей. Который (напиток) я любил употреблять, еще за долго до того как команде разработчиков нового языка программирования выделили офис напротив большего дуба. И жёлудь и дуб по Английски "an oak". Но пришлось немножко подкрутить и команда поменяла название, причём на название другого напитка который и был определённой маркой кофе. Потом ещё удалось объяснить что такого не политически корректного было в эмблеме SUN и её тоже поменяли. Мало того когда команда разработчиков встретилась с невозможностью дальшего эволюционирования языка Java получилось много чего непонятного. И в этот момент, уже была на подходе следующая концепция, которую оной команде никто так и не презентовал. А взята была концепция из двух вещей, первое из различных программок под Spectrum (по большему счёту Sex Album), и тестовой программы для "электронного информационно-игрового комплекса Поиск". Идея заключалась в том что тестовая программа демонстрировала отработанную годами эмуляцию аппаратного обеспечения посредством аппаратных и программных средств.
Усилия энтузиастов свелись к тому что они эмпирически доказали что небольшой набор библиотек может содержать в себе практически все механизмы динамичного вывода графики да и звука. Значит для быстрой работы с загружаемыми данными не нужен вообще будет загружаемый программный код который может например переносить вирусы или быть источником для сбоев в результате ошибок. Тоже самое было воплощено в флеше (намёк на Sex Album для ZX Spectrum). Хотя флеш делался уже под линейную адресацию видеопамяти без всяких цветовых страниц запакованных в байт нескольких пикселей и обрабатываемых современными процессорами. В результате, продукт построенный на такой идее оказался настолько удачным и востребованным что вытеснил Java практически отовсюду где её/его позиции были очень сильны.

Я сам хотел сделать немножко по другому, и встроить идею похожую на флеш в саму ОС, и сделать что-то на похожее на оболочку для запуска приложений, но не судилось. Зато Java засунули туда куда ему место.
Да и идея о управлении эволюционированием языков возникла намного раньше. Дело в том что для маленького парка персональных компьютеров которые делали энтузиасты проблема совместимости была как не странно очень большей, одним из воплощений проблемы была несовместимость различных версий языков программирования пару версий C с десяток версий BASIC, различные модификации Assembler'а, и много еще каких-то частично реализованных языков. Хотелось взять все под контроль. Для этого в частности и хотелось отказаться от типа указателей.

Теперь о том что мне не нравится в Fortress. Во первых механизм "распараллеливания" уже вносит ограничения в "полую свободу" но в рамках языка. Некое определение типов может быть скорее сложностью нежели новой возможность. Причём сложностью которую надо знать и учитывать, хотя используют её редко. Зато она вносит какой-то элемент шарма тем что она мало понятна, а по большему счету ничего нового не даёт большинству разработчиков программного обеспечения, которые и так могут воспользоваться либо ForTran либо Pascal. Метод "без семафоров", делает трансляцию ещё сложнее, обычно такие функции выполняла операционная система, теперь, как видим к ним уже обязан язык программирования очень универсального назначения. По крайней мере в языке C вообще нету семафоров он по очереди выполняет все что может, либо же выполняет некие внешние события (что редко используется). А соседний процесс может воспользоваться средствами IPC которые предоставляет ОС это могут быть и семафоры, и очереди, и тот метод без семафоров упомянутый в статье. Мало того сложность языка явно превышает и C, и Modula, и C++, и Fortran и многие другие, что аж не как не сопутствует его будущей эволюции, даже если кто-то в приказном порядке голосом тренера так решил. Я бы сказал что это искуственно созданная из исчерпанного материала тупиковая ветвь эволюции.

--DawnON

P.S. Забыл сказать что сей час хочу сделать целых два языка программирования. Один под современные требования компьютинга полный таких наворотов что пока что нигде не было. Причём этот "полный наворотов" язык можно будет запускать даже на очень очень скромных машинах (и транслятор и программы транслированные оным). Настолько скромными что для C было бы малою Другой язык оторван от современных требований и нацелен в будущее, при чем так что бы лет через 30-50 языки слились воедино. Мало того ни тот ни другой язык не предъявляет требований к особенностям аппаратуры реализации взаимодействия. Хотя трансляторы как некоторые программные, конечно будут построены исходя из тех либо иных предпочтений.

А еще вот вспомнилось, когда-то в Украине хотели сделать Java-компьютер. Потом почему-то появился некий дяденька который в приказном тоне наговорил, много непонятных общих фраз. Потом, через много лет когда приказной тон дяденьки уже подзабылся, похожие фразы вспоминались в контексте отмены поправки Джексона-Веника для Украины.

Наверное хорошо что ещё одна авантюра в те дни съела сама себя.

Вообще, это одно удовольствие стравливать авантюристов между собой. Как в том Французском фильме когда двое уже не молодых но все ещё начинающих бизнесмена, выясняли кто продавал кому другому и сколько раз из них несуществующий или ущербный товар. Но там ещё в фильме к каждому из них было по даме которые наверное оценили что те двое уже не молодых мужчин хоть на что-то способны.

--DawnON

P.S. Если бы не склонность к абстрагированию иммиджей (изображений) я бы наверное тоже бы "печатал все". А то иногда кажется что в декаде 11 пальцев.

Что-то как-то не тащатся от темы новых языков программирования.

Зато как я написал комментарии которые непосредственно к теме программирования не имеют отношения. Там когда по- просыпались за океаном, то уже был резонанс.

А жаль, что предмет не так уж интересен как хотелось бы.

Но я все равно буду работать над новым языком, (даже двумя), и новой операционной системой (собственно опять двумя). Пускай пока и без команды разработчиков.

--DawnON

Да вот еше вспомнилось.
Если у местных изданий есть проблемы с цензурой, которая осуществляется путём распределения мощностей полиграфических (printing) предприятий. то печать можно заказать за границей в Болгарии, Греции, Турции, Словакии, России, Франции, Великобритании. Так же издания можно распостранять в єлектронном виде. (В средини 90-х аналогичная проблема была в Югославии и Украине. В те времена было проведено много экспериментов в области электронного распостранения информации. В частности произведение "Herb", FreeNet Ian'а Clark'а из Edinburg'а, существенно улучшена технология электронных листков, и многое другое.) Можно сказать некоторые выводы можно было сделать из результатов таких экспериментов.

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT