http://www.delphifeeds.com/go/f/111926?utm_source=dlvr.it&utm_medium=facebook
Что сказать? Интересно конечно.. забавно.. круто.. Уважаю.
Но я для всего этого использую UML и кодогенерацию.
Там "поменял сигнатуру виртуальной функции" и сразу автоматом поменялись 135-ть override'ов в других модулях.
Или поменял "метод генерации String на WideString" и поменялось в 1024-х модулях.
Про примеси, синглетоны, publisher/subscriber, а также итераторы и тестовую аксиоматику, а также "автоматические" IfDef и секции uses - так вообще молчу...
А что касается разделения на "секцию интерфейса" и "секцию реализации". Так это вообще - "ДИКОСТЬ". Давно пора сделать если не язык, то редактор, который сам автоматически их синхронизирует. Ну 21-й век на дворе...
Что ещё сказать?
Вот в xCode и Objective-C мне крайне НРАВИТСЯ, что приватные методы можно не объявлять в интерфейсной секции класса. А в C++ нравится, что реализацию методов можно писать прямо в h-файлах. Правда они при этом делаются inline. Но это не беда. Особенно при современных гигагерцах и терабайтах.
А вообще говоря - "скрестить" бы все "эти подходы", не забывая про UML.
А ещё бы я ввёл квалификатор метода - notvirtual. По аналогии с virtual, final (sealed). Хочешь - ставь квалификатор. Но! Это ТВОЁ ОСОЗНАННОЕ решение, а иначе - пусть компилятор разбирается.
И ещё.. По мотивам - http://programmingmindstream.blogspot.ru/2014/01/freeandnil.html?showComment=1389911523375#c3709559021046326060
По-моему уже назрела НЕОБХОДИМОСТЬ в синергии языковых подходов.
Скажу КРАМОЛЬНУЮ мысль! По-моему надо (китам индустрии) уже договориться и сделать УЖЕ один "КОШЕРНЫЙ" язык. Учитывающий особенности многообразия.
Я конечно понимаю - "конкуренция и всё такое" :-)
Меня конечно сочтут "мечтателем" и "велосипедоизобретателем"...
Но я продолжу...
Ещё бы конечно здорово базировать этот КОШЕРНЫЙ ОБЩИЙ язык на графическом представлениии. Ну типа UML. А лучше - "чертежей". Почему?
Отвечу. Я писал вот тут - http://programmingmindstream.blogspot.ru/2014/01/uml.html
Лично для меня код представляется "разноцветными квадратами и стрелками".
Моторика работы такая, что я "вижу разноцветные пятна" и двигаю мышь в "нужный мне угол". Ну как с иконками на "рабочем столе".
Ответ - "я и так помню где в коде что находится" - не катит. Я САМ - УНИКАЛЬНЫЙ РАЗРАБОТЧИК (без ложной скромности) - я ПОМНЮ где и что находится в 15 млн строк кода. Не верите? Спросите моих коллег. Ну если вы такой же "УНИКУМ" и пытаетесь спорить - то наверное тут мы не найдём общий язык. Видимо у вас "свой путь", а у меня - свой.
Продолжу.
И даже если я работаю с диаграммой на которой - "более ста элементов" (как например вот тут - http://18delphi.blogspot.ru/2013/09/blog-post_1303.html. За что меня уважаемый мною NameRec долго "бил ногами") - этот подход всё равно работает.
Поверьте мне НА СЛОВО.
Моторику не обманешь.
Я НЕ ДУМАЮ - "а где этот элемент находится", я ПРОСТО "кидаю мышь в ту или иную сторону - в которую мне подсказывает моя моторика". Иногда - ПРОМАХИВАЮСЬ. Но! ОЧЕНЬ РЕДКО.
Но тут "дистанционно" я конечно "никого не убежу". Тут надо "опыт" и "понимание принципов работы". А иначе про "коня в вакууме" можно БЕСКОНЕЧНО спорить.
Надо ПОКАЗЫВАТЬ - "как оно работает". Как? Пока - НЕ ЗНАЮ. А надо ли?
Что до "программирования" и IDE "нового поколения" (http://programmingmindstream.blogspot.ru/2013/12/ide.html), то я себе мыслю это так:
Это не "разрозненный набор тулзов, тулзочек и утилит", а нечто "монолитное и целостное". Ну скажем Eclipce - отчасти является "примером для подражания". Но лишь ПРИМЕРОМ.
Китам индустрии надо сделать "что-то такое", что с одной стороны держит программиста в рамках:
1. ТЗ
2. Внешнего дизайна (скриншотов)
3. Модели. UML или "чертежей" (тут уж как получится)
4. Набора тестов (связанных в итоге с ТЗ и внешним дизайном)
А с другой стороны, подталкивающее программиста к использованию:
1. Аспектов и примесей
2. Шаблонов проектирования
3. Инструкции программирования (в конце концов)
Я для себя лично в "текущей разработке" выделяю четвёрку:
1. ТЗ
2. Модель
3. Код
4. Тесты
Но! Почему бы не пойти дальше?
Скажем так... "Атлас машин и механизмов" или "номенклатура микросхем".
Скажете - "это всё было.. компонентный подход и всё такое".
Конечно!
А ещё раньше были БИБЛИОТЕКИ.
Но! На дворе же - 21-й век.
Надо же "двигаться дальше".
Сделать что-то вроде - http://programmingmindstream.blogspot.ru/2013/12/blog-post_5331.html но не "на закорючках", а для "нормальных людей".
Это я всё к чему?
Ну "ГЛУПО" думать о "синхронизации прототипов функций" в "интерфейсной" части и части реализации. Ну ГЛУПО!
21-й век на дворе.
Век терабайтов и гигагерц.
Надо УЖЕ ДУМАТЬ о вещах более ВЫСШЕГО ПОРЯДКА.
Не о строках кода, а о "цветных квадратах" и "стрелках между ними" как минимум.
Что сказать? Интересно конечно.. забавно.. круто.. Уважаю.
Но я для всего этого использую UML и кодогенерацию.
Там "поменял сигнатуру виртуальной функции" и сразу автоматом поменялись 135-ть override'ов в других модулях.
Или поменял "метод генерации String на WideString" и поменялось в 1024-х модулях.
Про примеси, синглетоны, publisher/subscriber, а также итераторы и тестовую аксиоматику, а также "автоматические" IfDef и секции uses - так вообще молчу...
А что касается разделения на "секцию интерфейса" и "секцию реализации". Так это вообще - "ДИКОСТЬ". Давно пора сделать если не язык, то редактор, который сам автоматически их синхронизирует. Ну 21-й век на дворе...
Что ещё сказать?
Вот в xCode и Objective-C мне крайне НРАВИТСЯ, что приватные методы можно не объявлять в интерфейсной секции класса. А в C++ нравится, что реализацию методов можно писать прямо в h-файлах. Правда они при этом делаются inline. Но это не беда. Особенно при современных гигагерцах и терабайтах.
А вообще говоря - "скрестить" бы все "эти подходы", не забывая про UML.
А ещё бы я ввёл квалификатор метода - notvirtual. По аналогии с virtual, final (sealed). Хочешь - ставь квалификатор. Но! Это ТВОЁ ОСОЗНАННОЕ решение, а иначе - пусть компилятор разбирается.
И ещё.. По мотивам - http://programmingmindstream.blogspot.ru/2014/01/freeandnil.html?showComment=1389911523375#c3709559021046326060
По-моему уже назрела НЕОБХОДИМОСТЬ в синергии языковых подходов.
Скажу КРАМОЛЬНУЮ мысль! По-моему надо (китам индустрии) уже договориться и сделать УЖЕ один "КОШЕРНЫЙ" язык. Учитывающий особенности многообразия.
Я конечно понимаю - "конкуренция и всё такое" :-)
Меня конечно сочтут "мечтателем" и "велосипедоизобретателем"...
Но я продолжу...
Ещё бы конечно здорово базировать этот КОШЕРНЫЙ ОБЩИЙ язык на графическом представлениии. Ну типа UML. А лучше - "чертежей". Почему?
Отвечу. Я писал вот тут - http://programmingmindstream.blogspot.ru/2014/01/uml.html
Лично для меня код представляется "разноцветными квадратами и стрелками".
Моторика работы такая, что я "вижу разноцветные пятна" и двигаю мышь в "нужный мне угол". Ну как с иконками на "рабочем столе".
Ответ - "я и так помню где в коде что находится" - не катит. Я САМ - УНИКАЛЬНЫЙ РАЗРАБОТЧИК (без ложной скромности) - я ПОМНЮ где и что находится в 15 млн строк кода. Не верите? Спросите моих коллег. Ну если вы такой же "УНИКУМ" и пытаетесь спорить - то наверное тут мы не найдём общий язык. Видимо у вас "свой путь", а у меня - свой.
Продолжу.
И даже если я работаю с диаграммой на которой - "более ста элементов" (как например вот тут - http://18delphi.blogspot.ru/2013/09/blog-post_1303.html. За что меня уважаемый мною NameRec долго "бил ногами") - этот подход всё равно работает.
Поверьте мне НА СЛОВО.
Моторику не обманешь.
Я НЕ ДУМАЮ - "а где этот элемент находится", я ПРОСТО "кидаю мышь в ту или иную сторону - в которую мне подсказывает моя моторика". Иногда - ПРОМАХИВАЮСЬ. Но! ОЧЕНЬ РЕДКО.
Но тут "дистанционно" я конечно "никого не убежу". Тут надо "опыт" и "понимание принципов работы". А иначе про "коня в вакууме" можно БЕСКОНЕЧНО спорить.
Надо ПОКАЗЫВАТЬ - "как оно работает". Как? Пока - НЕ ЗНАЮ. А надо ли?
Что до "программирования" и IDE "нового поколения" (http://programmingmindstream.blogspot.ru/2013/12/ide.html), то я себе мыслю это так:
Это не "разрозненный набор тулзов, тулзочек и утилит", а нечто "монолитное и целостное". Ну скажем Eclipce - отчасти является "примером для подражания". Но лишь ПРИМЕРОМ.
Китам индустрии надо сделать "что-то такое", что с одной стороны держит программиста в рамках:
1. ТЗ
2. Внешнего дизайна (скриншотов)
3. Модели. UML или "чертежей" (тут уж как получится)
4. Набора тестов (связанных в итоге с ТЗ и внешним дизайном)
А с другой стороны, подталкивающее программиста к использованию:
1. Аспектов и примесей
2. Шаблонов проектирования
3. Инструкции программирования (в конце концов)
Я для себя лично в "текущей разработке" выделяю четвёрку:
1. ТЗ
2. Модель
3. Код
4. Тесты
Но! Почему бы не пойти дальше?
Скажем так... "Атлас машин и механизмов" или "номенклатура микросхем".
Скажете - "это всё было.. компонентный подход и всё такое".
Конечно!
А ещё раньше были БИБЛИОТЕКИ.
Но! На дворе же - 21-й век.
Надо же "двигаться дальше".
Сделать что-то вроде - http://programmingmindstream.blogspot.ru/2013/12/blog-post_5331.html но не "на закорючках", а для "нормальных людей".
Это я всё к чему?
Ну "ГЛУПО" думать о "синхронизации прототипов функций" в "интерфейсной" части и части реализации. Ну ГЛУПО!
21-й век на дворе.
Век терабайтов и гигагерц.
Надо УЖЕ ДУМАТЬ о вещах более ВЫСШЕГО ПОРЯДКА.
Не о строках кода, а о "цветных квадратах" и "стрелках между ними" как минимум.
Кашрут как средства прекращения (или начала) священной войны.
ОтветитьУдалитьХорошо, что Александр "внёс" нас в поле реальности (а не "искажения реальности по Джобсу", оффтоп, iPhone 6 как-то совсем уж канонизировал дизайн). Как-то я переводил выступление Бьерна Страуструпа - http://www.youtube.com/watch?v=0hZcVnUYmzY у нас на CodeRage по C++11. Ожидал "скучнятины" и традиционно-патерналистских заявлений "папа обо всё позаботился" и "жить стало лучше, жить стало веселей".
Но! Бьернушка наш Страуструп (в этот раз) показал абсолютную беспонтовость и честность на тему "вендорам договориться". Вполне себе прямо заявил, что это - в масштабах вселенского проекта - "кашерного язык" - вещь сложно достижимая, т.к. понятие "совместимость" тащит нас голым задом не только вниз по покатым доскам недостроенной избы всеобщего IT-благоденствия, но и вверх (супротив законов физики - совместимость "вниз" - написали на новом, компилируем на старом). Это я к тому, что уж вроде бы там, где все изначально единоверцы (С, С++... SQL :)), договориться ооооочень сложно. Бьернушка так и сказал - не дам спекулировать своим авторитетом! Не надо меня перетягивать как удава! Но чем он меня поразил (еще раз) - беспонтовостью. Так и сказал - не "переговорщик я, тем более не координатор... не ЛИДЕР". Я могу блюстию чистоту/эволюцию языка, но увольте меня с дипломатическо-организационной роли. "Эта роль - ругательная, ко мне прошу её не применять".
теперь немножко "свежих сплетен из Embarcadero"
ОтветитьУдалитьПустили мы "новый компилятор". Ну там "новый" он такой... ступенчатый. Фаршируешь гуся гречневой кашей потихоньку - гусь новым с каждой ложкой не становится. Но когда я собирался сказать "в Delphi 2010 доступен новый компилятор с новой RTTI" (напомню, что RTTI в Delphi был всегда, только изначально он поддерживал лишь RAD-концепцию, читай "пропертя", а в 2010 он стал типа "общечеловеческим"... лицо стало человечнее, а RTTI нужно для построения фреймворков). На этой фразе меня начальник отвёл в сторону и попросил "не говори слово "новый" компилятор. никогда не говори". Почему? Стремаются девелоперы от слова "новый компилятор". Это означает, что новая версия подтянет сложнопредсказуемый по объему пул задач по апгрейду сорцов. Компилятор НИКОГДА не должен быть новым. Только обновлённым.
Иначе "новую версию дельфей" никто не купит. Деньги - содержимое бензобака машины IT-индустрии. С пустыми баками машина не поедет. Разве что инерция поможет. Энергия движения переходит в быстропрожираемую тепловую энергию теплокровных сотрудников компании.
Ну а чисто по-человечески...
ОтветитьУдалитьДействительно реформаторская идея... получит ли поддержку? Или "нас и тут неплохо кормят". Я про разработчиков. Или очередной скандал как с FreeAndNil?
Скажу КРАМОЛЬНУЮ мысль! По-моему надо (китам индустрии) уже договориться и сделать УЖЕ один "КОШЕРНЫЙ" язык.
ОтветитьУдалитьhttp://dannycomputerscientist.files.wordpress.com/2013/04/xkcd-sandards.png
:)
>Сделать что-то вроде - http://programmingmindstream.blogspot.ru/2013/12/blog-post_5331.html но не "на >закорючках", а для "нормальных людей".
ОтветитьУдалитьТак оно и есть "для нормальных людей". И "закорючек" там не больше, чем везде. Так в чём проблема?