Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | |
Молодой человек, вы меня умиляете :) 09.07.04 14:20 Число просмотров: 1569
Автор: leo <Леонид Юрьев> Статус: Elderman
Отредактировано 09.07.04 15:03 Количество правок: 1
|
[moved from site updates]
> Язык ПРОГРАММИРОВАНИЯ может быть только
> машино-ориентированным, ибо задача программирования -
> получение максимально эффективного кода.
>
> Все остальное может быть объектно-ориентированным, т.е.
> заточеным под моделирование материальных объектов или
> понятийно-ориентированным, т.е. заточенным под
> моделирование человеческого мышления и человеческого
> представления об этих объектах.
Нет, всё совсем не так. Вот старый "баян":
- когда появился С, любители ассемблера говорили: "системные подпрограммы и драйвера нужно писать на ассемблере, С проигрывает в скорости";
- когда появился ассемблер, любители машинных кодов говорили "bla-bla-lba, так как ассемблер не всегда оптимально кодирует команды и расслабляет программиста";
- еще раньше ругали идею программы как набора более-менее последовательных инструкций "bla-bla-bla схема с непосредственными соединениями работате быстрее;
Мы ради интереса делаем компилятор с K2, в языке только объекты. Например аналог unsigned С/C++ - это "класс" который может состоять (в частности) из N-бит и быть >= нуля. На выходе компилятора -исходник C, можно VHDL, или например наборы micro-ops для оптимизированного под задачу набора инструкций процессора плюс программа в этих командах. И что получается - да объектное..., да "заточенно"..., но быстрее и ассемблера и "обычных" машинных кодов :)
Та эффективность про которую вы говорите - это вопрос качества компилятора и квалификации программиста. Но есть и другая эффективность - время затраченное на реализацию (проектирование , кодирование и отладку).
Программирование это всегда моделирование, и ни как иначе. Не пропускайте лекций, там иногда говорят интересное...
Удачи!
|
|
<programming>
|
Разнос идеи JavaBeans? :) 07.07.04 18:58 [Ktirf]
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
А между тем как раз JavaBeans оказались очень неплохой моделью, прообразом этакой софтверной "умной пыли", которая, будучи грамотно организована, способна творить великие вещи. Я не могу сказать, что объектная парадигма провалилась. Да, чрезмерные и неадекватные ожидания, которые возлагались на нее, не оправдались. Но, прошу прощения, распределенные архитектуры настоящего (CORBA, COM) порождены именно этой самой парадигмой, в них она проявила всю свою мощь.
Хотя Smalltalk, LISP, ML все-таки жалко. Хорошие языки. Кстати говоря, Java - это несостоявшийся Smalltalk, поскольку Sun в свое время хотела лицензировать его, но из-за жадности менеджмента (с обеих сторон) сделка не состоялась, в связи с чем началась разработка Java.
А идея мутирующих программ хороша только на словах. Отлаживать подобные программы чрезвычайно сложно (раньше компилятор хоть часть ошибок мог отловить, а тут все ошибки - времени выполнения), а уж безопасность... Программу на Smalltalk открывать для доступа через сеть - это же страшно подумать. Никакого контроля доступа не хватит.
|
|
не скажу про smalltalk, а вот Lisp и уж тем более ml не... 08.07.04 11:06
Автор: n013e Статус: Member
|
[moved from site updates]
> Хотя Smalltalk, LISP, ML все-таки жалко. Хорошие языки.
не скажу про smalltalk, а вот Lisp и уж тем более ml не такие уж и мёртвые языки...
|
|
Разделяй и властвуй? ;-) 08.07.04 10:12
Автор: HandleX <Александр М.> Статус: The Elderman
|
[moved from site updates]
> А между тем как раз JavaBeans оказались очень неплохой
> моделью, прообразом этакой софтверной "умной пыли",
Ну не думает пока софтвер, хоть убейте! ;-) И не умён.
До сих пор думает программист или пользователь.
> которая, будучи грамотно организована, способна творить
> великие вещи.
Опять же, организована. Предполагает "кашевара" и "кашееда". Со всеми вытекающими последствиями — гибкости нет, доколе софт не перекомпилируется, если проект не open-source, то общайтесь с разработчиками (часто до хрипоты и время уходит и денег просят: "вы знаете, то что вы хотите, уже есть в новой версии нашей программы. Upgrade до версии хх.хх стоит $ххх), и т.п.
Часто то, что раздражает пользователя, правится изменением буквально нескольких строк кода.
> Я не могу сказать, что объектная парадигма провалилась.
> Да, чрезмерные и неадекватные ожидания,
> которые возлагались на нее, не оправдались.
В оригинале статья называется «Objects have failed», переводите, как хотите. Хотите «провалилась», хотите «обманула ожидания». Но вообще это просто ещё одно IMHO на существующую проблему. Как она будет решаться, покажет время. Но тенденция такая, что софтверные компании незаинтересованы в гибкости выпускаемых ими сред программирования и программ... Так зелень косить проще ;-)
> Но, прошу
> прощения, распределенные архитектуры настоящего (CORBA,
> COM) порождены именно этой самой парадигмой, в них она
> проявила всю свою мощь.
Суть этих систем проста до безобразия — Ещё Одна Транспортная Система, Заточенная Под Общую Объектную Реализацию Чего-Либо И Принятая Всеми, Из-За Лени ;-)
> Хотя Smalltalk, LISP, ML все-таки жалко. Хорошие языки.
Вот и похоронили ;-) Их не жалеть, их развивать надо!
> Кстати говоря, Java - это несостоявшийся Smalltalk,
> поскольку Sun в свое время хотела лицензировать его, но
> из-за жадности менеджмента (с обеих сторон) сделка не
> состоялась, в связи с чем началась разработка Java.
Да кто его знает, как оно было... Интересно как оно есть и как оно будет...
Да, у Java нет проблем ;-) За нас, программистов, там всё решено Умными Дядями...
А ещё нет проблем у мёртвых...
> А идея мутирующих программ хороша только на словах.
Поздравляю! Однако, мы телесны и осязаемы и суть продукт миллионолетних крошечных мутаций... А говорите, "на словах"... ;-)
> Отлаживать подобные программы чрезвычайно сложно (раньше
> компилятор хоть часть ошибок мог отловить, а тут все ошибки
> - времени выполнения), а уж безопасность... Программу на
> Smalltalk открывать для доступа через сеть - это же страшно
> подумать. Никакого контроля доступа не хватит.
Ходил я всё время по земле, и забыл про крылья, а тут мне снова их дали... Вот ужас-то какой! А вдруг откажут? Как грохнусь, и крышка мне! ;-)
Сущность жива, пока она развивается... Жизненный цикл программы, как сущности, которая живёт в компьютере и цель которой что-то делать для нас, помогать нам в решении наших проблем, которые постоянно изменяются, становится ущербным сразу же после компиляции. После компиляции из программы "вырезается" то, что способно её менять. После компиляции программа ещё "дёргается", но она уже мертва.
А про отладку и скорость разработки в SmallTalk ходят легенды... Вопрос: зачем после изменения строчки кода в большом проекте мне надо идти пить кофе в ожидании, пока всё откомпилируется? А потом добираться до нужного места в программе (после её запуска), и там смотреть, как оно получилось? Ой, не получилось. Надо было иначе. Файл->Выход и всё сначала! ;-)
Так что бросаясь словами "экстремальное программирование", "объектная реализация" и т.п., не удивляйтесь, если увидите хитрую улыбку у старого SmallTalker'а, лиспера или у того, кто программирует на Forth.
Кстати о Forth — он постарее, попроще (сперва до умопомрачения, потом это проходит)... но могущественен не менее. К примеру, объекты прикручиваются к Forth с лёгкостью (скажем, за день) его же средствами. Представляете — оказывается, не нужно переделывать компилятор, чтобы появилась поддержка объектов! ;-) Да и Forth может генерить как полностью интерпретируемый, так и "шитый" (т.е. через некий InterMediate Language - чувствуете, запахло .net'ом?), так и полностью откомпилированный код. "Старички" могут научить кое-чему, а?
Ну и про безопасность — сколько раз говорилось, что на неё не влияет язык/средство разработки! Вернее влияет, но обычно в худшую сторону. Какая разница, чем не контролировать буфер? На безопасность больше влияют дизайн и тщательная отладка, а вот в отладке run-time очень помогает. Особенно когда дизайн и работа и отладка происходят вот прям тут, в среде разработки, программа "пищит" у вас под клавишами!
Ну в общем вот такое IMHO.
|
|
маркетинг-маркетинг... все стали жертвой рекламы... %( 07.07.04 21:53
Автор: n013e Статус: Member
|
[moved from site updates]
|
| |
когда вы программируете на C++ ,а не на бейсике вы назовёте... 09.07.04 08:54
Автор: noonv <Vladimir> Статус: Member
|
[moved from site updates]
когда вы программируете на C++ ,а не на бейсике вы назовёте себя жертвой рекламы?
Статья конечно задевает за живое, потому что она отчасти права - всё меняется ......
|
| | |
не надо отрицать, что C++ тоже раскрученный язык,... 09.07.04 12:24
Автор: n013e Статус: Member
|
[moved from site updates]
> когда вы программируете на C++ ,а не на бейсике вы назовёте
> себя жертвой рекламы?
> Статья конечно задевает за живое, потому что она отчасти
> права - всё меняется ......
не надо отрицать, что C++ тоже раскрученный язык, правильно?
о многие нынешние популярные языки раскручиваются сами-знаете-кем, так?
Это к вопросу о рекламе.
ООП дал течь, хотя некоторые считают, что он был порочен изначально, зато другие придерживаются мнения, что никто просто ООП не умеет использовать... Я однажды был на лекции тов. Непейвода (кажется не ошибся), он толкал речь про то, что ребенок был мёртвым, что это единственная парадигма у которой нет сильного научного обоснования, был ещё человек, который высказался, что реально научился ООПу только после прослушивания курса в МИФИ, так что...
Как правильно говорит zelych, каждому языку своё, в том отношении, что для ООПа нужно своё применение, просто проблема в том, что для написания компилятора или еще чего-нибудь подобного ООП не нужен, не нужен он и для высокопроизводительных систем и т.д. Думаю, что в работе большинства из вас он тоже не шибко нужен, поэтому мы его и критикуем. Зато попробуйте предствить что-нибудь более логичное, чем применение ООПа для моделирования, очень и очень удобно... думаю, что если порыться можно найти кучу других не менее красывых применений объектам.
ООП действительно применяется там где не надо и кем не попадя, вот это реальная проблема. Т.е. все наши диспуты упираются в общий непрофессионализм программеров, а не в сам ООП. Предлагаю над этим подумать.
P.S. сам ООП не люблю и стараюсь его не использовать
|
| | | |
Не стоит смешивать ООП и C++ 09.07.04 14:47
Автор: amirul <Serge> Статус: The Elderman
|
[moved from site updates]
> не надо отрицать, что C++ тоже раскрученный язык,
Я отрицаю. Ну и что?
> о многие нынешние популярные языки раскручиваются
> сами-знаете-кем, так?
Ой ли. Все ли их нововведения так уж единодушно принимаются?
> отношении, что для ООПа нужно своё применение, просто
> проблема в том, что для написания компилятора или еще
> чего-нибудь подобного ООП не нужен, не нужен он и для
> высокопроизводительных систем и т.д. Думаю, что в работе
С чего Вы взяли? Ядра и NT и linux - объектно ориентированы (надеюсь возможность поддержки ОО парадигмы в языках типа С для вас не является откровением). ОО подход позволяет еще больше (по сравнению с функциональным и модульным подходом, которые, кстати, никто не отменял: объекты можно распихать по независимым модулям) снизить логические связи между частями, что в конечном итоге приводит к повышению порогового размера для программ, которые в принципе можно написать и самое главное поддерживать (правка ошибок и внесение прочих изменений)
> большинства из вас он тоже не шибко нужен, поэтому мы его и
> критикуем. Зато попробуйте предствить что-нибудь более
Неправда, я очень часто использую части ОО в проектировании драйверов. Хотя пишу их на чистом С.
> P.S. сам ООП не люблю и стараюсь его не использовать
Зря. Объектная декомпозиция предоставляет гораздо бОльшую управляемость проектом, чем функциональная.
|
| | | | |
К счастью не все.
09.07.04 15:45
Автор: n013e Статус: Member
|
[moved from site updates]
> Ой ли. Все ли их нововведения так уж единодушно
> принимаются?
К счастью не все.
> С чего Вы взяли? Ядра и NT и linux - объектно ориентированы
%-[ ]
> (надеюсь возможность поддержки ОО парадигмы в языках типа С
> для вас не является откровением). ОО подход позволяет еще
> больше (по сравнению с функциональным и модульным подходом,
> которые, кстати, никто не отменял: объекты можно распихать
> по независимым модулям) снизить логические связи между
> частями, что в конечном итоге приводит к повышению
> порогового размера для программ, которые в принципе можно
> написать и самое главное поддерживать (правка ошибок и
> внесение прочих изменений)
Помнится Торвальдс в своей (ну ладно не совсем своей) книжечке писал по поводу концепции миниядер, что накладные расходы на взаимодействие модулей превысит рано или позно все разумные пределы, тут то же самое
> Неправда, я очень часто использую части ОО в проектировании
> драйверов. Хотя пишу их на чистом С.
>.....................................................
> Зря. Объектная декомпозиция предоставляет гораздо бОльшую
> управляемость проектом, чем функциональная.
В части проектирования может быть ты прав, и кое-что следует использовать, но реализовать драйвера на крестах точно никто не будет...
|
| | | | | |
К счастью не все. 09.07.04 15:55
Автор: Ktirf <Æ Rusakov> Статус: Elderman
Отредактировано 09.07.04 15:55 Количество правок: 1
|
[moved from site updates]
> Помнится Торвальдс в своей (ну ладно не совсем своей)
> книжечке писал по поводу концепции миниядер, что накладные
> расходы на взаимодействие модулей превысит рано или позно
> все разумные пределы, тут то же самое
Во-первых, они все-таки микроядра, а не мини. Во-вторых, это был принципиальный спор Торвальдса с Таненбаумом, а в принципиальных спорах истина, извините, не рождается. Попытки последовательно применять только один принцип рискуют привести к абсурдной архитектуре. Примером тому собственное ядро Торвальдса, в которое он уже очень давно, скрепя сердце, добавил-таки модульную архитектуру. Потому что понял, что не везде прав в этом споре.
> > Неправда, я очень часто использую части ОО в
> проектировании
> > драйверов. Хотя пишу их на чистом С.
> >.....................................................
> > Зря. Объектная декомпозиция предоставляет гораздо
> бОльшую
> > управляемость проектом, чем функциональная.
> В части проектирования может быть ты прав, и кое-что
> следует использовать, но реализовать драйвера на крестах
> точно никто не будет...
Ничего, что BeOS на плюсах писалась, нет? Только не надо мне говорить про то, где она сейчас - BeOS сгубил маркетинг, а не архитектура.
|
| | |
Жертвы маркетинга как раз те, кто программирует на VB, а не на C 09.07.04 11:09
Автор: amirul <Serge> Статус: The Elderman
|
[moved from site updates]
> когда вы программируете на C++ ,а не на бейсике вы назовёте
> себя жертвой рекламы?
"Программистов" на VB на порядок больше и спрос на них выше :-)
> Статья конечно задевает за живое, потому что она отчасти
> права - всё меняется ......
Это да
А вообще для всестороннего развития надо знать несколько языков с разными парадигмами. Где то я встречал набор: как минимум C/C++, Lisp, Smalltalk, Python
|
| | | |
ML сюда хорошо добавить еще, для прочувствования самогенерирующихся программ. 09.07.04 14:19
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
[moved from site updates]
|
| | | | |
тогда уж рефал: метапрограммирование, суперкомпиляция и всё такое.. и ждать метасистемного прихода.. 09.07.04 21:31
Автор: zelych Статус: Member
|
[moved from site updates]
|
| | | | | |
Извините, не сталкивался, но вероятно, идея та же. 10.07.04 01:46
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
[moved from site updates]
|
| | | | | | |
к сожалению ничего не знаю по поводу самогенерирующихся программ.. [upd] 10.07.04 07:20
Автор: zelych Статус: Member
Отредактировано 10.07.04 17:02 Количество правок: 1
|
[moved from site updates]
или это что-то вроде Reflection`а?
по поводу рефала - refal.ru
|
| | | | | | | |
Спасибо за ссылку 10.07.04 17:30
Автор: Ktirf <Æ Rusakov> Статус: Elderman
Отредактировано 10.07.04 17:37 Количество правок: 3
|
[moved from site updates]
Собственно, я говорю о метапрограммировании, и судя по всему, у суперкомпиляции с ним много общего. Смысл метапрограммирования, грубо говоря, состоит в том, что некоторые фрагменты программы автоматически воссоздаются при компиляции на основе определенного закона. В качестве примера одного из самых тупых (и при этом самых известных) средств метапрограммирования можно привести препроцессор языка C. Более продвинутое и тоже весьма известное средство метапрограммирования - это Yacc. Насколько я знаю, наиболее мощными средствами метапрограммирования обладает язык Scheme.
Boost Metaprogramming Library - метапрограммирование в приложении к C++
|
| | | |
ASM & C - программирование, остальное - моделирование 09.07.04 13:17
Автор: Zef <Alloo Zef> Статус: Elderman
Отредактировано 09.07.04 13:19 Количество правок: 1
|
[moved from site updates]
Язык ПРОГРАММИРОВАНИЯ может быть только машино-ориентированным, ибо задача программирования - получение максимально эффективного кода.
Все остальное может быть объектно-ориентированным, т.е. заточеным под моделирование материальных объектов или понятийно-ориентированным, т.е. заточенным под моделирование человеческого мышления и человеческого представления об этих объектах.
|
| | | | |
Молодой человек, вы меня умиляете :) 09.07.04 14:20
Автор: leo <Леонид Юрьев> Статус: Elderman
Отредактировано 09.07.04 15:03 Количество правок: 1
|
[moved from site updates]
> Язык ПРОГРАММИРОВАНИЯ может быть только
> машино-ориентированным, ибо задача программирования -
> получение максимально эффективного кода.
>
> Все остальное может быть объектно-ориентированным, т.е.
> заточеным под моделирование материальных объектов или
> понятийно-ориентированным, т.е. заточенным под
> моделирование человеческого мышления и человеческого
> представления об этих объектах.
Нет, всё совсем не так. Вот старый "баян":
- когда появился С, любители ассемблера говорили: "системные подпрограммы и драйвера нужно писать на ассемблере, С проигрывает в скорости";
- когда появился ассемблер, любители машинных кодов говорили "bla-bla-lba, так как ассемблер не всегда оптимально кодирует команды и расслабляет программиста";
- еще раньше ругали идею программы как набора более-менее последовательных инструкций "bla-bla-bla схема с непосредственными соединениями работате быстрее;
Мы ради интереса делаем компилятор с K2, в языке только объекты. Например аналог unsigned С/C++ - это "класс" который может состоять (в частности) из N-бит и быть >= нуля. На выходе компилятора -исходник C, можно VHDL, или например наборы micro-ops для оптимизированного под задачу набора инструкций процессора плюс программа в этих командах. И что получается - да объектное..., да "заточенно"..., но быстрее и ассемблера и "обычных" машинных кодов :)
Та эффективность про которую вы говорите - это вопрос качества компилятора и квалификации программиста. Но есть и другая эффективность - время затраченное на реализацию (проектирование , кодирование и отладку).
Программирование это всегда моделирование, и ни как иначе. Не пропускайте лекций, там иногда говорят интересное...
Удачи!
|
| | | | | |
Молодому человеку "под 40" и он работает админом научного центра 8-) 10.07.04 12:36
Автор: Zef <Alloo Zef> Статус: Elderman
|
[moved from site updates]
> Нет, всё совсем не так. Вот старый "баян":
Я на этом "баяне" 25 лет играю.
> - когда появился С, любители ассемблера говорили:
> "системные подпрограммы и драйвера нужно писать на
> ассемблере, С проигрывает в скорости";
Современный С в скорости не проигрывает. Сколько раз проверял, компилер выдает код, практически не поддающийся дальнейшей ручной оптимизации. Условие - программер должен знать что во что компилиться.
> Мы ради интереса делаем компилятор с K2, в языке только
> объекты. Например аналог unsigned С/C++ - это "класс"
> который может состоять (в частности) из N-бит и быть >=
> нуля. На выходе компилятора -исходник C, можно VHDL, или
> например наборы micro-ops для оптимизированного под задачу
> набора инструкций процессора плюс программа в этих
> командах. И что получается - да объектное..., да
> "заточенно"..., но быстрее и ассемблера и "обычных"
> машинных кодов :)
Зачем просто и ясно, когда можно сложно и заумно?
Ни хрена не понял, переведи на ассемблер или С, тогда пойму...
По-моемому мыслить категориями процессор-память-регистры-порты гораздо проще. И эффективней. Исчезает барьер между программой и устройством. Сразу видишь, как сконструировать устройство, наиболее эффективное для данного класса задач. А то у нас часто получается, что заменяем один триггер машиной, содержащей 10Е9 триггеров...
> Та эффективность про которую вы говорите - это вопрос
> качества компилятора и квалификации программиста. Но есть и
> другая эффективность - время затраченное на реализацию
> (проектирование , кодирование и отладку).
Разделение на программирование и моделирование решает эту задачу. Программист создает максимально эффективные "кубики" для решения данного класса задач, а затем ламеры строят из этих кубиков свои модельки.
> Программирование это всегда моделирование, и ни как иначе.
> Не пропускайте лекций, там иногда говорят интересное...
На лекции давно не хожу, бо еще в 20 лет понял, что учить и учиться одновременно не возможно, а потому, кто учит, тот сам неуч. А слушать неучей - не хорошо.
Самый лучший способ учиться тому, что уже знают другие - "шпионаж": под-слушивай, под-глядывай, а потом - под-делывай. И старайся свою копию сделеать лучше "ихнего" оригинала. "Второй" всегда имеет больше шансов, чем "первый" обнаружить и устранить ошибки ((с) А.Макаревич). Ну и разницы не будет, копировать у людей, у природы, или изобретать свое. Барьера психологического не будет, оторпи перед самостоятельностью.
|
| | | | | | |
такой большой дядька, а.. 10.07.04 14:32
Автор: zelych Статус: Member
|
[moved from site updates]
> По-моемому мыслить категориями
> процессор-память-регистры-порты гораздо проще. И
> эффективней. Исчезает барьер между программой и
> устройством. Сразу видишь, как сконструировать устройство,
> наиболее эффективное для данного класса задач. А то у нас
> часто получается, что заменяем один триггер машиной,
> содержащей 10Е9 триггеров...
больно уж императивно-однопоточное у вас мышление получается..
одни барьеры исчезают, появляются другие: например, пользователь-программист.. ибо один мыслит кнопками и потоками своих данных, а другой - регистрами..
или ещё хуже: программист-решаемая задача.. достаточно легко за кучкой регистров не приметить слона - логичность и простоту задачи..
напомню, что пользователь - это такое гадкое существо, для которого как раз и пишутся программы..
опять же, никто не заставляет вас писать весь проект на одном единственном языке и менять миллиард триггеров на миллион строк кода, помноженных на тысячу часов времени..
к чему мучаться выбирать, если можно всё достойно сочетать??
> На лекции давно не хожу, бо еще в 20 лет понял, что учить и
> учиться одновременно не возможно, а потому, кто учит, тот
> сам неуч. А слушать неучей - не хорошо.
примите мои соболезнования, не повезло вам с преподами..
|
| | | | | | | |
одни барьеры исчезают, появляются другие 11.07.04 06:53
Автор: Zef <Alloo Zef> Статус: Elderman
Отредактировано 11.07.04 06:57 Количество правок: 1
|
> одни барьеры исчезают, появляются другие: например,
> пользователь-программист.. ибо один мыслит кнопками и
> потоками своих данных, а другой - регистрами..
Сей барьер называется "информационная безопасность"
> или ещё хуже: программист-решаемая задача.. достаточно
> легко за кучкой регистров не приметить слона - логичность и
> простоту задачи..
> напомню, что пользователь - это такое гадкое существо, для
> которого как раз и пишутся программы..
Про кубики для прикладниковя выше писал.
>
> опять же, никто не заставляет вас писать весь проект на
> одном единственном языке и менять миллиард триггеров на
> миллион строк кода, помноженных на тысячу часов времени..
>
> к чему мучаться выбирать, если можно всё достойно
> сочетать??
Вот именно. Потому челу, в другом треде на этой доске я порекомендовал писать интерфейс на Борланде, а ядро проги на VC (и особенно - отлаживать).
> > На лекции давно не хожу, бо еще в 20 лет понял, что
> учить и
> > учиться одновременно не возможно, а потому, кто учит,
> тот
> > сам неуч. А слушать неучей - не хорошо.
>
> примите мои соболезнования, не повезло вам с преподами..
Нет, с преподами мне везло, хотя и не со всеми. Просто, я претендую на авторство новой методологии самообученя... Хотя и не уверен, что эта методология подходит кому-то, кроме меня.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
