информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыЗа кого нас держат?Страшный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
У страуструпа есть целая глава про частые ошибки при разработке программ на С++ 28.07.03 15:45  Число просмотров: 1755
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> За Microsoft С++ серьёзно пока не брался, но даже на этом
> форуме многие плюются на его MFC.
К примеру я плююсь на MFC из-за его монстрообразности. Но ведь еще большая монстрообразность борландовских продуктов и библиотек не мешает людям их юзать. Просто для некоторых это не является главным.

> Предвижу возражения типа «раньше писали код в обычном
> редакторе и запускали компилер из командной строки», но
> ведь XXI век на дворе, насколько я понял ;-)
Гы, об этом ниже. :-)

> объектные библиотеки, пошёл бардак. А то, что писали не
> они, вообще никуда не годится ;-)
Тут особо сказать нечего, можно писать на CPP но не использовать обертки для WinAPI. То бишь строить свою иерархию классов, а не встраиваться в чужую.

> кода, как таковое ;-) Ведь в принципе, «кирпичики» кода по
> своему смыслу одинаковы, неважно на каком языке они
> пишутся. Операции с данными, доступы к методам или полям и
> проч. Объекты тоже штука достаточно абстрактная…
> Я вот всё это к чему. Когда наконец появится среда
> программирования, отвязанная от языка как такового — некий
> конструктор приложений, в котором наглядно и динамично
> представлена логика будущего приложения?
А теперь о сабже. Среди таких ошибок как "использование C++ в стиле C", "отказ от наследования" и т.д., есть такая интересная ошибка "отказ от программирования" :-) Не помню всех аргументов и последствий, но предостерегается именно от такого "гипер-визуального программирования". Кому интересно, может почитать у страуструпа.

Я же могу сказать, что если такая визуальная среда программирования достигнет уровня универсальности C/C++, программировать на ней станет не легче, чем на самих C/C++. Потому как сейчас все визуально-ориентированные среды (RAD-среды) удобны для новичков только тем, что ограждают его от лишних сложностей. Но вот когде человек уже и сам в состоянии контроллировать это "лишние сложности", среда чаще всего продолжает ограждать. И тогда приходится или отказываться от среды или находить извращенные способы обхода препятствий.

> В котором объекты являются просто шаблонами будущей логики,
> с возможностью гибкого изменения этой логики «на лету»?
> Вот, к примеру Проводник M$ Windows (не плюйтесь, плз) —
> типичный пример браузера логических структур (в котором
> объекты это ресурсы компьютера). Разве нельзя подобным
> образом «браузить» и создавать абстрактную логику будущего
> приложения?
Кстати, пример довольно показательный. Проводник в винде может показывать самые разнообразные типы объектов, но если попробовать на основе того же проводника сделать например калькулятор или криптопакет, то возникнут сложности, которые обойти то можно, но с гораздо большими затратами, чем если использовать нечто более универсальное.

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

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

> Сегодня понедельник, наверное просто тяжёлый день ;-)
Да уж %-/
<programming>
Всё как будто специально плохо или разочарование в современных средах IDE... 28.07.03 14:48   [amirul, Ktirf, DamNet, whiletrue, Sandy]
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 28.07.03 14:54  Количество правок: 1
<"чистая" ссылка>
Моё первое знакомство с subj началось с Delphi. Сперва были трудности с освоением, потом восторг типа «ну вот, окошки хлопают, есть in-line assembler, мощный отладчик и VCL. Потом начала потихоньку брать злоба вроде «нет функций in-line», «нет перегрузки функций» и проч., а VCL оказался пародией на нормальное объектно-ориентированное программирование. Кое-что со временем улучшалось (к примеру, появилась перегрузка функций), но главная проблема в плане невозможности сколько-нибудь серьёзного изменения работы встроенных классов осталась — к примеру, однажды написанный борландовский компонент почти невозможно изменить коренным образом, не открывая его исходники и не переписывая его заново, потом добавляешь «свой» компонент в палитру и вот, наслаждайся… Новый, но уже свой геморрой ;-)
Потом послушал советы бывалых зубров, типа «Паскаль это ламерство» и надо, мол, тебе переходить на C++. Ладно, думаю, пусть будет поменьше крови в процессе переучивания, попробую C++ Builder… Ага, вот вам вся мощь C++, но там VCL, который взят из Delphi, да ещё и в объектных библиотеках, так что всем понятно, что для изменения компонент запускаешь Delphi и вперёд ;-)))
За Microsoft С++ серьёзно пока не брался, но даже на этом форуме многие плюются на его MFC.
Из бесплатных компилеров попробовал легендарный Watcom C, и всё в нём хорошо, исключая IDE, который хоть и облегчает программирование (ну там редактор с подстветкой операторов и визуальное управление параметрами командной строки компилятора\линкера). Но вот формы создавать более-менее быстро или палитры обектов кода там нет,
Предвижу возражения типа «раньше писали код в обычном редакторе и запускали компилер из командной строки», но ведь XXI век на дворе, насколько я понял ;-)
Всё больше склоняюсь к выводу, что компиляторы на самом деле круты, неважно, Delphi это или C++, поскольку писали их умные люди, технари, которые отменно знают низкоуровневые особенности компьютера и которым на «обычного» человека наплевать, поскольку у них всё работает отменно ;-) Но вот потом, когда эти же люди начали писать объектные библиотеки, пошёл бардак. А то, что писали не они, вообще никуда не годится ;-)
И ещё у меня есть сильное подозрение, что «трёхкитовая» модель (инкапсулирование, наследование, полиморфизм) до сих пор «хромает» в третьем ките — полиморфизме, по крайней мере, его поддержка в современных средах IDE. Я максималист по натуре, меня вообще раздражает текстовое окно редактора кода, как таковое ;-) Ведь в принципе, «кирпичики» кода по своему смыслу одинаковы, неважно на каком языке они пишутся. Операции с данными, доступы к методам или полям и проч. Объекты тоже штука достаточно абстрактная…
Я вот всё это к чему. Когда наконец появится среда программирования, отвязанная от языка как такового — некий конструктор приложений, в котором наглядно и динамично представлена логика будущего приложения? В котором объекты являются просто шаблонами будущей логики, с возможностью гибкого изменения этой логики «на лету»? Вот, к примеру Проводник M$ Windows (не плюйтесь, плз) — типичный пример браузера логических структур (в котором объекты это ресурсы компьютера). Разве нельзя подобным образом «браузить» и создавать абстрактную логику будущего приложения?
А то вот что получается — компилятор разбирают текстовый код на логические структуры, потом из этих структур генерит низкоуровневый код, а потом эдакая штука, называемая «компоновщиком», генерит исполняемый файл. А у программиста в голове уже есть эти логические структуры, когда он пишет софт, но ему их надо кодировать в языке. Налицо «лишний» этап создания приложения.

Народ, выскажитесь, плз, кто что думает.

Сегодня понедельник, наверное просто тяжёлый день ;-)
Всё как будто специально плохо или разочарование в современных средах IDE... 10.08.03 11:30  
Автор: beetle <beetle> Статус: Member
<"чистая" ссылка>
> Моё первое знакомство с subj началось с Delphi. Сперва были
> трудности с освоением, потом восторг типа «ну вот, окошки
> хлопают, есть in-line assembler, мощный отладчик и VCL.
> Потом начала потихоньку брать злоба вроде «нет функций
> in-line», «нет перегрузки функций» и проч., а VCL оказался
> пародией на нормальное объектно-ориентированное
> программирование. Кое-что со временем улучшалось (к
> примеру, появилась перегрузка функций), но главная проблема
> в плане невозможности сколько-нибудь серьёзного изменения
> работы встроенных классов осталась — к примеру, однажды
> написанный борландовский компонент почти невозможно
> изменить коренным образом, не открывая его исходники и не
> переписывая его заново, потом добавляешь «свой» компонент в
> палитру и вот, наслаждайся… Новый, но уже свой геморрой ;-)
> Потом послушал советы бывалых зубров, типа «Паскаль это
> ламерство» и надо, мол, тебе переходить на C++. Ладно,
> думаю, пусть будет поменьше крови в процессе переучивания,
> попробую C++ Builder… Ага, вот вам вся мощь C++, но там
> VCL, который взят из Delphi, да ещё и в объектных
> библиотеках, так что всем понятно, что для изменения
> компонент запускаешь Delphi и вперёд ;-)))
> За Microsoft С++ серьёзно пока не брался, но даже на этом
> форуме многие плюются на его MFC.
> Из бесплатных компилеров попробовал легендарный Watcom C, и
> всё в нём хорошо, исключая IDE, который хоть и облегчает
> программирование (ну там редактор с подстветкой операторов
> и визуальное управление параметрами командной строки
> компилятора\линкера). Но вот формы создавать более-менее
> быстро или палитры обектов кода там нет,
> Предвижу возражения типа «раньше писали код в обычном
> редакторе и запускали компилер из командной строки», но
> ведь XXI век на дворе, насколько я понял ;-)
> Всё больше склоняюсь к выводу, что компиляторы на самом
> деле круты, неважно, Delphi это или C++, поскольку писали
> их умные люди, технари, которые отменно знают
> низкоуровневые особенности компьютера и которым на
> «обычного» человека наплевать, поскольку у них всё работает
> отменно ;-) Но вот потом, когда эти же люди начали писать
> объектные библиотеки, пошёл бардак. А то, что писали не
> они, вообще никуда не годится ;-)
> И ещё у меня есть сильное подозрение, что «трёхкитовая»
> модель (инкапсулирование, наследование, полиморфизм) до сих
> пор «хромает» в третьем ките — полиморфизме, по крайней
> мере, его поддержка в современных средах IDE. Я максималист
> по натуре, меня вообще раздражает текстовое окно редактора
> кода, как таковое ;-) Ведь в принципе, «кирпичики» кода по
> своему смыслу одинаковы, неважно на каком языке они
> пишутся. Операции с данными, доступы к методам или полям и
> проч. Объекты тоже штука достаточно абстрактная…
> Я вот всё это к чему. Когда наконец появится среда
> программирования, отвязанная от языка как такового — некий
> конструктор приложений, в котором наглядно и динамично
> представлена логика будущего приложения?
> В котором объекты являются просто шаблонами будущей логики,
> с возможностью гибкого изменения этой логики «на лету»?
> Вот, к примеру Проводник M$ Windows (не плюйтесь, плз) —
> типичный пример браузера логических структур (в котором
> объекты это ресурсы компьютера). Разве нельзя подобным
> образом «браузить» и создавать абстрактную логику будущего
> приложения?
> А то вот что получается — компилятор разбирают текстовый
> код на логические структуры, потом из этих структур генерит
> низкоуровневый код, а потом эдакая штука, называемая
> «компоновщиком», генерит исполняемый файл. А у программиста
> в голове уже есть эти логические структуры, когда он пишет
> софт, но ему их надо кодировать в языке. Налицо «лишний»
> этап создания приложения.
лексический анализ необходимый этап создания программы по той простой причине, что человек должен иметь формальный
> Народ, выскажитесь, плз, кто что думает.
>
> Сегодня понедельник, наверное просто тяжёлый день ;-)
Мож закроем? 30.07.03 13:37  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
Всё как будто специально плохо или разочарование в современных средах IDE... 28.07.03 17:09  
Автор: lunc <Alexander Krizhanovsky> Статус: Member
<"чистая" ссылка>
> Я максималист
> по натуре, меня вообще раздражает текстовое окно редактора
> кода, как таковое ;-) Ведь в принципе, «кирпичики» кода по
> своему смыслу одинаковы, неважно на каком языке они
> пишутся.

Кстати, Together - полноценное CASE средство - рисуешь диаграммы, а система код генерит (описание классов и т.п.) Впирнципе это похоже именно на то, что ты хочешь
Дайте ссылку, плз… 28.07.03 19:44  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
Дайте ссылку, плз… 29.07.03 11:15  
Автор: lunc <Alexander Krizhanovsky> Статус: Member
<"чистая" ссылка>
Я знакомился с ним тоько методом тыка - сейчас Together есть на льбом CD с UML.
Когда-то оно жило на (внутри) (updated) 28.07.03 20:22  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
Отредактировано 28.07.03 20:25  Количество правок: 1
<"чистая" ссылка>
ссылке ниже, но можно также связаться со мной :)

www.togethersoft.com, но после покупки это редирект на страничку на сайте Borland.
Связываюсь — послал тебе мыло которое здесь опубликовано. Проверь почту. 29.07.03 20:46  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 29.07.03 21:01  Количество правок: 1
<"чистая" ссылка>
Ответ ушел. 30.07.03 11:25  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
Угу, только купили ее страшные Борланды... Будет теперь JBuilder с наворотом в виде генератора кода из UML... 28.07.03 17:12  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
Еще Джаву посмотри 28.07.03 16:25  
Автор: whiletrue <Роман> Статус: Elderman
<"чистая" ссылка>
Не в смысле ее платформо-независимости и пр., а как она сделана.

Вобщем-то это облегченный Си++. Плюс всякие встроенные мапы, динамические массивы, всякая работа со строками, упрощенный тайп кастинг,...

Да и все в ней вроде как в Си++, ан нет чуть по-другому...

Она вот более приближена к описываемому тобой "конструктору". Правда, все таки в текстовом виде.

Я это к тому, что это небольшой шажок от Си++ в сторону удобства программирования, а никто здесь не будет сомневаться, что у Си++ возможностей-то побольше.

И потом, зачем визуально программировать? Визуально настраиваем всякие формочки,... то что видим. Прогу-то зачем визуализировать - у меня лично со школы рвотный рефлекс к блок-схемам - грамоздко очень. Как-то непосредственно на языке программирования писать понятнее. Да и распечатать можно - на диване почитать...
У страуструпа есть целая глава про частые ошибки при разработке программ на С++ 28.07.03 15:45  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> За Microsoft С++ серьёзно пока не брался, но даже на этом
> форуме многие плюются на его MFC.
К примеру я плююсь на MFC из-за его монстрообразности. Но ведь еще большая монстрообразность борландовских продуктов и библиотек не мешает людям их юзать. Просто для некоторых это не является главным.

> Предвижу возражения типа «раньше писали код в обычном
> редакторе и запускали компилер из командной строки», но
> ведь XXI век на дворе, насколько я понял ;-)
Гы, об этом ниже. :-)

> объектные библиотеки, пошёл бардак. А то, что писали не
> они, вообще никуда не годится ;-)
Тут особо сказать нечего, можно писать на CPP но не использовать обертки для WinAPI. То бишь строить свою иерархию классов, а не встраиваться в чужую.

> кода, как таковое ;-) Ведь в принципе, «кирпичики» кода по
> своему смыслу одинаковы, неважно на каком языке они
> пишутся. Операции с данными, доступы к методам или полям и
> проч. Объекты тоже штука достаточно абстрактная…
> Я вот всё это к чему. Когда наконец появится среда
> программирования, отвязанная от языка как такового — некий
> конструктор приложений, в котором наглядно и динамично
> представлена логика будущего приложения?
А теперь о сабже. Среди таких ошибок как "использование C++ в стиле C", "отказ от наследования" и т.д., есть такая интересная ошибка "отказ от программирования" :-) Не помню всех аргументов и последствий, но предостерегается именно от такого "гипер-визуального программирования". Кому интересно, может почитать у страуструпа.

Я же могу сказать, что если такая визуальная среда программирования достигнет уровня универсальности C/C++, программировать на ней станет не легче, чем на самих C/C++. Потому как сейчас все визуально-ориентированные среды (RAD-среды) удобны для новичков только тем, что ограждают его от лишних сложностей. Но вот когде человек уже и сам в состоянии контроллировать это "лишние сложности", среда чаще всего продолжает ограждать. И тогда приходится или отказываться от среды или находить извращенные способы обхода препятствий.

> В котором объекты являются просто шаблонами будущей логики,
> с возможностью гибкого изменения этой логики «на лету»?
> Вот, к примеру Проводник M$ Windows (не плюйтесь, плз) —
> типичный пример браузера логических структур (в котором
> объекты это ресурсы компьютера). Разве нельзя подобным
> образом «браузить» и создавать абстрактную логику будущего
> приложения?
Кстати, пример довольно показательный. Проводник в винде может показывать самые разнообразные типы объектов, но если попробовать на основе того же проводника сделать например калькулятор или криптопакет, то возникнут сложности, которые обойти то можно, но с гораздо большими затратами, чем если использовать нечто более универсальное.

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

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

> Сегодня понедельник, наверное просто тяжёлый день ;-)
Да уж %-/
а как насчет UML? 28.07.03 15:10  
Автор: vh <Дмитрий> Статус: Member
Отредактировано 28.07.03 15:11  Количество правок: 1
<"чистая" ссылка>
Это что касается проектирования.
Моя мечта 29.07.03 14:01  
Автор: ben Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Я вот думаю, что было бы полезно для С++ - это использование инструмента, в котором программа пишется не в виде набора файлов, а прямо создаешь классы, функции в диалогах
но это не должна быть система с использованием UML, а просто заточена под чистый ++
У Страуструпа где-то даже написано, что к этому все придет в конце-концов, ибо в языке определены классы, функции, объекты, но не иcходные файлы, поэтому и работа собственно с понятиями языка гораздо продуктивнее, чем всяческая фигня вроде форматирования исходного текста, опечатки, зависимость от порядка включаемых файлов и так далее
К тому-же избавляемся от <#include>, многих <#define>
Существующие системы, которые я видел, идут от конкретной парадигмы проектирования к исходному коду, а я имею в виду систему чисто С++, причем как можно более стандартный
Видел я одну програмку такую - <ClassBuilder>, но она к сожалемию далеко не полностью покрывает язык, есть определения, которые можно написать руками, но нельзя в ней
Такая система, естественно, хранила программу в виде базы данных и могла бы генерить исходник по желанию, причем с любимым форматированием
Страуструп как раз писал обратное :-) 30.07.03 09:57  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> У Страуструпа где-то даже написано, что к этому все придет
> в конце-концов, ибо в языке определены классы, функции,
Он написал, что вряд ли нормальное программирование в ближайшем будущем изживет себя. Потому как как минимум эти среды будут писаться "обычными программистами". Во вторых такую генерацию кода из высокоуровневых спецификаций можно сделать только для хорошо формализованных задач: реляционные БД, построение юзер-интерфейса, некоторые математические задачи и др.. . И они проще обычного программирования именно за счет того, что жесткий формализм данных задач позволяет избавить программиста от отслеживания многих зависимостей (потому как из может отследить и среда проектирования).

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

ИМХО - один из самых жутких вариантов.
Страуструп как раз писал обратное :-) 30.07.03 13:16  
Автор: ben Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Извини, ты прочитал бы внимательнее, что я написал
Именно это и говотю, что всякие <case>/<UML> средства не могут быть использованы широко ещё долго (именно для прямой конвертации спецификаций в код)
а вот среда специально под С++, вот что нужно
и Страуструп пишет об этом по-моему в <Дизайн и эволюция языка C++. Объектно-ориентированный язык программирования>
Он ещё вспоминает <SmallTallk>-ские среды и говорит, что писание кода в текстовых файлах довольно извратно - вот об этом речь
К сожалению нет под рукой книги, не могу процитировать
Прошу прощения - невнимательно прочитал :-) 30.07.03 13:36  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
Размечтались :) 29.07.03 15:24  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
Вы что, рынок IDE только создается, тем более под C++, который, прошу прощения, в нормальном объеме стандартизовали только пяток лет назад. Вы вообще представляете, что это такое - написать IDE, использующую ВСЕ возможности C++?!

Короче говоря. Такие вещи - это дело будущего. Хотите мало-мальски достойную IDE - смотрите в сторону Java, для нее IDE проще написать в силу специфики языка. Либо пишите IDE сами. Я пока не видел ни одной среды разработки для C++, которая бы меня устроила, причем не так чтобы только "из кирпичиков" собирать, а в любой момент и ручками чтобы можно было подправить, да чтобы подсказывали, что писать, чтобы все было под рукой... Visual C++ хоть сколько-то близко подошел к этому, но и это, мягко говоря, не идеал. И вообще, я согласен со Страуструпом, что настоящая среда разработки должна включать в себя компилятор и компоновщик на настолько низком уровне, чтобы граф выполнения можно было посмотреть. До такого еще не дошла ни одна IDE.

Сказал я и пошел работать в Vim :)

PS Да, а что там насчет возможностей современных IDE вписаться в прокрустово ложе командной строки? ;)
Про «прокрустово ложе ком. строки» — «А ещё мы когда-то жили на пальмах» ;-)))) 29.07.03 15:48  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
Вовсе нет, просто есть такие странные люди, которым время от времени что-нибудь нужно сделать удаленно. 29.07.03 16:21  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
А еще есть еще более странные люди, которые не любят и не признают графический интерфейс, считают его излишеством и вполне способны обходиться пятью-восемью консолями. Кстати, очень часто такие люди работают эффективнее, чем использующие графику ;)
1  |  2 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach