Русские вычислители

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Русские вычислители » Русский язык программирования: от слов к делу » Исследование: выбор платформы, компилятора и графических библиотек


Исследование: выбор платформы, компилятора и графических библиотек

Сообщений 1 страница 100 из 201

1

Юрий написал(а):

По моему мнению, разрабатывать РЯП лучше для нескольких платформ. Поэтому надо решить какие графические библиотеки использовать. Их надо изучить и сделать выбор. Кто этим займётся? Какой код должен выдавать компилятор? Для Intel, или же ARM, или же LLVM (https://ru.wikipedia.org/wiki/Low_Level_Virtual_Machine)? Или выдавать на выходе код на Си, а уж Си есть на всех платформах. Кто исследует вопрос и аргументировано обоснует выбор?
В качестве GUI для РЯП можно рассмотреть следующие технологии:
https://ru.wikipedia.org/wiki/GTK+
https://ru.wikipedia.org/wiki/Qt
https://ru.wikipedia.org/wiki/WxWidgets
Есть ещё одна, про которую пишут, что её назначение – «создание графических интерфейсов для консольных программ (пакетов программ), встраивание в прикладные программы» (цитата). Это язык https://ru.wikipedia.org/wiki/Tcl и библиотека на нём https://ru.wikipedia.org/wiki/Tk.
Можно так же рассмотреть вариант, когда GUI организован через браузер. Так что вопрос остался открытым. Требуются желающие всё это изучить и выдать обоснованные рекомендации.


По просьбе Юрия, выполнил первоначальное исследование. Искал ответы в сети, задавал свои вопросы. Постепенно буду обновлять информацию.

Ниже солянка цитат из различных источников по выбору платформы, компилятора и графических библиотек.

1. если нужно ну очень быстро, то можете на TK (библиотека для си) gui сделать - у нее есть порт под винду.

2. рекомендую либо c++/qt4-5, либо java7-8

3. Не советую смотреть на wxWidges. Поверьте человеку который грыз этот кактус несколько лет. Единственное его преимущество - полностью нативные окошки под каждой системой. Однако виджеты ужасны с точки зрения удобства написания кода. Документации по ним не то чтобы совсем нет, но к сожалению зачастую не хватает чтобы понять что ты делаешь не так.
Берите Qt для интерфейсов. Это очень хорошая библиотека. Во-первых благодаря своему устройству Кюти помогает вам не выстрелить себе в ногу ( а на первых порах это будет случатся очень часто ). К Кьюти есть много хорошей документации и отличных примеров.

4. Есть очень легкий FLTK, но выглядит он, мягко говоря, ужасно.
Советую вам ориентироваться вот по этому (http://wiki.lxde.org/en/GUI_Toolkit_Comparison) сравнению кросс-платформенных графических тулкитов/фреймворков, который составили разработчики LXDE при переходе с GTK+ на Qt.

Лично мой выбор - Qt 4.X.X. С помощью статической сборки и утилиты upx возможно получить stand-alone приложение в одном EXE-файле, не зависящее от различных dll'ок.

5. Браузерное быстрее.
Нет заморочек с крестами (в JS можно намутить любое ООП какое тебе больше по душе, плюс есть CoffeeScript - можно юзать функциональщину), куча разных фреймворков – выбирай любой, в котором тебе работать удобнее. Фреймворков, которые специально точились для того и только для того, чтобы разрабатывать гуй было легко, удобно и быстро.

Проблема - приложение выглядит не нативно.
Частичное решение - берешь делаешь браузерное приложение, и открываешь его в QtWebKit - оно начинает вести себя как нативное (рамочка, сворачивание, итп).

Сильно не наоптимизируешь - сложный гуй будет жрать память и тормозить.

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

6. У Qt нет хозяина. Она теперь полностью свободна, весь штат бывшего Trolltech сохранён и оплачивается из кармана нокии, поддерживается сообществом KDE, собственным сообществом, а также множеством самостоятельных разработчиков. А с недавних пор, существует qt-project.org ставящий своей целью создание полностью открытого процесса разработки и управления.

7. На чём лучше писать кроссплатформенные приложения с доступом к последовательному порту?
Должна быть небольшая программка с GUI-интерфейсом, но данные будут получаться с микроконтроллера через последовательный порт.
Хотел писать на js, но в client-side js отсутствует доступ к Serial Port.
Ответ: python + pyqt

8. Преимущества

Используя подход, описанный в этой статье, вы не привязаны к платформе, вы можете использовать те инструменты, которые хотите, а в последующем легко их менять. На десктопе — Qt или GTK, на Android — libgdx или AndEngine, на iOS — cocos2d, выбор за вами. Можете вовсе отказаться от движков, используя API, предоставляемое платформой. Большую часть времени вы можете писать и отлаживать код в вашей любимой IDE на великом и могучем C++.

Недостатки

Недостатки, конечно, тоже есть, например, вы не сможете пользоваться готовыми UI компонентами — вам нужно будет реализовать их на C++. Либо выносить UI часть приложения в каждую платформу. Также вам обязательно придется тесно познакомиться с каждой платформой, но как показывает практика, полностью уйти от этого знакомства никогда не удается.

http://habrahabr.ru/post/133897/

9. Изначально создатели языка Си и системы Unix предполагали, что возникнут другие языки, более удобные для программистов (каждый язык со своей специализацией). Для каждого такого языка, на Си будет написан транслятор (не компилятор), который транслирует исходник с этого языка опять же на Си, а не в исполняемый код. И уже этот промежуточный Си-текст транслируется Си-компилятором в бинарный исполняемый файл. Такова была изначальная философия системы Unix: все программы портируемы и все языки надстраиваются над базовым языком Си.

10. >>Если поставить перед собой такую задачу и писать в соответствии со стандартом ANSI C, то на Си можно написать портируемую программу или библиотеку функций.

Аргумент отстойный. Стандарт ANSI C слишком мал и даже сетевой ввод/вывод в себя не включает. О какой портируемости речь? Для утилит уровня grep/echo/cat? Потому что никакое графическое приложение на ANSI C написать не получится. Кроссплатформенность в библиотеках типа qt/gtk достигается за счет подачи разного кода разным архитектурам. Нет причин, по которым то же самое нельзя сделать и в C++.

zlib и libpng плохие примеры, поскольку это вспомогательные библиотеки, которым от системы нужно разве что выделение памяти или файловый ввод/вывод - это должно быть в ЛЮБОЙ стандартной библиотеке любого языка программирования. Остальное в них составляют чистейшие алгоритмы.

http://www.codenet.ru/progr/cpp/c-vs-cpp/

11. >>Компиляторы Си++ намного сложнее, чем компилятор Си, и есть не везде.

Компиляторов куча, и под самое разное. Тот же GCC может быть легко портирован на нужную архитектуру. Поясняю принцип его работы - код на C++ сначала транслируется в ассемблер целевой архитектуры, после чего к нему "пришивается" OS-зависимый код (типа инициализации при старте и т.д.), после чего все это линкуется в нужный исполняемый формат, вместе с портированными стандартными библиотеками.

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

12. >>В основном Си++ используют, потому что под него написаны библиотеки классов (как правило привязанные к определённой платформе и операционной системе).

Внезапно, для использования C++ библиотек совсем не обязательно писать на C++. Достаточно написать заглушку классов в процедуры на C. Зачатки ООП есть в библиотеке Glib (не путать с Glibc), которую используют и в проектах на C.

13. В QtCreator можно писать и на чистом C/C++, так как собирает компилятор GNU(MinGW)

14. Компилятор GNU GCC, мне ардуино бесит из-за языка своего Processing - дрянь полнейшая. Визуальная часть питон + pyqt. Кроссплатформенность 100%

Отредактировано Infum (01.09.2014 19:25:56)

0

2

О графике.
Впечатления о Qt.
Купил как-то книжку Макса Шлее (наш бывший соотечественник, живущий в Германии) «Qt 4.5» вместе с CD. Пишу первую программу: «Hello, world!» - всё работает. Теперь пишу «Здравствуй, мир!» и … на выходе – «крякзябры». «Ага, думаю, там наверное, кодировка должна быть не 1251, а utf-8». Переписываю в utf-8. Опять «крякзябры», только другие. Лезу в Инет: в чём дело? Про Qt сайтов весьма немного, особо не разбежишься. Оказалось, для работы с русским текстом надо использовать интернационализацию. Т.е. принцип «делай то, что тебе говорят, за базар отвечаю» в Qt не проходит, эта штука считает себя умнее программиста.

Не понравилась скорость компиляции. Ведь библиотека Qt использует не стандартный C++, а некое надмножество. Поэтому сперва работает метаобъектный компилятор (MOC), который переводит программу в C++, затем полученный текст компилируется компилятором GCC, который сам по себе далеко не шустр. А в языке «Кумир» уже 3 этапа компиляции: Кумир --> Qt-диалект C++ --> С++ GCC --> машинный код.

Ну и размеры программы. В контроллеры программу после Qt точно не засунешь. На ассемблере простейший графический «Hello, world» занимает 3k. Да-да, такой компактный GUI на ассемблере. После Qt он потолстеет примерно на 3 порядка, вместо «k» надо писать «m».

Если об vxWidgets плохие впечатления, то где найти в этом мире правду? Где идеал GUI, гений чистой красоты? Тут грызёт тайная мысль: «А не замахнуться ли нам на Вильяма нашего Шекспира?», не написать ли свою графическую библиотеку? Тем более, что можно отбросить лишнее (а под Windows точно много лишнего). Но кто ж мне даст время на это? Я бы с удовольствием. Уволился бы с работы, но кто ж будет кормить меня во время написания библиотеки? Ну ладно, это вопрос риторический…

0

3

Qt жирный. А что вы хотели? Ведь хочешь кросс, получи касатку. Либо писать под каждую ОС свой код и оптимизировать.

Юрий написал(а):

В контроллеры программу после Qt точно не засунешь.


Вроде никто так не делает.

На примере: ATtiny2313 имеет следующие особенности: 2кБ встроенной программируемой ФЛЭШ-памяти программ,
128 байт EEPROM, 128 байт SRAM

.

Для МК есть специальные GUI библиотеки написанные на Си: http://makesystem.net/?p=457

Юрий написал(а):

Если об vxWidgets плохие впечатления, то где найти в этом мире правду?


Сколько людей, столько и мнений. Нужно пробовать. Можно что-то взять и допиливать. Можно что-то своё. Но на все хотелки жизни не хватит. :)

Отредактировано Infum (01.09.2014 20:28:18)

0

4

Вашему вниманию, ...ещё одна тропинка. Представлю ряд публикации ... http://shmat-razum.blogspot.com/2011/11/racket.html  "Есть табак, да нечем нюхать"  (ц) ...Цель авторов Racket можно сформулировать так: дать разработчикам возможность создавать свои языки, не лишая их при этом прелестей Лиспа. «Лисп как основа и любой ваш каприз вдобавок» — звучит как предложение, от которого невозможно отказаться. В отличие от Common Lisp, где новые языки как правило создаются на базе грамматики S-выражений, в Racket для них допустима любая грамматика. Плюс к тому, отладчик и редактор с подсветкой синтаксиса — практически даром. Решительно невозможно отказаться...   http://homelisp.ru/help/lisp.html  "Очень краткое введение в язык Лисп " ... (ц) Честно говоря, автор первоначально не планировал излагать в этом руководстве основы Лиспа. Однако, изучив литературу, изданную по Лиспу на русском языке, автор вынужден признать, что она весьма немногочисленна, а последняя книга по Лиспу издана почти 20 лет назад. Получается, что читатель, не знакомый с Лиспом, вынужден либо искать библиографические редкости, либо что-то качать из Интернета... .. В заключение, автор просит извинения у искушенного читателя (если он сюда забредет!) за навязчивое объяснение элементарных вещей... Его разработка по Липсу.. http://habrahabr.ru/post/83587/  ...(ц) HomeLisp (домашний Лисп) – это 32-х битная реализация Лиспа в среде Windows.За основу была взята реализация Лиспа, описанная в книге С.С. Лавров, Г.С. Силагадзе «Автоматическая обработка данных. Язык Лисп и его реализация» М. 1978.. ...HomeLisp включает в себя следующие независимые компоненты:
1.Среду разработки (IDE), содержащую ядро языка, текстовый редактор, конструктор диалогов (экранный дизайнер), построитель EXE-файлов и скромные средства отладки;
2.COM-библиотеку, позволяющую вызывать Лисп из любой программной среды, поддерживающей COM-автоматизацию (например, из Microsoft Excel), а также два скриптовых «движка», позволяющих писать скрипты на языке Лисп;
3.WEB-компоненту для работы на WEB-сервере IIS, позволяющую построить учебный класс для изучения Лиспа (при этом WEB-компонента инсталлируется только на сервере)..                   И домашняя страницы "Ракеты" http://racket-lang.org/  на которой тренировался  в создании языков первый автор..  это полноценная в добавок "руссифицированная " "Лисп-станция"

Отредактировано robur (17.09.2014 22:15:42)

0

5

Вообще тут речь о кроссплатформенности. А Вы пишите о HomeLisp, который работает только под Windows.

0

6

Юрий написал(а):

Вообще тут речь о кроссплатформенности. А Вы пишите о HomeLisp, который работает только под Windows.

НомеLisp машинка слабенькая  это было дано для общего обзора как водная на русском языке в Липсовскую тематику, американская "Ракета" зверь и всеядна (кроссплатформенная),  и это она способна создать язык.. любой в смысле, процедурный, ооп,.... компилируемые интерпретируемые, с любой лексикой.

Отредактировано robur (18.09.2014 22:37:12)

0

7

utkin написал(а):

Статья про Racket интересна, но она рассматривает семантику стандартным образом - переменые установленных типов, синтакисис в виде сокращений. Все что сейчас стандартно и модно. Реализация других вариантов сложней, так как нужно прорабатывать концепцию и писать не опираясь на стандартные библиотеки (которые частно не поддерживают юникод и необычные решения).

Да сложнее, нужна "привязка" к железу, к системам железа, значит нужны трансляторы на ассемблерах именно эта стратегия позволяет Си-подобным, так сказать, быть входу "постоянно"... и не быть "бедным родственником без своего угла". Но тут нужен целый институт... это не по силам одиночкам если конечно всё делать должным образом а непросто один или два "голых" русских языка программирования, а выстраивать целую систему.. где есть корень, ствол, ветви, листья.. Но с чего то нужно начинать.. ))

0

8

utkin написал(а):

Статья про Racket интересна, но она рассматривает семантику стандартным образом - переменые установленных типов, синтакисис в виде сокращений. Все что сейчас стандартно и модно.

Нестандартный подход?  )) нестандартный подход к обработки программ  Команды=данные=команды=... только у Лисп-подобных языков да и то не у всех подряд...  И такой подход врятли нужен процедурным языкам.. Или Вы имели в виду что то другое?

0

9

robur написал(а):

Но с чего то нужно начинать.. ))

С чего начали Вы? Где Ваши шаги и результаты? Или Вы пришли просто философствовать?

0

10

Infum написал(а):

robur написал(а):Но с чего то нужно начинать.. ))С чего начали Вы? Где Ваши шаги и результаты? Или Вы пришли просто философствовать?

Именно, с "философствования" я и начал, как Вы изволили выразится,... Сначала надо думать а потом делать.. а не на оборот.

0

11

Юрий написал(а):

Тут грызёт тайная мысль: «А не замахнуться ли нам на Вильяма нашего Шекспира?», не написать ли свою графическую библиотеку? Тем более, что можно отбросить лишнее (а под Windows точно много лишнего).


Точно на "Шекспира" это в самый раз .. )) В смысле "Семантическую библиотеку" для Графической, GL  к примеру, курочить её при этом необязательно  ..и к другим пользительным ресурсам свободного базового ПО.. Примерно то, что Вы делаете для С++.   

Юрий написал(а):

Я бы с удовольствием. Уволился бы с работы, но кто ж будет кормить меня во время написания библиотеки?

По хорошему конечно государство должно вас "кормить"   ...но пока оно додумается до этого...  )).   Хорошо бы пристроить это каким ни будь студентам мм..  для развития навыков программирования этакий "Студенческий проект"  молодых дарований.. ))  .. :rolleyes:  ..мм.. да.. ))

0

12

А какие претензии к государству? Государство - это прежде всего чиновники. А много ли чиновников понимает то, о чём мы пишем на этом форуме? Затащите кого-нибудь из "государевых слуг" и спросите, понимают ли они хоть что-нибудь из наших обсуждений. Нет, надеяться надо на себя и немного на инвесторов (если таковые вообще интересуются наукой и техникой).

Вот если бы я был миллиардером (на худой конец - миллионером), я бы точно вкладывался в технологии. Оставил бы себе достаточный минимум на жизнь, а остальное - в разработки.

Racket

Можно прочитать как "рэкет" :)

американская "Ракета" зверь и всеядна (кроссплатформенная),  и это она способна создать язык.. любой в смысле, процедурный, ооп,.... компилируемые интерпретируемые, с любой лексикой.

Системное ПО (к которому компиляторы тоже относятся) на медленных языках пишут редко. Поэтому Лисп в этой области отдыхает, как правило.

0

13

Моё мнение - если делать язык программирования, то лучше для начала его делать под LLVM, так как не придётся разрабатывать свой оптимизатор и генераторы кода под все платформы и архитектуры, а можно сосредоточиться на самом языке и на библиотеках для него. Ведь если идёт речь о русском языке программирования, то библиотек там надо много создать.
За LLVM я вижу будущее - это хорошая технология, хоть и не русская. Если понадобится, что-то аналогичное, но русское, то создать своё можно в любой момент, но смысл создавать своё, если появится, то только если сам язык будет интересным и приживётся, поэтому вначале лучше делать, через LLVM и тогда даже первые версии языка будут по качеству оптимизатора аналогичны С/С++ коду.

Мне нравится язык программирования D, он поддерживает кучу парадигм программирования и так же он использует кодировку UTF-8 благодаря которой в своих последних программах я использовал русский язык для всего, кроме ключевых слов.
Как вариант можно сделать форк данного языка, лучше форк компилятора ldc, который работает, через LLVM, перевести там всё на русский, может внести, что-то своё интересное и дальше развивать по своему пути.
И также перевести или написать заново стандартную библиотеку.

Это всё сложное дело и даже если идти по другому пути, то самое главное - это собрать сообщество единомышлеников, благодаря которому русский проект будет постоянно развиваться. И сообщество это тогда тоже будет расти. Думаю, что много людей захотели бы иметь свой родной язык программирования. По мере разрастания сообщества, шансы выжить у языка будут только расти. И тогда он начнёт завоёвывать популярность. И не важно, если только среди русских, нас 143 миллиона и это много, а если прибавить к этому Казахстан, Белоруссию, Украину и т.д., то это ещё больше.

Надо завести свой сайт языка, на котором выкладывать новости и документацию, например, как сайт dlang.org.
Вообщем нужно единое место для взаимодействия сообщества.
Так же у языка D есть репозиторий пакетов - очень удобная штука, для своего языка надо предусмотреть нечто подобное. Даже в С/С++ такого до сих пор не сделали.

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

(Я упомянул язык D потому, что это новый системный язык программирования, в нём учтены все современные парадигмы программирования, которые применяются в других современных языках, например ООП, обобщённое программирование, функциональное программирование, метапрограммирование, контракты, унитесты, параллельное программирование, срезы массивов, ассоциативные массивы и т.д. Думаю, что на данный момент - это лучший системный язык программирования, но пока не популярный из-за малого количества библиотек. Если делать русский язык, то лучше делать его системным, чтобы на нём можно было написать абсолютно всё.)

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

Отредактировано Yaisis (06.10.2014 21:13:11)

0

14

Юрий написал(а):

А какие претензии к государству? Государство - это прежде всего чиновники. А много ли чиновников понимает то, о чём мы пишем на этом форуме? Затащите кого-нибудь из "государевых слуг" и спросите, понимают ли они хоть что-нибудь из наших обсуждений. Нет, надеяться надо на себя и немного на инвесторов (если таковые вообще интересуются наукой и техникой).

Можно и так  ...а что делать? ))  Лебедев неплохая кандидатура как кандидат на спонсорство http://www.alebedev.ru/

Юрий написал(а):

Системное ПО (к которому компиляторы тоже относятся) на медленных языках пишут редко. Поэтому Лисп в этой области отдыхает, как правило

Да... отдыхают но скорее по другой причине а не из за какой то исключительной своей медлительностью. Современные Лиспообразные в том числе Ракета написаны и компилируется на С  ядро... из которого делаются примитивы Лиспа около 9 штук если не ошибаюсь, далее Лисп сам.. Когда то в досовские времена были свои на ассемблерах их так и называли Лисп-машины.. да и сейчас есть только ими не пользуются, ДОС морально устаревшая система.

Отредактировано robur (07.10.2014 21:33:14)

0

15

Yaisis написал(а):

Моё мнение - если делать язык программирования, то лучше для начала его делать под LLVM, так как не придётся разрабатывать свой оптимизатор и генераторы кода под все платформы и архитектуры, а можно сосредоточиться на самом языке и на библиотеках для него. Ведь если идёт речь о русском языке программирования, то библиотек там надо много создать.

  В общем интересное направление... но главного прорыва там не будет, только как один из этапов.

Yaisis написал(а):

За LLVM я вижу будущее - это хорошая технология

..сомневаюсь что  у них большое  будущее ,  как у свободного проекта, и это всё же не полноценная среда в отличие скажем java-машины со своей мини ОС образующей среду,  богатым набором библиотек, им просто не позволят подтянуть уровень, в режиме свободного проекта. В войне "виртуальных машин" им не выиграть у Майкрософт и Java даже со спонсорской помощью Гугл и Эпла.. только если они напрямую войдут в этот проект капиталами и своими ресурсами, но тогда проект перестанет быть свободным, со всеми вытекающими для нас.

Отредактировано robur (07.10.2014 22:57:01)

0

16

robur написал(а):

В общем интересное направление... но главного прорыва там не будет, только как один из этапов.

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

robur написал(а):

..сомневаюсь что  у них большое  будущее ,  как у свободного проекта, и это всё же не полноценная среда в отличие скажем java-машины со своей мини ОС образующей среду,  богатым набором библиотек, им просто не позволят подтянуть уровень, в режиме свободного проекта. В войне "виртуальных машин" им не выиграть у Майкрософт и Java даже со спонсорской помощью Гугл и Эпла.. только если они напрямую войдут в этот проект капиталами и своими ресурсами, но тогда проект перестанет быть свободным, со всеми вытекающими для нас.

Ну конечно, у каждого своё мнение, но у LLVM есть перед .NET и Java преимущества в том, как он реализован в виде модульной структуры. .NET не модульная, а на счёт Java не знаю.
Пока LLVM выглядит, как просто какой-то навороченный модульный компилятор, в .NET же мне нравится ещё то, что там есть общая стандартная библиотека, которая доступна из любого NET-языка. Думаю, что не плохо бы такую же иметь в LLVM.
А будущее у LLVM будет по любому, т.к. не будут все Линуксовские пакеты переходить ни на Яву, ни на NET, а на LLVM их можно уже компилировать. Так же есть реализация mono, через LLVM и думаю, что она и станет основной в будущем для проекта mono. Ну а mono - это реализация .NET.
Ну и по поводу Java скажу: Андроид в последней версии использует AOT компиляцию, которая по моим сведениям реализована, через LLVM, т.е. программы пишутся на Java, а компилирует их LLVM.
Также Adobe Flash реализован через LLVM.
И ещё куча всего сделано на базе LLVM.
И ещё скажу - LLVM - это не виртуальная машина в том смысле, как мы привыкли её видеть, хоть она и называется Low Level Virtual Machine, но она так называется потому, что оперирует байткодом в процессе компиляции, но это не значит, что она его выполняет - всё это зависит от задачи. Если вам понадобился JIT компилятор, как в Adobe Flash, то можете LLVM использовать таким образом, при этом вы можете выключить ненужные фазы оптимизации(а можете даже подключить свои собственные) и настроить машину на максимальную скорость, какая возможна в данной ситуации, например при JIT компиляции не нужны фазы оптимизации, которые обрабатывают inline функции, их можно отключить, а компиляция должна выполнятся максимально быстро, чтобы не тормозить программу. Если вы создали калькулятор(который будет выполняться на виртуальной машине с JIT компиляцией, калькулятор просто как пример, но для такой программы нет смысла всё это писать), то можно отключить все фазы оптимизации, которые обрабатывают условия и циклы, т.к. в вашем калькуляторе не будет ни условий, ни циклов. При JIT компиляции LLVM будет работать, как виртуальная машина. Но если вам понадобилось создать компилятор, как clang, то можно использовать полноценную компиляцию и LLVM в данном случае уже будет не виртуальная машины, а полноценный компилятор.
Ни .NET ни Java не являются такими универсальными и мощными конструкторами, как LLVM и они не позволяют сделать тоже самое, что можно сделать с помощью LLVM. Именно поэтому за LLVM будущее.

И ещё кое-что скажу по поводу LLVM, так как это интересно.
Вы же знаете наверно, что последняя операция в LLVM - это генераторы кода, которые описываются в специальном формате файлов для каждой архитектуры, т.е. в этих файлах описываются все регистры данной архитектуры, их взаимодействие и т.д. Аппаратно-зависимая оптимизация тоже включается на этой стадии и точно так же можно управлять фазами оптимизации и дописывать свои. Генераторы кода на основе всего этого описания компилируют байткод в машинный код данной архитектуры, но что самое интересное - это то, что можно провернуть и обратное действие, т.е. преобразовать код какой-то архитектуры в байткод LLVM(и такие проекты уже запущены в разработку). Т.е. открываются возможности, например взять любую x86 программу, преобразовать её в байткод LLVM, а потом этот байткод, например, скомпилировать в машинный код АРМ архитектуры. Или можно его просто заново оптимизировать, а потом снова скомпилировать в x86.
Ни .NET, ни Java такого не умеют и вряд ли в них когда-нибудь такое реализуют. Как я говорил, у них не модульная структура, у них нет такого мощного механизма, как фазы оптимизации и как генераторы кода, которые в LLVM создаются просто описанием в файлах(про генераторы кода), при этом похожие архитектуры могут иметь общие файлы.
А фаза оптимизации - это элементарная функция. Например фаза оптимизации по вставки inline функций - это просто функция с входными параметрами, которую вызывает LLVM, и которая если видит в своём параметре inline функцию, то вставляет её код в место её вызова(тут я примерно говорю, потому что не вникал в детальный механизм работы). Вся суммарная мощь оптимизатора - это куча элементарных фаз, которые по отдельности легче разбирать, дорабатывать и создавать, и которые описаны в отдельных модулях. И если в LLVM каждая фаза - это отдельный независимый модуль, которым можно управлять, подключать и отключать, то в .NET и Java оптимизация прописана сплошным кодом в тексте и так уже не поманипулировать.

Отредактировано Yaisis (08.10.2014 03:33:03)

0

17

Лебедев неплохая кандидатура как кандидат на спонсорство http://www.alebedev.ru/

Я думал, Вы про Артемия говорите. Это другой Лебедев, однако :)
Написать компилятор можно, в принципе, на любом языке. «Все языки эквивалентны». Если бы на этом форуме были поклонники Форта, они бы рассказали, как это прекрасно – писать компиляторы на Форте. Всё зависит от того, к какой секте Вы принадлежите :)

И ещё кое-что скажу по поводу LLVM, так как это интересно.
Вы же знаете наверно, что последняя операция в LLVM - это генераторы кода, которые описываются в специальном формате файлов для каждой архитектуры, т.е. в этих файлах описываются все регистры данной архитектуры, их взаимодействие и т.д. Аппаратно-зависимая оптимизация тоже включается на этой стадии и точно так же можно управлять фазами оптимизации и дописывать свои. Генераторы кода на основе всего этого описания компилируют байткод в машинный код данной архитектуры, но что самое интересное - это то, что можно провернуть и обратное действие, т.е. преобразовать код какой-то архитектуры в байткод LLVM(и такие проекты уже запущены в разработку). Т.е. открываются возможности, например взять любую x86 программу, преобразовать её в байткод LLVM, а потом этот байткод, например, скомпилировать в машинный код АРМ архитектуры. Или можно его просто заново оптимизировать, а потом снова скомпилировать в x86.

Да, я читал, что сделан компилятор из x86 в LLVM. Тогда, получается, вообще можно не париться, пиши себе код под х86, его всё равно когда-нибудь можно будет запустить на ARM – по мере развития LLVM.

0

18

Юрий написал(а):

Да, я читал, что сделан компилятор из x86 в LLVM. Тогда, получается, вообще можно не париться, пиши себе код под х86, его всё равно когда-нибудь можно будет запустить на ARM – по мере развития LLVM.

Теоретически да, а практически могут возникнуть проблемы. Допустим в x86 есть код по переводу процессора в защищённый режим, он программировался на ассемблере. В LLVM он наверно будет помечен, как ассемблерная вставка для конкретной архитектуры, т.к. я сомневаюсь, что в ассемблере LLVM будут аналогичные инструкции. Поэтому может получится так, что в одну сторону скомпилировать можно, но как поступить, если компилировать в обратную ? Конечно можно этот кусок кода опять вставить в байткод в виде ассемблерной вставки для конкретной архитектуры, но если потом компилировать байткод под другую архитектуру, которая во первых не понимает ассемблера предыдущей, а во вторых у неё даже нет такого понятия, как защищённый режим, то как компилировать данный код ? Тут я не знаю, как ведёт себя LLVM, но я предполагаю, что когда программисты делают ассемблерные вставки для конкретных архитектур, то они предусматривают алгоритм работы по-умолчанию для всех остальных, ну или для каждой делают вставку на её ассемблере и всё это по-идее хранится в байткоде, но если скомпилировать под конкретную архитектуру, то информация для остальных потеряется в получившейся программе. Если я прав в своих рассуждениях, то можно сделать вывод, что не со всеми программами можно будет провернуть такой трюк, трудности могут возникнуть особенно с системными. Поэтому лучше распространять программы в байткоде с AOT компиляцией, но к этому всё и стремиться.

Другой вариант - это если ассемблер LLVM имеет аналогичные инструкции от всех архитектур, тогда в байткоде не будут хранится не LLVM-мовские ассемблерные вставки, но всё равно надо как-то поступать с инструкциями, которые есть для одной архитектуры и нет аналогичных для другой.

Но конечно эта проблема решаема и может её решили как-то в LLVM.
Вообщем я не знаю таких тонкостей о LLVM.

Отредактировано Yaisis (08.10.2014 13:05:52)

0

19

Yaisis написал(а):

Ну конечно, у каждого своё мнение, но у LLVM есть перед .NET и Java преимущества в том, как он реализован в виде модульной структуры. .NET не модульная, а на счёт Java не знаю.

Да модульные они всё, только модули закрыты... и все включения новых модулей делаются через офис... а не по Вашей воле и за даром)), так задумано. Преимущество у LLVM одно он свободен и открыт.. Что кстати дает отличную возможность его " творческий переосмыслить"  :writing:  )).  Кстати Моno это Хамарин  а Хамарин под Майкрософт  ...который стоит на С#, C++ это такая стратегия у ник против Оракал с их Javой )) в продвижении своих продуктов на их территории.

0

20

Юрий написал(а):

Написать компилятор можно, в принципе, на любом языке. «Все языки эквивалентны».

  :nope:  Не все, чем меньше прокладок между машинным и языком разработки тем лучше.. ))

Отредактировано robur (08.10.2014 16:40:49)

0

21

Если исключить машинный код, то самой быстрой из "прокладок" считается Си. Си - это уже не Low Level Virtual Machine, а High Level Virtual Machine.

0

22

utkin написал(а):

Не все, чем меньше прокладок между машинным и языком разработки нем лучше.. ))Тогда почему Мелкософт пересл с С++ на C# в вин8? Основной средой заявлена Нет и все Апи идет через нее, оставшиеся прочие обещали из совместимости убить со временем либо перенести на Нет. Зачем же Мелкософту делать дополнительную прослойку? Очевидно гибкость и удобство разработки приоритетней скорости работы и прочих вещей.

И С#, C++ и Java это всё тот же С  "надстройками" для "классов" "объектов" всё это сводится к примитивам на С вся компиляция идёт через него..

0

23

robur написал(а):

Да модульные они всё, только модули закрыты... и все включения новых модулей делаются через офис... а не по Вашей воле и за даром)), так задумано. Преимущество у LLVM одно он свободен и открыт.. Что кстати дает отличную возможность его " творческий переосмыслить"    )).


Представьте любой компилятор и представьте, как там реализована оптимизация, допустим в том же gcc, который тоже пока не модульный. Так вот одно из отличий LLVM в том, что эта оптимизация разбита на элементарные действия, которые и вынесены в отдельные модули и которые легко подключаются и отключаются. Конечно я не видел кода .NET и Java, я только читал, что там не так, а используется традиционный подход.
И вы правильно заметили, что преимущество LLVM - это то, что он открыт для всех и благодаря этому многие пользуются именно им. Например Adobe Flesh не смогли бы реализовать эффективней ни на .NET ни на Java из-за их закрытости. А в LLVM же смогли включить только нужное.

robur написал(а):

Кстати Моno это Хамарин  а Хамарин под Майкрософт  ...который стоит на С#, C++ это такая стратегия у ник против Оракал с их Javой )) в продвижении своих продуктов на их территории.

Xamarin раньше назывался Novel. Раньше Майкрософт не имела к ним отношения, не знаю, как сейчас, но знаю, что некоторые технологии запрещены патентами к реализации в Mono. Если Макрософт заодно, то зачем запрещать ?

0

24

Юрий написал(а):

Если исключить машинный код, то самой быстрой из "прокладок" считается Си. Си - это уже не Low Level Virtual Machine, а High Level Virtual Machine.

Тут вы не правы или я вас не так понял.
Вы же знаете, что такое компилятор ?
У Си есть свои компиляторы, например GCC, который считается одним из лучших.
LLVM - это тоже компилятор, с помощью которого компилируется код.
Clang лишь преобразует код с языка Си в байткод LLVM.

Большинство компиляторов устроены следующим образом - есть лексический анализатор, который преобразует код с языка в какое-то промежуточное представление, потом к этому промежуточному представлению применяется оптимизатор, после чего оно преобразуется в машинный код. И все эти действия выполняются в одном файле(в одной программе) - этот файл и есть компилятор. Язык Си является одним из самых быстрых языков благодаря самому развитому оптимизатору. Но любой создатель своего языка пишет все эти действия в своём компиляторе заново. Так вот создатели LLVM решили вынести это промежуточное представление за компилятор - это промежуточное представление уже и есть байткод, они его проработали, чтобы с ним было максимально удобно работать. Они так сделали для того, чтобы отделить оптимизатор от компилятора, т.е. чтобы фазы компиляции вынести из одного файла в разные и в результате получилось три разных файла: 1)Преобразователь в байткод 2) Оптимизатор 3) Генератор в машинный код. Все их можно использовать по отдельности.
А какой смысл во всём этом ?
А смысл такой, что теперь можно написать любой язык программирования и он будет использовать тот же оптимизатор, что и в языке Си, т.е. качество оптимизации не будет зависеть от языка. Так же генераторы кода будут независимы. И не надо в каждом новом языке дублировать оптимизатор и генератор кода - не надо это каждый раз разрабатывать заново. И у такого подхода ещё куча преимуществ, например, лучшее тестирование оптимизатора и генераторов кода, т.к. все языки пропускаются через одни и те же программы. И т.д.

По качеству производимого кода LLVM уже на уровне GCC (+-), но пока в роли догоняющего.
Но и разработчики GCC тоже стали в роли догоняющего LLVM, они поняли, что появился мощный конкурент благодаря своей структуре и им надо что-то делать. И вот они стали разбивать свой GCC на части и он стремиться стать похожим на LLVM. Они уже вроде оптимизатор вынесли, но дальше я не в курсе уже. Не слежу за этим.

Поэтому прослойка, которая делает Си быстрым - это и есть GCC, LLVM или другой какой-нибудь компилятор данного языка. (Знаю только, что Borland делала плохие компиляторы.)

0

25

utkin написал(а):

Я Вас может разочарую, но в NET платформе нет компиляции в Си. Это байткод. Сама платформа суть интерпретатор, а не компилятор.

В последней версии .NET есть AOT-компиляция, т.е. компиляция перед выполнением, один раз, во все последующие всегда запускается уже скомпилированная нативная программа и это уже не интерпретатор. Только не знаю включена ли AOT-компиляция по-умолчанию, но понятно, что она будет включена в любом случае когда-нибудь. В Android L тоже уже включена по умолчанию AOT-компиляция(по моим сведениям) и код уже там выполняется нативно, а не в режиме виртуальной машины.

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

0

26

utkin написал(а):

Я Вас может разочарую, но в NET платформе нет компиляции в Си. Это байткод. Сама платформа суть интерпретатор, а не компилятор.

Байт код компилируется IL общий для все линейки языков системы это компромиссное решение (бизнес) исключение МС++ она может работать и на прямую минуя NEТ.   Сам же баит код это один из этапов компиляции в обще, просто в вируальных машинах он намеренно "раздут" во времени и пространстве дальнейшая его компиляция в машинный код у Майкрасофт делает компилятор который все же не интерпритатор (динамический компилятор) так вот он то же не на фортране раз на том конце не фортран)) А в документации по СIL  ясно сказано дословно CIL это подмножество Си только имеет меншее количество синтаксических форм.. (ц) ..он собирает все допустимые программы на Си, в нескольких основных конструкций с очень чистой семантикой.. ))  --

Отредактировано robur (09.10.2014 02:39:07)

0

27

Yaisis написал(а):

Xamarin раньше назывался Novel. Раньше Майкрософт не имела к ним отношения, не знаю, как сейчас, но знаю, что некоторые технологии запрещены патентами к реализации в Mono. Если Макрософт заодно, то зачем запрещать ?

В общем  скачал моно установил открыл а там во-от такая блямба Хамарин-студия.. )) ну думаю наверное сразу две скачал смотрю папки и правда вот папка моно.. моно там щелкаю ...и Хамарин опять занимает своё место ))) В общем без формы даром, с формой "инди" 25 баксов и далее по списку .. не смотрел правда в год или в месяц..  А то что сейчас имеет Майкрософт к ним отношение это по дизайну видно))

0

28

robur написал(а):

В общем  скачал моно установил открыл а там во-от такая блямба Хамарин-студия.. )) ну думаю наверное сразу две скачал смотрю папки и правда вот папка моно.. моно там щелкаю ...и Хамарин опять занимает своё место ))) В общем без формы даром, с формой "инди" 25 баксов и далее по списку .. не смотрел правда в год или в месяц..  А то что сейчас имеет Майкрософт к ним отношение это по дизайну видно))

Фирма называется теперь у них Xamarin, среда разработки - Xamarin Studio, раньше называлась Monodevelop, конечно они её переделали, но общие черты остались.
Реализация .NET называется Mono.
Есть реализация .NET, через LLVM, называется mono-llvm. Думаю, что эта реализация станет основной.

После того, как фирма стала называться Xamarin(или одновременно с этим), она выпустила свою Xamarin Studio, на которой решила зарабатывать, что и видно по вашему комментарию.
А Майкрософт конечно хочет, чтобы его .NET распространилась, она её так и задумывала, как кроссплатформенную технологию, но делать под другие платформы не хочет, сделала только под Виндовс, что и понятно. И конечно ей тогда выгодно, что появилась такая фирма, как Xamarin, которая сама всё сделает, а Майкрософт вроде с ней исходниками делится, ну или в общий доступ открывает, то, что касается .NET, естественно выборочно.

Вроде раньше ещё новость промелькала, где было написано о том, что Майкрософт возможно купит Xamarin, но не знаю, купила она её или нет.

0

29

Utkin написал(а):

и на прямую минуя NEТ. Это исключение, а не практика.

Да нет, к примеру читал библиотека классов NET полностью идет через МС++ как объясняется для быстродействия.. В обще идея склада, фабрики готовых полуфабрикатов кода интересная.. и была бы полезной если бы она была всеобщей так сказать..

Отредактировано robur (09.10.2014 11:33:37)

0

30

Юрий написал(а):

Если исключить машинный код, то самой быстрой из "прокладок" считается Си. Си - это уже не Low Level Virtual Machine, а High Level Virtual Machine.

В общем Си это "наше Всё" с него его компилятора видимо нужно и начинать. Был С станет к примеру РУС )) его структура оптимальна и проверена временем , можно сразу подразумевать с плюсами в смысле ООП  ..ну чтоб два раза не ходить.

0

31

Yaisis написал(а):

robur написал(а):В общем  скачал моно установил открыл а там во-от такая блямба Хамарин-студия.. )) ну думаю наверное сразу две скачал смотрю папки и правда вот папка моно.. моно там щелкаю ...и Хамарин опять занимает своё место ))) В общем без формы даром, с формой "инди" 25 баксов и далее по списку .. не смотрел правда в год или в месяц..  А то что сейчас имеет Майкрософт к ним отношение это по дизайну видно))Фирма называется теперь у них Xamarin, среда разработки - Xamarin Studio, раньше называлась Monodevelop, конечно они её переделали, но общие черты остались.Реализация .NET называется Mono.Есть реализация .NET, через LLVM, называется mono-llvm. Думаю, что эта реализация станет основной.
            После того, как фирма стала называться Xamarin(или одновременно с этим), она выпустила свою Xamarin Studio, на которой решила зарабатывать, что и видно по вашему комментарию.А Майкрософт конечно хочет, чтобы его .NET распространилась, она её так и задумывала, как кроссплатформенную технологию, но делать под другие платформы не хочет, сделала только под Виндовс, что и понятно. И конечно ей тогда выгодно, что появилась такая фирма, как Xamarin, которая сама всё сделает, а Майкрософт вроде с ней исходниками делится, ну или в общий доступ открывает, то, что касается .NET, естественно выборочно.
            Вроде раньше ещё новость промелькала, где было написано о том, что Майкрософт возможно купит Xamarin, но не знаю, купила она её или нет.

В обще это стандартная практика ... коммерческие ребята  всегда бдят за свободным сообществом... как только им кажется что это будет иметь коммерческие перспективы они прибирают это к рукам.. Бил Гейтс на этом собаку в молодости съел.. и не одну ))

Отредактировано robur (09.10.2014 11:53:34)

0

32

В общем Си это "наше Всё" с него его компилятора видимо нужно и начинать. Был С станет к примеру РУС )) его структура оптимальна и проверена временем

Когда мы встречались 30 августа, то и пришли к тому, что лучше всего (пока) - генерировать код на Си.
Кстати, Дмитрий спросил меня, а как называется моя утилита русификации. Ответил, что никак. Вы подсказали идею, её можно назвать "РуСи" :)

Тогда почему Мелкософт пересл с С++ на C# в вин8? Основной средой заявлена Нет и все Апи идет через нее, оставшиеся прочие обещали из совместимости убить со временем либо перенести на Нет. Зачем же Мелкософту делать дополнительную прослойку? Очевидно гибкость и удобство разработки приоритетней скорости работы и прочих вещей.

Жизнь их поправит :) Они и кнопку "Пуск" уничтожили, но отыграли назад. "Интел" тоже думал, что "Итаниум" возьмёт верх. Однако нет, инерция потребителей заставила вернуться на х86. Да не просто на х86, а на х86-64 - разработку конкурентов АМД. Не всегда монополисты повелевают рынками. Рынки тоже ведь кормят деньгами только тех, кто далает нужные ему вещи.

0

33

Юрий написал(а):

Когда мы встречались 30 августа, то и пришли к тому, что лучше всего (пока) - генерировать код на Си.
Кстати, Дмитрий спросил меня, а как называется моя утилита русификации. Ответил, что никак. Вы подсказали идею, её можно назвать "РуСи"

Жизнь их поправит  Они и кнопку "Пуск" уничтожили, но отыграли назад. "Интел" тоже думал, что "Итаниум" возьмёт верх. Однако нет, инерция потребителей заставила вернуться на х86. Да не просто на х86, а на х86-64 - разработку конкурентов АМД. Не всегда монополисты повелевают рынками. Рынки тоже ведь кормят деньгами только тех, кто далает нужные ему вещи.


Макрософт не для того развивала .NET, чтобы потом вернуться на Си.
Благодаря .NET программы у них станут платформеннонезависимые. Вон уже в Виндовс 10 говорят, что программы будут работать на любых устройствах и на десктопах, и на планшетах и на смартфонах и т.д.
А благодаря AOT-компиляции эти программы будут не медленнее Си и могут быть даже быстрее, т.к. будут компилироваться на самом устройстве и оптимизатор может задействовать все особенности архитектуры по-максимому. Для сравнения скомпилированные программы на С/С++ обычно распространяются в версиях под архитектуру 386 или 686.

0

34

utkin написал(а):

Насколько мне известно Нет программы не умеют работать без НЕТ платформы. Поэтому это интерпретация. Тот низкоуровневый язык все равно интерпретируется средой исполнения.


Я говорил про AOT-компиляцию, если она используется, то это уже не интерпретация, а сгенерируется полноценный машинный код, точно такой же, как генерируют компиляторы других языков.
Но .NET будет на устройстве для того, чтобы во первых скомпилировать байткод в машинные инструкции, также стандартная библиотека будет подключатся в виде внешней библиотеки. Но получившаяся программа не будет выполнятся в режиме интерпретации или JIT компиляции - будет полноценный нативный код.

Только я не знаю используется ли уже AOT-компиляция в .NET или она только будет включена в будущем.

0

35

robur написал(а):

В общем Си это "наше Всё" с него его компилятора видимо нужно и начинать. Был С станет к примеру РУС )) его структура оптимальна и проверена временем , можно сразу подразумевать с плюсами в смысле ООП  ..ну чтоб два раза не ходить.


Конечно язык С/С++ очень быстрый благодаря своему компилятору, но сам синтаксис языка устарел и обрастает костылями, чтобы догнать современные языки. Из-за совместимости приходится делать, как получается, чтобы не нарушить старых принципов работы, но это не всегда удобно.

Есть языки, которые придуманы, как замена С/С++ - это такие языки, как D, Rust, Go. И вот там всё уже с нуля разрабатывали, чтобы сделать максимально удобно.

С/С++ популярен сейчас из-за огромного количества библиотек и программ на нём.

А новый язык должен быть такой же быстрый, как С/С++ и такой же удобный, как Питон, D и т.д.

0

36

utkin написал(а):

Обычная программа на каком-нибудь c# не способна выполняться без среды выполнения. Именно не библиотек (без них естественно не способна), а без среды исполнения. Я понимаю, что вы говорите о возможностях. Я говорю о практике - Программы не компилируются для процессора, они компилируются для платформы. И потом платформа их выполняет. Конечно включив там всякие опции Вы возможно и добьетесь своего, но подавляющая часть программ этим не занята. Потому Ваш аргумент не аргумент - НЕТ это прослойка и она удобна для разработчика (Мелкософт).


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

Вы говорите о компиляции в байткод под виртуальную машину(ВМ), впоследствии ВМ или интерпретирует байткод или использует JIT-компиляцию - это быстрая компиляция наиболее ресурсоёмких участков кода с плохой оптимизацией.
Теперь ещё появилась AOT-компиляция, которая из байткода делает обычную программу, точно такую же, как получается после компилирования, например, Си кода, т.е. интерпретации в таком случае больше нет.
Вы можете просто взять AOT-компилятором скомпилировать байткод программы в машинный код архитектуры, добавить необходимые библиотеки и без ВМ запустить получившуюся программу.

Вот, почитайте:
http://en.wikipedia.org/wiki/Ahead-of-time_compilation              - это про то, что такое AOT-компиляция
http://dlang.ru/205-csharp-poluchit-aot-kompilyator                  - а тут новость, что C# будет её поддерживать

Отредактировано Yaisis (09.10.2014 22:47:50)

0

37

Utkin написал(а):

Скрестили Ежа с Ужом. Либо удобство либо скорость причем тенденция на удобство. Я вот не пойму зачем Вам "также быстро как и Си"? Какой класс задач Вы собрались решать на своем гипотетическом языке?


А вы знаете такой язык D - он почти такой же быстрый, как С/C++ и почти такой же удобный, как Питон.
А знаете такой язык Rust ?  - про него можно сказать тоже самое.

А теперь ответ на ваши вопросы:
1) На этом форуме мы обсуждаем русский язык программирования, который обязательно должен быть системным и быстрым, поэтому он должен быть, как С/С++ по скорости.
2) Если не сделать его таким же удобным, как современные языки, то он будет никому не нужен, потому что то, что получится - этого итак навалом.
3) Если сделать его быстрым, как С/С++ и настолько же удобным, то никто им не будет пользоваться, т.к. С/С++ уже есть и лучше перейти на D, Rust, Go, чем на это новое подделие, потому что те языки намного удобнее и наглядней, а по скорости почти такие же(может даже без почти).
4) Если сделать язык очень удобный, но по скорости, как Питон и Руби, то зачем нужен такой русский язык, когда для программирования системы придётся всё равно пользоваться иностранными. Конечно, если вы хотите ещё одну 1С сделать или какой-то специализированный язык...(но для чего ?), то пожалуйста, но к нему будут относиться, как ещё к одному ограниченому языку среди многих.

Utkin написал(а):

Скрестили Ежа с Ужом. Либо удобство либо скорость причем тенденция на удобство.

У вышеназванных языков это получилось.
Причём например системный язык программирования D можно использовать в качестве скриптового языка, а по скорости он как С/С++(Питон ему не конкурент).
А тенденция, как раз и на удобство и на скорость.
Удобные языки C#, Java снабжают AOT-компиляторами, которые их сделают по скорости почти, как С/С++. - это стремление к скорости.
Разработчики языков D, Rust, Go при стремлении сохранить и даже увеличить с помощью встроенных средств расспараллеливания скорость С/С++ так же стремятся к удобству внедряя в свои языки кучу полезных функций из Питона, Хаскеля, С# и т.д. Такие, как метапрограммирование, функциональное программирование, обобщённое программирование, делегаты, замыкания, ассоциативные массивы, срезы массивов, сравнение с образцом, встроенные средства параллельного программирования, унитесты, контракты и много ещё всего интересного.

Отредактировано Yaisis (09.10.2014 23:22:35)

0

38

utkin написал(а):

Вы равняетесь на наличие возможности, а не на использование возможности. Компиляция есть в нативный код, но она практически не используется. А используется повсеместно прослойка.

Пока не используется, т.к. ещё время не пришло.
В доступных версиях Android можно в настройках поставить AOT-компиляцию, она там не включена по-умолчанию, т.к. ещё экспериментальная.
В Android L будет использоваться компиляция по-умолчанию, а не интерпретация.
По поводу же .NET, то я думаю, что в Windows 10 будет использоваться компиляция по-умолчанию. А пока она только появилась и является экспериментальной функцией.
Поэтому стремление к скорости на лицо, но не всё же так быстро делается, сейчас такое время, когда это вот вот начнут использовать, как только доделают.
Мы же говорили о стремлении, а не о текущем положении дел.

utkin написал(а):

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

Совсем не согласен.
Я например часто пользуюсь метапрограммированием в D. И без этого было бы не удобно мне.
Это всё добавляется для того, чтобы сделать язык более удобным, чтобы у программистов было больше вариантов решения задачи, а к каждой задачи нужен свой подход. Где-то лучше использовать ООП, где-то лучше метапрограммирование, где-то что-то другое...
Срезы массивов вообще повсеместно используют в D, а ассоциативные массивы - это очень удобная штука, наверно во всех языках есть в виде библиотеки, а в D встроена эта возможность.

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

Utkin написал(а):

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

Я на Rust не ориентируюсь, я вообще пока его почти не знаю, но то, что я знаю о нём даёт мне повод приводить его как пример в качестве языка, где "Скрестили Ежа с Ужом", именно поэтому я его упомянул. Идеалом его не называю, пока из всех языков, которые я знаю, мне больше нравится D.

Отредактировано Yaisis (10.10.2014 15:33:45)

0

39

Юрий написал(а):

Когда мы встречались 30 августа, то и пришли к тому, что лучше всего (пока) - генерировать код на Си.Кстати, Дмитрий спросил меня, а как называется моя утилита русификации. Ответил, что никак. Вы подсказали идею, её можно назвать "РуСи"

  Всегда пожалуйста  8-)

0

40

utkin написал(а):

Это не аргумент. С Явы в экзе давно компилировать можно, но не взлетает однако же.


Аргумент, т.к. в Android L это будет по-умолчанию, а смартфоны на нём пойдут скоро.
Да и что вы заладили аргумент, не аргумент, если это будущее, все производители развиваются в данном направлении и совсем скоро это будет использоваться везде. Технология уже готова и она тестируется. По вашему они сделали её просто так ? Чтобы потом не использовать ?
И ещё раз назову Android L и Windows 10 - там это будет использоваться заместо виртуальной машины. И это аргумент.

utkin написал(а):

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


Ну во первых исходники можно компилировать в любой ОС.
Во вторых компиляция байткода с уже выполненной архитектурно-независимой оптимизацией выполняется намного быстрее, чем компиляция исходников на С/С++. И всё идёт в сторону развития распространения программ в байткоде с последующей компиляцией в машинный код.
В третьих Андроид - это ОС, а Линукс - это ядро. Андроид - это не переделанный Линукс, а это ОС на базе ядра Линукс.
Ну и например попробуйте скомпилировать из исходников на C/C++крупный проект, замерьте время, а потом тот же проект скомпилируйте с помощью LLVM в байткод LLVM, после чего скомпилируйте байткод LLVM в машинный код и замерьте время этого последнего действия(компиляции байткода в машинный код) и сравните с первым замером. А потом уже сравните, что является шагом назад.
Из вашего же примера по  нынешнему распространению программ, я могу привести кучу недостатков, которые все устраняет способ по распространению программ в байткоде с AOT компиляцией и не привносит ни каких новых недостатков.

utkin написал(а):

Так 10-ка уже есть, можете потестить нахаляву.

Я пользуюсь ОС на базе Линукс и Виндовсами не увлекаюсь.

utkin написал(а):

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

Ну вы имеете право иметь своё мнение, только уверен, что у большинства оно другое.
Моё мнение, если хоть, чем-то можно улучшить язык, то надо это вводить в него и даже если парадигмы незначительные, то их ввод всё равно принесёт только пользу.
И опять же могу привести пример с метапрограммированием, с помощью которого совместно с ОПП в D можно реализовать нечто подобное ТаблицеЗначений из 1С с добавлением к этому типу функциональности регистров сведений и применения механизма запросов к нему, как это реализовать без метапрограммирования я не знаю и по-моему это невозможно. Поэтому одно ООП - это мало. А если вы взгляните на стандартную библиотеку D, то там метапрограммирование используется очень часто для генерации кода и тех же самых классов на лету в зависимости от условий и всё генерируется во время компиляции, а не во время выполнения.

Или возьму функцию по проще, например ЗаполнитьЗначенияСвойств из 1С, в которую передаётся объект источник и объект приёмник(ну и ещё есть поля, в данном случае не важны), а дальше эта функция связывает реквизиты источника с приёмником по их наименованию и копирует значение из источник в соответствующий приёмник.

Если взять язык Си и написать такой код:

struct A {
   int a, b, c;
}

struct B {
   int b, d, c;
}

И написать:

A a;
B b;
ЗполнитьЗначенияСвойств(A, B);

В результате эта функция должна сделать следующее:
a.b = b.b;
a.c = b.c;

Так вот возможно ли в C/C++ создать такую функцию ?
(на сколько я знаю в D такое сделать реально)

utkin написал(а):

В D есть небезопасные ссылки а-ля Cи?

В D есть всё, что и в Си, и даже больше, контроль безопасности можно отключать и пользоваться указателями, как в Си.
Так же в D есть сборщик мусора, который тоже можно отключать.
Вы же читали о D("Читал, но не юзал."), что тогда спрашиваете ?
Значит плохо читали.
Да и я уже понял, что у вас другие идеалы, а свои я вам не навязываю.

Отредактировано Yaisis (10.10.2014 16:33:08)

0

41

Yaisis написал(а):

Конечно язык С/С++ очень быстрый благодаря своему компилятору, но сам синтаксис языка устарел и обрастает костылями, чтобы догнать современные языки. Из-за совместимости приходится делать, как получается, чтобы не нарушить старых принципов работы, но это не всегда удобно.

Ну да структура "речи" в этой "модели" там по сравнению с Java и С# несколько тягучая но это поправимо, по крайней мере в русской вариации ))   

Yaisis написал(а):

С/С++ популярен сейчас из-за огромного количества библиотек и программ на нём.

Именно компилятор и куча библиотека выделяют его из общего ряда.. Видимо им больше всех пользовались )).

Yaisis написал(а):

Есть языки, которые придуманы, как замена С/С++ - это такие языки, как D, Rust, Go. И вот там всё уже с нуля разрабатывали, чтобы сделать максимально удобно.

  Да есть  языки и не только эти которые могут дать фору С С++ в удобстве структуры для самовыражения )) Но у них недостаток они говорят по английский.  В обще я думаю так, любая структура развитого ЯП да и любого естественного языка должна уметь отвечать на определённые вопросы, на которые человеку приходится давать ответы, в данном случае "железу", и чем вопросы эти лучше сформулированы, системны а не представляют из себя бардак и "немые вопросы" на которые не знаешь что ответить, тем отвечать будет проще и тем язык совершеннее. Сюда же можно отнести и наше стремление и к Русскому языку, русской грамматике, это ведь она строит письменную речь, точнее она зафиксировала эти правила из жизни. И именно она подскажет как лучше.. говорить  с железом, раз справилась в этом с человеками то с железяками и подавно.

Отредактировано robur (10.10.2014 17:09:41)

0

42

utkin написал(а):

Суть одна.

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

utkin написал(а):

Я читал общий обзор, и там тоже много восторга было. А мне хочется деталей .

Ну я ответил на ваш вопрос и даже скажу больше - разработчики D сохранили некоторую совместимость с C/C++, ту, которая не портит языка. И поэтому, если скомпилировать код С/С++ компилятором D, то он либо будет работать, при этом будет работать абсолютно правильно, либо не будет работать вообще. Что облегчает портирование программ на язык D, т.к. необходимо изменять только нерабочие участки кода, а в рабочих можно быть уверенным, что они работают правильно.

0

43

robur написал(а):

...

Ещё можно использовать язык математики - он международный и понятен всем или многим.
А можно смешать русский с математическим.

Я когда давно диплом писал, то в разделе математического описания алгоритма главная часть моей программы выглядела компактно, понятно и без излишеств, но когда я стал это всё программировать на С/С++, то появилась куча циклов и т.д. И код сильно разбух, а я подумал, что плохо, что нельзя всё было записать математически и чтобы это сразу было программой, ну и работало со скоростью Си, чтобы компилятор сам это разбил на циклы и т.д.

Конечно во всяких матлабах так наверно можно писать, но матлаб - это не то.

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

Отредактировано Yaisis (10.10.2014 20:13:54)

0

44

Yaisis написал(а):

Ещё можно использовать язык математики - он международный и понятен всем или многим.А можно смешать русский с математическим.

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

Отредактировано robur (10.10.2014 17:24:29)

0

45

Yaisis написал(а):

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

А Вы не задавались себе вопросом почему  именно байт кодом, а не бинарным, скажем шифрованным, оперируют виртуальные машины..  Там ведь от байт кода до бинарного кода исполнения "пару тактов" он ведь исполняется быстрее и хранится точно так же как байт код, почему не сделали сразу "ход конём"? ))

0

46

robur написал(а):

А Вы не задавались себе вопросом почему  именно байт кодом, а не бинарным, скажем шифрованным, оперируют виртуальные машины..  Там ведь от байт кода до бинарного кода исполнения "пару тактов" он ведь исполняется быстрее и хранится точно так же как байт код, почему не сделали сразу "ход конём"? ))

Ничего не понял, но попробую ответить.
Виртуальная машина - это вымешленный компьютер, который не реализован на аппаратном уровне, т.е. байткод отличается от машинного кода только тем, что он написан под не существующий процессор.
Думаю, что байткод в первую очередь придумали для кросплатформенности, чтобы во первых не было зависимости от архитектуры.
Во вторых, если бы Оракл использовал в качестве байткода машинные инструкции x86 например, то могли бы возникнуть проблемы с Интел, т.к. пришлось бы покупать лицензию в случае, если бы Оракл решил создать аппаратное ускорение. Раньше я читал, что существуют процессоры, которые выполняют явовский байткод на аппаратном уровне, ну или ускоряющий его - детально не разбирался с данным вопросом.
В третьих байткод более продуман для реализации задуманых целей и поэтому является удобней существующих машинных кодов(предполагаю), в частности байткод LLVM - это RISC архитектура с бесконечным количеством регистров, т.е. регистров хватит для всего, но ни одна современная аппаратная архитектура не сможет такое предоставить, поэтому в данном случае эта вымышленная архитектура удобней и в ней ещё куча других удобств по сравнению с обычными процессорами.

Про "пару тактов" - это неверно. Программы в режиме интерпретации выполняются намного медленнее, чем нативные. В последнее время скорость виртуальных машин сильно ускорили JIT-компиляции байткода. Например я писал программу на C#, которая выполнялась за 10 секунд, потом я переписал её на Си не меняя основных алгоритмов и она стала выполнятся за 6 секунд. Т.е. C# по скорости уже достаточно быстрый. А АОТ-компиляция вообще должна сделать его на одном уровне с С/С++.

И ещё я вспоминаю про скорость работы явовского байткода, когда думаю например об такой среде разработки, как Eclipse, которая всегда тормозит(может и не тормозит, но дискомфорт в работе создаёт из-за своей скорости) у меня, ни одна другая среда так медленно не работала.

Ну и так же не понял я, при чём тут шифрование ?

0

47

robur написал(а):

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


Дело в том, что любой алгоритм можно описать с помощью математики, а "Буря мглою небо кроет вихри снежные крутя то как зверь она завоет то заплачет как дитя" - это вообще не из области программирования.

Так раньше люди хотели создать язык программирования, в котором программа будет писаться точно так же, как люди общаются, например на русском языке:

Код:
Обойти все элементы массива и подсчитать количество разных чисел в нём, 
затем вывести результат на экран в две колонки, 
в первой указать число, 
а во второй - количество вхождений его в массив.  
Данные о каждом новом числе выводить в новой строке, под предыдущей. 
Числа должны выводиться в порядке возрастания.

Конечно хорошо бы иметь такой язык, но его сложно сделать, в результате аналогичный код выглядит примерно так, на D(а математически можно более кратко записать):

Код:
import std.stdio;
void main() {
   int Массив[] = [1,2,3,4,2,3,1,1];
   int[int] СписокЧисел;
   foreach(Число; Массив) {
      СписокЧисел[Число]++;
   }
   foreach(Число; СписокЧисел.keys.sort) {
      writeln("Число: ", Число, ", количество вхождений: ",СписокЧисел[Число]);
   }
}

Отредактировано Yaisis (10.10.2014 23:42:28)

0

48

Yaisis написал(а):

Думаю, что байткод в первую очередь придумали для кросплатформенности, чтобы во первых не было зависимости от архитектуры.

Да? )) какая же это кроссплатформенная независимость если для неё нужна платформа виртуальная, а для исполнение  бинарников  не нужно никаких особых и сложных сред в виде виртуальных машин что бы обеспечить их аппаратную платформо-независимость..  32 разряда он на Линкусе 32..

Yaisis написал(а):

Во вторых, если бы Оракл использовал в качестве бай ткода машинные инструкции x86 например, то могли бы возникнуть проблемы с Интел, т.к. пришлось бы покупать лицензию в случае, если бы Оракл решил создать аппаратное ускорение.

Ну так до бинарников ведь все равно дело доходит, непосредственное исполнение ...правда? И бинарник от Оракл или тебя, или меня никакого отношению к Интел не имеет, это произведение ему не принадлежит.  )) И Интел по этому поводу ни гу-гу.

Yaisis написал(а):

байткод более продуман для реализации задуманых целей и поэтому является удобней существующих машинных кодов(предполагаю)

Байт код это этап трансляции, его можно  встретить в любом компиляторе или интерпретаторе во время работы.. если поковыряться. Следующие этап это ассемблирование, и далее машинный код. Чего тут может быть эффективнее уже готовых бинарников.  :dontknow:

Yaisis написал(а):

Про "пару тактов" - это неверно. Программы в режиме интерпретации выполняются намного медленнее, чем нативные.

Ну так режиму интерпретации чем могут помешать бинарные коды организуй их соответственным образом и будет обрабатывать исполнять строками... Здаётся мне что "виртуальные машины" служат другой цели, а именно занят пространство и место под солнцем лично для себя.. а не для оптимизации управления, скорости вычислительных процессов  :suspicious:  ..))

Отредактировано robur (10.10.2014 22:00:32)

0

49

Yaisis написал(а):

Дело в том, что любой алгоритм можно описать с помощью математики, а "Буря мглою небо кроет вихри снежные крутя то как зверь она завоет то заплачет как дитя" - это вообще не из области программирования.
Так раньше люди хотели создать язык программирования, в котором программа будет писаться точно так же, как люди общаются, например на русском языке:

  :)  Очень даже из области программирования и именно из области ООП... Мечтаете ведь о мета программировании... ? )) А с помощью этого высокоуровневого  исходника (тела функции )можно изобразить  переведя (ничего не поделаешь) правда его на уровень ниже, скажем С++ или какого ни будь из Лиспов библиотеки GL и  OpenAL, всю картину, в ведя нужные параметры в аргументы переменных, включая завывание и плач, то есть отобразить функцию на мониторе.)) Разве это не  алгебра..?

Отредактировано robur (10.10.2014 21:55:20)

0

50

robur написал(а):

Да? )) какая же это кроссплатформенная независимость если для неё нужна платформа виртуальная...

Именно, сама платформа конечно делается под разные архитектуры и ОС и тем самым её байткод выполняется везде. Как пример Java, которая работает везде - и в виндовсе, и в линуксе, и на телефонах, и на планшетах, и на x86, и на ARM , и на MIPS, и т.д. Портировать одну платформу под все эти ОС и архитектуры намного легче и быстрее, чем писать все созданные программы под каждое из перечисленного, поэтому программы в байткоде становятся кросплатформенными хоть и зависят от виртуальной машины.
Конечно вы скажите можно распространять в исходниках и компилировать - на что я скажу, что не все хотят открывать исходники.
И точно так же я скажу, что большинство разработчиков компилируют только под одну платформу, например x86 и Windows.
Но если разработчики не открывают исходники и не хотят компилировать под все платформы свои программы, то как сделать так, чтобы их программы были кроссплатформенными ?
И вот люди придумали создать виртуальную машину типа Java, .NET и т.д. и привлечь разработчиков, чтобы писали свои программы под эти ВМ, а об кроссплатформенности позаботятся разработчики виртуальных машин.

robur написал(а):

а для исполнение  бинарников  не нужно никаких особых и сложных сред в виде виртуальных машин что бы обеспечить их аппаратную платформо-независимость..  32 разряда он на Линкусе 32..

Ну да, ну да...
Попробуйте ка запустите AutoCad на Линукс, ARM или MIPS.
И попробуйте тоже самое провернуть с любой Java программой.
И тут я опять вспомню про AOT-компиляцию - с таким компилятором не нужно наличие ВМ и это круче, чем компилировать программы из исходников. AOT-компилятор превратит байткод в ваш любимый бинарник и при этом максимально подстроит его под ваш компьютер, что опять же намного круче, чем распространять заранее скомпилированные программы.

robur написал(а):

Ну так до бинарников ведь все равно дело доходит, непосредственное исполнение ...правда? И бинарник от Оракл или тебя, или меня никакого отношению к Интел не имеет, это произведение ему не принадлежит.  )) И Интел по этому поводу ни гу-гу.

Ну вы не внимательно читаете то, что я пишу, поэтому повторю: Если Оракл создаёт программное обеспечение, то Интел вряд ли предьявит притензии, но если Оракл решит создать свой процессор, который будет оперировать инструкциями Интел, то он обязан у Интел купить лицензию на машинные инструкции, иначе Интел его засудит. Точно такие же лицензии у Интел купили AMD и VIA. И оперировать специально-разработанным байткодом намного легче, чем машинными инструкциями, где нет вспомогательной информации, как пример я вам опять напомню о LLVM - сравните инструкции и гибкость байткода этой ВМ с инструкциями процессора x86. Кроме уже названного бесконечного количества регистров в LLVM, сами регистры в ней могут иметь любую разрядность - в x86 нет ничего подобного и никогда не будет. Байткод LLVM - это представление идеальной виртуальной архитектуры, а на практике такого процессора не будет никогда. Зачем для байткода использовать ограниченные реальные архитектуры ?

robur написал(а):

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

Извините, но чушь.
Что такое ассемблирование ? Вы этот термин сами придумали ?
Язык Ассемблер - это наглядное словестное представление машинных инструкций(плюс бывают вспомагательные облегчения написания кода, например ООП). Компилятору не нужно переводить его байткод в ассемблер, он его переводит сразу в машинные инструкции. Ассемблер нужен только для человека.
Тот байткод, который вы встретите в любом компиляторе - придуман специально для этого компилятора и в нём неудобно распространять программы. Например в GCC этот байткод имеет ссылки на исходный текст, который может иногда понадобится. В LLVM же байткод специальный, для виртуальной машины и его полностью отвязали от исходного текста.

robur написал(а):

Чего тут может быть эффективнее уже готовых бинарников.

То, что байткод не привязан ни к одной архитектуре - этим он и эффективней перед бинарниками.
Как писал выше в LLVM бесконечное количество регистров, а в x86 и в ARM оно ограничено. При этом в x86 намного меньше их. Вы предлагаете скомпилировать программу под x86 и так распространять ? А как эту же скомпилированную программу потом портировать на ARM, только представьте сколько трудностей возникнет. У LLVM же - универсальный байткод, который можно без проблем скомпилировать под любую архитектуру. Разработчики LLVM учли особенности всех существующих архитектур.

robur написал(а):

Ну так режиму интерпретации чем могут помешать бинарные коды организуй их соответственным образом и будет обрабатывать исполнять строками... Задаётся мне что "виртуальные машины" служат другой цели, а именно занят пространство и место под солнцем лично для себя.. а не для оптимизации управления, скорости вычислительных процессов    ..))

Тут я ничего не понял.
Судя по всему вы предлагаете скомпилировать байткод или не понятно что вы имеете ввиду.
Если его скомпилировать, то это уже будет не интерпретация, а я говорил именно о данном термине.
Конечно Java и .NET хотели занять пространство под солнцем, т.к. их делали коммерческие фирмы.
LLVM же я считаю технологией будущего - это и ВМ и компилятор одновременно.
Конечно по 100 раз вам объяснять о всех преимуществах данной технологии и видеть, что вы видимо не понимаете, о чём я пишу - это сложно.
Скажу ещё, что я сам раньше продумывал такую технологию, как LLVM для того, чтобы принести в мир лучшее, чем то, что существует, но вряд ли бы я это когда-нибудь реализовал, и поэтому, когда я читал описание LLVM я был очень рад, что наконец хоть кто-то это воплотил в жизнь. Я понял, что в LLVM есть всё, что я хотел иметь в своей технологии, но при этом мне уже не надо ничего делать.
И я советую вам детально ознакомится с тем, что такое LLVM и тогда вы может поймёте, чем она лучше ваших бинарников.

Отредактировано Yaisis (10.10.2014 22:37:32)

0

51

Yaisis написал(а):

Что такое ассемблирование ? Вы этот термин сами придумали ?

   :) (ц)/Вика/ ..Ассемблирование может быть не первым и не последним этапом на пути получения исполнимого модуля программы. Так, многие компиляторы с языков программирования высокого уровня выдают результат в виде программы на языке ассемблера, которую в дальнейшем обрабатывает ассемблер. Также результатом ассемблирования может быть не исполнимый, а объектный модуль, содержащий разрозненные блоки машинного кода и данных программы, из которого (или из нескольких объектных модулей) в дальнейшем с помощью редактора связей может быть получен исполнимый файл... https://ru.wikipedia.org/wiki/%D0%90%D1%81%D1%81%D0%B5%D0%BC%D0%B1%D0%BB%D0%B5%D1%80       

Yaisis написал(а):

Судя по всему вы предлагаете скомпилировать байткод или не понятно что вы имеете ввиду.

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

0

52

Yaisis написал(а):

на сколько я знаю в D такое сделать реально

А он под какой лицензией ?  ...что то я вменяемого ответа не нашёл в нэте..

0

53

utkin написал(а):

Прежде чем отметать задачу, попробуйте сначала попытаться ее решить.

Ну конечно можно попутаться описать это матиматикой. я вначале писал "хотя можно попробывать...", но потом удалил ту строчку.

utkin написал(а):

Конечно хорошо бы иметь такой язык, но его сложно сделать, в результате аналогичный код выглядит примерно так, на D(а математически можно более кратко записать):
Пример на программы первой Валентине:


В примере же не описано то, что я имел ввиду. Это же самое можно и на других языках написать.
Я же не имел ввиду, что сложно создать русский язык программирования, а имел ввиду, что сложно создать компилятор, который понимал бы русскую речь и создавал бы на основе русского текста программу.
Пример такой речи(программы) я привёл выше.

Отредактировано Yaisis (11.10.2014 00:12:43)

0

54

robur написал(а):

Очень даже из области программирования и именно из области ООП... Мечтаете ведь о мета программировании... ? )) А с помощью этого высокоуровневого  исходника (тела функции )можно изобразить  переведя (ничего не поделаешь) правда его на уровень ниже, скажем С++ или какого ни будь из Лиспов библиотеки GL и  OpenAL, всю картину, в ведя нужные параметры в аргументы переменных, включая завывание и плач, то есть отобразить функцию на мониторе.)) Разве это не  алгебра..?

Отредактировано robur (Сегодня 21:55:20)


Конечно можно, если задача ясна, но я не понял, чего требуется.

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

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

0

55

robur написал(а):

(ц)/Вика/ ..Ассемблирование может быть не первым и не последним этапом на пути получения исполнимого модуля программы. Так, многие компиляторы с языков программирования высокого уровня выдают результат в виде программы на языке ассемблера, которую в дальнейшем обрабатывает ассемблер. Также результатом ассемблирования может быть не исполнимый, а объектный модуль, содержащий разрозненные блоки машинного кода и данных программы, из которого (или из нескольких объектных модулей) в дальнейшем с помощью редактора связей может быть получен исполнимый файл... https://ru.wikipedia.org/wiki/Ассемблер

Ну если с этой точки зрения посмотреть, то такое тогда конечно может существовать.

robur написал(а):

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

Т.е. вы имеете ввиду, что будут распространяться зашифрованные бинарники, но при этом люди смогут запускать их на выполнение ?
Если так, то их легко расшифровать и поэтому смысла в шифровании нет никакого.

0

56

robur написал(а):

А он под какой лицензией ?  ...что то я вменяемого ответа не нашёл в нэте..

Недавно поменял лицензию на Boost.
http://dlang.ru/242-dmd-menyaet-licenziyu-na-boost

0

57

Yaisis написал(а):

Давайте опишите это с помощью математики.OpenGL и OpenAL тут вообще не причём, т.к. ни где не написано, что это надо выводить на экран или на звуковую карту

Ну это моя вина не уточнил ))).  f Мир = ( Аргументы: Буря Мгла небо вихрь снег зверь дитя покрытие кручение вой плач) ( Тело функции: Буря небо мглою кроет вихри снежные крутя то как зверь она завоет то заплачет как дитя  ) => оut

Отредактировано robur (11.10.2014 00:18:00)

0

58

Yaisis написал(а):

Т.е. вы имеете ввиду, что будут распространяться зашифрованные бинарники, но при этом люди смогут запускать их на выполнение ?Если так, то их легко расшифровать и поэтому смысла в шифровании нет никакого.

Все зависит от доброй воли от того  дадите Вы им  ключ или нет.. ))

Отредактировано robur (11.10.2014 00:34:37)

0

59

robur написал(а):

Ну это моя вина не уточнил ))).

Вот, вот.
Чтобы решение было правильное, задача должна быть правильно сформулирована.
В остальном всё понятно.

robur написал(а):

Все зависит от доброй воли от того  дадите Вы им  ключ или нет.. ))

Тогда ясно.
Точно так же можно просто заархивировать с паролем и распространять.

0

60

Yaisis написал(а):

robur написал(а):Ну это моя вина не уточнил ))).Вот, вот.Чтобы решение было правильное, задача должна быть правильно сформулирована.В остальном всё понятно.
            robur написал(а):Все зависит от доброй воли от того  дадите Вы им  ключ или нет.. ))Тогда ясно. Точно так же можно просто заархивировать с паролем и распространять.

Тогда ясно станет кто есть тот кто так поступает... а назовёте это "виртуальной платформой" с революционными байт кодами  ещё и уважать начнут... О-о .. платформа.)))

Отредактировано robur (11.10.2014 13:55:44)

0

61

Yaisis написал(а):

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

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

0

62

utkin написал(а):

Я считаю, что путем приближения от версии к версии возможно создание подобной программы. Вопрос совершенно в другом. Есть ряд критиков, которые считают, что код должен быть максимально коротким в буквальном смысле - ну то есть состоять из малого числа символов. Чем длинней будет Ваши программы, тем больше сопротивления Вы встретите.

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

Код:
Нарисуй в центре экрана круг, а внутри круга равносторонний треугольник, 
чтобы его вершины касались окружности и одна из вершин прилегала к самой верхней точки круга. 
Круг раскрась красным цветом, а треугольник зелёным. Треугольник расположи поверх круга.

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

Отредактировано Yaisis (11.10.2014 17:03:42)

0

63

robur написал(а):

Тогда ясно станет кто есть тот кто так поступает... а назовёте это "виртуальной платформой" с революционными байт кодами  ещё и уважать начнут... О-о .. платформа.)))

Если сделаете нечто подобное, как LLVM, Java, .NET, то может и начнут уважать. Хотя с такими соперниками уже сложно будет завоевать популярность.
И шифрование или распространение программ под паролем - не имеет никакого отношения к виртуальной платформе.
А я вообще за открытый код.

0

64

robur написал(а):

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

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

0

65

robur написал(а):

...


И ещё хотел сказать кое-что по поводу LLVM.
Вот например компиляторы С/С++ самые быстрые потому, что к ним уделяют больше всего внимания и дорабатывают их больше, чем все другие, по этой же причине в них должно быть меньше ошибок.
В LLVM большую часть вынесли за язык программирования, т.е. оптимизатор и генераторы кода не зависят от языка, а все языки программирования, использующие LLVM, имеют один общий оптимизатор и общие генераторы кода. Поэтому не важно какой язык - хоть это С/С++, хоть Rust, хоть Python и т.д. - оптимизировать их код будет одна и та же программа, точно также одна и та же программа будет преобразовывать его в машинный код. Поэтому развитие одной этой программы будет улучшать производительность сразу всех языков, которые используют LLVM, а то что все языки используют одну эту программу - это повышает её тестирование и следовательно быстрее будет уменьшаться количество ошибок в ней.
А разработчикам языков не надо создавать свои оптимизаторы и генераторы кода - надо только преобразовать код своего языка в байткод LLVM, что сильно упрощает и ускоряет разработку языков.
Таким образом разработчики языков могут сосредоточиться на разработке самого языка, а не тех вещей, которые уже давно разработаны до них и разработка которых отнимает много времени.
Например Rust, который позиционируется, как конкурент С/С++ написан под LLVM. А лично я пользуюсь компилятором D под LLVM.

0

66

utkin написал(а):

У Вас фантазии оторванные от действительности. Даже я не смог бы выполнить Ваш запрос - как минимум запросил бы радиус. Очевидно Вы далеки от проблемы. Попробуйте сначала поразмышлять над тем что Вы просите.

Ну во первых, что и кого я прошу ?
А во вторых, такой язык, о котором я говорю - это фактически уже искуственный интелект, уверен, что в будущем такие появятся, например компьютер IBM Watson может нечто подобное - следовательно с фантазией у меня всё нормально.

Лично я же хочу просто хороший русский язык программирования, например такой же, как D по синтаксису.

utkin написал(а):

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

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

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

0

67

utkin написал(а):

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

Где я писал про Си, и про "нач" и "кон" ?
Я сказал такой же язык, как D.
Сейчас пример приведу:

Код:
   Число Массив[] = [1,2,3,4,2,3,1,1];
   Число[Число] СписокЧисел;
   Цикл(Число; Массив) {
      СписокЧисел[Число]++;
   }
   Цикл(Число; СписокЧисел.Ключи.Сортировать) {
      Вывести("Число: ", Число, ", количество вхождений: ",СписокЧисел[Число]);
   }

Вот код полностью на русском - такой язык меня устроит.

utkin написал(а):

Вас не поймешь, то Вам компилятор подавай, то уточнения во время выполнения задачи... Я же писал, подумайте над проблемой сначала. Работы такие велись потому и глупости у Вас спрашиваю. Для меня они очевидны, а Вы, конечно извините, но размышляете устоявшимися стереотипами. Попробуйте взяться за решение задачи (в уме).

То, что мне надо я привёл в примере выше. То, что писал в предыдущих комментариях - это я писал то, что сделать сложно, но это не значит, что это мне надо. Но если бы такое сделали, то 100% успех языку гарантирован в России.
Это вы глупости говорите - сначала вникните в то, что я пишу и поймите, что мне это не надо и такой язык я не собираюсь делать.

utkin написал(а):

Вас не поймешь, то Вам компилятор подавай, то уточнения во время выполнения задачи...

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

utkin написал(а):

Попробуйте подойти к бухгалтеру и скажите сдай отчет в налоговую. Как Вы думаете - сдаст? Или утопит Вас в океане вопросов?


Сдаст, если отчёт готов. Или вы думаете, что я с бухгалтерами никогда не общался ?
Также я общался с программистами, которым давал задания и они делали их, без глупых вопросов про радиус, как-то они сами догадывались... А потом если я видел, что радиус меня чем-то не устраивает, то я говорил, как его подкорректировать.

Ну сказал я "Вывести круг на экран", что так сложно круг вывести ? Пусть рандомом сгененирует координату центра, радиус и выведет. Я потом увижу и если мне не понравится, то подумаю "надо бы ещё его вывести в центре экрана и размером на половину экрана" - это и скажу своему думающему компилятору или среде разработки, которые в данном случае связаны(назовём это просто программой) и эта программа добавит эти изменения к коду, в результате получиться то, что надо.
Конечно я понимаю, что всё это сложно сделать, но человек в данном случае смог бы обработать запрос, а речь и шла о программе, которая сможет также поступить, как и человек. И у IBM получилась похожая программа на её компьютере IBM Watson.

Отредактировано Yaisis (11.10.2014 21:53:59)

0

68

utkin написал(а):

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

  :yep:   Эргономика нужна...

0

69

utkin написал(а):

Это потому что я просил семантику языка. Вы же описание даете урывками, приходится вручную додумывать, чтобы хоть как-то понять Вас.


Потому что вы меня не понимаете.
Симантика - это наше с вами общение. точно также человек должен общаться с компьютером. Все его требования - это программа.

utkin написал(а):

Да они сами догадываются. Только потом ракеты падают или очередной робот убьет японского рабочего    Догадки возможны только в не критических операциях. А если язык можно и нужно будет использовать для создания драйверов, ОСей и прочего системного барахла, то ответы на глупые вопросы обязательно должны быть. Это не придирка, а требования к языку.

Из-за этих программистов ничего не упадёт, потому что они сами знают, что надо делать.
Вы вкурсе, что язык Дракон(https://ru.wikipedia.org/wiki/%C4%D0%C0%CA%CE%CD) создали для того, чтобы миновать программистов - он настолько прост, что инженеры сами программируют на нём, а инженер лучше знает, что необходимо сделать и ему куда проще самому сделать, чем объяснять всё программисту. Именно поэтому ничего не упадёт. А вот если инженер будет объяснять программисту, то вероятность появления ошибок в программе будет выше, т.к. не факт, что программист всё поймёт правильно.

utkin написал(а):

Это не так чтобы и сложно сделать - в систему исполнения можно внедрить такой функционал - как запрос параметров функций от пользователя (с автоматическим построеним диалоговых окон). И второе,  в программу также закладываются наиболее вероятные ответы на функции (хотя  бы на встроенные). Тут голая автоматика и человечностью не пахнет.

Это одна из самых сложных задач, потому что я говорю об искуственном интелекте, понимаете, компьютер должен понимать любую фразу, что я напишу, если в ней недостаточно сведений, то должен Спросить то, что не понятно. А человечество до сих пор даже нормальный переводчик сделать не может - куда ему до таких программ ?
И формы тут вообще не причём.
Опять же вы так ответили, потому что совсем не поняли о чём я говорю вам.
Вообщем давайте не будем продолжать обсуждать эту тему. Лучше обычные, всем привычные, языки обсудить.

0

70

utkin написал(а):

Число Массив[] = [1,2,3,4,2,3,1,1];
Ну я же говорил, без надмозга не обошлось

Что в привычном массиве не понравилось ?

0

71

utkin написал(а):

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

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

utkin написал(а):

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

Ну глупый программист конечно так и поступит - будет матюкаться и нервничать.
У меня же все символы печатаются по нажатию с правым Alt, так удобно, что я об этом даже не думаю. В обеих раскладках печатаю так символы и поэтому переключение расскладки не изменяет положение кнопки символа, что удобно в двойне.
И можно печатать даже слепым методом без проблем.
Квадратные скобки - это символ массива. И лично я хочу видеть их в языке, как и фигурные скобки вместо "Начало" и "Конец".
Опять же говорю - у меня нет никаких проблем ни в Линуксе, ни в Виндовсе с данными символами.
А вы просто расскладку настройте и не нервничайте.

В приведённом вами выше примере на языке Валентина, в том коде встречаются символы & и ' ', что ж вы их не прокритиковали, а к [] придрались ?

И кстати интересно, что вы предложите заместо [], {} и знаков <> ?
Как обращаться к массиву по индексу ?

Отредактировано Yaisis (13.10.2014 18:57:09)

0

72

utkin написал(а):

Бейсик однажды использовал круглые скобки. Конечно это не означает, что Вы обязаны теперь их использовать. Это только означает, что альтернативы есть. Если заниматься их поиском.

Да.. В Лиспе круглые скобки, а компилятор различает аргументы функции и тело функции не по "скобкам", их форме, а по месту их расположения в "строке"  по нескольким "шаблонам строк", точнее выражений.   Пример, стандартная лямбда ( безымянная функция в лиспе) (LAMBDA (x y) (+ (* x x) (* y y) ) )  В С++ безымянная int main=(..) {....};.

Отредактировано robur (13.10.2014 21:32:03)

0

73

utkin написал(а):

Вы в курсе, что у Дракона проблемы с декомпозицией?
Написать на нем ОСь для современного писюка это будет подвиг, за который нужно будет давать Героя России.

Этот язык не для осей.
Так же язык для осей - не для инженеров.

utkin написал(а):

Вы хотите невозможного. Даже наше общение с Вами показывает, что мы не допонимаем друг друга.

Тут я с вами согласен и уже сам тоже так начал думать.

utkin написал(а):

В том что это не русский язык, а перевод Си.

Это не псевдоним Си. Во многих языках так массивы объявляются и такое обозначение уже стало стандартом.

utkin написал(а):

Можно написать что-то вроде: Объявим массив чисел (1--4,2,3,1,1)

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

utkin написал(а):

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

Именно поэтому я бы оставил привычные символы, потому что это удобно и не стал бы ущемлять сам язык.
Ну конечно у вас своё мнение на правильное решение этой проблемы, а у меня своё.
И, если вы думаете, что вы думаете правильней, чем я, то в результате не факт, что именно ваш язык понравится большинству.

utkin написал(а):

Дело не в скобках, это только пример того что есть символы которые не приспособлены для ввода. И еще, я и целая орда программистов не будут менять свои привычки ради Вашей поделки. Поверьте мне на слово.

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

utkin написал(а):

Я их раскритиковал. Именно на опыте первой Валентине я давно отбросил свои иллюзии. У новой Валентины будет сменный синтаксис (аналогичными работами занимается Юрий) - основной набор будет стандартизирован. Дополнительные наборы синтаксиса программист сможет определять для себя сам.

Ветки про Валентину не видел. А вы делаете какой-нибудь язык или критикой только занимаетесь ?

utkin написал(а):

Бейсик однажды использовал круглые скобки. Конечно это не означает, что Вы обязаны теперь их использовать. Это только означает, что альтернативы есть. Если заниматься их поиском.

Альтернативы есть всегда, вот я вас и спросил потому, что хотел просто посмотреть, как вам понравится решение данной проблемы. На вопросы вы конечно не ответили.
Я лично решил данную проблему доработкой русской раскладки и при таком способе ещё куча свободных клавиш остаётся, можно их все полезными символами заполнить...
А так у меня тоже были притензии, но не к языкам программирования, а к русской раскладке. И видел на фотке американскую клавиатуру, так там кроме английской раскладки других больше не было. Тоже  хотел бы так, чтобы в России на клавиатурах были одни русские буквы, но такого не будет.

Отредактировано Yaisis (13.10.2014 21:53:47)

0

74

utkin написал(а):

Создать переменную Х  Создаем переменную Х Объявим переменную Х Объявляем переменную Х

Хочу поднять проблематику по теории так сказать русского языка и психологии. Мы вот когда пишем программу мы к кому  обращаемся в принципе?  ... к процессору, то есть должно быть к примеру создай ... объяви.. но, в реальности процессор для нас существо довольно умозрительное и не все в него "верят" ))))  и в добавок не одушевлённое по факту.. Ну мне думается такой "командный стиль" справедлив, чем безличное или во множественном числе ...  создаём.. объявим  Мы Николай вторые )))   ..это сбивает с толку и "размывает ответственность" между человеком и железом. Как Вы считаете?

0

75

utkin написал(а):

Ну мне думается такой "командный стиль" справедлив, чем безличное или во множественном числе ...  создаём.. объявим  Мы Николай вторые )))   ..это сбивает с толку и "размывает ответственность" между человеком и железом. Как Вы считаете?Именно потому много именований команд. Каждый способен выбрать себе тот вариант который устраивает его (и его модель) больше. Создаем, если работаем в команде. Создать если отдаем приказания системе исполнения (это не обязательно процессор, это может быть виртуальная машина). Поэтому я и придерживаюсь четкого и явного разделения синтаксиса и семантики в языке. Синтаксис должен быть настраиваемым. Тогда любое (ну почти) неудобство программист может пофиксить для себя сам. Нравится пишет в стиле Си, нравится использует древнерусский.

...мм.. Древнерусской? ))  Тут вопрос ведь не в том как кто хочет, ну или может.. а как правильнее вернее, грамотнее .. Культура должна же быть.. ..это наверное нужно к филологам за советом.

Отредактировано robur (14.10.2014 10:57:20)

0

76

utkin написал(а):

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

Я про Дракон говорил, ничто не мешает его доработать до такого состояния, когда на нём можно будет оси писать, но вряд ли это кому-то надо.

utkin написал(а):

В свое время я писал статью - Почему нет искусственного интелекта. Если будет скучно, можете почитать на досуге.

Я и сам знаю, почему его нет.

utkin написал(а):

Все они произошли от СИ. Речь не о стандарте, а о тупости самой фразу которой объявлен массив. Уже лучше писать тогда по-английски. Вас не понять - то Вы стремитесь к естественному, чтобы прям как с человеком, то цепляетесь за какие-то пережитки. И вносить английские стандарты в русский синтаксис это сильно.
Я, если разрешите, хотел бы дать Вам совет - прежде чем рубить с плеча, хорошенько обдумайте свои концепции.

Все эти символы известны каждому школьнику ещё из математики, поэтому они от-туда пошли и даже если Си их стал первым использовать, то это не значат, что они принадлежат ему, так же не значит, что эти символы принадлежат Америке или ещё какой-нибудь стране, если они есть только в их раскладке, т.к. они там есть только для удобства, ведь у американцев данный вопрос более продуман, это Россия тут в роли догоняющего и раскладку нормальную сделать не смогла.
И я не сремлюсь к естественному языку, я сказал, что не плохо, если бы такой был, но не факт, что я бы стал на нём программировать. Я вам привёл выше кусок кода с массивом - так вот это пример языка на котором я бы хотел программировать(как вариант) при этом все слова хочу чтобы были русские и чтобы остались математические символы. Математические символы - это не английские стандарты.
И вообще, не нравится - не пользуйтесь. Пользуйтесь своими языками без символов, но не навязывайте своё мнение окружающим.

utkin написал(а):

Очень странно. В бейсике путаницы почему-то никогда не возникает, а у Вас возникнет.

Мне бейсик не нравится - этим всё сказано.

utkin написал(а):

Кроме того, путаница возможна если Вы не будете вникать в смысл написанного (как это мы делаем когда программируем на английском). А если будете читать что написано, то путаницы не будет никогда. Например, цикл - for. Вы же не вчитываетесь в перевод этого слова. Для Вас просто for это цикл, было бы там cycle Вы бы все равно не вчитывались. Так вот открою Вам маленькую тайну (только чтобы никому!) - когда Вы начнете писать на русском - люди будут стараться понять смысл написанного, а не тупо следовать стандарту Число Массив.

Бред.
Цикл for и любые другие ключевые слова воспринимаются, как определённое действие, т.е. цикл и без разницы на каком языке - самое главное, чтобы знать, что это означает, а потом будет восприниматься одинаково, хоть на русском, хоть на английском. Я во всех языках одинаково отношусь к циклам, хоть в С/С++, хоть в 1С и т.д. При программировании я вникаю в сам алгоритм работы, а не в слова, но конечно видеть названия на русском мне удобней, но это не значит, что на английском я хуже программирую.

utkin написал(а):

Одназначно будет Вам минус, потому что в английском варианте нет нужды переключаться на другую раскладку чтобы написать скобку, коих в Си по самые не балуй. Понимаете в чем разница? Этот вопрос также поднимался (только не помню на этом форуме или на старом). В русскоязычном варианте, Вы требуете от человека постоянных переключений, а чтобы было удобно писать только в Вашей программе (потому что в других программах человек привык уже переключаться своей комбинацией клавиш), еще и клавиши переназначать. Если Вы думаете, что программисты будут испытывать от этого щенячий восторг, то я вынужден Вас разочаровать.

Сколько вам объяснять - надо русскую раскладку дорабатывать и выпускать новые клавиатуры, а вы хотите во всём русском от символов хороших избавиться. Ну хотите, создавайте свой язык без символов и пользуйтесь им один. И я же не утверждаю, что ваш язык мне например не понравится, просто вы на словах только критикуете и говорите, как надо, ничего не предлагая. Так же я уверен, что вы никогда не сделаете языка, который будет пользоваться популярностью.
И я не думаю о программистах, я думаю, о том, как было бы мне удобно, потому что я сам программист - как видите я испытываю восторг от этого, а вы уже заблуждаетесь, думая, что-никому такое будет неинтересно.

utkin написал(а):

В моем случае, как раз каждый будет пользоваться своими привычками по максимуму. Если Вам нужно Вы будете использовать скобки, если мне нужно я буду использовать стиль более приближенный к естественной записи. И более того будет возможность (технически уже проверено) перевода одного стиля в другой. Иными словами, я смогу читать Ваши программы, а Вы мои в том виде в котором они нам наиболее привычны (хотя написаны могут быть совершенно другим образом). Исключения составляют комментарии - их перевод (а предполагается использование юникода) с языка на язык весьма затруднителен.

Задумка конечно интересная, но вы заблуждаетесь на счёт того, что этим станут пользоваться. Т.к. вы не протолкнёте свой язык в общество. То, что вы говорите можно реализовать в любом современном языке с помощью трансляции.
Например есть синтаксис языка D в стиле Python, т.е. у D уже два синтаксиса и нет проблем понаписать ещё кучу, а если это всё вынести в файл настройки, то получится тоже самое, что и вы предлагаете. Поэтому ваша подделка скорее останется незамеченной. Я конечно хочу, чтобы у вас получилось сделать русский язык, который бы собрал вокруг себя большое общество и тогда бы я сам может стал бы им пользоваться. Но факт в том, что языков уже полно, конкуренция большая, программисты знают английский, многие даже считают, что в программировании должен использоваться только английский, потому что он международный. На нём может программировать и русский и китаец, т.е. разные нации могут понимать код, т.к. он написан на промежуточном языке, известном всем.

utkin написал(а):

Грубо говоря, прошелся по тем граблям на которые Вы сейчас активно наступаете, набил на лбу шишки и занялся переработкой.

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

0

77

robur написал(а):

Хочу поднять проблематику по теории так сказать русского языка и психологии. Мы вот когда пишем программу мы к кому  обращаемся в принципе?  ... к процессору, то есть должно быть к примеру создай ... объяви.. но, в реальности процессор для нас существо довольно умозрительное и не все в него "верят" ))))  и в добавок не одушевлённое по факту.. Ну мне думается такой "командный стиль" справедлив, чем безличное или во множественном числе ...  создаём.. объявим  Мы Николай вторые )))   ..это сбивает с толку и "размывает ответственность" между человеком и железом. Как Вы считаете?

Думаю, что нормально писать например просто "Создать переменную", что означает, что должна быть создана переменная после этого действия и не важно кто-её создаст. Если же "Создай переменную", то к кому идёт обращение не понятно. "Создаю переменную" тоже не красиво смотрится, т.к. возникает вопрос "А когда создашь ?". "Создание переменной" - это видимо долгий процесс... И т.д.

0

78

utkin написал(а):

Именно потому много именований команд. Каждый способен выбрать себе тот вариант который устраивает его (и его модель) больше. Создаем, если работаем в команде. Создать если отдаем приказания системе исполнения (это не обязательно процессор, это может быть виртуальная машина). Поэтому я и придерживаюсь четкого и явного разделения синтаксиса и семантики в языке. Синтаксис должен быть настраиваемым. Тогда любое (ну почти) неудобство программист может пофиксить для себя сам. Нравится пишет в стиле Си, нравится использует древнерусский.

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

Код:
Создать переменную х;
Создаю переменную y;
Создал переменную я;

Сложить переменную x и y;
Вычел переменную я из y;

и т.д.

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

Отредактировано Yaisis (14.10.2014 17:21:59)

0

79

Ох, как мно Вы тут понаписали! Даже прочитать некогда. Поэтому читаю выборочно, а отвечу совсем чуть-чуть.

И кстати интересно, что вы предложите заместо [], {} и знаков <> ?

Символов, которых нет на русской раскладке клавиатуры, очень много. Лично меня особенно расстраивает отсутствие  < > - Помимо [ { } ].

0

80

Yaisis написал(а):

Думаю, что нормально писать например просто "Создать переменную", что означает, что должна быть создана переменная после этого действия и не важно кто-её создаст. Если же "Создай переменную", то к кому идёт обращение не понятно. "Создаю переменную" тоже не красиво смотрится, т.к. возникает вопрос "А когда создашь ?". "Создание переменной" - это видимо долгий процесс... И т.д.

8-)  Ну как к кому..?  к тому  кто это делает согласно команде.. )))  Кем мы управляем командами?.. маленьким гномиком в "кейсе".. И "Создаю ...." действительно не очень выглядит, так как будто говоришь с самим собой.. с умным человеком, выглядит по дурацкий  ..Почти так же как и .. "Хочу переменную f  Вах".. )))

Отредактировано robur (14.10.2014 23:04:30)

0

81

Не знаю, как ведёт себя компилятор D, но большинство компиляторов C/C++ выдают предупреждение, что-то типа "Вы возможно хотели написать ==". Честно говоря, тут провоцируются досадные ошибки. Но надо выбрать: либо "=" для проверки на равенство и ":=" для присваивания. Либо "==" для проверки на равенство и "=" для присваивания. В первом случае из-за распространённости оператора присваивания придётся постоянно долбить лишнее двоеточее. Во втором - провокация ошибки.

В новом языке надо вообще запретить в операторе if операцию "=" (если для присваивания "=="). Если надо сделать проверку после присваивания, то if boolean(a=b) - через преобразование типов. Но это у себя на сайте я уже писал.

0

82

utkin написал(а):

По поводу раскладки, нет противопоставления русские-американцы, продумано не продуманно. Достаточно просто вспомнить, что у них 26 букв, а у нас 33 при тех же количествах кнопок на клавиатуре. Тут для Ё место кое-как нашлось, а Вы еще и спецзнаки хотите в одной раскладке.

Да я вас понимаю, просто хотелось бы, чтобы решение проблемы было выше, чем просто подгонка всех программ под русскую раскладку, как вариант, могли бы во всех клавиатурах стандартизировать способ введения символов с нажатой кнопкой Alt и чтобы он действовал во всех раскладках - это будет куда удобней, чем сейчас.  Сейчас даже запятые и точки находятся на разных кнопках в разных раскладках - это очень неудобно и вызывает постоянную путаницу при частом переключении раскладок и использовании данных символов, конечно пускай так остаётся, ведь есть те, кто привык к этому, но не плохо было бы ввести стандарт, чтобы при нажатии кнопки Alt - все эти символы находились на постоянных своих кнопках в любой раскладке. И с таким способом будет ещё куча свободных кнопок, на которых можно расположить и другие полезные символы. Просто вы думаете только о программистах, но не забывайте, что ещё есть полно русских математиков, физиков, инженеров и т.д., которые часто используют математические символы и которым приходиться мучится или с раскладками или вручную выбирать символ из списка в редакторах формул, когда можно было бы просто и быстро нажать комбинацию клавиш. Но конечно я вас понимаю, что проще подогнать свой язык под текущую действительность, чем пытаться куда-то протолкнуть новый стандарт, который ещё надо продумать.

utkin написал(а):

Дело не в Бейсике, а в том, что есть альтернативы. Захотите их использовать или нет это Ваше дело. Но отметать их, не рассматривая вообще, глупо.

Согласен, возможно есть и другой язык, который мне понравится. Даже возможно ваш понравится, когда вы его сделаете.

utkin написал(а):

А, просто Вы еще не открыли для себя эту фишку... Ну что же время значит еще не пришло . Ждем.

Совсем нет, я программирую уже несколько десятков лет. Просто возможно - эта фишка - это одна из черт вашего мировозрения. Мне же иностранные ключевые слова не мешают правильно воспринимать алгоритм. На самом деле в своём языке я думал заменить их на символы из математики. Русские математики же ими пользуются и не захотят менять ни на какие слова, потому что математическая запись - она краткая, понятная и точная. А чем длинней запись, тем её труднее держать в голове. В математики тоже есть "циклы", но они по-особому записываются и циклами не называются, но дело в том, что если вы будете писать программу, то заместо таких математических формул поставите циклы.С помощью математических формул можно описать любой алгоритм. И кстати функциональное программирование - не совсем отражает математику, да, там взяли функции, но циклы обычно реализуются с помощью рекурсии, что не всегда удобно.

utkin написал(а):

Дело не в том, что кому-то это будет интересно. Дело в том, чтобы это было интересно как можно большему количеству людей, если не хотите судьбы Оберона. И хотя там дело не в синтаксисе, смысл тот же. Язык хорош, но им мало кто пользуется, а тот кто пользуется сидит на попе и шипит по любому вопросу. Вместо популяризации принимают наооборот все меры чтобы сидеть в своем собственном мире и никого туда не пускать. Знаю, потому что общался с ними и когда работал в журнале пытался взять интервью. Абсолютное отсутствие желания помочь другим работать с языком.

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

utkin написал(а):

Я готов пойти на такую жертву - создать язык, которым никто не воспользуется. Узнаю причину и создам новый . Игра интеллекта тоже хорошо на самом деле, но как показывает мой скромный опыт, Вы немного в стороне от реальности.

Причины создания моего языка возникают у меня потому, что мне охота на нём по-программировать, например вчера я размышлял дальше об своём языке и переписал кусок кода своей нейросети, которая у меня на D, на свой вымышленный язык и то, как просто и быстро на нём получилось описать кучу циклов и т.д. побудило у меня интерес поэкспериментировать с ним, создать хотя бы недоделанную экспериментальную версию и по-программировать на нём алгоритмы в том стиле, который мне пришёл в голову. Конечно я пока сам не уверен, что эти решения можно выпустить дальше эксперимента и плюс ко всему, если делать серьёзный язык, надо ещё кучу всего продумывать. А отталкивает меня от серьёзного языка то, что я не хочу делать язык, который будет просто одним из кучи языков, ведь я не смогу написать все библиотеки и для всего, а без них я и сам на нём перестану программировать. И поэтому я трачу время на другие проекты, которые для меня не менее полезные. Причём тут моя реальность, я не понял, но скажу вам, что ваша реальность заключается в том, что вы думаете, о том, как написать удобный язык для всех и пока я не увидел в нём ничего такого, что бы его возвышало по сравнению с остальными, кроме русского синтаксиса, конечно я не знаю и может заблуждаюсь, я лишь делаю выводы на основе того, что вы мне сказали. Моя же реальность такова, что мой язык направлен на привлечение меня. Именно меня, т.к. есть вещи в других языках, которые меня не устраивают, а в моём меня устроит всё. Так же одна из вещей - это краткая запись. Если в других надо расписывать циклы, условия, то в своём я хочу просто описать смысл, без расписывания всего этого, как в математике пишется функция, указывается диапазон изменения переменных и условия, через запятую - всё, никаких циклов, блоков кода и т.д. И я заметил, что сейчас идёт стремление к такой универсальности, с каждым новым языком запись можно сделать всё кратче и кратче. Например в Rust сравнение с образцом, может сильно сократить объём кода. Так же сравнением с образцом(и не только этим) я пользовался в Хаскеле и там записи получались очень краткими. Думаю, что программистам понравится это нововведение, они к ней привыкнут и станут ли они пересаживаться на ваш идеальный язык, если допустим там такого не будет ? Поэтому надо не только развивать свои улучшения, но и брать полезные идеи из других языков.

utkin написал(а):

К системе исполнения, очевидно.

Переменные могут создаваться, как на этапе компиляции, так и динамически. Где-то компилятор может вообще для переменной отвести регистр и не выделять память, где-то может разместить в памяти, а может вообще её преобразовать в константу, которую подставит в соответствующее место в коде - всё зависит от переменной и как оптимизатор сможет оптимизировать взаимодействие с ней. По этому "Создай переменную" скорее обращение к компилятору.
Но не важно к кому обращение, мне такое написание не нравится, т.к. открою чужой код, начну читать, а там будет написано "Создай переменную", на что у меня может возникнуть вопрос - "Я что-ли её должен создавать ?". Конечно я-то разберусь в коде, просто по-моему такая запись выглядит некрасиво, как инструкция по написанию кода:

Код:
Создай переменную...
Выполни цикл...

Программист нанятый в фирму, получивший задание на доработку чужого кода, открытого в текстовом редакторе, но впервые столкнувшийся с данным языком программирования, спрашивает у начальника: "Тут написано, что я должен создать переменную и выполнить цикл... В какой среде и на каком языке осуществить данные действия ?".
Ответ начальника: "Это и есть язык "Валентина" дорабатывай прям там.".
Новый программист: "А... Да, я читал документацию по данному языку, там ещё было написано, что он поддерживает много синтаксисов, но все примеры были написаны в другом стиле, поэтому не узнал...".

utkin написал(а):

Я же писал, будет автоматический перевод в стандарт, хоть с китайского хоть с французского (кроме коментариев). Вы просто жмакаете кнопку и получаете программу в соответствии со стандартом. Никаких награмождений. Для чего это надо - писать Вы можете как Вам нравится, читать нужно одинаково, чтобы все понимали примерно одно и тоже.

Ну тогда хорошо, значит не так понял в первый раз.

utkin написал(а):

Это понятно, но можно пренебречь какой-нибудь тильдой и ради нее переключаться на латиницу. Иное дело когда требуются общеупотребительные символы (а для Си скобки это символы которые встречаются очень часто, наверно чаще чем буквы). Поэтому речь и шла об эргономике языка. Это практический аспект, который сложно учесть строя модель только в голове. Путей несколько - либо переиначивать раскладку программно (что вполне возможно) либо выпускать новые клавы (что естественно абсурд и никто такую раскладку не поддержит, а ради одного языка программирования никто заморачиваться тоже не станет) либо отказаться от символов (но тут вот традиции и пережитки прошлого тянут вниз).

Как вариант можно вообще словом написать "Больше", "Меньше", но думаю, что это не удобно.
Я за доработку раскладки таким способом, как я написал выше, а можно и лучше, если у вас есть идеи и коль сейчас правительство вроде инициализировало программы по развитию Российского ИТ рынка можно было бы попробовать внести данную инициативу на рассмотрение в думу, например через сайт народных инициатив https://www.roi.ru/ и попросить обязать поставлять в нашу страну клавиатуры с новой продуманной раскладкой, при этом сохранится совместимость со старой и никто не пострадает. Точно так же, как обязали поставлять в нашу страну смартфоны со встроенным ГЛОНАС модулем. Клавиатуры будут изначально содержать все нужные символы и иметь для этого подходящие драйвера, а людям станет удобней и не придётся ничего настраивать.
По поводу того, что никто данную раскладку не поддержит - это можно будет увидеть по голосованию, ведь только набрав 100 000 голосов "За" данная инициатива сможет попасть в думу на обсуждение.
И ещё куча 1С программистов, которые постоянно мучаются с данными символами, думаю, что они поддержат.
А вообще это нужно не только для программирования - я это уже писал выше.
И это не ради одного языка программирования - это ради всей страны.

0

83

utkin написал(а):

Кстати, в D есть защита в условиях? Ну то есть можно ли там как в Си написать:

Будет ли это проверка на равенство или оператор присваивания?


Выдаст ошибку: "Error: assignment cannot be used as a condition, perhaps == was meant?"
И программа не скомпилируется, пока не исправить.

0

84

Юрий написал(а):

В новом языке надо вообще запретить в операторе if операцию "=" (если для присваивания "=="). Если надо сделать проверку после присваивания, то if boolean(a=b) - через преобразование типов. Но это у себя на сайте я уже писал.

Согласен, что в if надо запретить операцию присваивания, но дело ещё в том, что операция "==" - это логическая операция, возвращаемая значение типа boolean(в C/C++ данный тип также воспринимается, как числовой имеющий значение либо 0, либо 1) и может использоваться не только в условиях, например:

b = (a==100)*5;

Поэтому, если в новом языке реализовывать такую же функциональность, то данный момент надо обдумать.

Юрий написал(а):

Но надо выбрать: либо "=" для проверки на равенство и ":=" для присваивания. Либо "==" для проверки на равенство и "=" для присваивания.

Лучше оставить то, что прижилось, а в условие запретить присваивание - это действие можно выполнить и за условием, в условиях оно ни к чему.

В своём языке я думал использовать:
":"    - для присвоения типа, инициализированного значением по-умолчанию,
"="   - для присвоения значения,
":="  - для присвоения типа и значения, и данная комбинация будет аналогична ключевому слову "auto", для вывода типа в других языках.

Отредактировано Yaisis (15.10.2014 20:36:20)

0

85

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

Первая мини клавиатура будет готова через 3-4 месяца. Планируем первую версию большой клавиатуры через пол года.

Поэтапно и параллельно делаем 8 битный процессор для робототехнических проектов. Можно будет программировать на РЯП, который вы разработаете и "стандартизируете". :)

Один из вариантов решения проблем, можно использовать п-код, в который будет транслироваться код из РЯП.

0

86

utkin написал(а):

математике понятие рекурсии есть, а вот понятия цикла нет.

Есть есть.. )) именно с появлением первых компьютеров и их практическим применением математиков озадачили, закрыли так сказать в комнате и не выпустили пока они не "родили".. )))) то что называется общим - дискретной математикой, естественно им было на чём стоять была уже теория графов где функции циклов описывались математический. Именно так перебором британцы пытались взломать германскую "Энигму" .

Отредактировано robur (25.10.2014 00:31:17)

0

87

utkin написал(а):

Мог бы стандартизировать кто?

Огранизации есть, которые стандарты создают, надо до них донести идею.

utkin написал(а):

Здесь это отрицательный опыт. Чем больше человек знает, тем сложней его научить чему-то принципиально новому. Старые знания будут постоянно подвергать сомнению новую информацию, выводы будут делаться по аналогии (которая может оказаться не уместной), прежние стереотипы будут мешать пониманию. Поэтому новому языку проще научить студента, чем переучить профессионала.

По отношению ко мне - это полная чушь.
Конечно опыт влияет, но в лучшую сторону. Студент, не знающий других языков, не сможет нормально покритиковать новый, т.к. ему просто не с чем сравнивать. Мне же полно с чем сравнивать и задачу я могу решить на любом языке, но есть те, которые больше удобны и те, которые неудобны.
Если брать вообще стариков, то им конечно лень учить новое.
Короче не гоните на меня чушь всякую и не пытайтесь не признание дурацкого языка свалить на то, что это просто людей сложно переучить.
Я опробовал много языков и например Хаскель вообще на С/С++ не похож, тем не менее он мне нравится. А на С/С++ я программировал очень много и этот язык как раз мне перестал нравится, потому что он устарел сильно и новые языки поудобней, чем он.

utkin написал(а):

Потому что нужно держать в голове смысл, а не представление данного смысла. Именно об этом я и говорил, когда приводил пример с for.

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

utkin написал(а):

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

Про хаскел - это как раз про то, что людям сложно переучиваться - функциональный стиль программирования очень сильно отличается от итеративного. Если в итеративном все строчки кода выполняются последовательно, то в функциональном могут параллельно, а последовательные действия там описываются совсем по-другому. Для меня лично Хаскель является интересным языком и в нём есть много интересных и удобных моментов. Но так же мне на нём не очень удобно программировать из-за отсутствия привычных циклов. Именно из-за таких моментов он и не популярен, т.к. все привыкли к итеративному стилю.
Теперь по поводу примера - конечно в вашем языке этого нет, как и нет очень многого, но всё это возможно добавить, поэтому лучше вам ознакомится с другими языками и взять из них то, что покажется вам полезным. Сравнение с образцом можно заменить на условия, но тогда запись получится длиннее и менее наглядной. Приведу пример в произвольном синтаксисе:
(x,y):
(0,y) => z = y
(x,5) => z = x+y
_      => z = x*y
Написал примерно, но смысл понятен - допустим есть кортеж (x,y) и надо выполнить какое-то действие над его переменными, потом описываются несколько образцов и первый образец, с которым совпадёт кортеж, его и обработает. Допустим x=100, y=5, тогда выполниться второй образец и произойдёт сложение x и y, если x=0, то выполнится первый образец, а если x!=0 и y!=5, то выполниться действие по-умолчанию. Сравнение с образцом добавили в Rust, но впервые я данную функцию увидел в функциональных языках и она там очень распространённая. Пример кода, который я привёл - это просто как пример, чтобы суть пояснить.

utkin написал(а):

Вот как раз сейчас там есть классические циклы (которые либо автоматически преобразуются в рекурсию, либо настоящие циклы). Например, в Scheme. И потом в математике понятие рекурсии есть, а вот понятия цикла нет. Его Вы представляете через другие механизмы (обычно функции высшего порядка, типа рядов, суммы там, произведения и т.д.). Так что кто ближе к математике вопрос спорный, я с Вами не согласен. И если говорить о числовых типов, то тот же Scheme однозначно ближе чем тот же Си к примеру.

Схему я не знаю, а Хаскель знаю не до конца, в Хаскеле вроде манады для этих целей есть.
А в математике можно записать примерно так:
x = E(Y(i)+Z(i)), где i (знак принадлежит) (3,100]
E - это обозначил знак суммы.
Y и Z - это функции
А вот i  получается переменная цикла, которая принадлежит диапазону от 4 до 100 включительно. С помощью такого можно описать любой цикл и это не рекурсия. Например в своём языке я думал ввести типы, которые обозначают изменяющиеся во времени переменные и они бы были заместо циклов. Связь между разными переменными цикла для их нормальной синхронизации я тоже частично продумал. Итерации нескольких переменных цикла в формуле зависят от их порядка следования в коде. Если одна переменная цикла указана в нескольких местах кода, то она изменяется в них одновременно. И т.д.

utkin написал(а):

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

Так я и имел ввиду стажёра по данному языку, но опытного в других языках, конечно ему в первый день объяснят, но если бы заместо вашего языка был код на С/С++, то он бы понял, что это и есть программа, а в данном примере он подумал, что в файле описана инструкция по тому, что ему необходимо сделать. Т.е. чисто визуально получается, что ваш язык можно принять не за язык. И ещё из моего примера ясно, что данный стажёр до этого читал документацию по вашему языку, но он же поддерживает бесконечное количество стилей, поэтому даже самый опытный программист на вашем языке, увидев где-нибудь самодельный и непривычный стиль может сойти за стажёра, т.к. он просто не узнает привычного языка. Ну конечно (следуя из ваших предыдущих предложений) он сможет потом применить к данному коду привычный для себя стиль.

Infum написал(а):

Значит пофиксили откровенную недоработку Си. Это прекрасно.

D - это не C/C++. А это язык написанный полностью с нуля и в нём нет недостатков C/C++.
Автор языка D до этого очень много лет писал компиляторы для языков C/C++(он один из тех людей, кто лучше всех знает эти языки) и потом решил создать язык лишённый недостатков этих языков.

utkin написал(а):

В Бейсике, который Вам не нравится (мне нейтрально, но я его не использую), опять же никаких проблем не возникает. Поэтому я призываю Вас ознакомиться с обзорами языков программирования (есть у Свердлова такой, но правда уже староват). Это расширит Ваш кругозор и даст понимание того, как похожие проблемы решаются в других языках.

Ознакомтесь сами, вы создаёте свой язык и многого не знаете из того, что реализовано в других - ваш язык просто не выдержит конкуренцию.
А Бейсик я знаю, но уже подзабыл, т.к. программировал на нём примерно в 1998 году.
И понимаете - мне ни к чему знать всё, что реализовано в других языках, а мне нужен только один язык, который мне будет нравится - я выбрал D, т.к. мне нравится на нём программировать.
Из всех системных языков программирования - он лучший, а не системные меня не интересуют, т.к. они медленные.
Я в курсе и без книг, как сделать так, чтобы проблем не возникало и кроме Бейсика есть полно других языков. А подумать я посоветовал именно вам - создателям своих языков.
И кстати, напомните, как такое реализовать в Бейсике(если там с этим "никаких проблем не возникает"):    b = (a==100)*5; ?

utkin написал(а):

Это расширит Ваш кругозор и даст понимание того, как похожие проблемы решаются в других языках.

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

Отредактировано Yaisis (16.10.2014 17:16:30)

0

88

Infum написал(а):

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

Первая мини клавиатура будет готова через 3-4 месяца. Планируем первую версию большой клавиатуры через пол года.

Вот хорошо, что хоть кто-то клавиатурой занялся.

0

89

utkin написал(а):

Ясно. Завышенное чувство собственной важности дает о себе знать . Дальше комментировать не стану, понятно, что бессмысленно.

Это скорее всего к вам относится.
И ответьте на вопрос про Бейсик, как там без условий реализовать такое: b = (a==100)*5; ?
Так как вы сказали, что в нём нет проблем с этим.

Отредактировано Yaisis (16.10.2014 20:50:22)

0

90

utkin написал(а):

b=(a=100)*5

Смотрится не красиво, т.к. в одном случае оператор = выполняет приравнивание, а в другом сравнение. Можно так же прочитать, как к "а" приравнять 100, потом умножить это на 5, после чего приравнять это к b, но если (a=100) - это логическая операция, которая выглядит, как операция присваивания, то это некрасивый ход. Именно поэтому я и написал, что надо подумать, чтобы сделать красиво и мне в данном случае больше нравится для логического оператора сравнения использовать ==, т.к. это и не сложно написать и всегда понятно, что за действие происходит.

utkin написал(а):

Есть еще один вариант, если у Вас есть опыт как Вы говорите, то сможете написать его сами.

В данном случае я спросил у вас, как произвести именно это действие, т.е. меня интересует логическая операция сравнения в Бейсике, а не остальные способы, которые её не используют. А спросил именно потому, что вы отослали меня к Бейсику - типа, зачем думать, когда в Бейсике уже сделано и нет ни каких проблем с этим. Так вот в Бейсике сделано плохо, а думать надо, чтобы сделать лучше. В данном случае лучше - это в D.
И конечно, всё, что мне надо, я могу написать сам.

utkin написал(а):

Только я другого не пойму. Причем здесь условия? Вы думаете тот код в ассемблере выполняется без условий ?

Во первых, такая запись без условий нравится многим программистам, т.к. код становится более кратким.
Во вторых ни к чему использовать условия, когда требуется логическая операция.
В третьих, все условные переходы тормозят конвейер и без них скорость работы кода может быть быстрее.
И теперь по поводу ассемблера - в ассемблере x86 условные переходы выполняются при помощи команд:
JMP - безусловный переход.
Jcc(где заместо cc пишется комбинация символов, характеризующая тип условия) - это команды условного перехода.
Как писал выше, команды условного перехода негативно влияют на конвейер процессора и процессору приходится предсказывать условные переходы, но часто возникают промахи и они снижают производительность.
Условные команды перехода осуществляют переход на заданный адрес в зависимости от установленных флагов процессора.
Флаги процессора устанавливает, например, команда CMP, которая просто вычисляет из первого операнда второй, при этом не сохраняя результат, но изменяя флаги процессора и эта команда не осуществляет условных переходов.
Поэтому код(формулы b = (a==100)*5; ) с условным переходом может преобразоваться примерно в такой на ассемблере x86:

Код:
   CMP AX, 100
   MOV AX, 1
   JE label
   MOV AX, 0
label:
   MOV BX, 5
   MUL BX

(написал код без оптимизации, а так можно было бы избавиться от умножения, но это только в данном примере, поэтому при немного другой формуле от умножения уже не избавиться)

b = (a==100)*5; - эту формулу, которая выполняет тоже действие, что и представленный код выше, на ассемблере x86 можно записать без условного перехода следующим образом:

Код:
   CMP AX, 100
   SETE AX
   MOV BX, 5
   MUL BX

В этом коде нет ни одного условного перехода и конвейер ни что не тормозит.

utkin написал(а):

Вы думаете тот код в ассемблере выполняется без условий ?

Я вам привёл пример того кода и показал, что он "в ассемблере" может выполняться без условий. Конечно, если код писать не на ассемблере, а на высокоуровневом языке, то его конечный вид будет зависеть от качества оптимизатора его компилятора. И в С/С++ оптимизатор очень мощный и вполне может заменить условные переходы на что-то похожее, особенно если код на языке записан верно. Ведь условия преобразовывать в формулу намного сложнее для компилятора(чем если ему всё сразу записать в виде формулы) и поэтому вероятность того, что он поставит условные переходы в результате будет выше.

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

Отредактировано Yaisis (19.10.2014 23:04:01)

0

91

Юрий написал(а):

Думаю Вам будет это интересно, пилят свой Си компилятор для Российской ОС  http://primula.l4os.ru/hello-world-news/  (ц) Мы — команда энтузиастов, работающая над созданием оригинального компилятора языка Си. Наша цель — создать лицензионно чистый, простой и легко переносимый компилятор для использования в проекте Хамелеон.
Нами были сформированы следующие требования — компилятор должен быть весьма простым, чтобы время на его изучение, понимание кода и принципов работы, было меньше, чем написание собственного решения. Компилятор не должен требовать сторонних библиотек и инструментов — для его работы должно хватать минимального набора стандартных POSIX функций. Исполняемый код компилятора должен быть весьма компактным — в перспективе должен помещаться на образ дискеты 1.44Мб...      Можно их "заразить"  :blush: )) "русофильством".

Отредактировано robur (19.10.2014 23:04:01)

0

92

utkin, к сожалению, физического изменения расположения существующих надписей она не производит :)

0

93

Т.е. предполагается сделать устройство, а не просто поменять раскладку системно? Т.к. клавиатуры без надписей имеются, но это не для детей, конечно. Или смена + дополнительное нанесение надписей на "чистые"?

0

94

Мы делаем с нуля новую клавиатуру для наших робототехнических проектов. Будут дополнительные клавиши. Потом планируем сделать обычную клавиатуру, но с чуть другим расположением клавиш и с дополнительными клавишами.

0

95

Квадратные скобки нужны, как и другие символы, недостающие в русской раскладке.

Необязательно. Например, пара <понятие>(<содержимое>) равносильна любому кол-ву разновидностей скобок (и даже эти круглые лучше убрать).
"массив(1,2,3,4,2,3,1,1)" лучше чем "[1,2,3,4,2,3,1,1];", т.к. не нужно задумываться про обозначения.
Каждый дополнительный знак - зло, т.к. его нужно заучивать.

Теперь язык будет полный юникод (хоть китайский, хоть французский), стандарт будет русским, остальное будет доступно настройке (ну не полностью, Юрий хотел возможность редактирования как в Питоне табуляцией, пока это к сожалению не возможно).

Возможно лучше исходить из самой обработки строк в Юникоде - международного приложения, а не исходника.

Есть много задумок, например, множественность конструкций, делающих язык более приближенным к естественному - это возможность написать одну конструкцию/команду различными способами (задается при проектировании синтаксиса.
Например, можно записать:
Создать переменную Х
Создаем переменную Х
Объявим переменную Х
Объявляем переменную Х
Все эти команды допускается использовать в языке (это анализируется на этапе разбора программы в один проход перед стартом).

Есть опасность потерять много времени. Десять неудачных названий делают язык только хуже: чтобы прочитать справку нужно время, и на "воду" его тратить жалко.
Порядок следования в "конструкциях" предполагается настраиваемым? Разрешение и предупреждение неоднозначностей?

Ну мне думается такой "командный стиль" справедлив, чем безличное или во множественном числе ...  создаём.. <...>  ..это сбивает с толку и "размывает ответственность" между человеком и железом. Как Вы считаете?


Именно потому много именований команд. Каждый способен выбрать себе тот вариант который устраивает его (и его модель) больше. Создаем, если работаем в команде. Создать если отдаем приказания системе исполнения (это не обязательно процессор, это может быть виртуальная машина). Поэтому я и придерживаюсь четкого и явного разделения синтаксиса и семантики в языке. Синтаксис должен быть настраиваемым. Тогда любое (ну почти) неудобство программист может пофиксить для себя сам. Нравится пишет в стиле Си, нравится использует древнерусский.

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

Поясняю: можно написать программу так, чтобы она читалась практически/как на обычном языке - чем больше разница будет м/у единицами языков, тем жиже, неинтереснее, ненадежнее и неприменимее в целом ЯП. Это основная мерка.

Есть и семантические изменения - начитался литературы по системному анализу и решил отказаться от специализации в структурах данных (да и впервой Валентине базовый тип один - строка). Теперь все переменные будут деревьями строк. В общем для меня много работы. Сейчас я готовлю библиотеку по работу с деревьями (в частности есть возможность загрузить выгрузить переменную в XML). Лексический анализатор перенес на Лазарус (из-за кроссплатформенности и Юникода).

Годные решения.
Utkin, Вы не рассматривали Лазарус в качестве целевой сборки, т.е. оформления интерпретатора компонентом?
Или как основу для графической оболочки?

Отредактировано MihalNik (24.10.2014 10:04:07)

0

96

MihalNik написал(а):

Квадратные скобки нужны, как и другие символы, недостающие в русской раскладке.
Необязательно. Например, пара <понятие>(<содержимое>) равносильна любому кол-ву разновидностей скобок (и даже эти круглые лучше убрать).
"массив(1,2,3,4,2,3,1,1)" лучше чем "[1,2,3,4,2,3,1,1];", т.к. не нужно задумываться про обозначения.
Каждый дополнительный знак - зло, т.к. его нужно заучивать.

Например можно записать так:
auto a = [1,2,3,4,5];
auto b = (1,2,3,4,5);
Форма записи краткая и понятно, что "a" - это массив, а "b" - это кортеж. Поэтому нельзя заменить квадратные скобки на круглые, т.к. массив станет кортежем или придётся для кортежей придумывать другое обозначение.
А вы похоже предлагаете писать так:
a = массив(1,2,3,4,5);
b = кортеж(1,2,3,4,5);
Конечно можно и так, но лично мне больше нравится первый способ, т.к. я могу в любое место программы передать [1,2,3] и будет понятно, что я туда передал массив, иначе же надо каждый раз писать слово "массив(1,2,3)", что долго.

MihalNik написал(а):

"массив(1,2,3,4,2,3,1,1)" лучше чем "[1,2,3,4,2,3,1,1];", т.к. не нужно задумываться про обозначения.

Вы ещё замените "a+b", на "сложить(a,b)", т.к. тогда не нужно будет задумываться, что обозначает символ "+".
И запоминать символы никакие не надо - все эти обозначения уже давно известны программистам, они их используют и даже не задумываются. Квадратные скобки воспринимаются, как знак массива точно так же, как символ + воспринимается, как знак сложения.
А если например надо обратиться к массиву по индексу, то пишем так: "a[индекс] = 3", где по квадратным скобкам видно, что идёт обращение к массиву. Как в вашем варианте без скобок реализовать эту операцию ?
Или в D например можно писать так "a[3..$-5] = b[6..$]", тут тоже понятно по квадратным скобкам, что операции идут над массивами. А вы как подобное собрались реализовать без символов ? Придумыванием дополнительных слов ?

MihalNik написал(а):

Каждый дополнительный знак - зло, т.к. его нужно заучивать.

Каждое дополнительное слово нужно заучивать и помнить, что именно оно является ключевыми. От языка к языку слова будут меняться и нужно постоянно вникать, какие слова используются в очередном языке. А все эти знаки уже давным давно являются стандартом в программировании и они не зависят от языка общения людей, т.е. они понятны людям любых национальностей. И если взглянуть на такие языки программирования, как С/С++, D, C#, Java, Python и многие другие, то в них используются одни и те же знаки для обозначения одних и тех же действий и у программистов не возникает трудностей со сменой языка программирования. Многие из знаков идут из математики, а математику должен знать любой программист. И не только программист - любой человек должен её знать.

Отредактировано Yaisis (24.10.2014 13:06:00)

0

97

Yaisis написал(а):

Например можно записать так:
auto a = [1,2,3,4,5];
auto b = (1,2,3,4,5);
Форма записи краткая и понятно, что "a" - это массив, а "b" - это кортеж. Поэтому нельзя заменить квадратные скобки на круглые, т.к. массив станет кортежем или придётся для кортежей придумывать другое обозначение.
А вы похоже предлагаете писать так:
a = массив(1,2,3,4,5);
b = кортеж(1,2,3,4,5);
Конечно можно и так, но лично мне больше нравится первый способ, т.к. я могу в любое место программы передать [1,2,3] и будет понятно, что я туда передал массив, иначе же надо каждый раз писать слово "массив", что долго.

Это лично Ваши предпочтения и ничего больше. В данном случае и знак равенства лишний. За массивные же куски вроде "[1,2,3]" в любом месте программы многие испытавают желание отрывать части тел. Есть еще заметное свойство: когда в исходнике много мусора, но написано краткими обозначениями, то его и не видно.
Тот же Си костляв как пресноводная рыба - из него ошибки вылавливать одно удовольствие. Это "генетически" передается)

Вы ещё замените "a+b", на "сложить(a,b)", т.к. тогда не нужно будет задумываться, что обозначает символ "+".
И запоминать символы никакие не надо - все эти обозначения уже давно известны программистам, они их используют и даже не задумываются. Квадратные скобки воспринимаются, как знак массива точно так же, как символ + воспринимается, как знак сложения.

Знак сложения знает 99% людей, про квадратные скобки - в 1000 раз меньше.
Что такое кортеж, сдается мне, даже Вы настолько хорошо знаете, что не можете по-русски это назвать одним словом. Просто не осознаете, обычное свойство коренного носителя.
В математике можно не искать, там учат называть по-другому.
Также программисты вот - вроде в языке сотня-две ключевых "слов", а с одного на другой переключишься - стошнит.
Не те, видно, это слова.

А если например надо обратиться к массиву по индексу, то пишем так: "a[индекс] = 3", где по квадратным скобкам видно, что идёт обращение к массиву. Как в вашем варианте без скобок реализовать эту операцию ?

В русском языке аж целых два способа. Оба распознаются и безо всяких скобок.

Или в D например можно писать так "a[3..$-5] = b[6..$]", тут тоже понятно по квадратным скобкам, что операции идут над массивами. А вы как подобное собрались реализовать без символов ? Придумыванием дополнительных слов ?

Тут вообще надо уточнить, что это за такое в D.
Действия с массивами могут быть заданы и без явного перечисления. "For each" неспроста придумали.
В списковых сопоставлениях что угодно без этого можно задать.

Многие из знаков идут из математики, а математику должен знать любой программист. И не только программист - любой человек должен её знать.

Какой стандарт?
Математика в целом плохой язык - некоторым обозначениям сотни лет и они ничем, кроме лени математиков не оправданы.
Уже в математико-ориентированных ЯП "математика" удобочитаемее и проще, чем в математике=)
В большинстве ЯП знаки использованы совсем по-другому.
Ну вот = это не присваивание, + и - не увеличение и не уменьшение * и / тоже исходно означают отношения, а не процедурно-функциональные вычисления.
Разве что в Прологе эти знаки более-менее соответствуют изначальному смыслу.
Функции в математике также означают не то, что в Си- или Паскале- подобных)
А где мн-ва в виде фигурных скобок?

А все эти знаки уже давным давно являются стандартом в программировании и они не зависят от языка общения людей, т.е. они понятны людям любых национальностей. И если взглянуть на такие языки, как С/С++, D, C#, Java и многие другие, то в них используются одни и те же знаки и у программистов не возникает трудностей со сменой языка.

Ну, конечно, не возникает, правда-правда.
Один холивар = и := чего только стоит, целые статьи написаны)
Сама разница в ЯП: Basik, C, Paskal, Smalltalk, Lisp, Prolog, Perl - дают целые линейки языков очень сильно различающихся обозначений.
Кстати, почему в Вашей линейке только С-подобные?

Каждое дополнительное слово нужно заучивать и помнить, что именно оно является ключевыми. От языка к языку слова будут меняться и нужно постоянно вникать, какие слова используются в очередном языке.

Русский язык один и смысл слов в нем как-то не особо сильно и быстро меняется. Правда их еще нужно знать.

Отредактировано MihalNik (24.10.2014 14:16:59)

0

98

utkin написал(а):

Я пытался узнать и был послан :). В общем это религиозно-интимное, не стоит обращать внимание  :D

То был у меня обед.

utkin написал(а):

неоднозначности на совести составителя, однако в большинстве случаев неоднозначностей не возникает.

Вот этот момент беспокоит - не случится ли накладок в результате преобразований туда-сюда?

utkin написал(а):

Я думаю стандарт надо вырабатывать совместными усилиями с несколькими программистами. Человек 5-6 не меньше. Тогда это будет и быстрей и более продуманней. В общем выносить в общественное обсуждение.

Тут я, правда, склоняюсь к несколько иному - что результат никак не должен зависеть от мнения 5-6 человек или даже нескольких сотен.

utkin написал(а):

Не рассматривал, но с учетом прошлого опыта (первая Валентина была обычный класс, который юзала среда разработки) это вполне возможно и нет технических препятствий для использования в таком ключе.

Это было бы интересно - в качестве дополнительного скрипта к жесткой программе.
Например, FastCGI+скрипт.

utkin написал(а):

Даже не знаю, поподробней можна?

Ну можно попробовать "обрусить" несколько основных компонентов Лазаруса.
Чтобы делать обычные приложения.
Вроде в Суржи/ДизельПаскале через интерпретатор работает что-то подобное?
Это было бы в любом случае полезно - т.к. там много нерусских наименований и в них долго новичку разбираться.
Зато при переключении с русского на английский м.б. намного легче, и новые слова запомнятся быстрее, т.к. смысл будет ясен.

utkin написал(а):

Вполне возможно, я на старом форуме предлагал людям обсудить вопросы синтаксиса. Не заинтересовал.

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

Отредактировано MihalNik (24.10.2014 16:07:21)

0

99

MihalNik написал(а):

Это лично Ваши предпочтения и ничего больше.

Конечно я говорю только о своих предпочтениях, так же, как и вы. Ни я, ни вы не можем говорить за всех.

MihalNik написал(а):

В данном случае и знак равенства лишний.

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

MihalNik написал(а):

За массивные же куски вроде "[1,2,3]" в любом месте программы многие испытавают желание отрывать части тел.

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

MihalNik написал(а):

Есть еще заметное свойство: когда в исходнике много мусора, но написано краткими обозначениями, то его и не видно.

Возможно тогда кому-то надо сходить к окулисту. Если много мусора, то надо в любом случае его разбирать и на любом языке этот мусор будет мусором.

MihalNik написал(а):

Тот же Си костляв как пресноводная рыба - из него ошибки вылавливать одно удовольствие. Это "генетически" передается)

Я знаю о проблемах С/С++. Я говорю о квадратных скобках, а не о этом языке. Его проблемы уж точно не из-за квадратных скобок.

MihalNik написал(а):

Знак сложения знает 99% людей, про квадратные скобки - в 1000 раз меньше.

Если программист не может осилить квадратные скобки, значит это не программист. Даже в 1С есть квадратные скобки, а среди тех, кто пишет на ней программы, не все программисты, тем не менее они справляются.

MihalNik написал(а):

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

Я знаю, как кортежи мне могут пригодиться в программировании, я не знаю как он звучал бы в переводе на русский и мне это не надо. В примере я привёл, как его можно отвести без наличия данного слова, которое не нужно. Кортеж - это тоже самое, что и структура, но переменные в нём не имеют наименований. Что это слово означает в "коренном носителе" мне наплевать и мне это не мешает пользоваться кортежами при программировании.

MihalNik написал(а):

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

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

MihalNik написал(а):

В русском языке аж целых два способа. Оба распознаются и безо всяких скобок.

Мне не нужны пустые слова, давайте примеры.

MihalNik написал(а):

Тут вообще надо уточнить, что это за такое в D.
Действия с массивами могут быть заданы и без явного перечисления. "For each" неспроста придумали.
В списковых сопоставлениях что угодно без этого можно задать.

В D это срезы массивов("a[3..$-5] = b[6..$]"), а foreach - это вообще из другой темы и в D такая конструкция тоже есть. foreach и срезы могут использоваться совместно, что очень удобно.

MihalNik написал(а):

Математика в целом плохой язык - некоторым обозначениям сотни лет и они ничем, кроме лени математиков не оправданы.
Уже в математико-ориентированных ЯП "математика" удобочитаемее и проще, чем в математике=)

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

MihalNik написал(а):

Ну вот = это не присваивание, + и - не увеличение и не уменьшение * и / тоже исходно означают отношения, а не процедурно-функциональные вычисления.
Разве что в Прологе эти знаки более-менее соответствуют изначальному смыслу.
Функции в математике также означают не то, что в Си- или Паскале- подобных)

+, -, *, / -- это математика, действуют также, как и в любом калькуляторе. В языках программирования выполняют те же действия, что и в математических формулах с тем же результатом. Плюс конечно некоторые языки используют символы для дополнительных целей, например в С * - это указатель.
Функция и не обязана быть на 100% похожей, определение функции из википедии:
"Функция (отображение, оператор, преобразование) — математическое понятие, отражающее связь между элементами множеств. Другими словами, функция — это правило, по которому каждому элементу одного множества (называемого областью определения) ставится в соответствие некоторый элемент другого множества (называемого областью значений)."
В языках элементы одного множества передаются в функцию, которая возвращает элементы другого множества, соответствующего переданному. Есть ещё процедуры. Не путайте функции с процедурами. В языках функции и процедуры могут быть перемешаны, т.е. одна и та же так называемая функция может выполнять роль и функции и процедуры одновременно - это неизбежное развитие, которое нужно в программировании, но которого не было в математике.

MihalNik написал(а):

А где мн-ва в виде фигурных скобок?

В математике фигурные скобки, как и квадратные могут применяться для множества различных целей. Например квадратные скобки могут применяться в векторах и матрицах, так же для указания диапазонов, так же могут применяться точно так же, как и круглые скобки, но квадратные имеют больший приоритет и т.д.. Одно из применений фигурных скобок - это группировка, например условий в систему уравнений. В языке С/С++ фигурные скобки используются тоже для группировки, но уже строк кода в один блок.

MihalNik написал(а):

Ну, конечно, не возникает, правда-правда.

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

MihalNik написал(а):

Один холивар = и := чего только стоит, целые статьи написаны)

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

MihalNik написал(а):

Кстати, почему в Вашей линейке только С-подобные?

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

MihalNik написал(а):

Сама разница в ЯП: Basik, C, Paskal, Smalltalk, Lisp, Prolog, Perl - дают целые линейки языков очень сильно различающихся обозначений.

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

MihalNik написал(а):

Русский язык один и смысл слов в нем как-то не особо сильно и быстро меняется. Правда их еще нужно знать.

Русский язык - это язык общения и это не значит, что для программирования надо использовать только его слова, не используя при этом символов. Языки программирования и языки общения всё-таки отличаются. Языки программирования развиваются в ту сторону, в которой алгоритмы можно будет записывать наиболее быстрым и при этом понятным способом. Краткую запись, которую вы отвергаете, любят многие программисты(уверен, что большинство) и без неё они просто не заметят вашего языка. Во всех современных языках она есть. Это же направление развития языков предсказывал Страуструп и в таких современных языках, как Pyton, D, Rust и т.д. её видно не вооружённым взглядом.

Отредактировано Yaisis (24.10.2014 21:54:57)

0

100

utkin написал(а):

"Кстати, почему в Вашей линейке только С-подобные?"
Я пытался узнать и был послан . В общем это религиозно-интимное, не стоит обращать внимание

Уж не надо преувеличивать, я вам в качестве примера приводил не только Си-подобные языки, но и например Хаскел. Или для вас у Хаскеля Си-подобный синтаксис ?
И вы сами послали себя, когда продемонстрировали своё незнание, как ассемблера, так и парадигм программирования, да и ещё много чего, без знания чего не создают языков программирования. Вы только пытались здесь выглядеть умнее всех и советовать всякие Бейсики и книги, где не было ничего похожего на обсуждаемые темы и которые не решали возникших проблем. На самом же деле вы просто не вникали в то, что пишет ваш собеседник(при этом другому человеку), а просто отсылали его туда, где он не мог найти нужных ответов.
И по поводу парадигм программирования я приведу вам пример:
Создатель языка D долго создавал свой язык, а потом создал его, но понял, что его язык не сможет привлечь к себе внимания других разработчиков потому, что в нём нет чего-то кардинально нового, тогда он разработал новую версию языка D2, в которой реализовал все или почти все парадигмы программирования и добавил ещё своего - это получился очень мощный и красивый язык и он стал не совместим с D1, именно поэтому я сказал вам, что лучше знать, как устроены другие языки и чтобы сразу в своём реализовывать всё необходимое или хотя бы планировать это, чтобы потом не пришлось очень сильно переделывать свой язык с потерей обратной совместимости.
Поэтому вы заблуждаетесь, думая, что сможете всё добавить в свой язык потом. Конечно может и сможете, но это могут быть уже костыли. Создатель D1 не смог без сильного переделывания языка.

Отредактировано Yaisis (24.10.2014 22:02:34)

0


Вы здесь » Русские вычислители » Русский язык программирования: от слов к делу » Исследование: выбор платформы, компилятора и графических библиотек


форум на 24bb Создать форум бесплатно