Русские самосчёты |
Привет, Гость! Войдите или зарегистрируйтесь.
Вы здесь » Русские самосчёты » Русский язык программирования: от слов к делу » Исследование: выбор платформы, компилятора и графических библиотек
Вполне возможно, я на старом форуме предлагал людям обсудить вопросы синтаксиса. Не заинтересовал.
Видимо, ваше видение синтаксиса их не устраивает...
Но вы конечно можете это обсуждать с MihalNik.
У вас с ним похожие взгляды.
Отредактировано Yaisis (24.10.2014 22:00:47)
Что-то мне подсказывает что людей знающих программирование больше чем людей знающих математику. Есть такая вещь как порог вхождения. Очевидно что математика отличающаяся от 1-2 курса есть напряг для среднестатистического человека. О Хаскеле речь уже была - мегакрут и практически мало применяется. Очевидно крутость и краткость записи не есть основа идеала.
Необязательно быть математиком, чтобы стать программистом. И так же существует полно программистов, которые знают математику плохо, тем не менее это не мешает им программировать.
Но если вы поступаете в высшее учебное заведение на программиста, то математику вам придётся сдать и задачи там далеко не детские.
Хаскель - это не математика и по-моему он даже сложнее. Он функциональный язык программирования, но это не значит, что он отражает математику. В нём присутствуют свои конструкции, которых в математике нет.
1С пример того как делать не надо и потому кивать на него не совсем кошерно.
Валентина тоже такой пример. Или вы скажете, что она лучше ? Это же ваш язык ?
И между тем он прав
Ну я и говорил, что он с вами. Хотя давайте пример в студию, может мне тоже не понравится такой кусок кода, потому что я не совсем представляю, что он имел ввиду.
Мы можем сказать за всех, если есть на что опереться, например на статистику.
Конечно, тогда вы должны подкреплять ссылку на статистику к соответствующим своим высказываниям, чтобы это были не пустые слова, как они выглядят сейчас.
О, да деление на нуль например.
В школе нам говорили, что на нуль делить нельзя. В языках программирования при делении на нуль возникает исключение, что соответствует тому, что нам говорили в школе на математике. Но исключение возникает при делении целых чисел, при работе же с числами с плавающей точкой в таком случае число получит значение +-INF, которое надо обработать самостоятельно. По поводу же математики люди сами не определились, как с этим поступать. С одной стороны получается бесконечность, т.к. делится на очень маленькое число, а с другой ничего, т.к. делится на ничего. И поэтому в языках программирования данная ситуация обрабатывается правильно.
Поэтому ваш пример дуратский.
Какая же это такая математика? Если правила можно менять тогда когда вздумается?
Если мы описываем предметную область то должны ей соответствовать в ключевых моментах.
Я не утверждал, что все языки копируют математику, лично я вам говорил, что символы квадратных и фигурных скобок взяты из математики, а не с запада и именно данные символы вполне вписываются в математический их смысл. А про функции я ничего не говорил и поэтому я не понимаю, почему вы и ваш друг приплели сюда ещё и функции. В языках они реализованы по своему, но, как я привёл выше - вполне похоже на математику. И языки не обязаны копировать функции. А копия функций из математики называется "чистые функции".
Ответ не соответствует вопросу
Значит вопрос был понят неверно. Надо уметь задавать вопросы.
Это не соответствует действительности. Такого направления нет, есть направление в использовании новой более емкой семантики, реализующей наиболее часто возникающие задачи. О скорости записи программ вопрос не стоит.
Суть одна и та же, это приводит к тому, что сказал я. Вы не думали, что я мог просто выразиться не так ? И вам обязательно придираться к каждому слову ?
И точно так же я могу сказать, что и вашего направления развития нет, но я не скажу, потому что я в состоянии сам додумать то, что вы имели ввиду.
Кстати я приводил вам пример со сравнением с образцом - сделано именно для того, чтобы повысить скорость разработки.
Так же:
метапрограммирование - для повышения скорости разработки.
обобщённое программирование - для повышения скорости разработки.
И можно ещё кучу примеров привести.
Язык определяется задачей, а не краткостью записи.
Вникните в то, что я имел ввиду и не несите чушь.
На языке D можно решить любую задачу многими способами. Какая же задача у вашей Валентины ?
А теперь изучите D и посмотрите, как кратко и красиво там можно записывать алгоритмы - именно это одна из основных ценностей языка. А нормальный язык должен позволять решать любую задачу.
На самом деле пока что не видно. Видно например Яву, где синтаксис перегружен и явно избыточен. Что такое D? Пыль даже без внятной литературы. Ну Питон ладно, есть отражения. Rust встречается еще реже как экзотика. Потому говорить о направлении пока рановато.
Ну вы, как всегда сморозили, не поняв собеседника. Если языки новые, это не значит, что они популярные. И не значит, что они приживутся, но посмотрите на все развиваемые новые языки, на парадигмы, которые они поддерживают и сделайте сами вывод куда они развиваются. И конечно не обращайте внимания на Валентину - она отстаёт от всех.
И если по D нет литературы, то тогда откуда я его знаю ? Вы даже можете зайти на сайт русского сообщества программистов D и там люди тоже знакомы с данным языком.
Да и если вам эти языки не нравятся, то посмотрите куда развивается тот же С/С++ - там в новых стандартах вставили кучу вещей ускоряющих программирования и улучшающих сам язык, и постоянно появляются новые стандарты.
C# популярен и посмотрите, какие штуки в нём есть.
Человек в какой-нибудь Германии пилит функцию и отправляет ее Вам. Вы переводите ее на стандарт (комментарии больное место) и понимаете о чем идет речь. Поскольку каждый работает на том языке на котором он думает число ошибок в теории должно стать меньше.
Я думал о похожем - это очень сложно и кто переводить будет ? А вдруг перевод не понадобиться ?
Но тяготеете то к великому и ужасному .
Я тяготею к D - это не С/C++.
Сделайте язык лучше, чтобы меня тянуло к нему и может буду тяготеть к вашему, но пока мне не нравится ваш язык, по крайней мере то, что я о нём знаю...
Хаскел мне кстати тоже нравится и Питон.
Вам уже второй человек пишет примерно тоже самое, а Вы все ершитесь . И про ассемблер тоже загнули.. ну да ладно. Не стоит разрушать иллюзий, это может вызвать шок.
Можно привести сюда кучу С/С++ программистов и они опустят все ваши высказывания. Но я не хочу этого делать, потому что считаю таких людей тролями и сам не согласен с их мнением, но факт в том, что их станет больше, чем вас - это же не значит, что они правы. Точно так же если вас двое против одного - это не значит, что вы правы.
Про ассемблер - вы не знали, как реализовать приведённый мной алгоритм без условий и сослались на то, что в "ассемблере" условие всё равно будет, отсюда я сделал вывод, что вы не владеете данным языком, коль не знаете такую элементарную инструкцию. Но на самом деле вы наверно его знаете чуть-чуть и поэтому считаете себя крутым программистом.
Забавно, я писал о том же и даже приводил свой опыт (иногда не совсем удачный). Оттуда же были объективные предложения по поводу переключения раскладки. Но видимо синдром Утенка не дает Вам возможности увидеть рациональное зерно.
Ну вы сравнили опыт написания языка программирования с опытом переключения раскладки. Ну руки у вас кривые вот вы и мучаетесь с раскладкой постоянно и не можете до сих пор осилить настройку раскладки.
Свой язык вы ещё не скоро сделаете и мучится с раскладкой вам возможно придётся всю жизнь, поэтому синдром утёнка - это как раз у вас.
У меня, как я уже говорил, нет никаких проблем с раскладкой и язык D я не поменяю на вашу Валентину, потому что она до него не дорастёт никогда.
А по поводу опыта, то вам надо было развивать опыт по строению языков, по используемым парадигмам и т.д. А вы вместо этого опыт переключения раскладки развивали, а теперь пытаетесь создать свой язык, потому что замучились её переключать и при этом не знаете ни одной парадигмы программирования.
Отредактировано Yaisis (25.10.2014 01:27:18)
Наверно это не случайно и объясняется широтой кругозора как следствия опыта и большого количества прочитанных книг...
У него возможно много опыта. А у вас я не уверен.
Вы думаете, как студент, считающий, что он круче всех и может всё сделать круче всех.
Да и два человека в форуме - это прям так круто ?
Это просто совпадение.
Напишите свои мысли например в контакте в группе по языку С/С++ и там вам сразу укажут насколько вы правы.
Даже если вы прочитали кучу книг, то знание - это не главное, а главное уметь правильно использовать свои знания и надо уметь думать самостоятельно, а не пересказывать всё, что вычитали.
Это в вашей Валентине все типы хранятся в строковом представлении ?
Отредактировано Yaisis (25.10.2014 00:17:44)
Тут я, правда, склоняюсь к несколько иному - что результат никак не должен зависеть от мнения 5-6 человек или даже нескольких сотен.
От чего же тогда он должен зависеть? 
))
Что-то мне подсказывает что людей знающих программирование больше чем людей знающих математику. Есть такая вещь как порог вхождения. Очевидно что математика отличающаяся от 1-2 курса есть напряг для среднестатистического человека. О Хаскеле речь уже была - мегакрут и практически мало применяется. Очевидно крутость и краткость записи не есть основа идеала.
Ага )) многие о математике начинают узнавать из программирования.. конечно под другим углом чем на уроках алгебры в школе. Математическая крутость, придельное абстрагирование хороши для общения математиков и их абстрактных миров, по другому они не могут ..то есть врятли захотят вернутся к своему "ассемблеру" времён Пифагора, "счётных палочек", а вот для дел земных и "общения" с железом и с другими людьми посредством его, такой подход явно "недостаточен".. в нём нет нужного. И Хаскел это ещё ерунда по сравнению с Рефалом.. только толку как говорится от этого не много ))
Отредактировано robur (25.10.2014 01:06:16)
От чего же тогда он должен зависеть?
Хорошо, тогда нужны четкие правила, чем руководствоваться?
Существуют правила русского языка, там почти все есть из того, что нужно. Если опираться не на них, то полученное к русскому языку вообще отношения будет иметь мало, очевидно. Вот Пролог французы придумали, но к французскому языку он имеет отношения мало. Ruby это тоже ведь не японский?
По сути служебные части речи содержат все известные черты высокоуровнего программирования.
Ага )) многие о математике начинают узнавать из программирования.. конечно под другим углом чем на уроках алгебры в школе. Математическая крутость, придельное абстрагирование хороши для общения математиков и их абстрактных миров
Просто плохо, а большей частью и вовсе не переведена на русский язык.
Ну не нужно значит это самим математикам:
Я знаю, как кортежи мне могут пригодиться в программировании, я не знаю как он звучал бы в переводе на русский и мне это не надо. В примере я привёл, как его можно отвести без наличия данного слова, которое не нужно. Кортеж - это тоже самое, что и структура, но переменные в нём не имеют наименований. Что это слово означает в "коренном носителе" мне наплевать и мне это не мешает пользоваться кортежами при программировании.
Да понимаю, поэтому и предлагал единый стандарт, а все остальное кому как нравится, с возможностью перегонки туды-сюды. Плюс это не все задумки - речь шла о базе. То есть не только синтаксис в рамках одного национального шрифта, а использование других языков - английский, китайский, французский и т.д. Естественно смешение в рамках одной программы наверно не желательно, а так в общем было бы интересно.
Человек в какой-нибудь Германии пилит функцию и отправляет ее Вам. Вы переводите ее на стандарт (комментарии больное место) и понимаете о чем идет речь. Поскольку каждый работает на том языке на котором он думает число ошибок в теории должно стать меньше.
Пока да, не нужно самому заниматься этим. Но вот возможность предоставить этим заниматься другим наверно надо.
Нужны практические испытания.
Вот тут возможно заранее стоит провести расчет. Там задача комбинаторно нелегкая, ошибки могут быть трудноуловимы - есть возможность случайно создать семантическое расхождение при внешней синтаксической правильности.
Для этой задачи навскидку неплох Пролог - предикаты и сопоставления с образцами для таких задач применяются. Да и собственный синтаксис у него минимальный (хотя не могу сказать что мне нравится он "как есть"). SWI с динамической типизацией, есть даже гуи (для простых задач подойдет). Язык прост, могу поделиться материалами, хотя на русском не много, но для данной задачи думаю хватит.
Не уверен, но м.б. подобные возможности (сопоставлений) есть в Концепте? Поищу еще кое-чего у себя.
Думается, что для интепретатора такая задача некритична, но в тоже время м.б. интереснее решать её на самом разрабатываемом языке?
Я могу и дальше предложить готовый класс, это наверно более универсально чем компонент.
Представляется, что компоненты на палитре инструментов психологически намного приятнее.
Могут быть настраиваемые свойства - тоже очень привлекательно само по себе;)
Представьте, можно добавить на форму интерпретор, правила, связать свойства... вообще если хотите, чтобы было популярным - люди любят лего)))
Отредактировано MihalNik (25.10.2014 09:11:29)
Возможно тогда кому-то надо сходить к окулисту. Если много мусора, то надо в любом случае его разбирать и на любом языке этот мусор
Достаточно посмотреть что-нибудь на Перле. Он имеет один из самых кратких синтаксисов.
Математика - это отличный язык. Если вы знаете математику на отлично, что все обозначения будут для вас наглядней и понятней, чем в языках программирования, т.к. взглянув на краткую формулу можно сразу понять её алгоритм и это проще, чем разбираться в том же алгоритме на языке программирования, расписанном на несколько страниц.
И в каком языке более удобочитаемее и проще, чем в математике ? Может вы имеете ввиду Хаскель например ? Если так, то в его рекурсиях можно запутаться и по-моему циклы даже более легче в понимании.
Хаскель? Далее или ранее Вы написали что у него вообще своя, отдельная математика.
Если хотите математику - есть уже mapple, matlab и т.д. - с точки зрения именно математики они просто прекрасны - понятия родные и не нужно придумывать велосипеды, как в C или D.
Безусловно языки там удобнее классического.
+, -, *, / -- это математика, действуют также, как и в любом калькуляторе. В языках программирования выполняют те же действия, что и в математических формулах с тем же результатом. Плюс конечно некоторые языки используют символы для дополнительных целей, например в С * - это указатель.
Функция и не обязана быть на 100% похожей, определение функции из википедии:
"Функция (отображение, оператор, преобразование) — математическое понятие, отражающее связь между элементами множеств. Другими словами, функция — это правило, по которому каждому элементу одного множества (называемого областью определения) ставится в соответствие некоторый элемент другого множества (называемого областью значений)."
В языках элементы одного множества передаются в функцию, которая возвращает элементы другого множества, соответствующего переданному. Есть ещё процедуры. Не путайте функции с процедурами. В языках функции и процедуры могут быть перемешаны, т.е. одна и та же так называемая функция может выполнять роль и функции и процедуры одновременно - это неизбежное развитие, которое нужно в программировании, но которого не было в математике.
В математике фигурные скобки, как и квадратные могут применяться для множества различных целей. Например квадратные скобки могут применяться в векторах и матрицах, так же для указания диапазонов, так же могут применяться точно так же, как и круглые скобки, но квадратные имеют больший приоритет и т.д.. Одно из применений фигурных скобок - это группировка, например условий в систему уравнений. В языке С/С++ фигурные скобки используются тоже для группировки, но уже строк кода в один блок.
Итого нет единого стандарта м/у разными языками, все необязательно, у каждого свой, а побеждает стадный инстинкт.
Я не говорил, что трудностей вообще не будет, всё таки не все языки похожи, так же у них различаются библиотеки и т.д. Поэтому ознакомиться с документацией придётся в любом случае.
Таких холиваров полно и один из них - это ваше виденье идеального языка в сравнении с моим. И у вас и у меня есть сторонники. И таких споров не избежать.
Потому что они самые распространённые. И я не мог перечислить абсолютно все языки, но я в курсе, что среди них много не похожих.
Я это знаю и предложенный вами язык, если вы его реализуете, то он будет всего лишь одним из множества языков и я сомневаюсь, что он станет популярным.
Русский язык - это язык общения и это не значит, что для программирования надо использовать только его слова, не используя при этом символов. Языки программирования и языки общения всё-таки отличаются. Языки программирования развиваются в ту сторону, в которой алгоритмы можно будет записывать наиболее быстрым и при этом понятным способом. Краткую запись, которую вы отвергаете, любят многие программисты(уверен, что большинство) и без неё они просто не заметят вашего языка. Во всех современных языках она есть. Это же направление развития языков предсказывал Страуструп и в таких современных языках, как Pyton, D, Rust и т.д. её видно не вооружённым взглядом.
Направление не интересно. Есть давно Пролог и в нем запись p(A1, ... ,An) соответствует до 2^n функциям - очевидно, это уже асимптотически плотный язык общего назначения. Другой его частный случай Хаскелл тем более слабо интересен - мало того, что ограничен, так еще и перегружен.
Потом, у каждого свои задачи и цели:
Если Вам нужна математика - есть готовые для этого языки, где не нужно собирать лесопед,
Нужна русификация С/++/D - ну так Юрий работает над С/++, возможно что до D и Python'a у него тоже руки могут дойти, так что Ваши требования (либо иное участие) скорее к нему.
Отредактировано MihalNik (25.10.2014 09:15:38)
Существуют правила русского языка, там почти все есть из того, что нужно. Если опираться не на них, то полученное к русскому языку вообще отношения будет иметь мало, очевидно.
Там существуют много разделов правил, очевидно что жи-ши.. нас интересовать не будут так же как и фонетика или к примеру морфемика, ну если только как образец для структурирования чего там более масштабного чем с десяток символов и команды. Так понимаю в фокусе внимания правила синтаксиса, правил построения словосочетаний и предложении, и морфлогии. Кстати обратил внимание что структура иерархия элементов любого ЯП с ООП в точности совпадает с структурой морфологии естественного языка где есть деления на существительные, прилагательные, глаголы, наречия -признаки действии (указатели на них) и местоимения указатели на существительные или прилагательные, служебные части речи. Но думаю.. )) что Страуструп создавая свой С++ врятли исходил из правил естественного языка, скорее из своих потребностей что неизбежно и "нечаянно" его привело к понятиям класса-объекта - существительным события-методам- глаголам.. и прочему. Что конечно наводит на размышления...
Отредактировано robur (25.10.2014 14:33:10)
Ой, сколько всего тут понаписано… Честно говоря, читал не полностью. Но создалось такое впечатление, что всё это уже обсуждалось, только другим составом участников. А темы и аргументы спорящих похожи.
Yaisis, мне тоже нравится D. Но писать компилятор лучше на C++ или вообще на чистом C. Потому что первый язык, который делается для любой платформы – это С. Он есть на любой платформе – в отличие от многих красивый и достойных языков.
....писать компилятор лучше на C++ или вообще на чистом C. Потому что первый язык, который делается для любой платформы – это С. Он есть на любой платформе – в отличие от многих красивый и достойных языков.
А на каком, на чьём именно, С-компиляторе делать это лучше всего, на ваш взгляд?
Достаточно посмотреть что-нибудь на Перле. Он имеет один из самых кратких синтаксисов.
Ну я же не говорил, что любой краткий синтаксис хорош, должен быть баланс между краткостью и понятностью. И не надо делать кратко, если потом код становиться трудночитаем. Как пример могу привести сравнение с образцом, код в таком случае может стать намного кратче, чем если использовать условия, но при этом он становиться и наглядней и его легче разобрать, чем кучу условий. Вот такую краткость надо вводить, а ту, которая приводит к запутыванию - нет.
Хаскель? Далее или ранее Вы написали что у него вообще своя, отдельная математика.
Если хотите математику - есть уже mapple, matlab и т.д. - с точки зрения именно математики они просто прекрасны - понятия родные и не нужно придумывать велосипеды, как в C или D.
Безусловно языки там удобнее классического.
Причём тут С, D и математика ?
Я сказал, что взяли в эти языки математические символы и всё. Мы про квадратные скобки говорили, или вы уже забыли ? И я не хочу математику, мне нравится D и какой же это велосипед, если по удобству и по мощности до сих пор нет ни одного такого же системного языка программирования.
А С - это вообще один из первых таких языков, который обрел популярность в те времена и не спроста. Как можно сравнивать Си с велосипедом, если в день его создания аналогов ему просто не было ?
Есть давно Пролог и в нем запись p(A1, ... ,An) соответствует до 2^n функциям - очевидно, это уже асимптотически плотный язык общего назначения.
Это всего лишь обычная функция, которую можно реализовать в любом современнном языке программирования и в D можно сделать точно такую же.
Если Вам нужна математика - есть готовые для этого языки, где не нужно собирать лесопед
Вы похоже читать не умеете - мне не нужна математика, а мне нужны языки, которые используют математические символы. И вообще я хотел бы иметь универсальный язык, на котором можно решить любую задачу. Такой язык возможен, но дело в том, что например математикам удобны языки, в которых написано куча математических библиотек - эти библиотеки можно реализовать в любом языке, но ни кто их не реализует, поэтому математики и останутся на том, к которому привыкли.
Нужна русификация С/++/D - ну так Юрий работает над С/++, возможно что до D и Python'a у него тоже руки могут дойти, так что Ваши требования (либо иное участие) скорее к нему.
Русификация языка - это ерунда бесполезная, потому что это не приживётся и все будут использовать исходный иностранный язык. У меня нет проблем с английским языком, но в данном форуме обсуждаются русские языки, а русский язык должен быть не хуже уже созданных иностранных. Иначе он так и останется не известным.
Я не знаю, что вы подразумеваете под русским языком программирования - просто игрушку и временное увлечение ? Я же подразумеваю то, что он изначально должен быть мощным, гибким и привлекательным для программистов, чтобы он смог завоевать сердца русских программистов и тогда они начнут на нём программировать, создавать библиотеки и база кода на нём будет расти - вот тогда от языка будет толк. Если же вы сделаете язык, который будет никому не интересен, то и библиотеки для него будет писать некому, сами вы их все не напишите никогда и тогда это будет просто плохая попытка создать русский язык.
Вы говорите, что у каждого языка есть своя задача. Так вот русский язык программирования должен быть обязательно высокопроизводительным системным языком программирования общего назначения, чтобы на нём можно было решить любую задачу.
Как пример я приведу опять язык D, который является высокопроизводительным системным языком программирования включающим в себя все современные парадигмы программирования и избавленный от недостатков присущих C/C++. Язык D подошёл бы и для математиков, если написать все необходимые библиотеки.
В результате без разницы хотите ли вы использовать квадратные скобки и другие математические символы или нет - это ваше дело, главное - это создать удобный язык общего назначения, который привлёк бы к себе огромное внимание.
Если вы создадите очередной интерпретатор, то это нельзя назвать полноценным языком, т.к. например для написании ОС, драйверов и программ требующих высокую производительность придётся использовать иностранный язык программирования, например такой, как C/C++, D, Rust и т.д.
MihalNik написал(а):
В русском языке аж целых два способа. Оба распознаются и безо всяких скобок.
Мне не нужны пустые слова, давайте примеры.
Где примеры ?
Отредактировано Yaisis (25.10.2014 15:13:34)
Если ставить во главу угла многоплатформенность, то тут без GNU CC не обойтись. Он работает на разных ОС, на разных процессорах. Но лично мне он не нравится раздутостью и тормозами. Очень нравится TinyCC, но он работает только под Windows и Linux и только на х86. Да и сам проект не развивается: проект авторский, автор отошёл от дел, а другие не подхватили упавшее знамя.
Достаточно посмотреть что-нибудь на Перле. Он имеет один из самых кратких синтаксисов.
Да я убил бы автора за бесконечные $ $ $!
Очень нравится TinyCC, но он работает только под Windows и Linux и только на х86.
...да симпатишный )) На х64 то же должен работать ...вот если бы наоборот то врятли. Ну и в перспективе, его работу с 32 разрядам можно расширить до 64.
Yaisis, мне тоже нравится D. Но писать компилятор лучше на C++ или вообще на чистом C. Потому что первый язык, который делается для любой платформы – это С. Он есть на любой платформе – в отличие от многих красивый и достойных языков.
Понимаю, но на D думаю, что было бы писать приятней и проще.
К сожалению он пока не так популярен, как С/С++, из-за того, что сложно сместить со своего места язык, который глубоко пустил свои корни.
Но я D упоминал не с той точки зрения, чтобы на нём компилятор создавать, а как пример очень хорошего системного языка программирования общего назначения и русский язык программирования должен быть не хуже его.
А на каком, на чьём именно, С-компиляторе делать это лучше всего, на ваш взгляд?
Думаю, что без разницы. Исходники на Си должны компилироваться любым С-компилятором.
Если С-компилятор не может скомпилировать исходники, которые компилируют другие С-компиляторы, то данный С-компилятор не придерживается стандарта, а значит не качественный.
robur написал(а):А на каком, на чьём именно, С-компиляторе делать это лучше всего, на ваш взгляд?Думаю, что без разницы. Исходники на Си должны компилироваться любым С-компилятором.Если С-компилятор не может скомпилировать исходники, которые компилируют другие С-компиляторы, то данный С-компилятор не придерживается стандарта, а значит не качественный.
Проблема не только в качестве но и в лицензии... а то потом схватят за хобот... )))
Если ставить во главу угла многоплатформенность, то тут без GNU CC не обойтись. Он работает на разных ОС, на разных процессорах. Но лично мне он не нравится раздутостью и тормозами.
Вот в LLVM эти проблемы должны убрать, т.к. её с нуля проектировали и учли все эти моменты, так же, как писали, на LLVM лучше дела с отладкой и ошибки выдаваемые компилятором более понятные, но я это всё не проверял.
Проблема не только в качестве но и в лицензии... а то потом схватят за хобот... )))
Зависит от того, как распространять, если в исходниках, то это уже не ваши проблемы, а если заранее компилировать, а потом распространять скомпилированный файл, то тогда да, надо выбирать компилятор с правильной лицензией.
Я сторонник распространения в байткоде LLVM с компиляцией в машинный код архитектуры в момент установки, но такой способ был бы идеален, если бы генераторы LLVM стояли везде, но их надо устанавливать самому, т.к. пока они ни где не стоят по-умолчанию(хотя на маках может и стоят...), поэтому данный способ не подходит.
Отредактировано Yaisis (25.10.2014 15:41:07)
Зависит от того, как распространять, если в исходниках, то это уже не ваши проблемы, а если заранее компилировать, а потом распространять скомпилированный файл, то тогда да, надо выбирать компилятор с правильной лицензией.
Чем больше степеней свободы тем лучше.))
Исходники на Си должны компилироваться любым С-компилятором.
В теории теория и практика неразделимы. На практике это не так. (с) Кто-то из великих.
Написал на С под компилятор Borland, потом хочется откомпилировать MSVC. И тут начинается... У Борланда какая-то функция объявляется в одном h-файле, у MS в другом. А у TinyCC в третьем. У Борланда для перебора файлов в папке работает один набор функций, а у MS и TynyCC - другой. А в остальном, прекрасная маркиза, компилируется любым компилятором.
D может выступать в качестве объекта подражания. В определённых пределах, конечно. Будучи полностью повторённым, он просто станет D++ 
В TinyCC есть поддержка 64-разрядных чисел. Но код он генерирует под 32-разрядные платформы. Этот код будет работать на 64-разрядных платформах, но будет "неродным". Как пример: Apple запретила размещение в своём магазине новых приложений не под 64-разрядные платформы. Если бы TinyCC генерировал бы код для Apple, то его не допустили бы в магазин: у него код 32-рязрядный.
Я сторонник распространения в байткоде LLVM с компиляцией в машинный код архитектуры в момент установки, но такой способ был бы идеален, если бы генераторы LLVM стояли везде, но их надо устанавливать самому, т.к. пока они ни где не стоят по-умолчанию(хотя на маках может и стоят...), поэтому данный способ не подходит.
Просто сайт, с которого вы собираетесь раздавать программы в байт-коде LLVM, должен иметь компилятор из LLVM в "родной" для пользователя код. Проблему можно решить не на стороне пользователя, а а стороне сервера.
Apple
Да Хрен... с ними, то же мне свет в окошке. В конечном счете ориентация языка должна быть на сферу производство мат.благ а не на "эфемерные удовольствия" от навигатора в пару кварталов от дома ))) В управляющих офисах стоят ведь нормальные машины.. а не "писки моды"
Отредактировано robur (25.10.2014 15:59:00)
В теории теория и практика неразделимы. На практике это не так. (с) Кто-то из великих.
Написал на С под компилятор Borland, потом хочется откомпилировать MSVC. И тут начинается... У Борланда какая-то функция объявляется в одном h-файле, у MS в другом. А у TinyCC в третьем. У Борланда для перебора файлов в папке работает один набор функций, а у MS и TynyCC - другой. А в остальном, прекрасная маркиза, компилируется любым компилятором.
У Борланда кстати раньше были одни из самых плохих компиляторов - генерировали код по производительности намного хуже других известных компиляторов.
А вообще проблему я понял, но тут придётся подстраиваться конечно, а возможно надо пути прописать где-то.
Думаю, что в таком случае надо тогда выбирать самый известный компилятор. Я бы наверно выбрал GCC, т.к. он ещё и свободный.
D может выступать в качестве объекта подражания. В определённых пределах, конечно. Будучи полностью повторённым, он просто станет D++
Ну повторять же необязательно, можно создать свой синтаксис. Ещё в D нету вроде сравнения с образцом - неплохо бы добавить.
Я имел ввиду не копировать D, а создать язык не хуже его, чтобы он так же поддерживал много парадигм программирования. А то например программисты привыкнут к какому-то удобству, потом пересядут на новый русский язык программирования, а там нет аналога этому удобству и это будет плохо. Это даже может повлиять на отказ их от нового языка.
В TinyCC есть поддержка 64-разрядных чисел. Но код он генерирует под 32-разрядные платформы. Этот код будет работать на 64-разрядных платформах, но будет "неродным". Как пример: Apple запретила размещение в своём магазине новых приложений не под 64-разрядные платформы. Если бы TinyCC генерировал бы код для Apple, то его не допустили бы в магазин: у него код 32-рязрядный.
Он наверно генерирует 32 разрядный код, который в режиме совместимости может и на 64 разрядной архитектуре выполняться.
64 разрядные числа были и в 32 битных машинах. В 64 битных архитектурах в основном имеется ввиду 64 битная адресация, а так они поддерживают и 256 разрядные числа, например в регистрах AVX.
D может выступать в качестве объекта подражания. В определённых пределах, конечно. Будучи полностью повторённым, он просто станет D++
Читал его историю, он по задумке авторов и должен был прийти на смену С++ )) После С.. следующая буква ..D не срослось.. в место этого стали надстраивать С++ ... сейчас 14-ый если не ошибаюсь.
Отредактировано robur (25.10.2014 16:08:42)
Просто сайт, с которого вы собираетесь раздавать программы в байт-коде LLVM, должен иметь компилятор из LLVM в "родной" для пользователя код. Проблему можно решить не на стороне пользователя, а а стороне сервера.
Сайт не должен иметь компилятор, а пользователям придётся установить LLVM на свои компьютеры, поэтому это создаст неудобство для них и поэтому пока так не надо распространять.
В Линуксе и на маках LLVM наверно когда-нибудь будет стоять по-умолчанию. Так же в новом Андроиде AOT компиляцию реализовали через LLVM, поэтому она там должна стоять.
А вот в виндовсе скорее всего LLVM никогда не будет стоять по-умолчанию, т.к. для Майкрософта - это чужая технология.
Как вариант можно на сайте размещать 2 скомпилированных файла:
1) Байткод LLVM.
2) Полностью скомпилированный файл обычным компилятором, например GCC.
А пользователь сам пусть решает, что качать.
Но в пункте 2 придётся размещать ещё скомпилированные файлы под разные ОС и архитектуры.
Читал его историю, он по задумке авторов и должен был прийти на смену С++ )) После С.. следующая буква ..D не срослось.. в место этого стали надстраивать С++ ... сейчас 14-ый если не ошибаюсь.
Если вы сравните С++14 и D, то D будет намного удобней и наглядней, а не срослось потому, что полно С/С++ программистов, которые привыкли к этому языку и не собираются его менять и так же для него уже написана куча библиотек, которые конечно можно подключить и к D, но развивать их всё равно придётся на С/С++, т.к. переписывать всё на D очень долго. Тоже самое касается и других программ.
А автор языка D 12 лет(если не ошибаюсь) разрабатывал компиляторы для С/С++ и он видел все недостатки данного языка, именно поэтому и стал разрабатывать D.
D лучше всех стандартов С/С++ именно тем, что он разработан с нуля, а для новых версий С/С++ приходиться писать костыли, т.к. нельзя терять обратную совместимость и все недостатки этого языка навсегда останутся с ним именно из-за обратной совместимости.
Читал его историю, он по задумке авторов и должен был прийти на смену С++ )) После С.. следующая буква ..D не срослось.. в место этого стали надстраивать С++ ... сейчас 14-ый если не ошибаюсь.
Так это ж были разные люди! Одни (Уолтер Брайт) хотели D, другие (Страуструп и Ко) продолжили впихивать в С++ все новые и новые возможности.
Сайт не должен иметь компилятор,
Конечно не обязан. Но может, если сильно захотеть
Вы похоже читать не умеете - мне не нужна математика, а мне нужны языки, которые используют математические символы.
А кто-то любит код в долларах)))
Это всего лишь обычная функция, которую можно реализовать в любом современнном языке программирования и в D можно сделать точно такую же.
Ещё в D нету вроде сравнения с образцом - неплохо бы добавить.
А вот здесь балкон будет - проходите...)))
В том-то и фишка, что предикат это не обычная функция, и чтобы использовать его в каком-то языке придется написать в нем Пролог.
Но Вам лучше писать в D.
Какой С какой D ... всё это прошлый век )) неведомый ..E ...Вот "радость жизни" и будущий правнук Си.. ))))
Какой С какой D ... всё это прошлый век )) неведомый ..E ...Вот "радость жизни" и будущий правнук Си.. ))))
Тогда уже Ё, русская линейка же: ё-мобиль, ё-язык, ё-троллейбус.
мне не нужна математика, а мне нужны языки, которые используют математические символы.
Если понимать Вас буквально, то тогда придётся признать, что многие математические символы на клавиатуре отсутствуют. Нет знака "не равно", нет "пустого множества", нет "пересечение множеств", "объединение множеств". В языке APL такие символы были. Они отображались на экране в традиционном начертании, а вот набирались на клавиатуре с помощью магических последовательностей.
В принципе, ничто не мешает использовать математические символы из набора Unicode. И даже на Unicode можно наплевать: графический экран позволяет отобразить любую начертание. Вот только с вводом с клавиатуры проблемы. Или не проблемы, но как-то надо превращать магические последовательности в символы. Вот поэтому в программировании имена функций многобуквенны - так проще. И потомки APL - языки J и K отказались от символов, которых нет на клавиатуре.
Тогда уже Ё, русская линейка же: ё-мобиль, ё-язык, ё-троллейбус.
Ага, добавьте ещё Ётафон Ну а язык программирования должен называться просто и со вкусом: Ёзык
robur написал(а):Какой С какой D ... всё это прошлый век )) неведомый ..E ...Вот "радость жизни" и будущий правнук Си.. ))))Тогда уже Ё, русская линейка же: ё-мобиль, ё-язык, ё-троллейбус.
Не... ))) Ё лучше пропустить а то постигнет его участь -мобилей и D. Он есть, но денег на него нет. С Ё... это обычное дело )))
Ага, добавьте ещё Ётафон Ну а язык программирования должен называться просто и со вкусом: Ёзык
С Ё лучше не шутить ...сакральное. )))
Ну а язык программирования должен называться просто и со вкусом: Ёзык
У меня племяш в свои 3 знает Ёзыка.
Отредактировано MihalNik (25.10.2014 17:06:41)
А вот здесь балкон будет - проходите...)))
В том-то и фишка, что предикат это не обычная функция, и чтобы использовать его в каком-то языке придется написать в нем Пролог.
Вы привели пример и плохо описали, что он означает. Возможно я не так понял. Объясните понятней и я скажу можно ли в D это реализовать или нет.
С помощью метапрограммирования в D можно сделать многое.
Отредактировано Yaisis (25.10.2014 19:03:34)
Если понимать Вас буквально, то тогда придётся признать, что многие математические символы на клавиатуре отсутствуют. Нет знака "не равно", нет "пустого множества", нет "пересечение множеств", "объединение множеств". В языке APL такие символы были. Они отображались на экране в традиционном начертании, а вот набирались на клавиатуре с помощью магических последовательностей.
В принципе, ничто не мешает использовать математические символы из набора Unicode. И даже на Unicode можно наплевать: графический экран позволяет отобразить любую начертание. Вот только с вводом с клавиатуры проблемы. Или не проблемы, но как-то надо превращать магические последовательности в символы. Вот поэтому в программировании имена функций многобуквенны - так проще. И потомки APL - языки J и K отказались от символов, которых нет на клавиатуре.
Дело не в этом, а просто эти спорящие люди предлагают отказаться от символов, которые уже используются в языках. А я хочу, что бы все эти символы остались.
Мне на самом деле нужны только они, а остальные нет. А всё пошло от-того, что я сказал, что эти символы пришли из математики. А эти люди читают невнимательно просто, отсюда и соответствующие их неправильные предложения.
Yaisis написал(а):
MihalNik написал(а):
В русском языке аж целых два способа. Оба распознаются и безо всяких скобок.
Мне не нужны пустые слова, давайте примеры.
Где примеры ?
Повторю ещё раз, где примеры ?
Или вы это всё выдумали ?
Отредактировано Yaisis (25.10.2014 17:34:39)
Вы привели пример и плохо описали, что он означает. Возможно я не так понял. Объясните понятней и я скажу можно ли в D это реализовать или нет.
С помощью метапрограммирования в D можно сделать многое.
1) Что это такое ни от кого не скрывается - гугл выдает предостаточно. Я не справочная.
2) В любом Т-полном языке можно реализовать любой другой, поэтому что ни говорить, всё бессмысленно.
P.S. Нет там этого и не будет - так как сразу отпадает необходимость в большом кол-ве ништяков, переучиваться никто не станет.
Сначала массы будут осваивать Хаскель, потом, постепенно, дойдут и до логического.
Повторю ещё раз, где примеры ?
Или вы это всё выдумали ?
Да считайте хоть, что я выдумал русский язык - Вас это не интересует, так что тратить время не стоит.
Отредактировано MihalNik (25.10.2014 18:14:01)
предлагают отказаться от символов, которые уже используются в языках. А я хочу, что бы все эти символы остались.
А какие именно?
Вы о чём-то спорите, только не понял – а где начальная посылка, вокруг которой ломаются копья?
1) Что это такое ни от кого не скрывается - гугл выдает предостаточно. Я не справочная.
2) В любом Т-полном языке можно реализовать любой другой, поэтому что ни говорить, всё бессмысленно.
P.S. Нет там этого и не будет - так как сразу отпадает необходимость в большом кол-ве ништяков, переучиваться никто не станет.
Сначала массы будут осваивать Хаскель, потом, постепенно, дойдут и до логического.
Короче это обычная функция, которую можно в D реализовать.
Если не справочная, то не чего в пример приводить обычные функции, которые легко реализуются в любом языке.
Да считайте хоть, что я выдумал русский язык - Вас это не интересует, так что тратить время не стоит.
Ну так бы и сказали, что вы просто предположили, что это как-то можно реализовать по-другому, при этом, как именно вы и сами пока не знаете и не задумывались об этом.
Я же спросил потому, что мне просто интересно, вдруг мне бы понравилась ваша идея, если бы конечно она у вас была.
А какие именно?
Вы о чём-то спорите, только не понял – а где начальная посылка, вокруг которой ломаются копья?
Да они предлагают отказаться от символов [], {} и аналогичных, которые есть в американской раскладке.
Я же говорю, что это полезные символы.
Один из них говорит, что данные символы пришли с запада и всё западное надо удалить, а я сказал, что эти символы из математики пришли и не принадлежат западу.
Второй говорит, что при встрече одного из этих символов в коде(например []), программисту становиться сложно распознать то, что он обозначает и т.д. Я же говорю, что данные символы программисты распознают, как и символы +, - и аналогичные и они в курсе, что [] - это например массив.
Вообщем есть символы на клавиатуре, которые стали стандартом, но эти символы доступны только в американской раскладке, что вызывает неудобство и это одна из причин, по которой они хотят отказаться от символов. Я же считаю, что надо дорабатывать русскую раскладку и не надо отказываться от полезных символов. Можно только знак $ заменить на знак рубля.
Начальная посылка, где-то вверху.
Отредактировано Yaisis (25.10.2014 19:20:19)
Большинство символов типа [] {} трудно не использовать, да и они хорошо распознаются в тексте глазами. Надо действительно что-то придумывать с раскладкой.
От $ отказаться легко (если конечно Вы не программируете на Perl или PHP), не нужен он особо.
Большинство символов типа [] {} трудно не использовать, да и они хорошо распознаются в тексте глазами. Надо действительно что-то придумывать с раскладкой.
От $ отказаться легко (если конечно Вы не программируете на Perl или PHP), не нужен он особо.
Да и $ можно оставить, для символа рубля(если он нужен) найдётся место.
Я думаю, что в любом случае надо оставить существующие символы, чтобы не терять совместимости с уже написанными программами.
Надо раскладку менять(дорабатывать) - это единственный правильный вариант.
Вы о чём-то спорите, только не понял – а где начальная посылка, вокруг которой ломаются копья?
Он Вам такого наговорит, что и нас с Utkin'ым не существует=)
Я ни от каких знаков отказываться не предлагал, там логика дырявая 
Суть примерно такова, что требуется корабль, а предлагается поставить дизельный мотор на велосипед.
Большинство символов типа [] {} трудно не использовать, да и они хорошо распознаются в тексте глазами. Надо действительно что-то придумывать с раскладкой.
От $ отказаться легко (если конечно Вы не программируете на Perl или PHP), не нужен он особо.
Способов довольно много, вплоть до того, что иногда знаки могут сами проставляться в исходнике, но совсем отсутствовать на раскладке, зависит от того какими их смыслами нагрузить.
Для глаз разные скобки неплохи, конечно.
Да понимаю, поэтому и предлагал единый стандарт, а все остальное кому как нравится, с возможностью перегонки туды-сюды. Плюс это не все задумки - речь шла о базе. То есть не только синтаксис в рамках одного национального шрифта, а использование других языков - английский, китайский, французский и т.д. Естественно смешение в рамках одной программы наверно не желательно, а так в общем было бы интересно.
Человек в какой-нибудь Германии пилит функцию и отправляет ее Вам. Вы переводите ее на стандарт (комментарии больное место) и понимаете о чем идет речь. Поскольку каждый работает на том языке на котором он думает число ошибок в теории должно стать меньше.
Вот, вспомнил, там проблема в переводе не только комментариев - названия разных переменных и др. понятий тоже так просто перевести не получиться. Т.е. только частично автоматизировано и нужно удобное надежное средство. А задача хорошая.
Отредактировано MihalNik (26.10.2014 02:38:40)
Если про символы, то я затронул проблему эргономики языка, указав, что используя текущее положение дел и русский язык часто придется переключать раскладку. Указал на проблему и предложил пару вариантов ее решения. Человек обиделся. Как-то так...
Ни кто не обижался, просто ваши варианты решения не понравились человеку и вы стали намекать на то, что он дурак, раз с вами не согласен. А этому человеку всё равно, как вы реализуете данные действия в своём языке, просто не навязывайте своё мнение окружающим. И не говорите всем о том, что вы умнее всех, раз у вас огромный опыт накопился по переключению раскладки.
Отредактировано Yaisis (26.10.2014 15:39:33)
Необязательно. Например, пара <понятие>(<содержимое>) равносильна любому кол-ву разновидностей скобок (и даже эти круглые лучше убрать).
"массив(1,2,3,4,2,3,1,1)" лучше чем "[1,2,3,4,2,3,1,1];", т.к. не нужно задумываться про обозначения.
Каждый дополнительный знак - зло, т.к. его нужно заучивать.
"a = массив(1,2,3,4,5);"
В данном случае и знак равенства лишний. За массивные же куски вроде "[1,2,3]" в любом месте программы многие испытавают желание отрывать части тел.
Знак сложения знает 99% людей, про квадратные скобки - в 1000 раз меньше.
Я ни от каких знаков отказываться не предлагал, там логика дырявая
Логика действительно дырявая в ваших высказываниях.
"А если например надо обратиться к массиву по индексу, то пишем так: "a[индекс] = 3", где по квадратным скобкам видно, что идёт обращение к массиву. Как в вашем варианте без скобок реализовать эту операцию ?"
В русском языке аж целых два способа. Оба распознаются и безо всяких скобок.
"Мне не нужны пустые слова, давайте примеры."
"Повторю ещё раз, где примеры ?
Или вы это всё выдумали ?"
Да считайте хоть, что я выдумал русский язык - Вас это не интересует, так что тратить время не стоит.
И ни одного способа даже не смогли назвать - пустые высказывания.
Суть примерно такова, что требуется корабль, а предлагается поставить дизельный мотор на велосипед.
Дело в том, что вы даже предложить ничего не смогли, когда я вас спрашивал о варианте вашего решения проблем.
Поэтому пока вы всё ещё мечтаете о "корабле", мы уже ездим на "велосипеде с дизельным мотором", а ваша мечта о корабле, так и останется несбыточной мечтой.
Отредактировано Yaisis (26.10.2014 16:16:17)
Вы о чём-то спорите, только не понял – а где начальная посылка, вокруг которой ломаются копья?
По хорошему, если вы хотите узнать суть спора, то я бы посоветовал прочитать внимательно историю переписки и сделать выводы самостоятельно, а не читать оправдания этих комментаторов, в которых не видно сути.
Ваше мнение ошибочно. Боюсь, опять скажите что навязываю свое мнение и Вы дурак...
Вы даже нормально выразить свои мысли не можете или в данном своём высказывании вы оскорбили меня, назвав дураком ?
костылей в виде специализированных типов данных, на вроде массивов
Гм… Лично моё мнение такое. Тип данных – это совершенно отдельная сущность, которая может находиться как составная часть, некий атомарный объект внутри другой сущности – множеств. Эти множества могут иметь разные формы: массивы, списки, ассоциативные массивы, стеки, деки, очереди, списки и т.д. Между ними надо провести грань, иногда тонкую. Например структура/запись (в Си/Паскале) – это тип данных или множество?
Думаю, такое дело больше всего зависит от целевых обрабатываемых данных.
Если интерпретатор работает только со строками не вникая в сложные бинарные форматы,
можно считать все данные строками
Отредактировано MihalNik (28.10.2014 12:19:40)
Ха... Что за шутки? )) .. Из комментариев http://forum.codenet.ru/q73887/Разрабатываю язык Динрус на основе D. (%D0%94%D0%B8+%D0%BF%D0%BE-%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8).+%D0%9A%D0%B0%D0%BA+%D0%BB%D1%83%D1%87%D1%88%D0%B5+%D1%80%D0%B0%D0%B7%D0%BC%D0%B5%D1%81%D1%82%D0%B8%D1%82%D1%8C+%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82+%D0%B2+%D1%81%D0%B5%D1%82%D1%8C%3F )) (ц) /24 декабря 2012, 12:35:51/ ..Динрус - это русская версия языка программирования D. На данный момент язык находится в разработке - ведётся разработка основной рантаймной библиотеки Dinrus.Base.dll
Описывать преимущества Ди перед Си++ не буду - они очень высоки.
Что касается Динрус, то я лично занимаюсь его разработкой и хотел бы найти помощников в этом деле.
Си входит сюда же, как составная часть.
Вот ряд сишных функций в Динрус:
extern (C):
цел удали(in ткст фимя);
alias удали remove;
цел переименуй(in ткст из, in ткст в);
alias переименуй rename;
фук времфл();
alias времфл tmpfile;
ткст времим(ткст s);
alias времим tmpnam;
цел закройфл(фук поток);
alias закройфл fclose;
цел слейфл(фук поток);
alias слейфл fflush;
фук откройфл(in ткст фимя, in ткст режим);
alias откройфл fopen;
фук переоткройфл(in ткст фимя, in ткст режим, фук поток);
alias переоткройфл freopen;
проц устбуф(фук поток, ткст буф);
alias устбуф setbuf;
цел уствбуф(фук поток, ткст буф, цел режим, т_мера размер);
alias уствбуф setvbuf;
цел вфвыводф(фук поток, in ткст формат, спис_ва арг);
alias вфвыводф vfprintf;
цел вфсканф(фук поток, in ткст формат, спис_ва арг);
alias вфсканф vfscanf;
цел всвыводф(ткст s, in ткст формат, спис_ва арг);
alias всвыводф vsprintf;
...... и т.д. Пойду разбираться )) по http://sourceforge.net/projects/dinrus/ … p_redirect
Отредактировано robur (30.10.2014 15:19:03)
Кстати "со следующим языком" Е я погорячился ...он уже есть ))) http://erights.org/ https://ru.wikipedia.org/wiki/Amiga_E
Отредактировано robur (30.10.2014 16:17:04)
Кстати "со следующим языком" Е я погорячился
Букв латинского алфавита всего 26. Выбирайте отечественное! Кириллица пока свободна!
Dinrus последний раз обновлялся в декабре прошлого года. Надо бы пригласить парня на этот форум, коли он задумался о программировании на русском. Кстати, уверен, что мой русификатор подойдёт или для языка D
Язык Д http://okante.narod.ru/D/high.html уже есть. Автор - Михаил Александрович Валеев.
Кстати "со следующим языком" Е я погорячился ...он уже естьБукв латинского алфавита всего 26. Выбирайте отечественное! Кириллица пока свободна!
А что делать придётся )).. Но Ж не стоит, ))) ..недаром Врунгель любил говаривать ... Как корабль назовёте так он и поплывёт.
Dinrus последний раз обновлялся в декабре прошлого года. Надо бы пригласить парня на этот форум, коли он задумался о программировании на русском. Кстати, уверен, что мой русификатор подойдёт или для языка D
Вам будет о чём поговорить ..))
Язык Д http://okante.narod.ru/D/high.html уже есть. Автор - Михаил Александрович Валеев.
Он интересно рассуждает http://okante.narod.ru/D/rl.html (ц) ...§ 2.1 Экстраполируем...
...всё это на языки и увидим. Язык компьютерный изобретен человеком, поэтому изначально был абсолютно познаваем, как чисто культурное произведение. Но затем по мере со всего развития он претерпел множество метаморфоз, большинство которых вели к его усложнению, он стал более мощен, поэтому более сложен, поэтому и менее познаваем (хотя пытались препятствовать этому, но ничего не поделаешь: реальные задачи требуют именно природные решения).
Русский язык давно уже закончил своё развитие в основном, поэтому проследить его становление слаженнее, однако должно быть ясно, что он стремился именно к простоте, следовательно к языку программирования (выделив сознательно какое-либо подмножеством получим типичный простой и эффективный зомби-язык(udaff.com), т.е. для НЛП, но это ложное программирование, оно противоречит принципам языка Д, поэтому оставим это).
Однако надо признать, что русский язык так и остановился на середине своего вектора развития. Это доказывается, например, этим всем текстом. Самые пытливые из вас уже наверняка заметили, что некоторые буквы (а иногда и слова) идут не так как надо. Вот это и является одним из проявлений избыточности русского языка.
§ 2.2. Предпосылки
Почему так? Всё очень просто.
Русский язык создавался на основе опыта, данных от природы. Человек того времени не смог так хорошо обобщать факты, потому что он был близок к природе, т.е. универсален, — и станцует и споет и по роже надает. За это он расплачивался отсутствие глубины знаний. Поэтому он не смог тогда выделять общие закономерности (анализ) и язык был огромен и сложен. Затем пошел процесс дифференциации, появились профессионалы, они-то и привели язык в божесткий вид, сделав из него такой, какой мы имеем сейчас.
Лирически отступив, скажу, что на данный момент дифференциация уже изжила себя как таковая, транзакционные издержки на взаимодействие между отдельными специалистами резко возросли (они ни хера друг друга не понимают). Маятник разума, разогнанный божественной рукой, дошел до со всего крайнего положения, и пора уже переходить к интеграции следую синусоиде гигантского переходного процесса (однако тут важное войти в резонанс).
Вернемся к языкам. Так вот русский язык уже развит в свою оптимальную форму.
Язык программирования. Изначально был придуман математиками, поэтому был не очень удобен зато красив (0101010001000010100100101010101010). Но, постепенно одумались и произвели на свет то, что мы сейчас видим. Ещё одной причиной для изначальной простоты языков программирования была причина легкости написания компилятора к ним. Дело в том, что в те далекие времени=а время в компьютерных клубах (тогда они были только в университетах) оплачивалось временем, проведенным в лагере (за вредительство, падла). Потому компилировать и интерпретировать надо было быстро.
§ 3. Вывод 1
Мы получили классическую пропорцию Русский язык / Человек = Язык программирования /Компилятор С++
Казалось бы нам следует отступиться от такой дерзкой мысли, превзойти интеллект человека. Неверно. Мы должны лишь направить туда вектор нашего развития, потому что именно здесь ключ к удовлетворению потребности во всё более возрастающем функционале.... Интересно .. он так пожалуй до "стековой машины" доберётся. ))
Отредактировано robur (03.11.2014 22:22:40)
Если выдрать из контекста и читать только приведнный фрагмент - многие вещи спорные, особенно с философским уклоном, навроде "абсолютно познаваем", универсальность человека на заре развития и т.д.
Да конечно..)) Но тем не менее ЯП это только то что вы в него "положите" и не более.. другое дело вы сами можете не знать о том что собственно "положили" туда.. ))) В общем старая история.. и в жизни и в программировании в частности..
Также огорчает культ поклонения с++. Бесспорно язык сыграл свою существенную роль в индустрии программирования, но не является необходимой вещью для развития ИТ. Иными словами отсутствие с++ не остановило бы развитие программирования. Потому наверно нет смысла молиться на него.
Ну так было бы чего ни будь другое.. просто так вышло что производители железа выбрали его.. Вот когда "стековые машины" окончательно набьют морду "регистровым", в связи с перспективой реализации технологии "квантовых процессоров", то будем "молится" на Форт ... ++ ))))
Опусы автора языка Д – смесь жанров: философии, юмора с небольшой примесью обещаний насчёт продвинутости своего языка. Там почерпнуть особо нечего. Если бы он определился бы с одним жанром, было бы проще его понять. А то не понятно - то ли шутит человек, то ли всерьёз так думает...
Вот когда "стековые машины" окончательно набьют морду "регистровым", в связи с перспективой реализации технологии "квантовых процессоров", то будем "молится" на Форт ... ++ ))))
Что Вам внушило мысль о грядущей победе стековых машин? Тенденции, как мне кажется, говорят об обратном. Если взять ассемблер LLVM, то эта теоретическая архитектура имеет бесконечное число регистров. К чему бы это? Почему упор сделан не на стек? Читал в Инете споры о том, что лучше – регистровая архитектура или стековая, многие доказывают, что регистровая лучше. Один из аргументов – то, что операции с регистрами произодятся за один такт процессора. Стек же находится в памяти. Это первые поколения процессоров обращались к памяти за один такт. Сейчас обращение в память съедают несколько тактов, что замедляет скорость вычислений.
Лично мне больше нравится стековая архитектура. Но недостаток её (долгое обращение к памяти), можно побороть. Попытки сделать стековый процессор были. Но никто не пытался делать стек сделать не в памяти, а в неадресуемых (безымянных) регистрах. Конечно, глубина стека потенциально перекрывает всю ОП. Но ведь вершину и наиболее близкие к вершине ячейки памяти можно разместить в регистрах процессора. Чтобы регистры хранили копию того участка ОП, который является стеком. Тогда к верщине стека можно будет обратиться за один такт. Окончательного же мнения, как лучше – с регистрами или стеком, не имею, потому что тему надо знать хотя бы на среднем уровне.
Форт никогда не «победит», его популярность уже лет 20-30 только падает. Желающие могут почитать статью на эту тему: «Почему обречён язык Форт». И комментарии к ней тоже.
огорчает культ поклонения с++
Постоянно пользуюсь, С++, но обожествлять его не собираюсь. Он лишь – инструмент, вот и всё. Пользуюсь С++ как унитазом: полезен, подчас незаменим, но глупо делать унитаз предметом культа. Приведу цитату Криса Касперски (в миру - Николай Владимирович Лихачёв):
Популярность Си++ отчасти вызвана тем, что он вобрал в себя все существующие парадигмы, допускающие эффективную реализацию. Остальные языки либо неэффективны, либо представляют собой подмножество Си++.
...благополучию Си++ ничего не угрожает. Сколько бы языков ни создавалось и какие бы усилия ни предпринимались для продвижения их на рынок, мы получим либо урезанный вариант Си++, либо страшный тормоз.
...новые языки приходят и уходят, а Си++ вбирает в себя все удачные решения своих конкурентов, становясь целым миром.
И действительно, трудно представить, что С++ вскорости будет уйдёт на второй план. В него внедряются интересные новации. Да, он плох по причине поддержки обратной совместимости. Я бы сделал ещё одну версию языка (назовём её условно ++С), из которой были бы «вырезано» всё плохое, и при этом ++С был бы подмножеством С++. Хорошим подмножеством, без тех вещей, которые вызывают заслуженную критику.
отсутствие с++ не остановило бы развитие программирования
Если одномоментно изъять во всём мире компиляторы С++ и запретить писать новые, то наступит компьютерный апокалипсис. Не смогут даже закрыть обнаруженные уязвимости: Microsoft, Google, Apple, Adobe и прочая, прочая, прочая...
Что Вам внушило мысль о грядущей победе стековых машин? Тенденции, как мне кажется, говорят об обратном. Если взять ассемблер LLVM, то эта теоретическая архитектура имеет бесконечное число регистров. К чему бы это? Почему упор сделан не на стек? Читал в Инете споры о том, что лучше – регистровая архитектура или стековая, многие доказывают, что регистровая лучше. Один из аргументов – то, что операции с регистрами произодятся за один такт процессора. Стек же находится в памяти. Это первые поколения процессоров обращались к памяти за один такт. Сейчас обращение в память съедают несколько тактов, что замедляет скорость вычислений.
Лично мне больше нравится стековая архитектура. Но недостаток её (долгое обращение к памяти), можно побороть. Попытки сделать стековый процессор были. Но никто не пытался делать стек сделать не в памяти, а в неадресуемых (безымянных) регистрах. Конечно, глубина стека потенциально перекрывает всю ОП. Но ведь вершину и наиболее близкие к вершине ячейки памяти можно разместить в регистрах процессора. Чтобы регистры хранили копию того участка ОП, который является стеком. Тогда к верщине стека можно будет обратиться за один такт. Окончательного же мнения, как лучше – с регистрами или стеком, не имею, потому что тему надо знать хотя бы на среднем уровне.
Форт никогда не «победит», его популярность уже лет 20-30 только падает. Желающие могут почитать статью на эту тему: «Почему обречён язык Форт». И комментарии к ней тоже.
)) Внушение было очень серьезным, тем более технология "квантовых процессоров" на подходе. 96 гигафлопс на технологии 180 нанометров при стандарте 10х10 мм, Чарльз Мур лично своим "Программируемым калькулятором" набил морду всему инженерному корпусу Интел с их "наномилитражём" )) А вы говорите "тугодум," главное творческий подойти к процессу.. и за один "такт" делать 144 операции )))) . Причина умирания Форта как раз в отсутствии родного железа для него, приходилось пастись на территории Си, и даже там он ему немногим уступал. Новость двухлетней примерно давности цитата с "Линкуса"
(ц) GA144: 144-ядерный агрегат с Forth на борту.
В каждом ядре:
32 5-битные инструкции
64 18-битных слов RAM
64 18-битных слов ROM
8+2 кольцевой стек данных
8+1 кольцевой стек возвратов
18-битный регистр A
9-ти битный регистр B
10-битный регистр P (счетчик команд) 9-й бит — режим арифметики, 8-й бит — пространство ввода-вывода, 0-7 - адрес.
144 ядра в виде матрицы 8*18. На внешних ядрах всякие полезные штуки типа ADC, GPIO и проч.
180 nm, 20$
96 миллиардов операций в секунду.
Все ядра работают полностью асинхронно. Единого тактового генератора нет вообще. Синхронизация через коммуникационные порты.
Возможность напрямую считывать инструкции из коммуникационного порта.
Инструкции пакуются в 18-битное слово: 3 полноценных 5-ти битных, плюс 3-битный огрызок.
Архитектор — Сам.
Виндовая версия (sic!) ColorForth с IDE'шкой и симулятором на халяву.
В отладочной плате ядро 0 крутит версию eForth из SPI флешки, ядро 1 обеспечивает взаимодействие с компом разработичка.
Команда разработчиков, выгнатая из IntellаSys (40-ядерный S40 схожей архитектуры, архитектор опять же Сам) основала свою компанию Green Arrays.
А вот некоторый обзор системы на русском PDF http://www.asu.ru/files/documents/00003829.pdf А это сайт Компании Мура http://www.greenarraychips.com/home/products/index.html
P.S Особенно это ...180 nm, от сюда и 20 баксов, ...96 гигафлопс 
...Ляля. ))
Отредактировано robur (14.11.2014 07:11:53)
Ещё недавно отсутствие покупателей у какой-то новой архитектуры означало её крах. Один из недавних ярких примеров – Itanium. Всё у неё замечательно было, вот только спрос не очень. Это и погубило.
Но теперь всё по-другому! Если нет покупателей, то можно делать процессоры для себя, загрузив их денежной работой, а именно добычей биткоинов. Если эта 144-ядерная архитектура так хороша, то она столько заработает своему создателю! Или не заработает, если не хороша. "Будем посмотреть".
Ещё недавно отсутствие покупателей у какой-то новой архитектуры означало её крах. Один из недавних ярких примеров – Itanium. Всё у неё замечательно было, вот только спрос не очень. Это и погубило.
Но теперь всё по-другому! Если нет покупателей, то можно делать процессоры для себя, загрузив их денежной работой, а именно добычей биткоинов. Если эта 144-ядерная архитектура так хороша, то она столько заработает своему создателю! Или не заработает, если не хороша. "Будем посмотреть".
Пробивал я эту тему... )) Там научная проблема и дело даже не столько в "железе" многоядерной архитектуры а в программировании на нём.. Нет пока научной математической абстракции которая бы ясно моделировала работу и давала представление таких вычислений то бишь теории, никто толком ничего сказать не может, "кто в лес кто по дрова", а те что есть "закрыты" например я знаю что NVIDIA продвинулась в этом направлении программировании на такой архитектуре в смысле универсальных многоядерных процессоров но как это они делают они не кому не говорят)) Интересно что даже сам термин параллельные вычисления при анализе абсурден, он пытается нарушить принцип причинности, нельзя ведь ходить параллельно двумя ногами ))) Так же и с командами программы. Было бы правильнее говорить о распределённых вычислениях на процессорах многоядерной архитектуры.. )) И вот сейчас ребята сидят и чешут репу над этим GA 144 ... У них до сих пор нет ОС для "параллельных" вычислений.. занимаются как это говорится прототипированием чего то там, используя подключения к РS с ОС Винд или Линкус через порт )) Ну это пройдёт со временем... Кстати это отличная возможность для электронной отрасли в РФ ... если Мур умудрился на 180 нм сделать 96 гигафлопс то им сам бог велел на 90 нм сделать в два раза больше за ту же цену. Нужно собрать светил математики физики в одной комнате и не выпускать пока они не решат эту задачу распределённых вычислений для много- много- ядерной архитектуры .
Отредактировано robur (15.11.2014 13:46:10)
Пробивал я эту тему... )) Там научная проблема и дело даже не столько в "железе" многоядерной архитектуры а в програмемировании на нём.. Нет пока научной математической абстракции которая бы ясно моделировала работу и давала представление таких вычислений то бишь теории, никто толком ничего сказать не может, "кто в лес кто по дрова", а те что есть "закрыты" например я знаю что NVIDIA продвинулась в этом направлении программировании на такой архитектуре в смысле универсальных многоядерных процессоров но как это они делают они не кому не говорят)) Интересно что даже сам термин параллельные вычисления при анализе абсурден, он пытается нарушить принцип причинности, нельзя ведь ходить параллельно двумя ногами ))) Так же и с командами программы. Было бы правильнее говорить о распределённых вычислениях на процессорах многоядерной архитектуры.. ))
Никакой принцип причинности там не нарушается. Неудачные названия говорят лишь о плохом знании языка, не более. Для математиков - сплошь и рядом, да, они склонны распространять свой небогатый запас на все что угодно.
Отредактировано MihalNik (17.11.2014 20:47:54)
Никакой принцип причинности там не нарушается. Неудачные названия говорят лишь о плохом знании языка, не более. Для математиков - сплошь и рядом, да, они склонны распространять свой небогатый запас на все что угодно.
Неудачные названия говорят не о плохих знаниях языка а о плохих знаниях предмета рассмотрения или в общее о их отсудствии... По себе знаю )) отсюда и выходит "плохой язык". По поводу попыток "забодать" принцип причинности в данном вопросе вот по любопытствуйте ...(ц) /Вика Модель Акторов/ Развитие модели акторов имеет интересную связь с математической логикой. Одной из ключевых мотиваций для её развития была необходимость управления аспектами, которые возникли в процессе развития языка программирования Planner. После того как модель акторов была первоначально сформулирована, стало важно определить мощность модели в отношении тезиса Роберта Ковальского о том, что «вычисления могут быть сгруппированы по логическим выводам». Тезис Ковальского оказался ложным для одновременных вычислений в модели акторов. Этот результат всё ещё является спорным, и он противоречит некоторым предыдущим представлениям, поскольку тезис Ковальского верен для последовательных вычислений и даже для некоторых видов параллельных вычислений, например, для лямбда-исчислений.
Тем не менее были предприняты попытки расширения логического программирования для одновременных вычислений. Однако, Хьюитт и Ага в работе 1999 г. утверждают, что результирующая система не является дедуктивной в следующем смысле: вычислительные шаги параллельных систем программирования логики не следуют дедуктивно из предыдущих шагов. А постановка проблемы всего то требовала дать абстрактную математическую модель вычисления одной программы на n-количестве процессоров, а не упражняется в изобретение синонимов к старым понятиям в данном случае объект, выдавая их за вновь образованные, втюхивая ересь программистам о "параллельном вычислении" где команды программы исполняются, присутствуют, в "двух местах сразу" и не зависимо друг от друга... Возможно в Шапито такие фокусы и проходят ))) ....но не в реальном физическом мире нет..
Тут пожалуй один выход, решать эту задачу не в парадигме абстрактной логики математической, а в парадигме логики физики.
Отредактировано robur (17.11.2014 22:02:37)
Неудачные названия говорят не о плохих знаниях языка а о плохих знаниях предмета рассмотрения или в общее о их отсудствии... По себе знаю )) отсюда и выходит "плохой язык".
В данном случае личные впечатления не уместны. Медленный и слабый перевод знаний с одного языка на другой говорит об обратном - люди плохо знают языки. Причем именно свой родной, т.к. изучают его в далеком детстве. Сложно перевести серьёзные знания: переводчики не совладают с предметной областью, а специалисты - с областью перевода, зато ими эти знания успешно усваиваются и применяются на другом языке, безо всякого перевода, для программиста это очевидно.
Тут пожалуй один выход, решать эту задачу не в парадигме абстрактной логики математической, а в парадигме логики физики.
Логика физики это лишь некоторые разделы математики, которая и заключает все "какие-нибудь" логики.
утверждают, что результирующая система не является дедуктивной в следующем смысле: вычислительные шаги параллельных систем программирования логики не следуют дедуктивно из предыдущих шагов.
Странное утверждение. Разделить вычисления можно всегда. Но не все полученные результаты будут иметь физический смысл для решения задачи, это просто бессмысленно требовать.
Любое условие лишает смысла одну из двух выбираемых ветвей вычисления. Зависимость от данных снижает вероятность значимости предсказанного вычисления.
В любом случае, результат, имеющий смысл в конечном счете, а не отбрасываемый на каком-то шаге, будет выводимым следствием, либо решение неправильно.
А постановка проблемы всего то требовала дать абстрактную математическую модель вычисления одной программы на n-количестве процессоров, а не упражняется в изобретение синонимов к старым понятиям в данном случае объект, выдавая их за вновь образованные, втюхивая ересь программистам о "параллельном вычислении" где команды программы исполняются, присутствуют, в "двух местах сразу" и не зависимо друг от друга... Возможно в Шапито такие фокусы и проходят ))) ....но не в реальном физическом мире нет..
n-процессоров в физическом мире будут соответствовать "идеальному" вычислителю только ряда задач динамического программирования, да еще с определенной кратностью числа проходных
данных. Во всех остальных случаях есть "ненужные" вычисления.
Постановка абстрактных желаний не всегда дает желаемый результат, т.к. он уже ограничен имеющимися знаниями. Даже для заведомо осуществимого они могут просто сказать: "слишком долго".
Отредактировано MihalNik (18.11.2014 02:51:35)
Логика физики это лишь некоторые разделы математики, которая и заключает все "какие-нибудь" логики.
Пожалуй модератора нужно попросить создать какую ни будь ветку для обсуждения "Высоких материи" )) и почистить тему ..захламили. ...Что касается математики ..то Вы не правы, физика и математика равны как явления этого мира в том смысле что обои используют Логику как явление. Она старше в этой иерархии явлений их обоих. Отличие математической абстрактной логики и логики физических величин существенно, одна работает с абстрактными величинами, системой "переменных" другая с системой "констант". По этому математикам частенько пеняют на то что они не знают "где верх где низ" или когда "пытаются" переопределить "константы" в "переменные" в наглую. В общем математиков одних оставлять нельзя... )))
n-процессоров в физическом мире будут соответствовать "идеальному" вычислителю только ряда задач динамического программирования, да еще с определенной кратностью числа проходных
Только если они не асинхронные.. )) Все что от них нужно это увеличение скорости вычислении, использование преимущества их множественности перед моно- процессором, и что бы естественно никаких "параллельных" результатов на выходе... ))
Отредактировано robur (18.11.2014 11:33:05)
Что касается математики ..то Вы не правы, физика и математика равны как явления этого мира в том смысле что обои используют Логику как явление. Она старше в этой иерархии явлений их обоих. Отличие математической абстрактной логики и логики физических величин существенно, одна работает с абстрактными величинами, системой "переменных" другая с системой "констант". По этому математикам частенько пеняют на то что они не знают "где верх где низ" или когда "пытаются" переопределить "константы" в "переменные" в наглую. В общем математиков одних оставлять нельзя... )))
Именно математика занимается поиском и построением непротиворечивых логик, а физика - распознанием и применением их в реальном мире.
У них разные цели, математика - всего лишь языковое средство для других наук. И никто не называет логику, в т.ч. числа, разделом физики.
Отредактировано MihalNik (18.11.2014 14:59:48)
Именно математика занимается поиском и построением непротиворечивых логик, а физика - распознанием и применением их в реальном мире.У них разные цели, математика - всего лишь языковое средство для других наук. И никто не называет логику, в т.ч. числа, разделом физики.
Отредактировано MihalNik (Сегодня 17:59:48)
Ну пожалуйста вон нашли уже "непротиворичивую логику".)) Взяли и описали абстрактно "сервер-клиент" пере назвали актором и завели тему в тупик ... Математика логический создаёт оперирует абстракциями "в самой себе". Физика же ничего "не изобретает" она берет только то что есть в реальности извлекает логику которая уже есть.. Тут пожалуй трудно будет назвать логику разделом физики.. скорее наоборот )) Логика как явление, читай причинность, есть источник физики как науки а не наоборот не говоря уже о математике.
Отредактировано robur (27.11.2014 23:22:22)
Тогда почему Мелкософт пересл с С++ на C# в вин8?
Насколько мне известно, Мелкомягкие в восьмых Окошках сделали ставку как раз на WinRT, а не на .Net, а это уже естественный код, а не CIL.
Вот отрывок из книги «Разработка приложений для Windows 8 на языке C#» (Пугачёв С., 2013 г.):
Между тем, сама платформа Windows, т. е. Win32 API получала не так много на-
стоящих толчков к развитию базовой модели разработки. Пожалуй, последним су-
щественным нововведением был COM (Component Object Model), появившийся еще
в 90-е годы. Но все это время компьютеры не стояли на месте. Появлялись всевоз-
можные новые устройства, экраны, чувствительные к прикосновениям, возникали
новые форм-факторы, такие как планшеты, и т. д. Наконец, такой параметр, как
энергопотребление, становился все более важным. Если для Windows 95 энергопо-
требление почти не имело значения, то для Windows 8 — это один из основных по-
казателей.
Поэтому, создавая новую версию Windows, в Microsoft понимали, что необходимо
разработать и новый API, который, будучи родным (native) для операционной сис-
темы, станет отвечать новым требованиям и веяниям времени. В результате по-
явился Windows Runtime (WinRT).
Windows Runtime — это новая модель разработки приложений, а также объектно-
ориентированный языконезависимый программный интерфейс (API), написанный
на неуправляемом коде и реализующий концепции асинхронного программирова-
ния. Все функции и методы, потенциально работающие более 50 мс, реализованы
асинхронно. Синхронных аналогов для них нет. Это обеспечивает лучшие характе-
ристики и бóльшую "отзывчивость" приложений.
WinRT работает на основе новой оптимизированной версии COM, при этом благо-
даря системе метаданных и языковых проекций он может напрямую интегриро-
ваться с управляемыми средами, такими как .NET Framework. Некоторые API, вхо-
дящие в WinRT, могут быть использованы и в классических приложениях, но
бóльшая часть из них доступна только для Windows Store-приложений.
Потихоньку интересуюсь LLVM. Вещь, конечно, занимательная, перспективная. Жаль только, что документации для неё на русском осень мало. Читать её на английском – это гораздо медленнее. А когда что-то непонятно, думаешь: то ли перевёл неправильно, то ли сам смысл не уловил.
Несмотря на то, что LLVM – это «low level …», оказывается, этот «level» ни такой уж и «low». Такое впечатление. Не всё ясно в работе стека. Как указателю стека присвоить некий адрес. Если нет операций на таком низком уровне, то язык LLVM не намного ниже того же Си.
Это реализация самой API. А то, что будет взаимодействовать с ним предполагается на .Net
Как это может предполагаться, если WinRT и .Net в целом противопоставляются друг другу?
Т.е. последняя слишком медленна, поэтому и запилили WinRT, просто новое сопряжение можно использовать и в .Net.
Потихоньку интересуюсь LLVM
Вот ещё один предмет для исследования ( возможно и его можно русифицировать ) ..)). Канадский кросс-платформенный проект язык еС - Си, с надстройкой ООП на подобие Оbjective С . С полноценной IDE, лицензия BSD, меню IDE русифицировано, правда немного коряво )).. "проэкт" к примеру.
http://ecere.org/
Отредактировано robur (12.12.2014 20:01:31)
А LLVM насколько хорошо Вы знаете? Они прямо про себя пишут: "Compiler Infrastructure", это не просто очередной ЯП.
А LLVM насколько хорошо Вы знаете? Они прямо про себя пишут: "Compiler Infrastructure", это не просто очередной ЯП.
Да не очень )), интересовался конечно, ребята хотят развернутся по взрослому с прицелом на 64-х битники, читал у него есть принципиальное отличие от виртуальных машин НЕТ и Джава ...он регистроорентированная машина, не.. стеки конечно есть, но упор на другую организацию адресного пространства.. А то что не просто ЯП это в точку.
Отредактировано robur (13.12.2014 22:04:44)
У них "ассемблер" рассчитан на любую разрядность. Хоть на 16, хоть на 64. По идее можно для 48-разрядных БЭСМ-6 компилировать
У них "ассемблер" рассчитан на любую разрядность. Хоть на 16, хоть на 64. По идее можно для 48-разрядных БЭСМ-6 компилировать
Ага ..)) будет работать, но еще лучше будет работать на 64- битниках если они "завоют мир" согласно далеко идущим планам у некоторых ))... вот откуда ноги растут (ц) ...
В частности, на LLVM основана подсистема OpenGL в MacOS X 10.5, а iPhone SDK использует GCC с бэкэндом на LLVM. Apple является одним из основных спонсоров проекта, а вдохновитель LLVM — Крис Латтнер — теперь работает в Apple ....
http://habrahabr.ru/post/47878/ фокус-мокус несколько лет подготовки и Интел за бортом http://www.ixbt.com/news/hard/index.shtml?18/48/65 и более не главный партнёр Аpple
Отредактировано robur (13.12.2014 22:31:11)
Кстати, подробный расклад по LLVM ... )) ..от IBM http://www.ibm.com/developerworks/ru/li … ilerllvm1/
Отредактировано robur (13.12.2014 22:47:06)
Читал я это. Но как-то куцо это всё. После прочтения вопросов стало больше, чем их было до.
На русском очень мало пишут. Придётся осваивать навыки беглого чтения. Иначе просто закопаешься, переводя.
"проэкт" к примеру
Так и должно быть. А то нынче получается так: буква «э» есть, звук «э» есть, слова со звуком «э» тоже есть, но писать букву «э» там почти всегда нельзя.
robur написал(а):"проэкт" к примеруТак и должно быть. А то нынче получается так: буква «э» есть, звук «э» есть, слова со звуком «э» тоже есть, но писать букву «э» там почти всегда нельзя.
Ну да ...Пусть тогда со своим английским разберутся, там в обще форменное безобразие ..в написании и произношении написанного ..))))
Пусть разбираются, я не против. А нам со своим, в свою очередь, разобраться нужно.
А нам со своим, в свою очередь, разобраться нужно.
Ну да.. Кстати вот набрел ЯП РС/Б. http://www.rs.b.nm.ru/Opisanie.htm Судя по описанию русскоязычный написанный первоначально на Макросах ФАСМ РС/А потом по "взрослому" РС/Б, Си подобный, проект явно заброшенный, ...автор rs.b@nm.ru , кстати то же пишет не поект а проэкт ..)) и Агоритмы пишет через а , но это ерунда главное что бы думал правильно. Сайт правда "никакой" еле пробился с третьего раза то ли поисковик глушит то ли сам сайт(хост) такой, не понятно. Скачал но не устанавливал не копался пока, нет времени...
(ц) ...Это промежутачная была написана на РС/А, с минимумом возможностей,
и предназначена лиш для компиляции первой версии РС/Б.
Тем немение с её помощью можно писать небольшие программы под Win32.
О СТРУКТУРЕ ЯЗЫКА
Язык разделён на две основные части:
1)Данные - над которыми выполняются действия.
2)Алгаритмы - которые собственно и выполняют эти действия.
Данные:
Являются основной частью любой программы, фактически данные представляют из
себя некоторое чило байт обединйнные именнем (Кроме флагов имеющих
размер в бит), но для удибства данные представленны следуйщими
основными типами:
"ЧИСЛО" - Собственно числовие данные (со знаком и без, целые,и с плавающей точкой)
"ТЕКСТ" - Текст
"РЕЗЕРВ" - Резервирование места для данных
"БУФЕР" - Спец. структура для динамической работы с памятью.
"УКАЗАТЕЛЬ" - Спец. структура для динамической работы с данными.
"ФЛАГ" - Однобитные данные (условия "да"/"нет")
Константы - собственно число или "текст", константа можно именовать а можно
использовать непосредственно.
Переменные - это также данные создаваемае в процессе работы программы и
используемые для временного хранения данных, их имена действуют только
в локальной области где они были
созданы, и их содержимое уничтожается по выходе
процеса из этой области.
Алгаритмы:
Наименьшим элементом алгаритма являются операторы,
которые собственно и оперируют данными. Алгаритмы представлены
на следуйщие основные типы:
Манипуляции данными - это оператры перемещения данных, арифметика, логические операции, и др.
Построения алгритмов - это метки, оператры условного/безусловного перехода, цикличиских операций, и др.
Структуризация алгритмов - это такие структуры как "МАКРОС","ФУНКЦИЯ","ЛОКАЛ" и др.
Спец. структуры - такие как "АСМ"
ИМЕНА И ОБЛАСТИ ИХ ДЕЙСТВИЯ
Объекты программы (метки, данные, переменные, именованые_константа,
подпрограммы), должны обязательно иметь имена (а иначе как к ним обращятся),
имена не стандартизировани могут состоять из любого количества
любых символов (кроме спец символов, и пробелов), имя не
может быть числом (то есть состоять только из цифр, и иметь формат числа).
Всё пространство программы разделено (условно) на области действя имён,
есть одна глобальная область и множество локальных областей:
Имена зарегистрирование как локальные в одной из локальных областей будут извесны
только там и не где более.
Имена зарегистрирование как глобальные будут извесны везде в программе,
зарегестрировать имя как глобальное можно где угодно в программе,
для этого достаточно поставить за именем параметр "Г", такие имена не будут
изменены (локалкзированы) при компиляции.
(!)В локальной област можно зарегестрировать локальное имя такое же как в глобальной
но при этом обратится к глобальному имени будет не возможно.(все обращения будут
переименованы новым лок именем)
Возможно назначить имени три статуса:
"Г" - Имя относится к глобальным и будет известно везде в программе.
"Л" - Имя является локальным и будет извесно только в текущей локальной области (по умолчанию).
Локальные области вложени друг в друга начиная от файла основного кода,
который является первой локальной областью.
Аргументы - это специальные имена при помощи которых становится возможным
передать имена меток,данных,перменных,констант(но не подпрограмм) из одной локальной области, другой
(сделать их общими), имена всегда передаются из внешней области во
внутренею (вложеную), и никогда наоборот.
(!)Локальные имене имеют большый приоритет чем глобальные, потму если зарегистрировать
локальый объэкт с такимже именем как глобальный, не будет возможности обратится к
глобальному объекту (абращения будут относится к локальному).
КОМПИЯТОР
Компилятор "РС/Б" компилирует из исходного текста программы ассемблерный
листинг, который в последующем компилируется ассемблером в бинарник ....
Отредактировано robur (17.12.2014 19:57:58)
Да, повеселил меня этот товарищ словами «ПРОЭКТ, ПРИРВАТЬ, АЛГАРИТМЫ, АБРАЩЕНИЯ, ВНУТРЕНЕЮ, ОБЪЭКТ, ЗАРЕГЕСТРИРОВАТЬ». Почти через слово. Естественно, вопросы: «Отчего такая вопиющая безграмотность? Где с русским языком так из рук вон плохо?» Посмотрел его IP, оказывается, он из-под Киева…
Да, повеселил меня этот товарищ словами «ПРОЭКТ, ПРИРВАТЬ, АЛГАРИТМЫ, АБРАЩЕНИЯ, ВНУТРЕНЕЮ, ОБЪЭКТ, ЗАРЕГЕСТРИРОВАТЬ». Почти через слово. Естественно, вопросы: «Отчего такая вопиющая безграмотность? Где с русским языком так из рук вон плохо?» Посмотрел его IP, оказывается, он из-под Киева
Да, тут только можно грустно улыбнутся ... ) Вот для обзора нашел ещё нечто подобное и более грамотное но более специализированное заточенное на микроконтроллеры ЯП Рефлекс http://reflex-language.narod.ru/
(ц) A1. Язык Рефлекс, известный также под именем "Си с процессами", — это язык программирования в процесс-ориентированном стиле, предназначенный для описания управляющих алгоритмов. Область его использования — промышленная автоматизация и робототехника: системы, предполагающие активное взаимодействие с внешней средой, технологическим оборудованием, физическими процессами через датчики и органы управления.
А2. Базовые цели, которые ставились при разработке языка, — это его адекватность задачам управления, легкое изучение пользователем, комфортные программирование и сопровождение уже созданных программ.
А3. Язык по синтаксису очень похож на язык Си, что обеспечивает простоту его изучения большинством практикующих программистов. Язык имеет англоязычный и русскоязычный синтаксис, а также допускает идентификаторы на русском языке, и это делает его крайне привлекательным для отечественных пользователей.
А4. В отличие от языка Си, где программы строятся как иерархия функций, базовое понятие языка Рефлекс — процесс. Программа на языке Рефлекс — это множество параллельно исполняемых процессов, которые могут запускать друг друга, останавливать и контролировать текущее состояние. В языке предусмотрены операции с временными интервалами и средства описания связей с датчиками и управляющими органами. Разнообразие специфических приемов при создании программ и методы структуризации алгоритма позволяют говорить в случае языка Рефлекс об особом стиле программирования — процесс-ориентированном программировании.
А5. Рефлекс — это развитие проекта СПАРМ (средство программирования алгоритмов работы микроконтроллеров, авторы Зюбин В.Е., Карлсон Н.Н. 1988-1990 гг). Год создания настоящей версии языка Рефлекс — 1998 (Зюбин В.Е. с участием Петухова А.Д., Данчина Д.Ю.). Год ее реализации (создание транслятора) — 2002 год....
"Рефлекс" есть в моих списках: Энтузиасты-разработчики компиляторов и их проекты
"Рефлекс" есть в моих списках: Энтузиасты-разработчики компиляторов и их проекты
О прощения, просто не увидев его в на страницах форума в разделе Русские языки программирования.
Привет всем! Сайт классный. Я недавно начал писать собственный интерпретатор скриптового языка, но знаний мало, а книг толковых нет, много воды. Поэтому решил начать что-то сам. Предлагаю энтузиастам-программистам С# объединиться и создать полноценный скриптовый язык, котоорый будет работать как на стороне сервера, так и на строне клиента. Чтобы не было разбиения на языки типа php, javascript, ajax, jquery и тому подобные. Чтобы был один язык, но был двузадачным (для клиента и сервера). Кому это интересно, пишите на почту: almp@i.ua или skype: avmpapus
Я смотрю, у Вас давно такая идея возникла: Ссылка 1,
Ссылка 2, Ссылка 3. Какие цели Вы ставите перед собой?
Если Вы решили работать над интерпретатором. то Вам, по-видимому, надо пообщаться с Уткиным: язык Валентина.
Самое ужасное, страшное, это когда человек не владеющий технологиями, без опыта, без знаний, без "досконального" изучения ранее созданных инструментов и технологий, пытается создать что-то, что будет лучше чем всё ранее было создано. Возможно так могут только гении, но остальным необходимо изучить всё, что ранее было создано, чтобы создать что-то лучше.
Самое ужасное, страшное, это когда человек не владеющий технологиями, без опыта, без знаний, без "досконального" изучения ранее созданных инструментов и технологий, пытается создать что-то, что будет лучше чем всё ранее было создано. Возможно так могут только гении, но остальным необходимо изучить всё, что ранее было создано, чтобы создать что-то лучше.
Не уверен насчёт досконального изучения всего, что было создано. Всё досконально изучить всё равно невозможно. И чем дальше в будущее, тем больше становится того, что, по-вашему, нужно будет досконально изучить перед созданием своего. То есть с течением времени доскональное изучение всего становится всё более и более невозможным. А чем больше его, тем больше времени будет уходить на доскональное изучение этого, тем меньше времени будет оставаться для придумывания своего. Как говорится, чем дальше в лес, тем больше дров.
Думаю, достаточно изучить общее устройство, общие подходы в наиболее распространённых вещах.
И есть ещё одна небольшая, но очень важная вещь: чем больше чужого вы изучаете, тем сильнее становится косность вашего мышления, тем сильнее оно заобразцовывается, залекаливается, тем труднее становится выйти за пределы привычного и придумать что-то качественно новое. Так что в изобретательстве возможен такой подход: сначала придумать самостоятельно всё, что сможете придумать, а только затем начинать изучать созданное, чтобы выйти на второй круг придумывания, уже с учётом созданного. Это лучше, чем сначала изучать созданное, т.к. из-за залекаливания мышления могут не родиться в уме стоящие придумки, которые могли бы родиться в противном случае. В изобретательстве вообще много подходов существует для раскоснения, разлекаливания мышления.
Хотел выразить мысль, что необходимо изучить базу, от которой двигаться дальше. В место этого употребил "доскональна". То есть по Вашему человек не владеющий программированием сможет разработать совершенно новый язык программирования с нуля, который превзойдёт все ранее созданные языки программирования?
Самое ужасное, страшное
Да ничего страшного и ужасного. Если человек войдёт в тему, изучит теорию и практику - то результат придёт. Если не изучит, то и не увидим страшного и ужасного его творения.
Стимулом к познанию является какая-то цель. Мечта, если хотите. Талант проявляется через желание чем-то заниматься. Если хочется - пусть работает, может, появится новый условный Касперский. Ну не знает что-то, так мы все имеем пробелы в знаниях. Пусть, как говорится, тот первым бросит в него камень, кто без этого греха....
человек не владеющий программированием сможет разработать совершенно новый язык программирования с нуля, который превзойдёт все ранее созданные языки программирования?
Знания придут в процессе, если процесс будет упорным
Знаете, мне как-то написал один филолог. Он в компьютерах не понимает - от слова вообще. Но собрался разработать новый невиданный язык программирования. Овладевать новыми знаниями вроде бы готов. Ну так флаг в руки! Чем бы мужики не тешились, лишь бы водку не пили.
То есть по Вашему человек не владеющий программированием сможет разработать совершенно новый язык программирования с нуля, который превзойдёт все ранее созданные языки программирования?
Кто знает? Быть может, этот человек, мышление которого не ограничено ограниченностью существующих языков программирования, придумает что-то более близкое к естественным способам выражения своих мыслей.
К тому же, я уже сказал, что сразу после придумывания всего что получится без знания существующего, нужно начать изучать существующее, чтобы выйти на второй круг творчества — уже со сравнением своего и существующего.
Сайт Рефлекс-а или взломан или помер. Хотел зайти посмотреть, но там перекидывают на какие-то мусорные вещи с подписками.
Рефлекс по приведенному здесь краткому описанию похож процесс-ориентированным программированием на то что я сам задумал сделать. Мне кажется такой подход (процесс-ориентированный) как раз может решать задачи и сервера и клиента, а также может описывать (программировать) вещи от самого низкого уровня до самого высокого. Попробую поискать другие места в инете, где Рефлекс может быть описан.
У меня http://reflex-language.narod.ru/ нормально открывается. Странно 
У меня http://reflex-language.narod.ru/ нормально открывается. Странно
Наверное у меня что-то с мобильным модемом/сервисом или с компом, потому что меня сразу выбрасывает на podpiskipro.ru
...
А, нет. Пробился. Остановил загрузку страницы и нажал "обновить". Возможно сайт или его хост все-таки заражен. Смена модема на другой поменяла только мусор куда выбразывалось. Ну вобщем стерпимо и я начал изучать что было сделано уже в этой области.
Отредактировано Алексей Яковлев (31.05.2015 17:23:55)
Вы здесь » Русские самосчёты » Русский язык программирования: от слов к делу » Исследование: выбор платформы, компилятора и графических библиотек