← All posts tagged programming

OCTAGRAM
OLE programming Поплавал в документации OLE Automation. Глаза текут от GetIDsOfNames, DISPATCH_METHOD, rgdispidNamedArgs, DISPPARAMS.

И ладно бы это только OLE такое. У сторонних разрабов духу не хватает пойти против птичьих стандартов именования, сказать «да в гробу мы видели ВАШИНЕЧИТАЕМЫЕКРИЧАЩИЕИМЕНАКАПСОМСКАЖИСПАСИБОЕСЛИВНУТРЕННИЕСЛОВАНЕСОКРАТИЛИ, ВАШИ_ЧУТЬ_ЛУЧШЕ_ЧИТАЕМЫЕ_КРИЧАЩИЕ_ИМЕНА_КАПСОМ, местВаши прилВенгерские сущИмена, ВашЕдваЧитаемыйВерблюжийРегистр, вашДебильныйВерблюжийРегистрСМаленькойБуквы и вс эт вш атмсфр», забубенить Везде_Одинаковые_Идентификаторы и сильной рукой навести порядок. Как сделали в языке Ада. По сравнению с Делфями нравится, что выправили Char на Character, чтоб с самого начала не показывать дурной пример.
OCTAGRAM
Харьков ada programming Бригада главного программиста Шаптала Ю. (справа-налево: Шаптала Ю., Подоприголова А., Лапшун Т.) работает над проектом «Графический интерфейс энергетического анализа Ада программ».

OCTAGRAM
dotnet ida NGEN programming Если NGEN.EXE в .NET создаёт обычный машинный код, то и вызовы методов там должны быть какие-то такие, чтобы переживать изменения в зависимостях. В частности, про NGEN пишут такое (источник цитаты не понятен, но есть подозрение, что «CLR via C#» Джеффри Рихтера):
NGEN can't make as many assumptions about the execution environment as the JIT compiler can and therefore will produce unoptimized code.
For example: it adds indirections for static field access because the actual address of the static fields is known only at run time.

То есть, такой неафишируемый аналог SOM по сути, ведь после закрытия лавочки в IBM над .NET те же люди работали, Дженнифер Гамильтон, в частности. Ковырнул библиотечку из Native Image Cache в IDA, там какой-то ужас. Многочисленные нормально выглядящие поначалу функции вдруг содержат на ровном месте db 4 dup (0CCh), ломающий анализатор кода. Ни прыжка, ни потенциально безвозвратного вызова перед ними нет, ничего. Те же функции, которые были распознаны, не имеют перекрёстных ссылок. Надо, видимо, какой-нибудь класс экспортировать в COM, пройтись по нему NGEN.EXE, написать программу, которая создаст объект этого класса и войдёт в метод, чтоб иметь возможность сравнить результат деятельности NGEN.EXE с исходным кодом. Как это всё сшивается, по сравнению с SOM пока совсем не понятно.
OCTAGRAM
ООП SOM Smalltalk objectiveC programming J. Hamilton. A model for implementing an object-oriented design without language extensions
Почитал. Выходит, селекторы должны указывать на смещение внутри таблицы виртуальных методов, а эти таблицы в общем случае должны предусматривать селекторы вообще для любого метода любого класса, а то, что на самом деле там их меньше, — это оптимизация. Этот доклад ссылается на объектные модели Smalltalk и Objective-C, в которых одиночное наследование, при этом ссылка на этот доклад найдена в книге «Programming with DirectToSOM C++», где модель однозначно поддерживает множественное наследование. Однако, в принципе, понятно, как применить одно к другому. В случае Smalltalk и Objective-C объектная модель плоская, допускающая коллизии между селекторами никак не связанных между собой классов, и именно разруливанию этих ситуаций посвящён доклад. А в SOM одноимённые методы классов так конфликтовать не могут, поскольку жетоны методов функционально эквивалентны кортежу из ссылки на класс-объект и имени метода. Однако конфликт возникает в другом месте, если мы пытаемся сделать у каждого класса таблицу виртуальных методов с поиском по индексу. Любое множественное наследование приводит к тому, что на один и тот же слот в таблице виртуальных методов начинают претендовать не подозревавшие о существовании друг друга классы, у которых появился общий потомок. В этом случае можно таблицы виртуальных методов родительских классов раздвинуть так, чтобы потомки не могли конфликтовать, и уже без проблем произвести таблицу виртуальных методов наследника. Приходится попариться при создании классов, зато потом всё летает. Хотя я ещё не исследовал перемычки SOM и не знаю, как оно там было на самом деле.
OCTAGRAM
социализм общество тнк programming
По его словам, четвёртая технологическая революция может привести к тому, что все ресурсы будут сосредоточены в руках компаний-гигантов, у которых есть необходимые знания и навыки для создания софта, в то время как все остальные будут вынуждены довольствоваться крайне низкооплачиваемой работой.
Одним из выходов из сложившейся ситуации может стать повсеместное введение безусловного базового дохода. По мнению Тернера, государство должно поддерживать людей, которые оказались в крайне невыгодном положении из-за развития технологий — по крайней мере, выплачивать им пособия, достаточные для оплаты расходов на продукты питания и здравоохранение. С ним согласен финский экономист и предприниматель Бьорн Валрус, который считает, что автоматизация в скором времени приведёт к полному исчезновению рабочего класса.
Технологии подрывают капитализм
OCTAGRAM
oberon Java RRBC programming Причина, по которой некоторые языки программирования вообще и Оберон в частности находятся в таком бедственном положении
В переводе про совместимость примечательна сноска
e Текущие реализации Java не поддерживают такое, но новые спецификации ясно требуют, чтобы все наши трансформации поддерживались.
В оригинале доклада были ещё номера страниц в спецификации. То есть, как я вижу ситуацию, у индустрии была серьёзная проблема с обеспечением совместимости, и в спецификации Java английским по белому писали, что можно, а что нельзя допускать, и одновременно была целая эпопея со способами вызова из других языков:

* JDK 1.0 native method interface
* Netscape’s Java Runtime Interface
* Microsoft’s Raw Native Interface and Java/COM interface
* Java Native Interface
* Java Native Access

Одновременно несмотря на претензии типо-Java-вости и украденных идей со стороны некоторых адвокатов Оберона я что-то не припоминаю, чтоб было какое-то аналогичное соревнование, как лучше совместить код на Обероне с другими языками программирования. По ключевым словам «Oberon Runtime Interface» и «Oberon Native Interface» ничего не находится. А было ли что красть?

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

То есть, пока разработчики Java и около бурно решали серьёзнейшие проблемы индустрии и представили хоть и во многих смыслах дурацкое решение, но-таки решение, оберонщики занимались чем-то своим, щёлкали клювом, проблемы, стоящие перед индустрией, не решали и закономерно оказались не нужны. Даже, похоже, до сих пор так и не поняли, как это произошло.
OCTAGRAM
ООП типизация programming Approaches to Composition and Refinement in Object-Oriented Design
MN93 shows that framework refinement (in the sense of adapting a frame-work to yield another abstract framework) is not possible under either co-variant(Eiffel) or contravariant (Modula-3) typing rules.
Надо бы как-нибудь ликвидировать свою безграмотность по части ковариантного и контравариантного вот этого всего.
OCTAGRAM
великобритания аристократия ada programming Untangling the Tale of Ada Lovelace
В сознании простого русского человека претензии «элиты» на «элитарность» всегда комичны. Как ни станет кто элитой, так это надо на газенвагенах, ой, то есть, я хотел написать, на гелендвагенах покататься. В царские времена — крепостных понасиловать и прочее, что там вытворяли те, кто стал прообразом Троекурова. Сейчас вот имеем неудовольствие посмотреть, как отдохнула природа на детях Гайдара, Михалкова, Райкина. Каждый раз, как включались социальные лифты, когда всю страну пылесосили, так имели рывок вперёд, а как возвращались в родоплеменной строй, так деградировали.

И тем удивительнее смотреть, как в Великобритании элита действительно была. И вручную посчитать таблицы функций с точностью до нескольких знаков, и потом механизировать это — не хухры мухры. Простому русскому человеку понятны Перельманы, вышедшие из народа, а чтоб в одном человеке могли совмещаться и происхождение, и дееспособность — это какая-то фантастика.
OCTAGRAM
dll programming У библиотек на языках, транслируемых в машинные коды, часто вижу такую проблему, что их нельзя выгрузить. И программисты, и компиляторы относятся к создаваемым разделяемым библиотекам так, будто они в адресном пространстве навсегда. Delphi все строковые литералы размещает в сегменте «только для чтения» с отрицательным счётчиком ссылок. А выгрузи такую библиотеку — и все такие строки ломаются к чертям, хотя, если перенести в кучу, то они бы там успешно пережили выгрузку. Ленивая подгрузка библиотек сделана так, что они подгружаются, но не выгружаются обратно в случае выгрузки основной.

А без нормальной выгрузки не будет перезагрузки на лету.
OCTAGRAM
ООП MultipleInheritance programming Про интерфейсы и классы:
В COM замороженность интерфейсов диктовалась техническими ограничениями, во всяком случае, это то, что на виду. Однако, если присмотреться, то даже в виртуальных машинах, сценарных языках программирования и т. п. окружениях, где технические проблемы решены, мы не можем просто взять и расширить интерфейс, так как интерфейс может быть реализован вообще каким угодно классом, и не согласованные с другими командами разработчиков расширения интерфейса сломают их классы. А вот если есть класс с реализацией по умолчанию, то этот класс можно расширять, и все довольны. Так приходим к мысли о том, что множественное наследование всё–таки нужно, а так называемое «множественное наследование только для интерфейсов» — это пыль в глаза. На самом деле нет, а звучит как будто есть.

Естественно, под множественным наследованием я не имею в виду убожество из стандарта C++.
OCTAGRAM
ГОСТ ada programming Мучился когда–то с определением языка программирования в дипломе. Стыренное из википедии определение без указания авторства благополучно совпало с чьим–то дипломом и дало пару процентов неоригинальности. Пришлось искать другое определение, где бы можно было найти первоисточник.

А меж тем, оказывается, целый ГОСТ есть, ГОСТ 28397-89 (ИСО 2382-15-85). «Язык, предназначенный для представления программ.»

Нашёл ещё ГОСТов на языки программирования:
ГОСТ 21551-76 Язык программирования АЛГАМС
ГОСТ 22558-89 Язык программирования Кобол
ГОСТ 23056-78 Язык программирования Фортран
ГОСТ 23057-78 Язык программирования Базисный Фортран
ГОСТ 27787-88 Язык программирования БЕЙСИК
ГОСТ 27974-88 Язык программирования АЛГОЛ 68
ГОСТ 27975-88 Язык программирования АЛГОЛ 68 расширенный
ГОСТ 27831-88 Язык программирования АДА
ГОСТ 28140-89 Язык программирования ПАСКАЛЬ

Я раньше знал, что стандарт на Аду 83 перевели на русский, но я не знал, что это было для ГОСТ и стало таковым. И действует.
Нашёл ещё такое: ГОСТ Р 34.1702.3-92 Связь ядра графической системы с языком программирования Ада.
Этакий unit Graph, но для Ады и по ГОСТу.
OCTAGRAM
unicode GNAT ada programming Обнаружил, что GNAT уже давно автоматически использует UTF-8 как однобайтовую кодировку, а не ANSI (управляется переменной среды GNAT_CODE_PAGE). В смысле, использует её для I/O, в частности, имён файлов, где и был камень преткновения, поскольку у таких модулей, как Ada.Directories, аргументы в однобайтовых String, а не двухбайтовых Wide_String или четырёхбайтовых Wide_Wide_String. Кодировка исходников управляется -gnatW, в юникодных кодировках можно давать идентификаторам имена не на латинице и писать строковые литералы, но такие литералы должны быть достаточно широкими, потому что String по стандарту жёстко Latin-1, а всё русское требует минимум Wide_String. Есть, правда, вариант, при котором компилятор думает, что он парсит исходник в Latin-1, а он — в UTF-8 или ANSI, но как–то это не правильно, мне кажется. Идентификаторы не получится юникодные написать, и широкие строковые литералы, наоборот, будут коцаться.
Восемь назад на Windows такие строки было особо некуда деть, кроме платформозависимого Win32Ada. Нет, можно, конечно, было подключить Ada.Wide_Wide_Text_IO и пошпарить Юникодом в тексте файла, но имя файла при этом будет ограничено ANSI. Эту дырку GNAT закрыл давно. Есть у процедур открытия файла строковый параметр Form, смысл которого по стандарту определяется компилятором, и в GNAT его можно было использовать для того, чтобы указать, что имя файла — в UTF-8, а не ANSI. Так что, сконвертировав имя файла в UTF-8, можно даже было и открыть его. А вот Ada.Directories было более проблемным, там никаких параметров Form не было, чтоб отказаться от этого проклятого ANSI. Понятно, что были и Матрёшки, где диктатура четырёхбайтовых строк, не дожидаясь, когда стандарт избавится от однобайтового наследия, но состояние стандартной библиотеки тоже важно.

Попутно, пока искал, поиск выдавал мне, как обстоят дела у других разработчиков
But the problem is MSVC only accept UTF8+BOM and MinGW only UTF8-BOM
note that MinGW use UTF-8 for sources, while VC8 use ANSI
Если этот «хорошо подходящий для Windows» компилятор до сих пор форсит ANSI в исходниках (кто будет ставить BOM для UTF-8?), сочувствую тем, кто вынужден этой пакостью пользоваться.
OCTAGRAM
icon programming Fundamentals of the Icon programming language
Когда в твоих руках Icon, решение любой задачи похоже на перебор. На странице 78 примеры.
every write(!"ab", !"+-", !"cd"); # Примерно по такой методе я тесты на несколько мегабайт генерил
(0 to 20 by 2) = (0 to 20 by 3) # Экология? Нет, не слышал.
По сравнению с Prolog, даже такими диалектами, как Mercury, с нормальным синтаксисом функций, Icon — наиболее удобный язык программирования с откатами.

Так как в серьёзных приложениях требуется журналирование ошибок, молчаливая неудача, которая может может возникать и отсекать ветку перебора сразу в нескольких местах, например, по признакам выхода за границы диапазона, наличию элемента в ассоциативном массиве или любом логическом условии, которое можно проверить только после того, как предшествующие проблемы были исключены, уже не годится. Приходится обильно разбавлять всё понятными сообщениями, и магия коротких ёмких выражений улетучивается. Вот если бы как–нибудь добавить к неудачам метаинформацию, как у исключений, что–нибудь и вышло.
OCTAGRAM
ada programming Конец адского мандата
Когда–то Ада была обязательна при выполнении проектов для минобороны США, ну а попутно это двигало смежные индустрии.

Это однозначно положительно сказывалось на качестве этих проектов, но вредило языку. Производители инструментария знали, что они могут сделать до некоторой степени любую фигню, и если она пройдёт тесты на сертификацию, то получит право на бренд «Ада», и огромной куче фирмёшек, работающих на оборонку, придётся приткнуться к одному из таких производителей. А производитель может однажды вложившись, снимать сливки, и адаистов такая ситуация напрягала. Например, первый транслятор Ada в машинные коды GNAT появился в результате гранта минобороны, а до этого делали интерпретатор байт–кода, и хватит. Это уже потом пошли ObjectAda, PowerAda, AdaMagic, Irvine, и мы сейчас знаем Ada только как язык, компилируемый в машинные коды (JVM и .NET не очень приживаются за ненадобностью).

Ну что ж, теперь в 2016м году плоды конкуренции в полной мере пожаты. Из реализаций современного стандарта остался только один, но качество инструментария и впрямь довольно неплохое. Я наблюдаю это с 2005го года, и вижу, как качество GPS неуклонно возрастало, переболев детскими болезнями.

Однако, додики, оставшись без законодательных ограничений, свалили с Ады и пишут всякие Flash runtime и CLR отнюдь не на Аде, и поэтому у них там баги без конца.

И непонятно, как бы это разрулить, чтоб всеобщее счастье было. Может, надо периодически вводить–снимать мандат, чтоб балансировать между плохими средствами разработки и плохим ПО.
OCTAGRAM
programming Shorter code is inconsiderate
A dangerous trend that I consistently see is that code implementations with the fewest lines of code tend to be up-voted and rewarded as the most elegant, creative, and clever solutions.
This is crap. Brian Kernighan had it right when he said:
“… debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?”

Да, тут они верно подметили. Но всё же бывают разные ситуации. В приведённом примере короткий код написать корректно сложнее, чем длинный. А C по сравнению с Ada, не имеет RAII и исключений, поэтому там, наоборот, написать корректно длинный код на C сложнее, чем короткий — на Аде.

Возможно, ситуации второго типа настолько въелись в подсознание, что всё доводят до абсурда, забывая, для чего это затевалось.