О графике.
Впечатления о 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 точно много лишнего). Но кто ж мне даст время на это? Я бы с удовольствием. Уволился бы с работы, но кто ж будет кормить меня во время написания библиотеки? Ну ладно, это вопрос риторический…

Вашему вниманию, ...ещё одна тропинка. Представлю ряд публикации ... 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)

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

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

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

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

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

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

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

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

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

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

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

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

Ну конечно, у каждого своё мнение, но у 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Повторю ещё раз - 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)

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

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

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

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

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

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

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

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

Ну вы имеете право иметь своё мнение, только уверен, что у большинства оно другое.
Моё мнение, если хоть, чем-то можно улучшить язык, то надо это вводить в него и даже если парадигмы незначительные, то их ввод всё равно принесёт только пользу.
И опять же могу привести пример с метапрограммированием, с помощью которого совместно с ОПП в 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 такое сделать реально)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

и т.д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

b = (a==100)*5;

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

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

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

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

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

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

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

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

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

Во первых, такая запись без условий нравится многим программистам, т.к. код становится более кратким.
Во вторых ни к чему использовать условия, когда требуется логическая операция.
В третьих, все условные переходы тормозят конвейер и без них скорость работы кода может быть быстрее.
И теперь по поводу ассемблера - в ассемблере 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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