Свой компилятор(С++'о подобный)

[Пепел Феникса]

Зато D компилируется

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

судя по вики, симпатичен, но все-таки чего то не хватает

[anyx]

Сообщение от Пепел Феникса

идеального ЯП
совместимость с С++, то есть по сути это выходит расширенный С++.

ЛОЛШТО? ИДЕАЛЬНЫЙ ЯП на основе самого сложного, кривого и одного из самых медленных (из компилируемых в нативный код) языка? Сразу нет.

Сообщение от Пепел Феникса

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

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

[Пепел Феникса]

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

[anyx]

Сообщение от Пепел Феникса

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

По-вашему, в C# вообще возможно добавить ещё что-то? «C# уверенно движется к тому, чтобы отобрать у крестов (С++) лавры самого сложного и уродливого языка.» - говорит Лурк

Советую не опираться на привычные формы и стандарты языков программирования (привычные по костыльным уродствам вроде С++).

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

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

[Пепел Феникса]

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

подумал и решил что нет.
разве что косвенно(под управлением ЯП) для связи с С функциями например.

[the_deer_one]

anyx

Почитайте о принципиально других парадигмах программирования (функциональная, автоматная).

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

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

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

Не забывайте, что за параллельными вычислениями будущее

Да ну. Вроде недостатков производительности не наблюдается.

[anyx]

Сообщение от Пепел Феникса

подумал и решил что нет.
разве что косвенно(под управлением ЯП) для связи с С функциями например.

Так для биндинга к Сишной либе, использующей указатели, используется код на Си. Функции биндинга будут принимать аргументы типа «указатель на объект твоего языка», работать с ними при помощи функций библиотеки языка.

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

Сообщение от the_deer_one

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

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

Сообщение от the_deer_one

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

Значит реализация в C# кривая, раз приходится так извращаться. С точки зрения логики указателей вообще не существует, значит и ЯП может обойтись без них. Готов поспорить, что озвученную вами проблему я смогу решить за неделю, избавившись от необходимости использования указателей.

Сообщение от the_deer_one

Да ну. Вроде недостатков производительности не наблюдается.

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

[the_deer_one]

anyx

С точки зрения логики указателей вообще не существует, значит и ЯП может обойтись без них.

В смысле не существует? 0_0

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

Ну да, Распределённость, Многопоточность, Светлое Будущее, Масштабируемость, облака как Символ Эпохи. Скоро уже хеловорды многопоточными будут.

[Пепел Феникса]

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

может не повезло, а может то что не верное направление передано.

Да ну. Вроде недостатков производительности не наблюдается.

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

Так для биндинга к Сишной либе, использующей указатели, используется код на Си. Функции биндинга будут принимать аргументы типа «указатель на объект твоего языка», работать с ними при помощи функций библиотеки языка.

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

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

вообще мне не нравится понятие "код на Си", интегрируюсь я с бинарником, а не с кодом.

[anyx]

Сообщение от Пепел Феникса

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

Так код на Си является только обёрткой для преобразования данных. Т.е. код на Си будет преобразовывать всякие поинтеры/структуры в объекты вашего языка. А код на вашем языке реализует логику. Это нормально, ведь писать логику на Си сложно. Хотя можно, конечно, если требуется производительность.

Сообщение от the_deer_one

В смысле не существует? 0_0

В том смысле, что когда вы думаете над алгоритмом, вы не оперируете понятием «указатель», вы оперируете данными, объектами, называйте как хотите. Указатель - деталь реализации, а не логики, т.е. с точки зрения логики нет никаких указателей.

Сообщение от the_deer_one

Ну да, Распределённость, Многопоточность, Светлое Будущее, Масштабируемость, облака как Символ Эпохи. Скоро уже хеловорды многопоточными будут.

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