Re: Проэктируем новый язык программирования
От: Аноним  
Дата: 11.12.02 22:47
Оценка:
Здравствуйте, IO,
Что то в этом форуме много пессимистов Может они в чем то и правы, но суть
не в этом.
Я очень давно интересуюсь технологией компиляции и должен сказать, что создать действительно хороший язык, удавалось только избранным. НО если вы готовы занятся
разработкой компилятора, хотя бы с очень простым синтаксисом (для начала), то эта
затея оправдывает себя по двум причинам:
Во первых на этом можно неплохо заработать, но это не главное, главное то, что
при разработке компилятора круг возникающих проблем очень велик, и поэтому как
программист вы будете развиватся, а это не мало важно.
Короче я ЗА! У меня эта идея уже давно была, вот только в одиночку не справится.
Если, что я оставляю адрес d_den@mail.ru
Re: Проэктируем новый язык программирования
От: Jekky  
Дата: 11.12.02 22:54
Оценка:
Получите ИМХО, раз просили.
Оно такое: языков должно быть два:
1-й: для развития системы.
2-й: для собственно программы(UI, главным образом).
Никоим образом не претендую на "САМОЕ ПРАВИЛЬНОЕ имхо". Наоборот, хотелось бы услышать (увидеть) другие мысли...
Re: Проэктируем новый язык программирования
От: Whisperer  
Дата: 11.12.02 23:08
Оценка:
Здравствуйте, IO, Вы писали:

Меня всегда интересовало кто возмется за ответственность "привязонности" (понятие общее но под какую платфоруму будет заточен — я бы не взял на себя ответственость — хотя я и LOL).

А теперь мое личное мнение (ногами можете бить если — попадете (кто был на встрече RSDN поймет )).

Сейчас надо разрабатывать языки с привязкой к конкреной OC — так как получим максимальную производительность (если разработчики компилятора(интерпритатора) ерундой не занимались).

А мысли котрые проскакивали уже дано насчет своей OC — я поддержу — но пока только в проекте — потому что не чуствую в себе тех сил которые должны быть в человеке при разработке OC — (я еще очень сильно хромаю в ассемблере — дает знать — 54 летняя задержка в технологиях — я думаю через год можно поднять тему снова).

Если ее раньше не поднимут — я ее поддержу — возможными силами и средствами (связями — тоже )
Re: Проэктируем новый язык программирования
От: Аноним  
Дата: 13.12.02 11:54
Оценка:
Здравствуйте, IO, Вы писали:

IO>Идея такая:

IO>развернуть обсуждение о создании нового языка программирования между довольно опытными программистами разных специализаций. На выходе получить концепцию языка, удовлетворяющего всех.
IO>Причем начать можно с самых общих (почти философских вещей).
IO>Цель в том, что-бы новый язык во-первых учитывал недостатки уже существующих. Во-вторых был бы универсальным для разных областей (сколько можно плодить эти языки). В-третьих имел бы заложенные мощные механизмы по наращиванию и расширению. Т.е. основная концепция должна быть достаточно универсальна (микро-ядро)?

IO>Ваши мнения?


Мнений нет, есть предложение,
когда будет создан новый, самый универсальный язык программирования, не останавливаться на достигнутом,
а предложить генетикам вывести в пробирке универсального программиста, который бы лабал на этом универсальном языке.
Если еще есть предложения по развитию идеи, добро пожаловать.
Re: :)))
От: jazzer Россия Skype: enerjazzer
Дата: 15.12.02 13:55
Оценка: 6 (1) :)
Здравствуйте, IO, Вы писали:

IO>Ваши мнения?


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


Язык программирования десятого уровня С**.
Ламер и Гуру:
Л: Я тут программу написал, не работает...
Г: Покажи.
Л: "Хочу базу данных;"
Г: Эх ты, ламер... Надо так: "Хочу базу данных(чтоб работала);"

jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: Виртуальные макросы :)
От: Снорк  
Дата: 16.12.02 13:00
Оценка:
Здравствуйте, IO, Вы писали:

IO>Ваши мнения?


Не хватает целой кучи макро-удобств:

1)
__FILE__
__LINE__

Этого слишком мало! Хочу __TEXT__, __METHODNAME__, __METHODTEXT__.

2) Нельзя нормально наследовать макросы.
Например, сборка Release не содержит в себе #define new, сборка Debug содержит #define new DEBUG_NEW
И всё!
А нет бы добавить сборку Debug_TestMemoryOptimize:
#ifdefdefineandinherit new MYDEBUG_NEW
а компилятор подставлял бы вместо new сначала стандартный дебужный new, а потом мой.

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

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