Re[14]: Следующий язык программирования - Философия программирования

Здравствуйте, Зверёк Харьковский, Вы писали:

Языки — это не результат технологического прогресса. Точнее это не первая его цель. Это средство давления корпораций на разработчиков. Точно так же и технологии. Корпорации подсаживают разработчиков на иглу. Кого-то подсаживают на героинчик, кого-то на кокаинчик, а у нас на Java, или на C# с нетом впридачу, или на Web сервиса.

А попутно продаются продукты, за которые платятся деньги. Особенно это заметно на net. Под этим лейблом Microsoft начало много продавать продуктов(хотя многое имело к Net очень опосредованное отношение).

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

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

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

). Ту же самую модель конструктора были предложены в C# и в Java, и они стали бестеллерами. И постепенно вытесняют с рынка бизнес-приложений С++, хотя быстрее выполняться чем С++, они никогда не будут.
Какой-бы хороший язык не был-бы, без библиотек на все случаи жизни, он никто. И тут важно не только иметь такие библиотеки, нужно еще донести до конечного потребителя языка, что они существуют. С# начинался с Framework в котором были(и остаются) WinForms. Но при выходе релиза, уже существовали библиотеки визуальных компонентов. Так что все по умному.

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

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

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

С уважением, Gleb.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>И последнее: лично мне наиболее современным и "впередсмотрящими" языками представляются не тяжеловесные "все-в-одном + своя платформа + вообще-все-что-вам-может-понадобиться-когда-либо" Java и C#, а более легковесные, без груза "обратной совместимости по парадигме", приспособленные к сегодняшнему миру Python и Ruby.
ЗХ>Такие дела.

Мне думается, что язык программирования должен удовлетворять следующим критериям:
1) Быть безусловно объектным, в котором представлены:
a) сильная инкапсуляция;
б) смешивание (mixins);
в) ...
2) Независимым от платформы — компиляция в промежуточный код.
3) Иметь простую виртуальную машину для выполнения кода (грубо: модель процессора со стэковой архитектурой).
4) И самое главное, чтобы исходники программы на этом языке легко читались ЧЕЛОВЕКОМ.
И тогда создание поистине всемирных библиотек кода на этом языке можно сделать по принципу Wikipedia. И Сеть будет Компьютером.

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

Здравствуйте, AndrewVK, Вы писали:

ЗХ>>б) (формулировка ПК) "каков должен быть сегодня новый язык, чтобы найти себе массовую популярность без поддержки лидером рынка?"

AVK>Промышленным.
А я бы сказал специализированным. Кто спонсор PhP, никто не знает?
IMHO А промышленный язык — это средство давления на рынок. Его просто так не пропустят.

С уважением, Gleb.

Здравствуйте, iZEN, Вы писали:

ZEN>Что мне не нравится в ОО-ориентированном языке — это слишком сильная связь между предком и потомками, которая ужасна и неэффективна в глубокой иерархии. 70% кода в этом случае, как правило, — просто балласт и никогда не работает.

Другие варианты есть? Не похоже, что в ближайшие 10-15 появится более популярная, чем ООП парадигма.

Лично мне пока хотелось иметь такие вещи:
1) XML диалект для описания объектной модели приложения с инструментом для динамической генерации исходников на C# и Java (хотя бы), а также структуры базы данных, чтобы окончательно отделить логику приложения от исходных текстов программы
2) XML диалект для унифицированного описания GUI приложения, чтобы отделить интерфейс от логики и исходных текстов приложения
3) Везде перейти от абсолютного позиционирования элементов GUI к относительному
4) Перейти к системам контроля версий (CVS) оперирующими не файлами, а объектами приложения
5) Библиотеки функций и алгоритмов в Интернет/Интранет, ставишь в исходном коде ссылку и все, получается как WebService, но на уровне исходных текстов

В общем основное IMHO — это что сейчас необходимо совершенствование не самих языков, а средств проектирования и разработки приложений, пора уже идти дальше UML и RUP, пора закрыть вопросы, связанных с форматированием кода, все должно быть автоматически: нужное количество табуляций и пробелов, положение { и } и т.п.

Здравствуйте, henson, Вы писали:

H>5) Библиотеки функций и алгоритмов в Интернет/Интранет, ставишь в исходном коде ссылку и все, получается как WebService, но на уровне исходных текстов

Хмы. Это мысль. Не учел

Здравствуйте, iZEN, Вы писали:

ZEN>б) смешивание (mixins);

Кстати любопытно: интересная ведь концепция, но почти нигде не получила распространения. Интерфейсы — пожалуйста, mixins — фигушки. Интересно, почему?

Здравствуйте, Зверёк Харьковский, Вы писали:

AVK>>В какой категории?

ЗХ>Гхм. В промышенной, вестимо. "изменит представление" суть "все станут программировать по-другому.

Зависит от того, что понимать под прорывом. Если завоевание новым языком десятков процентов рынка, то может.

ЗХ>>>б) (формулировка ПК) "каков должен быть сегодня новый язык, чтобы найти себе массовую популярность без поддержки лидером рынка?"

AVK>>Промышленным.

ЗХ>Это необходимое или достаточное условие?

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