идеальный язык программирования , каким он должен быть?

Цитата Flex Ferrum @ 22.10.06, 13:25

И от того, что ты понимаешь под "приличным расширяемым продуктом".

Это когда сегодня тебе говорят: к вечеру надо векторный редактор, который работает только с прямыми линиями. На следующий день приходят и заявляют: а теперь надо, чтобы он еще умел вставлять битмапы из файла и рисовать окружности; через полчаса твой продукт уже может все это. Правда, описанный пример хорошо ложиться на парадигму OOD (design), но тем не менее требования кардинально меняются и продукт должен быть быстро адаптирован и не должно было быть потрачено много времени для обеспечения расширяемости на начальном этапе разработки. Как-то так.

Добавлено 22.10.06, 13:38
Кстати, об одномиз подходов, называемых bottom-up design я на днях прочитал и проникся: идея заключается в том, что мы не приступаем непосредственно к решению задачи, а создаем инструментарий, который позволяет нам решить задачу в терминах ее предметной области, после чего решаем задачу на ее «естественном языке». Затем, если на следующий день нас попросили расширить функциональность, то есть два варианта:
1. новая функциональность может быть выражена в уже описанных терминах предметной области => собираем новую функциональность из готовых кубиков
2. для расширения продукта необходимо расширить набор понятий предметной области => расширяем базовый инструментарий и из готовых кубиков собираем требуемую функциональность

Добавлено 22.10.06, 13:39
Фактически, bottom-up design похож на OOD, но формализуется не задача, а язык задачи.

Цитата linuxfan @ 22.10.06, 13:33

Это когда сегодня тебе говорят: к вечеру надо векторный редактор, который работает только с прямыми линиями. На следующий день приходят и заявляют: а теперь надо, чтобы он еще умел вставлять битмапы из файла и рисовать окружности; через полчаса твой продукт уже может все это. Правда, описанный пример хорошо ложиться на парадигму OOD (design), но тем не менее требования кардинально меняются и продукт должен быть быстро адаптирован и не должно было быть потрачено много времени для обеспечения расширяемости на начальном этапе разработки. Как-то так.

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

Добавлено 22.10.06, 13:43
А если изначально подойдешь с умом к решению задачи, то выбор инструментария ты будешь делать уже из совсем других соображений.

Добавлено 22.10.06, 13:44

Цитата linuxfan @ 22.10.06, 13:33

Кстати, об одномиз подходов, называемых bottom-up design я на днях прочитал и проникся: идея заключается в том, что мы не приступаем непосредственно к решению задачи, а создаем инструментарий, который позволяет нам решить задачу в терминах ее предметной области, после чего решаем задачу на ее «естественном языке». Затем, если на следующий день нас попросили расширить функциональность, то есть два варианта:

Хороший подход. Частенько им пользуюсь.

Добавлено 22.10.06, 13:46
Собственно, тем тот же шарп или джава "берет" - в нем изначально представленно большое количество этих самых кирпичиков, пользуясь которыми можно решить задачу (.NET Framwork, Swing, и т. п.).

Цитата Flex Ferrum @ 22.10.06, 13:42

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

Ну так общеизвестно, что гуано можно написать на чем угодно.
Я один рз на чистом C написал декодер протокола, причем т. к. в протоколе были пакеты, состоящие из одинаковых типов полей, а мне было впадлу писать кучу case'ов с вызовами одинаковых процедур, я на этом же самом C завернул описания пакетов в C'шные структуры, причем пакеты описывались в терминах протокола (т. е. пакет, состоящий из целочисленного, строкового поля и из массива строковых полей). В результате когда для каких-то целей другой человек начал ковырять этот декодер, я поразился, что эта хреновина, оказывается, недурственно расширяется, правда не без костылей и грязных хаков, но очень легко. Достаточно было вписать пару строчек, но перед этим необходимо было решить более сложную задачу: в какое место их вписывать.
Фактически, это был мой первый неосознанный опыт bottom-up дизайна. Я получил удовольствие как от реализации, так и от результата.

Добавлено 22.10.06, 13:49

Цитата Flex Ferrum @ 22.10.06, 13:42

Собственно, тем тот же шарп или джава "берет" - в нем изначально представленно большое количество этих самых кирпичиков, пользуясь которыми можно решить задачу (.NET Framwork, Swing, и т. п.).

Протестую! Swing, библиотеки Java и .NET'а, это не кирпичики, это материал, из которого надлежить наобжигать кирпичей и сделать цемент для построения приложения! В терминах реальных задач «layout» встречается очень редко

Цитата linuxfan @ 22.10.06, 13:47

Ну так общеизвестно, что гуано можно написать на чем угодно.

Ну так об том и речь.

Добавлено 22.10.06, 13:51

Цитата linuxfan @ 22.10.06, 13:47

Протестую! Swing, библиотеки Java и .NET'а, это не кирпичики, это материал, из которого надлежить наобжигать кирпичей и сделать цемент для построения приложения! В терминах реальных задач «layout» встречается очень редко

Ээээ... Батенька... Далеко не всегда. В ТЗ, положим, у тебя написано: "На экране должна быть таблица, отображающая перечень активных пользователей". Ты это выражаешь в терминах DataGrid'а + SqlConnection + SqlCommand + некоторое количество хранимых процедур. Что ты тут изобратать собрался?

Цитата

Ну так общеизвестно, что гуано можно написать на чем угодно.

Нужно отдать должное, что на плюсах гуано написать легче, т.к. много очень "интересных" и "специфических" моментов

Цитата BugHunter @ 22.10.06, 13:52

Нужно отдать должное, что на плюсах гуано написать легче, т.к. много очень "интересных" и "специфических" моментов

Ну, тут все зависит от того, что понимать под гуаном. Вон, Ho Im плювался от гуано, написанного на PHP.

Цитата Flex Ferrum @ 22.10.06, 13:49

Далеко не всегда. В ТЗ, положим, у тебя написано: "На экране должна быть таблица, отображающая перечень активных пользователей".

Э, нет. ТЗ -- это уже формализованные требования/пожелания пользователя. А пользователь хочет «видеть список активных пользователей» (ой, тафталогия получилась ), а ты этот список делаешь так: берем 1 часть DataGrid + 1 часть SqlConnection + ..., замешиваем это в class UsersList -- и получаем кирписик для решения задачи.

Цитата linuxfan @ 22.10.06, 13:55

а ты этот список делаешь так: берем 1 часть DataGrid + 1 часть SqlConnection + ..., замешиваем это в class UsersList -- и получаем кирписик для решения задачи.

Ну, далеко не всегда это будет замешено в класс UsersList.

Цитата linuxfan

на крестах напишу за 20 секунд:

#include <iostream>
#include <cstdlib>
int main()
{  std::cout << "Random is " << random() << std::endl;  
return 0;
}

Начнется все с попытки реализовать random, закончится выводом. Даже если взять всю libc и заюзать prntf, все равно получется дольше и больше букафф

void main ()
{  
  printf ( "Random is %X", rand() );
}

и где ж многа букаф та? прошу заметить - даже хедеров никаких не нужно..

Цитата mICRo @ 22.10.06, 13:59

и где ж многа букаф та? прошу заметить - даже хедеров никаких не нужно..

А теперь вместо %X пишем %s (ну абшиблись мы). Радостно наблюдаем за результатом...

Цитата mICRo @ 22.10.06, 13:59

и где ж многа букаф та? прошу заметить - даже хедеров никаких не нужно..

Это половые проблемы MSVC. По стандарту нужен:
1. stdlib.h (random)
2. stdio.h (printf)
В оригинальном посте речь шла об ASM, а printf ИМХО одно из самых удачных изобретений человечества. Плюсовые потоки по удобству использования сильно сливают printf'у, т. к. вместо каких-нибудь "%5.2f" там такой огород писать придется... Яркий пример того, что плюсы писались не для человека, а для машины.

Добавлено 22.10.06, 14:03

Цитата Flex Ferrum @ 22.10.06, 14:02

А теперь вместо %X пишем %s (ну абшиблись мы). Радостно наблюдаем за результатом...

Ну нормальный компилер (gcc) кинет варнинг

Цитата linuxfan @ 22.10.06, 14:03

Плюсовые потоки по удобству использования сильно сливают printf'у, т. к. вместо каких-нибудь "%5.2f" там такой огород писать придется... Яркий пример того, что плюсы писались не для человека, а для машины.

Так подобная штука и в плюсах есть. Boost::format (http://www.boost.org/libs/format/doc/format.html) называется, причем оно помощнее, чем printf будет.

cout << boost::format("writing %1%,  x=%2% : %3%-th try") % "toto" % 40.23 % 50;
     // prints "writing toto,  x=40.230 : 50-th try"

Цитата mo3r @ 22.10.06, 14:23

Boost

Набор костылей на все случаи жизни , причем и запись какая-то неестественная.

Цитата linuxfan @ 22.10.06, 14:26

Набор костылей на все случаи жизни

кирпичики, из которых можно строить хорошие системы

Цитата wormball @ 22.10.06, 13:14

Таки выкинули. (и не надо говорить, что holy wars - это не корзина!)
Теперь надо переименовать в "asm vs c++"

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

Добавлено 22.10.06, 14:40

Цитата linuxfan @ 22.10.06, 14:26

Набор костылей на все случаи жизни , причем и запись какая-то неестественная.

это так любую библиотеку можно назвать костылями,
хотя на самом деле они именно

Цитата mo3r @ 22.10.06, 14:32

кирпичики, из которых можно строить хорошие системы

Сообщение отредактировано: impik777 - 22.10.06, 14:43