[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Среды разработки



On 18.10.2012 18:40, "Артём Н." wrote:
18.10.2012 00:16, Alexander Danilov пишет:
On 17.10.2012 22:22, "Артём Н." wrote:
16.10.2012 23:21, Alexander Danilov пишет:
что после этого всякого,
утверждающего что C++ - это просто, а Haskell - это сложно, считаю умственно
неполноценным родственником Джорджа Буша младшего, на котором природа не
то, что
отдохнула, она даже и не напрягалась.
Ну, по-моему, никто не говорит о простоте.
Полуркайте, "Как выучить C++ за 21 день". ;-)

Я вас нах... не посылал, так что тоже будьте вежливы.
Я вас, вроде, тоже не посылал. А баяна этого вы, похоже, не знаете...
"Как выучить C++ за 21 день" - я про это, такое только умственно отсталым
предлагают :)
Наоборот, по-идее, должно быть.
Вы, для начала, погуглите, потом говорите.
"C++ за 21 день" - это известная тема, только гуглите по картинкам.

По идее то, может вы и правы, но на практике то, скорее всего прав я, ибо листал пару раз такие книжкию


Есть, тут другой RAD.
Первый RAD с которым я познакомился в Unix - shell+coreutils(тогда это была
большая куча пакетов).
Второй RAD - perl+CPAN.
Были и другие.
Это не RAD. Это компоненты.
Это RAD - rapid application development, именно так. Именно с помощью этих
средств очень быстро разрабатываются приложения, я куски сишного кода менял на
вызовы system("awk ..."), и кода становилось значитально меньше и работал он
значительно лучше и сопровождать было значительно проще, rapid - быстрее просто
некуда!
В плане обработки текста.
Но минусы:
1. Кроссплатформенность хромает.
Каким образом она хромает? Все инструменты кросcплатформенные дальше некуда.
2. Скорость падает.
Как бы не наоборот. Скорость разработки точно возрастает, надёжность софта
точно, да и на Си написать то, что перл умеет лучше всего, да ещё чтоб и
работало быстрее, чем перл, это надо быть сишником среднего уровня и выше, что в
наши дни большая редкость.
Это где редкость? o.O Не знаю, что вы подразумеваете под "средним уровнем", но,
по-идее C - простой язык.

По идее - вы правы, а на практике я прав, практика - это ведь не HelloWorld.c, это нечто посложнее.
И чтобы стать неплохим сишником надо написать немало своего кода и чужого много пересмотреть/адаптировать. Но на Си сейчас большую прикладуху не пишут, а именно там встречаются пятизвёздочные указатели, многозадачность, условное выделение и освобождение памяти и прочее, отчего даже отладчик впадает в ступор. На самом деле Си - простой язык, но для системщиков, а их очень мало.



3. Связь между awk и C-шным кодом через костыли.
Стандартные системные IPC - костыли? Не согласен
Просто не самая лучшая идея встраивать awk через системные вызовы: я бы встроил
тогда уж что-то наподобие Lua (ну awk тоже неплохо, только, если встраивать
по-человечески, как библиотеку, если такое имеется).

Когда я пользовался awk, то lua ещё наверно и в проекте не было.
А потом, lua для потоковой обработки данных скорее всего хуже awk будет.


вот писать формирование
отчётов на Си - это не просто костыли, это [*** ну тут такой нехороший эпитет
***]. Ибо сегфолты и коры дампы постоянно по причине кривости пользовательского
ввода и трудности проверки его сишными средствами.
Да ладно. Пишут же на C компиляторы и всякие там awk?
Я тут тоже занялся "полезной работой" и, больше ради повторения, написал парсер,
который производит разбор в соответствии с метаданными, загруженными из INI
(взял парсер иника из интернетов), но в INI я добавил условия типа if, elif и
else (однопроходный анализатор с построением дерева), плюс разбор выражений в
C-стиле (без построения дерева) и построение списка полей на основе метаданных.
И ничего: это чуть сложнее, чем обычный пользовательский ввод, но работает без
сегфолтов и компилируется на 32-х и 64-х разрядной системе нормально.

Вообще-то отсутствие сегфолтов ещё ничего не доказывает, вот тесты могут что-то доказать, но то же не всё.

Правда писать что-то на C я теперь зарёкся. :-) Да и рекурсивный анализатор вряд
ли уже когда-то писать буду: прочитаю всё-таки "Книгу дракона" и стану
пользоваться генераторами.

Немного извращённо: лучше уж perl взять.
Хотя, идея любопытная.
Хоть и не имеет прямого отношения к RAD.
Имеет, ибо Unix и есть RAD.
Unix? Я ни разу в нём не работал. А Unix-подобные ОС бывают и без средств
разработки.



Что, unix без /bin/sh? Ну наверно бывают, для какого-то очень экзотического применения наверно...


Reply to: