Ответ на »сообщение 300« (Jack Of Shadows)
___________________________
>>> До сих пор программистов застваляют декларировать типы, хотя уже давно необходимости в этом нет.
Аналог определения типов есть даже в обычном русском языке. Называется "определение понятий". Иначе рапоряжение "продать косу" может быть неверно понято. В нормативных документах есть специальный раздел, объясняющий толкование терминов, используемых в работе.

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

А языки программирования останутся разве что для мобильных телефонов :-)


Ответ на »сообщение 304« (panda)
___________________________
>>> Т.е. по Вашему мнению, Джоель Спольски просто никакой программист, раз предпочитает писать на VB?
Непорядок у Вас с логическими выводами. Я не говорил, что все, кто пишут на VB, не являются хорошими программистами. VB все равно загнулся бы, так как никто не стал бы поддерживать язык для одного человека. А Джоель Спольски преспокойно перешел бы на Delphi.

по поводу оптимизации:
http://www.paulgraham.com/popular.html
Лучше иметь хороший профайлер, чем хороший компайлер
...
8 Efficiency

A good language, as everyone knows, should generate fast code. But in practice I don't think fast code comes primarily from things you do in the design of the language. As Knuth pointed out long ago, speed only matters in certain critical bottlenecks. And as many programmers have observed since, one is very often mistaken about where these bottlenecks are.

So, in practice, the way to get fast code is to have a very good profiler, rather than by, say, making the language strongly typed. You don't need to know the type of every argument in every call in the program. You do need to be able to declare the types of arguments in the bottlenecks. And even more, you need to be able to find out where the bottlenecks are.
...

Ответ на »сообщение 304« (panda)
___________________________
Джоел отвечал на вопрос, почему он не пишет на чем-то более приличном, в стиле "некогда думать, пилить надо".

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

Ответ на »сообщение 298« (Geo)
___________________________

Если бы большинство программ писали программисты, то VB давно скончался бы в страшных корчах. К сожалению, если считать по количеству отдельных "проектов", то большинство программ пишут различные "менеджеры", которые ходили на недельные курсы по овладению компьютером.
Т.е. по Вашему мнению, Джоель Спольски просто никакой программист, раз предпочитает писать на VB?

Ответ на »сообщение 302« (Jack Of Shadows)
___________________________
Да кстати, сишарп и java ни в коей мере не считаю шагом в направлении к человеку.
Это все те же, ориентированные на машину языки.
Именно поэтому они обрастают таким огромным количеством человеко-ориентированных инструментов.
Я имею в виду IDE.
Поскольку в этом направлении требует развития индустрия. Но апологеты императивных языков пытаются усидеть на 2-х стульях.
Оставить машинно-ориентированный язык, при этом нацепив на него человеко-ориентированные костыли (IDE)

Результат в общем то ужасающ.

Ответ на »сообщение 301« (Руслан Богатырев)
___________________________
Ну что ж.
Давайте тогда сконцентрируемся на вашей главной мысли.

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

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

Ответ на »сообщение 300« (Jack Of Shadows)
___________________________

Делить языки надо не на фортран - Алгол - СИ
А на процедурные (императивные) и функциональные.

Замечание понятно, только был вынужден вырвать кусок, при этом ушел контекст. Полностью можно посмотреть на www.oberon2005.ru.

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

Насчет деления: делить не НУЖНО, а МОЖНО как угодно, лишь бы от этого был какой-то прок (в смысле последующих рассуждений и выводов).

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

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

Ответ на »сообщение 299« (Руслан Богатырев)
___________________________
В результате такие критерии, как простота (наглядность исходных текстов), надежность, компактность программ и эффективность исполняемого кода, теперь заменяются на один главный критерий — скорость реализации идей.

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

и

эффективность исполняемого кода

И противопоставляется им качество прямо вытекающее из первого списка

скорость реализации идей

Ведь скорость реализации идей прямо зависит от того насколько прост язык и насколько легче его читать (писать)

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

Делить языки надо не на фортран - Алгол - СИ
А на процедурные (императивные) и функциональные.

Процедурные танцуют от компьютера. Во главу угла у них ставится компьютер.
Человек лишь сошка, обслуживающая дорогое оборудование. Главно заботой таких языков является эффективность кода. Минимум потребляемой памяти, максимальная скорость исполнения, минимум работы для компилятора, максимум работы для дешевого программиста.
Понятно что все это идет со времен, когда компьютеры стоили жутко дорого и были чрезвычайно ограничены в рессурсах.
До сих пор программистов застваляют декларировать типы, хотя уже давно необходимости в этом нет. Компилятор может сам вывести типы.
Это сильно упростит язык, но при этом и сильно усложнит компилятор. Выбор как видите до сих пор делается в пользу компьютера а не человека.
Можно избавиться от огромного количества ненужных типов. Как например разные варианты строки, или integer-SmalInt-BigInt или float-double.
Это сильно упростит язык но при этом ужасно снизит эффективность кода.
Выбор как видите до сих пор делается в пользу компьютера а не человека.
И так далее можно долго продолжать.

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

Слава богу программирование сегодня развивается в правильном направлении.
Императивное программирование достигло своего (ту)пика в лице таких монстров как java и си-шарп.
Новых императивных языков после них просто не появится. Они будут последними, пока на смену им не придет быстро развивающееся функциональное программирование.
Уже сейчас ФЯ все шире используются в производстве. Эрикксон переписала весь свой код на Ерланге, собственном функциональноем языке. И чрезвычайно этим довольна.

Все большую популярность и известноть получает Хаскель, и микрософтовский F#

Западная научная среда давно уже изгнала императивные языки и пользуется исключительно языками семейства МЛ и Scheme

Так что тем кто дейстительно хочет работать на очень простых, легко читаемых, и в то же время чрезвычайно мощных языках - недолго осталось ждать.

Ответ на »сообщение 294« (Сергей Перовский)
___________________________

А скорость действительно перестала быть главной характеристикой.

Ответ на »сообщение 297« (Сергей Перовский)
___________________________

Для остальных гораздо важнее скорость разработки,

Выскажу свою точку зрения (выдержка из статьи 'От Паскаля к языку Zonnon', 2003):

Наверное, не будет преувеличением сказать, что среди императивных языков с точки зрения синтаксиса можно выделить три доминирующих направления: Фортран-ориентированное (Фортран, Кобол, Visual Basic), Паскаль-ориентированное (Паскаль, Delphi/Object Pascal, Ada), Си-ориентированное (Си, С++, Java, C#). Конечно же я намеренно упрощаю реальную картину, но при изложении новых идей лучше отталкиваться от понятных эталонов.

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

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

Ответ на »сообщение 297« (Сергей Перовский)
___________________________
>>> Если бы для большинства программистов быстродействие имело решающее значение, VB давно скончался бы в страшных корчах
Если бы большинство программ писали программисты, то VB давно скончался бы в страшных корчах. К сожалению, если считать по количеству отдельных "проектов", то большинство программ пишут различные "менеджеры", которые ходили на недельные курсы по овладению компьютером.