Сообщения

Сообщения за август, 2015

Компонентный Паскаль: перенос учебника.

Решил перенести учебник в формат BlackBox, сделать как подсистему. Исходный вариант учебника на ВикиБокс. Всё-таки в BlackBox ближе целевая аудитория. Скачать можно здесь: http://oberoncore.ru/ , форумы, BlackBox, литература. Стараюсь делать на совесть, может кому пригодится)

Go1.5: самокомпиляция + мульпроцессорность

Вышел тутась на днях Go 1.5. Разрабы обещали много всяких вкусняшек. Но что получили на самом деле? ,) ----- 1. Мультипроцессорность . Скомпилировал я свой тест, запустил. Ускорение примерно в 2,6 раза (вместо 5,27 сек). Явно задействовано 2 ядра, запуск диспетчера задач показал, что это так. Но ускорение кода больше, чем 2х. Видимо, где-то что-то оптимизировали в кишках. Возможно, помог ассемблер))) Ещё два ядра висят ни при делах))) Добавляю две go-рутины и вижу: загружено всё. Это приятно. Но вот время выполнения подозрительное... Не изменилось. Возможно, это был мой косяк в коде. 2. Самосборка не прошла! Всё-равно требуются какие-то внешние библиотеки с привязками на Си. 3. В целом , Go стал ближе к тому, о чём декларировалось. Отложим в чулан) Не знаю, пригодится ли)

Компонентный Паскаль: компиляция.

Дошли у меня руки до компиляции. Вчера компилял DLL и наблюдал в бинарнике экспортируемую функцию, стало интересно собрать экзешник. Видел на форуме как накомпилять учебный пример, был немного в шоке -- в файл пихалось три десятка файлов. Завёл после кода  в коммандер DevLinker.LinkExe и начал ваять. В рабочем журнале высыпалось штук 20 сообщений, что не видит линкер кучу модулей. Логика подсказывает, что более глубокие модули нужно втыкать раньше. В итоге получилось модулей для линкования штук 50))) Начала в голове вырисовываться схема зависимостей. После заполнения списка, первая мысль была: ну и ад. Потом пришла вторая мысль: а собственно, ничего страшного, ведь коммандер вызывается один раз, и в целом, руками допиливать список модулей глобально не придётся. Да и наверняка в ИСР есть команда, которая шукает все модули) На этом приключения не закончились. Начал линкер ругаться на то, что нет ядра. Хотя на самом деле было. Оказалось, правильная форма записи: Kernel+ По аналогии, з

КП: полная русификация! )

Скачал одну из версий БлекБокса из "Проекта Информатика-21", кинул сверху русификатор (нутрянку не смотрел, но судя по обсуждению на оберонкоре.ру сделано элегантно), накатил парочку подсистем. В итоге получил кучу документации по русски (на нормальном человеческом русском), кучка примеров, и ВНИМАНИЕ! Русифицированные ключевые слова, чего я так и не смог добиться от Go или python. Таким образом, программа целиком может быть написана на русском (+специфические символы языка). Открыл пример "Тетрис", перевёл половину слов на русский и поймал себя на нескольких мыслях: 1. Часть слов я в мозгах переводил не верно. 2. Смысл программы доходит быстрее, появляется глубина/перспектива кода. 3. Часть английских идентификаторов выбрана неудачно, либо я не понимаю семантику этих слов. 4. Ну и убогий английский язык....))) Короче, погружение в русскоязычную программную среду мне показалось перспективным. Несколько нелепо смотрятся английские вкрапления через импорт. В Go

КП и Go: вещественная арифметика, кто шустрее?

Решил я не откладывать в долгий ящик тест скорости программ на Go и КП. Набросал простенький цикл с вещественными числами. Ну очень тупой тест, но там где начинаются измерения -- там начинается наука. Фишка тут вот в чём: и в Go, и в КП тип float=double для тех, кто не в теме. Т.е. короткие вещественные числа -- только для машинного обмена данными. (Интересны оба решения. Странно... Никто не хочет возиться с float32? Есть практика, доказывающая превосходство точной арифметики? А не заимствовали ли  разработчики Go решение из Компонентного Паскаля?) И теоретически, работа с короткими числами должна идти несколько медленней. В Go тупо не предусмотрена математика с типом float32. Про КП я этого просто не знаю (не знал до теста). Как оказалось Go с типом float32 всё-таки на 10% работает медленней, чем с типом float64. Видимо, сказывается излишнее двойное преобразование float32->float64->float32. А в КП, что REAL, что SHORTREAL -- всё едино. Работает медленней на 5-7%, что говорит

Go: опять обманули

Я очень надеялся, что в Go нативно поддерживается мультипроцессорность, но как оказалось -- максимум я могу рассчитывать лишь на кооперативное выполнение тысяч легковесных потоков в рамках единого процесса. Да, решение вполне рабочее, но не хочется лишний раз делать мультипроцессорный велосипед. Наверняка есть какие-то либы для поднятия этого дела, но как-то это всё не честно. Да и скажем прямо, Марк Саммерфильд просто стонет от счастья шкодить на Go. Есть там приятные вещи притянутые из python, Си, Компонентного Паскаля, да -- компилит в статический бинарник, НУ НЕТУ ТАМ ВАУ-ЭФФЕКТА. После БлекБокса максимум кандидатская клюква. Поэтому, товарищи, я плавно возвращаюсь к Компонентному Паскалю)

Go и Компонентный Паскаль: IDE

IDE совсем немаловажный вопрос при разработке. Давно никто не ведёт разработку в блокноте. Это антинаучный подход. Кроме того, сам факт обращения к сторонним инструментам, говорит о том, что IDE лишней совсем не является. Как-то не камильфо скакать между окнами, чтобы коммит отправить на гитхаб, компильнуть, доки полистать. Как говорит русская народная мудрость:"Один в поле не воин". В python нормальной ИДЕ нет. Приближаются к ним Komodo, Qt Develop. С натяжкой удобными можно считать Geany и Kate. Остальные, кто utf8 не переваривает, кто фолдинг не умеет, и почти никто не справляется с показом контекстной справки. Spider вроде не очень тяжёлый, но его боевая консоль в форме IPython несколько пугает, да и коряво работает с модулями, скомпилированными в cython -- после первой загрузки невозможно скомпилировать модуль cython. Приходится закрывать Spider (причём с ошибкой). Такие дела. Go не имеет среды хоть какой-нибудь. Ну хотя бы на уровне IDLE. Но есть сторонняя IDE на Qt. В

Go: ООП не как у всех

В Go отключена перегрузка имён методов. Это ограничение вызвано особенностями встраивания типов, вместо наследования . Я не совсем понимаю почему так, видимо из-за того, что Go не анализирует сигнатуры (хотя Компонентному Паскалю это вполне прилично удаётся). В python есть вполне приличное множественное наследование, и в нём красиво решена проблема хрупкого базового класса. В Go внаглую передран синтаксис объявления методов из КП. Но прочитав первые 3-5 страниц шестой главы -- я не вижу ни одной отсылки к КП. Немножко некрасиво. Мне откровенно не нравится использование утиной типизации в системном языке. Я не могу Go назвать типобезопасным языком. Ада вроде типобезопасная, но мы то помним злополучный пуск "Ариана" и былинный отказ двигателя из-за ошибки в софте, из-за внутренней сложности Ады. (И как-то сразу вспоминаются итоги конкурса по Аде с фразой:"Господин Вирт верит, что существуют простые решения сложных проблем"). КП выглядит богаче и надёжней. Возможность

Go: загадочный if

На стр. 248 у Саммерфильда нашёл штуку, которая явно является источником ошибок. С учётом того, что if начинает новую область видимости, такого рода форма if оправдана: if res, err:= func(); err=nil{   res+=1 } Объявление с присвоением в охране -- это норма. А вот то, что переменные в дальнейших ветках "else if" (локальные между прочим) видны до конца if -- это дико! И обратите внимание на то, как в данном случае неудачно использован терминатор ";"! В других языках это бы просто разорвало инструкцию) А если по ошибке вместо ";" поставить "," -- будет ещё веселей)) Всё понимаю, интересное решение, можно наделать прикольных велосипедов, но ведь Go -- для системного программирования, разве нет? Да и сама форма условия с вычислениями в охране -- ну зачем так усложнять? Да, привыкнуть можно, но как-то мне это не по нраву. Чем проще код, тем надёжней.

Go: спорный синтаксис

В Go как-то странно решён вопрос с разделителями -- фигурными скобками и точкой с запятой. Достаточно просто перенести скобку на следующую строку и лови ошибку. Точка с запятой нужны редко, но НУЖНЫ! Кстати, ставить их где попало не запрещено. Так что, непонятно до конца в чём был смысл усложнять лексический разбор. Оператор создания и присвоения _:=_ использован несколько неудачно, так как нет объявления _:_. (переделка Си спорная). Да и математически знак _=_ не есть присвоение. Это уравнивание левой и правой части, а не присвоение нового значения. Паскаль семейство более логично. А объявление переменной в охране цикла -- удобно, но спорно. Сам же Саммерфильд на стр. 243 говорит, что использование этой фичи почти всегда является багом.("небрежное использование этого приёма может порождать проблемы"). Ещё в качестве странности Go отмечу, что если объявлена переменная в заголовке функции, новая переменная с таким же именем не в охране условия/цикла -- создана не будет!!!! А м

Про системное программирование на Go и Компонентный Паскаль.

В Go мне нравится, что нет try и except. Ни одна ошибка не должна "вываливаться внезапно". Что меня раздражает в python. Такие ситуации есть признак хренового проектирования языка программирования. Но в Go есть аналог finnaly -- defer. При чём с отложенным исполнением. Не то, чтобы оно дико раздражало (рантайм освобождает автоматом все ресурсы при окончании программы даже по аварии, и это правильно), но есть в этом что-то кривое. В этом отношении Компонентный Паскаль с его системой контроля типов, автоматическим управлением памятью (не как в Go, гораздо адекватней) -- смотрится очень мило. Правда компилять в КП гораздо неудобней. Итого. В плане системного программирования Go подходит хуже КП на 15%. По моим скромным дилетантским прикидкам.

Приведение чисел: Компонентный Паскаль vs. Go

Прочитал главу Марка Саммерфильда про форматирование строк. Библиотеки продуманы совсем не дурно в Go. Но Компонентный Паскаль всё-равно выглядит несколько предпочтительней. Его система приведения типов выглядит более логичной. Хоть КП и не требует явного приведения типов, как там используются приведения -- излишнего раздражения не вызывает. Постоянно тыкать мордой Go не катастрофа, но как-то можно было и аккуратней вопрос решить.

C++ -- тяжёлый случай.

Попробовал скомпилировать программу после чистой установки gcc. Опять не видит файлы (привет новый стиль), опять проблемы с путями и всё такое. В топку. Ну не нравится мне С++! Просто органическая неприязнь. Вот что мешает для нового стиля сделать вот так: #define: cpp 4.8 #define: coding utf8 И ВСЁ!!! Овцы целы, волки сыты. Нет контрольных строк -- значит исходник древний, ничего о стандартах не знает. И не надо мне петь, что даже древний код сможет компильнуться современным gcc. Не верю! В Go хоть компилер прилично работает, среда сама компилер цепляет, доки по человечески оформлены, посмотреть можно. Так что помашем ручкой. Вообще, смотрю проблема человеческий язык найти для программирования. Не хорошо всё это.

Сплошные тернии

В который раз сталкиваюсь с тем, что тупо не работает компилятор gcc. Минут 20 ушло на то, чтобы понять, что объявление #include <iostream.h> объявлено устаревшим, и такого файла нет вообще!))) Ещё час, чтобы найти старую версию компилятора, и таки убедиться -- НЕ РАБОТАЕТ!))) После всех таких телодвижений голова автоматически поворачивается в сторону python/cython, Go, Компонентного Паскаля. Там таких закидонов не бывает. Да и поддержка кодировок сделана куда адекватней. Поддержка встроенной мультипроцессорности всё ещё остаётся под большим вопросом. Уж лучше GIL, но работающий, чем суперскорость, но теоретическая)))