Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Шахтер, Вы писали:
Ш>>Попробуйте, в качестве упражнения, сделать хороший текстовый редактирующий элемент, такого же класса или лучше, как в студии. Если я правильно понял, Янус использует Scintillе-у? А что, свой было влом сделать?
AVK>Зачем?
Не понял вопроса. Зачем что? Сделать хороший редактирующий элемент в качестве упражнения? Для того, чтобы понять всё нищету фреймворков. Для интереса, посмотрите сорцы Scintille-ы. Любой апологет хорошего стиля программирования, смартпойнтеров и.т.п. умрёт на месте, увидев те простыни членов в классах, которые там есть. Если же вы имеете ввиду, зачем свой редактирующий элемент для Януса, ну, например, для виртуального пространства, которое я так люблю и для многих других хороших вещей, которые в Scintille отсутсвуют. Между прочим, отсутствие хорошего компонента редактирования, причем хорошо написанного -- большой пробел Открытых Сырков.
Здравствуйте, Шахтер, Вы писали:
Ш>>>Попробуйте, в качестве упражнения, сделать хороший текстовый редактирующий элемент, такого же класса или лучше, как в студии. Если я правильно понял, Янус использует Scintillе-у? А что, свой было влом сделать?
AVK>>Зачем?
Ш>Не понял вопроса. Зачем что?
Переписывать сцинтиллу.
Ш>Сделать хороший редактирующий элемент в качестве упражнения?
У меня еще не настолько плохо с головой чтобы писать что то ради упражнения.
Ш> Для интереса, посмотрите сорцы Scintille-ы.
Я их видел и даже запускал под отладкой.
Ш> Любой апологет хорошего стиля программирования, смартпойнтеров и.т.п. умрёт на месте, увидев те простыни членов в классах, которые там есть.
Ну и что в этом хорошего? Вот оказалось к примеру что сцинтилла не юникодная, а чтобы переделать ее на уникод надо перелопатить гору кода. ВОт тебе и результат криворукости.
Ш> Если же вы имеете ввиду, зачем свой редактирующий элемент для Януса, ну, например, для виртуального пространства, которое я так люблю
Чего это?
Ш> и для многих других хороших вещей, которые в Scintille отсутсвуют.
ПОка что все запросы она покрывает с лихвой.
Ш> Между прочим, отсутствие хорошего компонента редактирования, причем хорошо написанного -- большой пробел Открытых Сырков.
, который использует рефлекшин, всё что нужно сделать — это перенести это в генератор, который будет вызван компилятором. На эмите такие вещи делаются на раз.
M>А порядок освобождения? А блокировки? А исключения? Для IDisposable такая самодеятельность не прокатит.
Порядок освобождения и блокировки можно так же контролировать атрибутами. Обработка исключений — какая проблема? По спецификации Dispose не должен выбрасывать никаких исключений. Да и в клинических случаях никто не запрещает написать Dispose самостоятельно. Но вот 90% спокойно можно имплементировать единообразно.
M>Ну да, то есть для каждого интерфейса нужно писать расширение. Тогда понятно. Тоже вариант, только такое себе. Как-то не очень вдохновляет
Для интерфейсов, атрибутов и для их комбинаций. Так же как в ATL реализовано что-то подобное для многих интерфейсов COM. Например, можно недельку посидеть и покрыть практически все задачи связанные с маппингом, при этом заметно выиграв в производительности, т.к. сегодня подавляющее число занимающихся этим библиотек реализует это через рефлекшин.
M>По моим очень дилетантским прикидкам, метапрограммирование компиляторов это вопрос, которому нужна серьёзная теоретическая проработка. Ну уровне какой-нибудь докторской диссертации или круче. Народной инициативой тут, никак не обойдёшься.
Да это сколько угодно, хоть обпрорабатывайся, проработка никогда не помешает. Только любая теория без практических исследований так теорией и остаётся.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Шахтер, Вы писали:
IT>>Боюсь что в 98% современных приложений адресная арифметика может пригодится только для прохождения интервью на работу при решении задачки типа переливания строки из пустого в порожнее.
Ш>Современные приложения далеко не ограничиваются тем, чем вы занимаетесь.
К сожалению, всё это многообразие сосредоточено в пяти процентах от общего числа задач, стоящих перед программистами. Остальные 95% это автоматизация той или иной деятельности, которая автоматизируется чем не попадя, начиная от 1C и заканчивая ассемблером.
IT>>Настоящие же индейцы во всю используют смарт-поинтеры и бьют по рукам любого в тиме, кто использует голые указатели. И очень этим гордятся.
Ш>Я, как настоящий истребитель индеёцев, бью по рукам всех в тиме, у кого ручонки тянуться к stl boost loki и.т.п. лабуде.
Я хоть и не любитель stl'ев, но всяческие крайности тоже не уважаю, unless при этом приводятся вполне весомые аргументы, которые я предпочетаю услышать как настоящий истребитель истребителей индейцев
IT>>Вообще же указатели в C++ — это дремучее наследие C, ничего больше.
Ш>Указатели -- один из краеугольных камней C/C++. Тот, кто не умеет ими пользоваться, просто не владеет основами языка, таким людям надо выбирать себе языки попроще, C#, например.
Представь себе, люди пишут вполне достойный код на C++ и при этом не используют указателей. Что касается C, да, там это камень... краеугольный. Понимание механизмов адресной арифметики само по себе весьма полезно, кто бы спорил, 10 лет назад это было даже обязательным, чтобы называться программистом. Но сегодня знание того, что "short *p; p++;" смещает указатель на 2 байта, а "short **p; p++;" на 4, слабо тебе поможет при разработке системы класса предприятия. Здесь нужно знать побольше, причём на много.
Ш>Как показывает опыт, попытка избавиться от ликов с помощью технологических приёмов, не только приводит к чудовищной потере производительности, но и не избавляет от самих ликов.
Да ну? Если не устраивает autoptr, то аналогичный смарт поинтер пишеться за пол часа на коленке. Причём потеря производительности в этом случае будет напрямую зависить только от диаметра кривизны рук разработчика.
Ш>Точно так же, использование готового оконного фреймворка позволяет более или менее быстро и беспроблемно сделать оболочку, соотвествующую идеологии этого фреймворка, но не более того. Ш>Попробуйте, в качестве упражнения, сделать хороший текстовый редактирующий элемент, такого же класса или лучше, как в студии. Если я правильно понял, Янус использует Scintillе-у? А что, свой было влом сделать?
Если мне понадобится хороший тесктовый редактирующий элемент, то я его куплю (open source проекты не в счёт). Будет на много дешевле и быстрее. Писать я его буду только как разработчик библиотеки компонентов.
Ш>Тут надо понимать одну вещь. Человеческий мозг -- гораздо более мощное орудие, чем любой компилятор. Поэтому попытка избавиться от необходимости думать, спихивая свою работу тупой машине, контрпродуктивна.
Человек ещё и хороший бегун, но что-то мало кому приходит в голову бегать на работу каждый день по 10-50 километров. Почему-то люди предпочитают ездить на автобусах, метро и прочих тупых автомобилях.
Ш>Это прокатывает только для определённых классов задач, где можно ограничиться несложным комбинированием простых рецептов. Это то, что можно условно назвать Макдональдс. У Джоела об этом хорошо было написано. Но существование Макдональдсов нисколько не отменяет существование дорогих и качественных ресторанов, где работают не повара, окончившие 21-дневные курсы, а истинные мастера своего дела. Кстати, куда вы водите свою любимую женщину? Неужели в Макдональдс?
Насколько мне известно в некоторых столицах мира Макдональдс — это элитный ресторан
Вообще же аналогия плохая. Программирование всё же ближе к производству, чем к услугам населению, где да, действительно, индпошив рулит. Соответственно, в данном случае лучше подошло бы сравнение современного автоматизированного завода с захудалой частной мастерской, где почти вся работа делается примитивными инструментами типа напильника практически в ручную.
Ш>Насколько я понимаю, MC++ был скороделкой, его вполне можно при этом использовать. Что будет с выходом новой версии C++/CLI и как оно будет выглядеть -- ещё вилами на воде писано. Мне кажеться, лучше дождаться релиза, а тогда и обсуждать, что удачно, что нет.
Согласен. Но что-то мне подсказывает, что handles в нём так и останутся
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Тебе самому это не страшно читать?
Нет. Это стандартная практика при создании кросс-компиляторных библиотек.
VD>Ты не понял главного. Вся нужная информация задается декларативно. Просто весь обвязочный код выносится из рабочего и достраивается компилятором (вернее его расширениями) во время компиляции (вернее на первых стадиях).
Нет это ты не понял.
class MyClass
:IEditable
,ISuperEditable
{
int ID { get; }
string Description { get; set; }
}
Что случатся если оба интерфейса захотят реализовать пустые проперти про своему?
VD>Это нечто вроде шаблонов, но намного более гибких. Ты можешь просто перестраивать код, а не мытариться в рамках одной концепции.
Ну не знаю чем тебе не нравятся шаблоны. Я лично просто пишу логику, а всю грязную работу делает компилятор.
WH>>Опять. С какой базой? Через какого провайдера? VD>Ну, с той что задана в глобальном атрибуте, например.
К какому из десятка серверов в сети цепляться? К какой базе в сервере?
Короче допустим провайдер известен это ADO.NET. Надо подцепиться к серверу [конфиг его знает] на компе [конфиг его знает] к базе [конфиг ее знает] и что-то сделать с таблицей CoolTable ессно это должна быть транзакция.
VD>Что с того толку? Все равно море ручного кодирования. Причем везде и всегда. Плюс глюки от примитивных ошибок и нечитаемый код.....
Влад не обобщай свои проблемы на всех. ATL+stl+boost+20К кода(в основном для того чтобы интерфейс ATL привести к человеческому виду) и получается такой код
Как видишь данный код мало отличается от того что ты предлагаешь
STDMETHODIMP CSRCOMM_OPCGroup::SetDatatypes
(/* [in] */ DWORD dwCount
,/* [size_is][in] */ OPCHANDLE *phServer
,/* [size_is][in] */ VARTYPE *pRequestedDatatypes
,/* [size_is][size_is][out] */ HRESULT **ppErrors
)
try
{
scoped_lock(this);//Декларируем что данный метод надо синхронизировать
com_check (owner_, E_FAIL);//Декларируем проверки
com_check_arg (dwCount>0);//Эта кидает E_INVALIDARG
com_check_ptr (phServer);//Эти E_POINTER
com_check_ptr (pRequestedDatatypes);
com_check_ptr (ppErrors);
com_auto_arr<HRESULT> hr(dwCount);//Елси память не выделена то вылетит E_OUTOFMEMORY
HRESULT res=S_OK;//Дальше чистая логикаfor(DWORD i=0;i<dwCount;++i)
{
if(ref_t<CSRCOMM_OPCGroupItem> item=get_item(phServer[i]))
{
if(FAILED(item->set_type(pRequestedDatatypes[i])))
hr[i]=OPC_E_BADTYPE;
else
hr[i]=S_OK;
}
else
hr[i]=OPC_E_INVALIDHANDLE;
if(FAILED(hr[i]))
res=S_FALSE;
}
//До этой строчки код полностью exception safe
//А дальше им просто взяться не откуда
*ppErrors =hr.detach();
return res;
}
com_catch_all()//Тут ловим исключения _com_error, достаем из него HRESULT и возвращаем
Ну повесишь ты проверки на параметры, а синхронизацию на функцию и что изменится? Проверки переместятся из тела функции в ее описание.
VD>Лучше бы он почитал про OpenC++. Глядишь весь этот огород и не стал бы городить.
Ну что я могу сказать. Не нравится, не ешь.
А что касается OpenC++ то на кой мне сдалася еще один препроцессор? А отлаживать я как это буду?
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, IT, Вы писали:
IT>Боюсь что в 98% современных приложений адресная арифметика может пригодится только для прохождения интервью на работу при решении задачки типа переливания строки из пустого в порожнее. Настоящие же индейцы во всю используют смарт-поинтеры и бьют по рукам любого в тиме, кто использует голые указатели. И очень этим гордятся.
А я спорю? Сам всех про рукам бью если вижу указатель без смартпоинтера.
IT>Какая больше подходит. Решит это компилятор, который будет натренирован тобой.
А! Ну-ну.
IT>>>Здесь я не просто хочу от компилятора добавления соответсвующих методов интерфейса, но так же реализации свойств. Да не просто так, а что бы свойства только возвращали int и string, а внутренне были представлены классами EditableInt32 и EditabelString. WH>>И от куда компилятор об этом узнает? Уж не из факта неследования от IEditable ли? А если бедет интерфейс ISuperEditable? IT>Ну сам подумай, откуда он может это узнать? Откуда ты ему скажешь, оттуда он и узнает. Можно из моего интерфейса, можно из твоего. Они между прочим, совсем не обязаны быть связанными между собой наследованием или чем-то ещё, но вполне оба могут выполнять нужные функции. Можно прикрутить атрибуты, можно наследование. Всё сгодится. Если будет возможность во время компиляции почитать метадату и обработать её средствами превышающими возможности используемого языка, то возможности самого языка от этого только возрастут, за счёт заимствования этой мощи у этих же средств. Типа такая рекурсия, ну ты понял
Я только одного не понял что будет если оба интерфейса захотят реализовать не реализованые протерти?
Ой чую что у народа с этой игрушкой непоняток будет не меньше чем с С++. Они будут другими но их будет не меньше.
ЗЫ МемориЛик: Злое, мифическое существо по словам дотнетчиков обитающие в каждой программе на С++.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
Ш>> Любой апологет хорошего стиля программирования, смартпойнтеров и.т.п. умрёт на месте, увидев те простыни членов в классах, которые там есть.
AVK>Ну и что в этом хорошего? Вот оказалось к примеру что сцинтилла не юникодная, а чтобы переделать ее на уникод надо перелопатить гору кода. ВОт тебе и результат криворукости.
Я не говорю, что это хорошо. Тем более стимул сделать по своему и хорошо. И дать образец хорошего программирования.
Ш>> Если же вы имеете ввиду, зачем свой редактирующий элемент для Януса, ну, например, для виртуального пространства, которое я так люблю
AVK>Чего это?
Возможность перемещать курсор вдоль строки в любую позицию.
Ш>> и для многих других хороших вещей, которые в Scintille отсутсвуют.
AVK>ПОка что все запросы она покрывает с лихвой.
Не покрывает. Код писать на ней очень неудобно. Там какие-то проблемы с отступами появляются. Я пишу код в студии, а потом copy/past ом переношу в Янус. Не очень удобно.
Ш>> Между прочим, отсутствие хорошего компонента редактирования, причем хорошо написанного -- большой пробел Открытых Сырков.
AVK>Закрытых тоже.
Здравствуйте, WolfHound, Вы писали:
VD>>Тебе самому это не страшно читать? WH>Нет. Это стандартная практика при создании кросс-компиляторных библиотек.
Ну, тогда какие могут быть вопросы.
VD>>Лучше бы он почитал про OpenC++. Глядишь весь этот огород и не стал бы городить. WH>Ну что я могу сказать. Не нравится, не ешь.
Не ем. И другим советую не совать в ром что попало.
WH>А что касается OpenC++ то на кой мне сдалася еще один препроцессор? А отлаживать я как это буду?
Насклько я понимаю он генерирует С++-код. Ты не умеешь отлаживать С++ кода? Или ты прос сам герератор? Герератор отлаживают разработчики.
А вот отлаживать шаблоны бывает ой как не просто. Их даже писать менее удбно чем обычный код. Ведь редактор не знает ничего о параметрах типа и стало быть все комплит-ворды и т.п. идут лесом.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mihailik, Вы писали:
IT>>После того как компилятор распарсил код и создал дерево объектов и кода у себя в памяти, он должен вызвать моё расширение, которое сможет проанализировать и при надобности изменить это дерево.
M>Ну да, то есть для каждого интерфейса нужно писать расширение.
Они получаются универсальными. Это нечто вроде шаблонов в XSLT. Ты пишешь преобразование и применяешь его где нужно.
M> Тогда понятно. Тоже вариант, только такое себе. Как-то не очень вдохновляет
А альтернатива есть?
IT>>взаимодействие компилятора и расширений. Если это не закладывать в компилятор с самого начала, то шансов на успех практически никаких.
M>По моим очень дилетантским прикидкам, метапрограммирование компиляторов это вопрос, которому нужна серьёзная теоретическая проработка. Ну уровне какой-нибудь докторской диссертации или круче. Народной инициативой тут, никак не обойдёшься.
А я еще ни разу не видел чтобы в жизнь нкую идею воплтил доктор. Обычно они теорию толкают, а реализацию делают простые смертные (инженеры, программисты). Теоритически все уже довольно ясно. Есть даже некоторые реализации (OpenC++, например). Так что...
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
Ш>Тут надо понимать одну вещь. Человеческий мозг -- гораздо более мощное орудие, чем любой компилятор. Поэтому попытка избавиться от необходимости думать, спихивая свою работу тупой машине, контрпродуктивна. Это прокатывает только для определённых классов задач, где можно ограничиться несложным комбинированием простых рецептов. Это то, что можно условно назвать Макдональдс. У Джоела об этом хорошо было написано. Но существование Макдональдсов нисколько не отменяет существование дорогих и качественных ресторанов, где работают не повара, окончившие 21-дневные курсы, а истинные мастера своего дела. Кстати, куда вы водите свою любимую женщину? Неужели в Макдональдс?
Осталось только доказать, что человеческий мозг, программирование и инфраструктура общественного питания подчиняются одинаковым законам и аналогии между ними являются прямыми (уместными). А пока это, извини, демагогия. Не удивлюсь, если ответом на этот послание кто-нибудь сделает еще одну некоррекнтную аналогию.
Что же касается мозга, то его возможности ограничены. И всю рутинну нужно сваливать на компьютеры. Они собственно для этого и созданы. А мозг должен весь свой потенциал выкладывать там где компьютеры бессильны. Изнаешь, что? Я пока не вижу ситуации при которой для мозга не будет серьезной нагрузки в следствии того, что все задачи переложены на компьютер.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
Ш>Не понял вопроса. Зачем что? Сделать хороший редактирующий элемент в качестве упражнения? Для того, чтобы понять всё нищету фреймворков. Для интереса, посмотрите сорцы Scintille-ы. Любой апологет хорошего стиля программирования, смартпойнтеров и.т.п. умрёт на месте, увидев те простыни членов в классах, которые там есть.
Я писал свой контрол (для КОМ-а) редактирующий код. Он был менее крут нежели Сентила, но тем не менее проблем с кривостью кода не испытывал. Все было по-максимуму безопастно и прилично.
И вообще, как кривость одной реализации может доказывать неверность всего класса или неприенимость чего либо? Ну, должна же быть логика в рассуждениях?
Ш> Если же вы имеете ввиду, зачем свой редактирующий элемент для Януса, ну, например, для виртуального пространства, которое я так люблю
Это уже реализовано в Сентиле.
Ш> и для многих других хороших вещей, которые в Scintille отсутсвуют.
А может проще их туда добавить?
Ты представляешь себе объем кода который нужно написать чтобы получить приличный редактор?
Ш> Между прочим, отсутствие хорошего компонента редактирования, причем хорошо написанного -- большой пробел Открытых Сырков.
А причем тут это? Мы что апологеты Открытых Сурков?
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
Ш>>Как показывает опыт, попытка избавиться от ликов с помощью технологических приёмов, не только приводит к чудовищной потере производительности, но и не избавляет от самих ликов.
IT>Да ну? Если не устраивает autoptr, то аналогичный смарт поинтер пишеться за пол часа на коленке. Причём потеря производительности в этом случае будет напрямую зависить только от диаметра кривизны рук разработчика.
Проблема только в том, что не всегда все можно заменить в самрт-поинтры, да и самрт-поинтры могут пересекаясь давать странные результаты. Но единственым способом избежать ликов в большом приложении написанных на С++, это создать автоматизированную систему их обнаружения. Мы по крайней мере именно так сделали. А вот на Шарпе даже добиться лика трудновато.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Осталось только доказать, что человеческий мозг, программирование и инфраструктура общественного питания подчиняются одинаковым законам и аналогии между ними являются прямыми (уместными). А пока это, извини, демагогия. Не удивлюсь, если ответом на этот послание кто-нибудь сделает еще одну некоррекнтную аналогию.
Ну, считай демагогией.
VD>Что же касается мозга, то его возможности ограничены.
Осмелюсь заметить, что возможности компьютера ещё более ограничены.
VD>И всю рутинну нужно сваливать на компьютеры. Они собственно для этого и созданы.
Правильно.
VD>А мозг должен весь свой потенциал выкладывать там где компьютеры бессильны. Изнаешь, что? Я пока не вижу ситуации при которой для мозга не будет серьезной нагрузки в следствии того, что все задачи переложены на компьютер.
Здравствуйте, VladD2, Вы писали:
Ш>> Если же вы имеете ввиду, зачем свой редактирующий элемент для Януса, ну, например, для виртуального пространства, которое я так люблю
VD>Это уже реализовано в Сентиле.
Да ну? Что то никак не получается зайти курсором за конец строки.
Ш>> и для многих других хороших вещей, которые в Scintille отсутсвуют.
VD>А может проще их туда добавить?
VD>Ты представляешь себе объем кода который нужно написать чтобы получить приличный редактор?
Да, хорошо представляю.
Ш>> Между прочим, отсутствие хорошего компонента редактирования, причем хорошо написанного -- большой пробел Открытых Сырков.
VD>А причем тут это? Мы что апологеты Открытых Сурков?
Существует проблема. Есть задача, которую хотелось бы иметь решённой. Грубо говоря, есть спрос на рынке. Именно потому, что её решение достаточно дорогое в смысле требуемых усилий. А с другой стороны, есть, скажем, редактор студии. Он меня вполне удовлетворяет. А вставить его в своё приложение я не могу. И вы в Янус не можете.
Здравствуйте, Шахтер, Вы писали:
Ш>Да ну? Что то никак не получается зайти курсором за конец строки.
Это насраивается. По крайней мере я вроде читал в фича-листе.
Ш>Да, хорошо представляю.
Значит не очень, раз такие вещи говоришь.
Ш>Существует проблема.
Только в твоей голове.
Ш> Есть задача, которую хотелось бы иметь решённой.
Только тебе.
Ш> Грубо говоря, есть спрос на рынке.
Спрос удовлетворен.
Ш> Именно потому, что её решение достаточно дорогое в смысле требуемых усилий.
Глупость и полная алогичность. Спрос никак не может определять дороговизну и сложность производства.
Ш> А с другой стороны, есть, скажем, редактор студии. Он меня вполне удовлетворяет. А вставить его в своё приложение я не могу. И вы в Янус не можете.
И? Нам более чем достаточно Синтилы.
В общем, я так и не понял причем тут синтила. Ты про сабж то не забыл?
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
Ш>Я не говорю, что это хорошо. Тем более стимул сделать по своему и хорошо. И дать образец хорошего программирования.
Все же ты плохо представляешь объем работ. Такие вещи в качестве примера не делаются.
Ш>Не покрывает. Код писать на ней очень неудобно. Там какие-то проблемы с отступами появляются. Я пишу код в студии, а потом copy/past ом переношу в Янус. Не очень удобно.
И какие же проблемы?
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
VD>>Что же касается мозга, то его возможности ограничены.
Ш>Осмелюсь заметить, что возможности компьютера ещё более ограничены.
Они не "ещё более ограничены", они другие. Причем компьютерные возможности — это всегда вопрос денег и времени. А вот возможности человеческого мозга ограничены принципиальными особенностями. И взваливать на них работу которою им можно не делать прото бессмысленно.
VD>>И всю рутинну нужно сваливать на компьютеры. Они собственно для этого и созданы.
Ш>Правильно.
А к чему ты призываешь? Прочитай свои слова еще раз. Может ты хотел сказать нечто другое?
VD>>А мозг должен весь свой потенциал выкладывать там где компьютеры бессильны. Изнаешь, что? Я пока не вижу ситуации при которой для мозга не будет серьезной нагрузки в следствии того, что все задачи переложены на компьютер.
Ш>И это правильно.
Ну, тогда не понятно как может быть правильно это:
Тут надо понимать одну вещь. Человеческий мозг -- гораздо более мощное орудие, чем любой компилятор. Поэтому попытка избавиться от необходимости думать, спихивая свою работу тупой машине, контрпродуктивна.
Ведь это напрямую противоричит моим словам. Всю работу которую можно спихнуть на компьютер — нужно на него спихивать. Отсюда и компиляторы должны быть интелектуальнее, и языки более простыми и информативными.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
