Прыжки по коду
От: licedey  
Дата: 12.12.16 17:26
Оценка:
Дело в том, что почти всегда над проектом я работаю в одиночку. Проекты разной величины, ну скажем самые большие занимают год-полтора.
Так вот суть в чем. Я понимаю, что уже сто лет как напридумывали всяких редмайнов, джир и фабрикаторов, со скрам бордами через плечо.
НО! Заказчик пишет — я хочу такую то фичу, она должна свистеть, а сзади у нее должен быть красненький мотор. Он уложился в три строки. И вроде с виду
все понятно, думаешь, тю, легкотня на пару дней. НО! Начинаешь писать код, разбивать его на классы, потом на свойства, методы. Доходя до реализации,
которых, далеко углубляешься в дебри кода, соблюдение этих солид принципов и прочьего, что вчерашняя легкотня, превращается в монстрообразное мессиво
которое практически выходит из под контроля.

А выходит из под контроля почему? Потому что держать в голове его не удается. Например у меня 200 файлов с классами, в них в общей сложности 2000 методов и свойств,
а человек, насколько я знаю может держать в голове до 9 сущностей. ОК, в IDE все перед глазами и хоткеями можно перейти к нужному месту этого монстра.
НО! Заказчик говорит, а я хочу еще вот такую зелененькую свистелку сбоку.

В общем, чтобы не растекаться мыслью по древу, перейду к вопросу. У вас есть монстр, у вас есть задача. Между ними — пропасть реализации. Как удержать в голове и реализовать все микрозадачи?
Обычный процесс кодинга идет примерно так (по себе сужу). Вам надо создать класс (в нужной папке), создать в нем свойства, затем связать это с UI, потом поправить класс Settings, чтобы он учитывал внесенные изменения, в другом классе создать объект, перейти в нужный метод итд. В общем случае, мы постоянно прыгаем по коду. Огромному неуправляемому. И как проще сделать, чтобы эти прыжки были более продуктивными и не напрягали весь мозг.

Вот мой пример, что для этого делаю я. У меня есть мультизадача, или сверхзадача, которую обозначил заказчик (хотите менеджер). Разумеется я разбиваю ее на более мелкие подзадачи. И далее, исходя из них я начинаю кодить. Но тут и приходиться запинаться все время. Прыг в UI, прыг в конфиги, прыг в класс модели, прыг в класс view-модели,
назад в UI. И этот процесс цикличен. Между этими прыжками, можно потерять какую-либо деталь и вообще улететь в космос, размышляя о бытие.
Вобщем я пишу все в блокнот, все эти микрозадачи, и при каждом прыжке лезу в заметки, чтобы не забыть. У вас как?

p.s. сейчас мне представляется эта картинка из фильмов про хакеров, когда хакер бешено кодит и за 62 секунды у него получается прога. А еще, часто
на слуху в IT-блогах проскальзывает "состояние потока". Что это за состояние, когда тебе надо контролить уйму деталей? Писать все в один файл как emacs.c?
Re: Прыжки по коду
От: Evgeny.Panasyuk Россия  
Дата: 12.12.16 17:45
Оценка: 2 (1)
Здравствуйте, licedey, Вы писали:

L>Вобщем я пишу все в блокнот, все эти микрозадачи, и при каждом прыжке лезу в заметки, чтобы не забыть. У вас как?


Раньше писал в обычный текстовый файл — то есть да, блокнот.
Сейчас использую Org-mode — по сути те же самые текстовые файлы, но с минимальной структурой: иерархичеными пунктами, гиперссылками (в том числе и на конкретный кусок файла, в том числе и на файлы на удалённой машине через несколько ssh-туннелей), изображениями, интерактивными кусками кода на разных языках.

https://www.youtube.com/watch?v=dljNabciEGg
Отредактировано 12.12.2016 22:34 Evgeny.Panasyuk . Предыдущая версия .
Re: Прыжки по коду
От: Sinix  
Дата: 12.12.16 18:00
Оценка: +1
Здравствуйте, licedey, Вы писали:

L>Вобщем я пишу все в блокнот, все эти микрозадачи, и при каждом прыжке лезу в заметки, чтобы не забыть. У вас как?


Старый добрый принцип "слона едят по кусочкам". Разбиваем любую фичу на микрофичи (максимум на полдня работы каждая, обычно меньше) таким образом, чтобы по завершению каждой у нас был рабочий код. Рабочий — это не в смысле полностью функциональный, это в смысле всё, что доступно пользователю, является рабочим или прикрыто заглушкой. На микрофичу заводится отдельный тикет (подтикет, если ваш issue tracker такое умеет), дальше всё как обычно.

Конкретный способ разбиения зависит от команды, опыта разработчика, архитектуры и тыды и тыпы и подбирается по ходу дела, с третьей-пятой попытки обычно выстраивается рабочая схема. Оформляем по ней чеклист — готово.
Если разбиение систематически не получается — ну, вот вы и узнали, что такое технический долг

И да, пара сотен файлов — ни о чём. Разумеется, если у вас вменяемая система именования и IDE, которая умеет в моментальный глобальный поиск по произвольной части имени.

L>А еще, часто на слуху в IT-блогах проскальзывает "состояние потока".

Состояние, когда удаётся удерживать в кратковременной памяти все детали по текущей задаче. Переоценено, т.к при должном уровне опыта переключение с контекста на контекст не представляет особой проблемы. Особенно если прокачать скилл "отвечать угу/ага/давай позже, не вслушиваясь в вопрос"
Отредактировано 12.12.2016 18:09 Sinix . Предыдущая версия .
Re: Прыжки по коду
От: Философ Ад http://vk.com/id10256428
Дата: 12.12.16 18:17
Оценка: 2 (1)
Здравствуйте, licedey, Вы писали:

L>...Начинаешь писать код, разбивать его на классы, потом на свойства, методы. Доходя до реализации,

L>которых, далеко углубляешься в дебри кода, соблюдение этих солид принципов и прочьего, что вчерашняя легкотня, превращается в монстрообразное мессиво
L>которое практически выходит из под контроля.

L>А выходит из под контроля почему? Потому что держать в голове его не удается. Например у меня 200 файлов с классами, в них в общей сложности 2000 методов и свойств,

L>а человек, насколько я знаю может держать в голове до 9 сущностей. ОК....


Все эти SOLID придумали не для религиозных ритуалов — это методы борьбы со сложностью. Нужно абсолютно точно понимать что значит каждая буква в это аббревиатуре, и зачем всё это, потому что иначе вместо уменьшения сложности ты получишь её увеличение.

L>..., в IDE все перед глазами и хоткеями можно перейти к нужному месту этого монстра...


Не нужно, не надо всё перед глазами — всё в твой мозг всё равно не влезет. Вместо этого стой системы так, чтобы всю систему ты мог схематически изобразить семью фигурами структурной схеме (каждый квадратик или кружочек на схеме — какая-то подсистема). Далее строй так, чтобы каждая подсистема могла быть изображена семью фигурками на плоскости и т.д. При таком подходе массивы каких-нибудь элементов должны представлять из себя отдельную фигурку: массив виртуальных машин в клауде, массив хранилищ данных, массив схем в БД, массив элементов данных.... После этого не допускай бардака, чтобы искать не приходилось. Т.е. нельзя допускать, например, чтобы элементы UI оказались среди элементов данных.
Соблюдая эти принципы ты избежишь излишней сложности: на каждом шаге тебе придётся оперировать небольшим множеством сущностей. Это намного, НАМНОГО лучше, чем когда перед глазами абсолютно всё одновременно.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[2]: Прыжки по коду
От: Sinix  
Дата: 12.12.16 18:29
Оценка:
Здравствуйте, Философ, Вы писали:

Ф>Далее строй так, чтобы каждая подсистема могла быть изображена семью фигурками на плоскости и т.д.

Вот я бы не стал рекомендовать ничего подобного, т.к в большинстве случаев подобные хитрые схемы вырождаются в слепой карго-культ в стиле трёх сигм или ещё какой мутотени.

Подсмотрите опыт у профессий, где импровизация идёт вперемешку с типовыми процедурами и цена ошибки действительно высока — буквально везде safety checklist / SOP (Standard Operating Procedures). Для сложных задач — наборы SOP с изолированным контекстом (т.е. знать что-либо про остальные SOPы не требуется, всё содержится в самом списке).

P.S: не забываем, что чеклист — это не инструкция, а шпаргалка в стиле "чего тут можно сделать".
Re: Прыжки по коду
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 12.12.16 18:31
Оценка:
Здравствуйте, licedey, Вы писали:

L>А выходит из под контроля почему?


Потому, что фичи нужные заказчику размазаны по коду. Они не обязательно существуют в виде класса, метода и его части, но могут включать в себя куски в одних и тех же или разных файлах. Именно поэтому нужен функционал по CRUD, который позволяет выделять и объединять разные куски кода для выполнения этих операций. Это абсолютно тоже самое, что и SQL DML в базах данных или REST в сети, только для кода.

Как-то писал уже про модифицируемость кода и отсечение целей, хотя по хорошему данные о выделениях должны храниться вне кода. На самом деле это чисто программная проблема, ведь выделение это по сути положение и размер, а файл однозначно идентифицируется с помощью хеш-сумм. Группы выделений в файлах как раз и будут составлять необходимую фичу. Подобный функционал не встречал ни в редмайне, ни в какой-нибудь IDE, следовательно при всей своей навороченности программ фундаментальные проблемы программистов так и не решены.
Re[2]: Прыжки по коду
От: Sinix  
Дата: 12.12.16 19:02
Оценка:
Здравствуйте, velkin, Вы писали:

V>Подобный функционал не встречал ни в редмайне, ни в какой-нибудь IDE, следовательно при всей своей навороченности программ фундаментальные проблемы программистов так и не решены.

Blame в svn/git/... + интеграция с issue-трекером?
Re[3]: Прыжки по коду
От: Философ Ад http://vk.com/id10256428
Дата: 12.12.16 19:04
Оценка: +1
Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Философ, Вы писали:


Ф>>Далее строй так, чтобы каждая подсистема могла быть изображена семью фигурками на плоскости и т.д.

S>Вот я бы не стал рекомендовать ничего подобного, т.к в большинстве случаев подобные хитрые схемы вырождаются в слепой карго-культ в стиле трёх сигм или ещё какой мутотени.

К сожалению твоя общая рекомендация "есть слона по кусочкам" часто приводит к тому, что каждый кусочек слона связан с миллиардом других кусочков слона, и даже просто добраться до кусочка 1ACE8 составляет проблему, не говоря уже о том, чтобы его поправить так, чтобы весь слон при этом не рассыпался. Моя основная мысль заключалась в том, что нужно оперировать разумным кол-вом кусочков за раз. А этого можно добиться только иерархическим проектированием этого самого слона.

S>Подсмотрите опыт у профессий, где импровизация идёт вперемешку с типовыми процедурами и цена ошибки действительно высока — буквально везде safety checklist / SOP (Standard Operating Procedures). Для сложных задач — наборы SOP с изолированным контекстом (т.е. знать что-либо про остальные SOPы не требуется, всё содержится в самом списке).


Такие чек-листы писались чьей-то кровью. Там каждый пункт — чья-то инвалидность или жизнь. Сомневаюсь, что ТС готов составить такой списочек. Так что тут больше подходят инженерные подход, типа проектирования сверху вниз.
Всё сказанное выше — личное мнение, если не указано обратное.
Отредактировано 12.12.2016 19:05 Философ . Предыдущая версия .
Re[3]: Прыжки по коду
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 12.12.16 19:40
Оценка:
Здравствуйте, Sinix, Вы писали:

V>>Подобный функционал не встречал ни в редмайне, ни в какой-нибудь IDE, следовательно при всей своей навороченности программ фундаментальные проблемы программистов так и не решены.

S>Blame в svn/git/... + интеграция с issue-трекером?

У меня все проекты в гите, да и с тем же редмайном знаком, более того, всё это связано вместе. Потому и говорю, что проблему "прыжков по коду" это не решает. Предположим есть фича 342 "ляляляляля ляляля ляляляля ляляляляляля". И мне нужна по коду операция Read в CRUD, она же Select в базах данных и так далее. Вот так фича 342 выглядит в файлах:

файл 134:
ляляляляля
    ляляляляляляляля
        лялялялялял
    ляляляляляляляляляляляляляляля
ляляляляляляляляляля
ляляляляляляляляляля

файл 173:
ляляля
ляля
лялялялялял
    лялялялял
    ляляляляляляляляляля
ляляляляляляля

файл 231:
ляляляляля
ляляляляляляляляляля
ляляляляля

То есть при нажатии на фичу нужно открыть файлы где она находится и выделить нужный код. Более того, фича может пересекаться с другими фичами, отсюда нельзя накладывать ограничения на пересечения выделений кода с другими фичами, что в принипе упрощает дело по созданию такой программы.

А теперь представим, что такой информации нет. Вопрос, откуда программист возьмёт знания о том, что фича 342 "ляляляляля ляляля ляляляля ляляляляляля" заложена именно в этих строчках кода. Конечно, можно проанализировать код и догадаться, но это опять же говорит о том, что часть информации о разработке была потеряна.
Re[4]: Прыжки по коду
От: Sinix  
Дата: 12.12.16 19:43
Оценка:
Здравствуйте, Философ, Вы писали:


Ф>К сожалению твоя общая рекомендация "есть слона по кусочкам" часто приводит к тому, что каждый кусочек слона связан с миллиардом других кусочков слона,


Есть такое дело, но это скорее к процессу разработки в целом вопросы, а не к проблеме топикстартера. Я ж не зря писал про "зависиот от команды/проекта/etc" Для наших проектов великолепно работает примерно такое комбо:
1. Нужен устоявшийся процесс разработки с микроитерациями
2. Обязательно использовать проектирование по реальным сценариям использования.
3. Не пренебрегать разделением ответственностей.
4. Следить за техническим долгом.

Если всё это выполнено — дальше никаких проблем. Если нет — требуйте замены слона, этот поломался.

Про разделение ответственностей при проектировании недавно расписывал, тынц
Автор: Sinix
Дата: 03.11.16
и тынц
Автор: Sinix
Дата: 20.01.16
. В первой ссылке есть пара реальных топиков-примеров, чтоб было понятно, о чём речь.


Ф>и даже просто добраться до кусочка 1ACE8 составляет проблему, не говоря уже о том, чтобы его поправить так, чтобы весь слон при этом не рассыпался.

Ну, мне рабочий проект в таком состоянии не попадался (нерабочих было сколько угодно, но мы их сначала воскрешали, а затем уже лепили фичи), так что как быть с таким зомби — идей никаких.



S>>Подсмотрите опыт у профессий, где импровизация идёт вперемешку с типовыми процедурами и цена ошибки действительно высока — буквально везде safety checklist / SOP (Standard Operating Procedures).

Ф>Такие чек-листы писались чьей-то кровью. Там каждый пункт — чья-то инвалидность или жизнь. Сомневаюсь, что ТС готов составить такой списочек. Так что тут больше подходят инженерные подход, типа проектирования сверху вниз.

+1. Тут необязательно дословно перенимать, идею уж точно можно позаимствовать. Если речь про разработку типовых вещей, как у топикстартера, то можно и без крови обойтись. Просто расписать текстом что делается прямо в процессе работы и ужать до 5-10 пунктов.
Здорово упрощает работу, т.к. в каждый отдельный момент времени в голове можно держать только часть задачи и сразу выбрасывать эту часть при переходе к следующему пункту. Не надо скакать обратно в проверках "что забыл" — уменьшается пространство состояний — меньше стресс. Анекдот про "мы меееедленно спустимся с горы" в действии
Re[4]: Прыжки по коду
От: Sinix  
Дата: 12.12.16 19:58
Оценка:
Здравствуйте, velkin, Вы писали:

V>А теперь представим, что такой информации нет. Вопрос, откуда программист возьмёт знания о том, что фича 342 "ляляляляля ляляля ляляляля ляляляляляля" заложена именно в этих строчках кода. Конечно, можно проанализировать код и догадаться, но это опять же говорит о том, что часть информации о разработке была потеряна.


Да отлично оно работает. Главное не забывать указывать номер коммита в issue tracker, по хронике потом восстановить кто, куда и чего труда не составляет.

Ну и не смешивать в одном коммите/куске кода несколько ответственностей, чтобы правки по несвязанным задачам не перезатирали друг друга.
Re[2]: Прыжки по коду
От: licedey  
Дата: 12.12.16 21:23
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, licedey, Вы писали:


L>>Вобщем я пишу все в блокнот, все эти микрозадачи, и при каждом прыжке лезу в заметки, чтобы не забыть. У вас как?


S>Старый добрый принцип "слона едят по кусочкам". Разбиваем любую фичу на микрофичи (максимум на полдня работы каждая, обычно меньше) таким образом, чтобы по завершению каждой у нас был рабочий код. Рабочий — это не в смысле полностью функциональный, это в смысле всё, что доступно пользователю, является рабочим или прикрыто заглушкой. На микрофичу заводится отдельный тикет (подтикет, если ваш issue tracker такое умеет), дальше всё как обычно.


Слона то я съедаю на завтрак, обед и ужин. Я больше хотел узнать про инструменты. Выше Евгений привел пример одного. Я еще пользуюсь Help&Manual, что структурировать инфу, составлять свой knowledgebase.
Вы посмотрите сколько людей стонут в разделе Работа
  кхм
(голосом Жириновского)

, что они не могут справится с этой махиной которая досталась им от прошлого пейсателя.

Из ваших слов, решение — issue tracker, остальное решит мозг?
Re[5]: Прыжки по коду
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 12.12.16 21:29
Оценка: 3 (1) +2
Здравствуйте, Sinix, Вы писали:

S>Да отлично оно работает. Главное не забывать указывать номер коммита в issue tracker, по хронике потом восстановить кто, куда и чего труда не составляет.

S>Ну и не смешивать в одном коммите/куске кода несколько ответственностей, чтобы правки по несвязанным задачам не перезатирали друг друга.

Дело не в коммитах и уж тем более не в том кто и что записал, ведь именно так и начинался топик:

Дело в том, что почти всегда над проектом я работаю в одиночку.

Потому и написал не конкретный код, а что-то вроде "ляляляляляля", так как это нельзя проанализировать, а нужно заранее знать указанное автором кода. Проектирование архитектуры программы, рефакторинг, её тестирование, документирование, не говоря уже о кодировании, а так же многое другое лишь частные случаи мыслительной деятельности конкретного программиста. Если посмотреть на топик далее:

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

Так и выходит, что в итоге надо или помнить, или писать заметки. Но заметки тоже могут быть более развитыми. К примеру, я говорю о том, что сама система заметок плохо развита, так как не имеет прямой привязки к коду. Даже имея заметки, но не имея конкретного указания на код, и уж тем более возможности открыть весь связанный код вместе, получаем систему в которой программист вынужден использовать сравнение. Всё как по учебнику логики, только с отвлечением на лишние мозговые операции. А потом идёт синтез, куски кода сливаются вместе и для их разбора снова нужен анализ и сравнение.

Я к тому, что смысл не в том, чтобы разложить весь функционал по полочкам, то есть пространствам имён, классам, методам и тому подобным механизмам конкретного языка, которых в другом языке может и не быть. Вопрос в более эффективном анализе и синтезе, а так же сохранении результатов не только у себя в голове, но и на внешнем материальном носителе. Не помню в какой книге читал, но взять тот же опенсорс, казалось бы есть код, его можно прочитать и понять, а может быть откомпилировать и запустить. Однако в большинстве случаев теряется существенная часть процесса разработки, так как программисты редко описывают почему они приняли то или иное решение.
Re: Прыжки по коду
От: alpha21264 СССР  
Дата: 13.12.16 00:18
Оценка:
Здравствуйте, licedey, Вы писали:

L>В общем, чтобы не растекаться мыслью по древу, перейду к вопросу. У вас есть монстр, у вас есть задача. Между ними — пропасть реализации. Как удержать в голове и реализовать все микрозадачи?

L>Обычный процесс кодинга идет примерно так (по себе сужу). Вам надо создать класс (в нужной папке), создать в нем свойства, затем связать это с UI, потом поправить класс Settings, чтобы он учитывал внесенные изменения, в другом классе создать объект, перейти в нужный метод итд. В общем случае, мы постоянно прыгаем по коду. Огромному неуправляемому. И как проще сделать, чтобы эти прыжки были более продуктивными и не напрягали весь мозг.

Если это твой индивидуальный проект, то ты можешь сам определять архитектуру.
Ну и организуй архитектуру так, чтобы прыжков было не очень много.
Я делаю так — у меня есть движок, гуи, и настройки.
Все три сущности размазаны по десятку файлов.
Но в каждый момент нужно работать только с одним сишником и одним хедером (итого — два) .
В смысле для движка два, для ГУИ два и для настроек два (всего одномоментно шесть).
Я работаю в Линуксе в KDE. У меня есть виртуальные экраны.
Движок на одном экране, ГУИ на втором, настройки на третьем, на четвёртом — отладчик.
Собственно всё, в человеческий максимум — 10 объектов я уложился.

Течёт вода Кубань-реки куда велят большевики.
Re[2]: Прыжки по коду
От: licedey  
Дата: 13.12.16 02:46
Оценка:
Здравствуйте, alpha21264, Вы писали:

A>Здравствуйте, licedey, Вы писали:


A>Если это твой индивидуальный проект, то ты можешь сам определять архитектуру.

A>Ну и организуй архитектуру так, чтобы прыжков было не очень много.
A>Я делаю так — у меня есть движок, гуи, и настройки.
A>Все три сущности размазаны по десятку файлов.
A>Но в каждый момент нужно работать только с одним сишником и одним хедером (итого — два) .
A>В смысле для движка два, для ГУИ два и для настроек два (всего одномоментно шесть).
A>Я работаю в Линуксе в KDE. У меня есть виртуальные экраны.
A>Движок на одном экране, ГУИ на втором, настройки на третьем, на четвёртом — отладчик.
A>Собственно всё, в человеческий максимум — 10 объектов я уложился.

С мониторами — хорошая идея, думаю. Хотя не каждый может позволить себе, ну в силу площади рабочего места хотя бы. Я к тому и вел, чтобы меньше "скакать" — какой инструмент на данный момент лучший?
Чего вообще хочется идеального в вакууме. У меня есть класс модели и форма, для простоты. Я пишу класс — а форма сама строится, пусть криво, лучше потом поправить. Или наоборот, я рисую форму, а класс модели под нее уже готов. Совсем конкретно — сейчас навеяло меня WinForms на эту затею. Ранее WPF. Да и ASP.NET MVC, хоть и scaffold'ит что-то, но верстку все равно надо самому делать. Ближе всего к моей хотелке — конечно скафолдинг в MVC. В руби на рельсах тоже так можно. Но не покидает ощущение, что мы можем взять "перо" -> расчертить доску (блочный layout сделать) -> врисовать туда же пером контролы и приписать им метки. Все. На выходе у нас отверстанный (пусть частично) UI, у нас модель и у нас viewModel. А такие вещи, как settings, logs, exception handling, должны драгнгробом или кликом добавлятся в этот условный холст. Причем сеттинги и логи, тоже привязаны к нарисованной модели.
Есть такая странная технология как Lightswitch. Вот она как то, что-то близкое. Но все одно шаблон, интерфейс хауноу.

  Oсторожно холивар
Не холивара ради, но UI на плюсах — у меня просто психика не выдерживает. Хоть Qt, хоть MFC, WinApi — все один сплошной геморой. И в том же духе Mac-ориентированные swift/objc.
Создавать вручную UI, кодом, узревая как поправил метку через 5 минут компиляции — не, за такое больше не берусь.
Re[3]: Прыжки по коду
От: Sinix  
Дата: 13.12.16 05:39
Оценка:
Здравствуйте, licedey, Вы писали:

L>Вы посмотрите сколько людей стонут в разделе Работа

Ну тут как — кто-то стонет, кто-то делает. Все обязанности распределены, все довольны

L>Из ваших слов, решение — issue tracker, остальное решит мозг?

В первую очередь — отсутствие бардака в проекте, мозг уже в довесок. Ну и плюс issue tracker и нормальная IDE, разумеется, которая умеет находить зависимости/места использования/текст в прямом эфире. Ничего сверх этого обычно не требуется.
Re[6]: Прыжки по коду
От: Sinix  
Дата: 13.12.16 06:03
Оценка: +1
Здравствуйте, velkin, Вы писали:

V>Дело не в коммитах и уж тем более не в том кто и что записал, ведь именно так и начинался топик:

Дело в том, что почти всегда над проектом я работаю в одиночку.

А какая разница? Это ж не повод разводить в проекте неразбериху до такой степени, чтоб рутинные действия начинали создавать проблемы. Как по мне, наоборот, "индивидуальные" проекты должны обкладываться всеми мыслимыми и немыслимыми подстраховками, ибо больше надеяться не на кого.

V>Потому и написал не конкретный код, а что-то вроде "ляляляляляля", так как это нельзя проанализировать, а нужно заранее знать указанное автором кода.

Бардак, без обид. Если без помощи человека из существующих артефактов (кода, тестов, документации и чтотамещё) нельзя восстановить что, зачем и куда, то код у нас неподдерживаемый. Для кого либо кроме автора ценности он представляет не больше, чем розеттский камень. Ну, т.е. только в плане занимательных историй на ночь.



V>Так и выходит, что в итоге надо или помнить, или писать заметки.

Угу, документацию по проекту надо вести. Систематически.
Если есть проблемы с сложностью проекта — обязательно с фиксацией в issue-трекере. Иначе потом концов не найти и проблемы тихо копятся, пока проект не загнётся под своим же весом.


V>Даже имея заметки, но не имея конкретного указания на код, и уж тем более возможности открыть весь связанный код вместе, получаем систему в которой программист вынужден использовать сравнение.

А поиском зависимостей, хотя бы в виде find all references — никак?

V> Вопрос в более эффективном анализе и синтезе, а так же сохранении результатов не только у себя в голове, но и на внешнем материальном носителе.

Не вопрос — на выходе получится DSL-нотация, которая понимает все возможности вашего языка, но читается лучше и умеет синхронизироваться с кодом. Как по мне, сделать такую штуку на пару порядков сложнее, чем найти инструмент, который умеет строить граф зависимостей.


V> Не помню в какой книге читал, но взять тот же опенсорс, казалось бы есть код, его можно прочитать и понять, а может быть откомпилировать и запустить. Однако в большинстве случаев теряется существенная часть процесса разработки, так как программисты редко описывают почему они приняли то или иное решение.


Бардак, сэр
Re: Прыжки по коду
От: rm822 Россия  
Дата: 13.12.16 08:55
Оценка: +2 -2
L>Как удержать в голове и реализовать все микрозадачи?
А Никак.
L>И как проще сделать, чтобы эти прыжки были более продуктивными и не напрягали весь мозг.
Никак.

У тебя прыжки не потому что код или инструменты, код и прыжки всего лишь отражают модель твоего мышления
Re: Прыжки по коду
От: Географ Россия нет
Дата: 13.12.16 13:36
Оценка: +1
Здравствуйте, licedey, Вы писали:

L>Дело в том, что почти всегда над проектом я работаю в одиночку. Проекты разной величины, ну скажем самые большие занимают год-полтора.

L>Так вот суть в чем. Я понимаю, что уже сто лет как напридумывали всяких редмайнов, джир и фабрикаторов, со скрам бордами через плечо.
L>НО! Заказчик пишет — я хочу такую то фичу, она должна свистеть, а сзади у нее должен быть красненький мотор. Он уложился в три строки. И вроде с виду
L>все понятно, думаешь, тю, легкотня на пару дней. НО! Начинаешь писать код, разбивать его на классы, потом на свойства, методы. Доходя до реализации,
L>которых, далеко углубляешься в дебри кода, соблюдение этих солид принципов и прочьего, что вчерашняя легкотня, превращается в монстрообразное мессиво
L>которое практически выходит из под контроля.
...
Большой проект, 40 мегабайт в EAR, только половина — на внешние библиотеки. На Java. Писали десятки людей из не одной конторы десяток лет. Сотни тысяч обращений и загрузок данных (в основном XML, не часто бинарные файлы) в день в течении 2 недель в начале квартала. Не магазин. Слежу за всем один плюс подключается ещё человек, если затрагивается БД (слава разуму!).

И смысл [уже] был утерян. Изначально. Даже документации нет. Никакой! При передаче декомпилировали исходники, какая тут документация? И суть — рассыпается поневоле на отдельные кусочки. Это — да.
Мозг постепенно запоминает всю эту гущу. Мелкие ошибки устранены, но применением крупных, не адекватных усилий.

Теперь о главном.

Если заказчику и основному потребителю этого чуда что-то нужно изменить или добавить, то он пишет ТЗ! Оно практически всегда описывает проблему достаточно точно. Иногда даже не нужно звонить и уточнять. Похоже, это единственный путь реально бороться с расплыванием по древу мыслей заказчика и его фрейдистскими желаниями. которые неудержимы.

Суть метода ТЗ — упорядочивание мыслей заказчика и понимание им главной мысли — всё суета (Vanitas vanitatum et omnia vanitas).
Re: Прыжки по коду
От: · Великобритания  
Дата: 13.12.16 13:51
Оценка:
Здравствуйте, licedey, Вы писали:

l> Так вот суть в чем. Я понимаю, что уже сто лет как напридумывали всяких редмайнов, джир и фабрикаторов, со скрам бордами через плечо.

l> НО! Заказчик пишет — я хочу такую то фичу, она должна свистеть, а сзади у нее должен быть красненький мотор. Он уложился в три строки. И вроде с виду
Я как фанат ещё упомяну тесты (разных уровней Unit, Integration, Func, Perf, etc). Тесты тоже неплохой инструмент управления сложностью. Каждый тест по сути небольшая исполняемая программка, и вместо написания огромного сложного приложения ты пишешь сотни маленьких и простых. А собирать сложную конструкцию из простых и ожидаемо работающих деталей — проще.
Мало того, сами тесты служат документаций. Если непонятно что делает конкретная строчка|метод — всегда можно посмотреть как она протестирована.
Ещё наличие тестов заставляет использовать правильную архитектуру. Например, явное отделение API который можно легко тестировать и UI, который общается с человеками (понятное дело, что это больше подходит для более менее сложных приложений, где помимо UI есть хоть какая-то логика).
Ещё — регрессия. Когда будешь окрашивать новую свистелку в зелёный цвет ты не перекрасишь случайно свой красненький мотор.
avalon/2.0.1
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: Прыжки по коду
От: licedey  
Дата: 13.12.16 19:28
Оценка:
Здравствуйте, ·, Вы писали:

·>Здравствуйте, licedey, Вы писали:


l>> Так вот суть в чем. Я понимаю, что уже сто лет как напридумывали всяких редмайнов, джир и фабрикаторов, со скрам бордами через плечо.

l>> НО! Заказчик пишет — я хочу такую то фичу, она должна свистеть, а сзади у нее должен быть красненький мотор. Он уложился в три строки. И вроде с виду
·>Я как фанат ещё упомяну тесты (разных уровней Unit, Integration, Func, Perf, etc). Тесты тоже неплохой инструмент управления сложностью. Каждый тест по сути небольшая исполняемая программка, и вместо написания огромного сложного приложения ты пишешь сотни маленьких и простых. А собирать сложную конструкцию из простых и ожидаемо работающих

Кстати про тесты. Я в целом то с вами соглашусь, но сколько времени уходит на их написание? Когда ты один на один с заказчиком — плевать он хотел на тесты и все что под капотом, ну вы сами знаете. Важен бюджет и чтобы работало. Все. Вот хоть в нерабочее время эти тесты пиши.
И вот хотелось бы спросить еще, вы как фанат тестов, случаем не посоветуете тулзу которая под C#/Visual Studio бы генерила тесты. Не только стабы пустышки, а именно чтото сама додумывала и пыталась хоть немного покрыть функционал? Пойду конечно погуглю, но лучше спросить
Re: Прыжки по коду
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.12.16 19:46
Оценка:
Здравствуйте, licedey, Вы писали:

L>Прыг в UI, прыг в конфиги, прыг в класс модели, прыг в класс view-модели, назад в UI. И этот процесс цикличен. Между этими прыжками, можно потерять какую-либо деталь и вообще улететь в космос, размышляя о бытие.


На чем пишешь?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Прыжки по коду
От: · Великобритания  
Дата: 13.12.16 20:40
Оценка:
Здравствуйте, licedey, Вы писали:

l> ·>Я как фанат ещё упомяну тесты (разных уровней Unit, Integration, Func, Perf, etc). Тесты тоже неплохой инструмент управления сложностью. Каждый тест по сути небольшая исполняемая программка, и вместо написания огромного сложного приложения ты пишешь сотни маленьких и простых. А собирать сложную конструкцию из простых и ожидаемо работающих


l> Кстати про тесты. Я в целом то с вами соглашусь, но сколько времени уходит на их написание?

От опыта зависит. Если есть опыт, то код с тестами как правило пишется быстрее. Т.к. значительно уменьшается время от внесения изменения до проверки как это изменение функционирует. Таких ситуаций "ой, опечатка! тут надо было +1, а не -1 написать! Ох... опять компилить, деплоить, запускать..." практически не остаётся — а таких опечаток очень много, съедают кучу времени.

l> Когда ты один на один с заказчиком — плевать он хотел на тесты и все что под капотом, ну вы сами знаете. Важен бюджет и чтобы работало. Все. Вот хоть в нерабочее время эти тесты пиши.

Тесты не должны идти отдельной строчкой бюджета, это неотъемлемая часть качественной разработки. Ты ж заказчику не просишь отдельно оплатить "использование VCS" или "написание осмысленных идентификаторов в коде". С другой стороны не каждому заказчику нужна качественная разработка... но надеюсь мы не о таких проектах говорим.

l> И вот хотелось бы спросить еще, вы как фанат тестов, случаем не посоветуете тулзу которая под C#/Visual Studio бы генерила тесты. Не только стабы пустышки, а именно чтото сама додумывала и пыталась хоть немного покрыть функционал? Пойду конечно погуглю, но лучше спросить

В идеале тесты до основного кода пишутся... На основе чего эта тулза должна генерить тесты? Если ты можешь генерить тесты, то чего уж — генери сам основной код... и покрой тестами генератор.
avalon/2.0.1
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: Прыжки по коду
От: licedey  
Дата: 13.12.16 21:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, licedey, Вы писали:


L>>Прыг в UI, прыг в конфиги, прыг в класс модели, прыг в класс view-модели, назад в UI. И этот процесс цикличен. Между этими прыжками, можно потерять какую-либо деталь и вообще улететь в космос, размышляя о бытие.


VD>На чем пишешь?


Nemerle

Ну в основном на C#/C++
Re[3]: Прыжки по коду
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.12.16 21:04
Оценка:
Здравствуйте, licedey, Вы писали:

L>Nemerle


Зря шутишь. На немерле то как раз сложность обуздать по проще.

L>Ну в основном на C#/C++


С Плюсами все фигово по определению, а на Шарпе можно фичами РеШарпера пользоваться. Там для навигации много чего есть. В том числе и из гуя в код и обратно.

Еще есть способ работающий везде, но требующий пунктуальности. Используешь теги в коментариях типа
// #фича_ххх

Ну, и в остальных местах (треккер, гит, доки) используешь эти теги. При этом они должны быть уникальны, конечно. Далее тупой поиск позволяет найти все связанное.
Это и для плюсов катит.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Прыжки по коду
От: licedey  
Дата: 13.12.16 21:17
Оценка:
Здравствуйте, ·, Вы писали:

·>Здравствуйте, licedey, Вы писали:


l>> И вот хотелось бы спросить еще, вы как фанат тестов, случаем не посоветуете тулзу которая под C#/Visual Studio бы генерила тесты. Не только стабы пустышки, а именно чтото сама додумывала и пыталась хоть немного покрыть функционал? Пойду конечно погуглю, но лучше спросить

·>В идеале тесты до основного кода пишутся... На основе чего эта тулза должна генерить тесты? Если ты можешь генерить тесты, то чего уж — генери сам основной код... и покрой тестами генератор.

Ну я не фанат TDD, не понимаю как это делать. Читал, пытался писать сначала тесты, но привычка знаете, сначала формы шлепать, потом функционал потихоньку добавлять, а потом по требованию правой кнопочкой мыши и Generate Unit Test...
Re[4]: Прыжки по коду
От: licedey  
Дата: 13.12.16 21:26
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, licedey, Вы писали:


L>>Nemerle


VD>Зря шутишь. На немерле то как раз сложность обуздать по проще.


Я не шучу, еще 4 года назад ваш парсер c# кода использовал в своем проекте. За что вам спасибо. Но помоему больше не доводилось нигде.
Как можно обуздать сложность, не спрашиваю, но можете рассказать.

L>>Ну в основном на C#/C++


VD>С Плюсами все фигово по определению, а на Шарпе можно фичами РеШарпера пользоваться. Там для навигации много чего есть. В том числе и из гуя в код и обратно.


Решарпер почему то у меня ассоциируется с громадной универсальной махиной, которая только тормозит студию. Я понимаю конечно, что продукт хороший и повсеместный,
но мне тот же visual assist ближе.

VD>Еще есть способ работающий везде, но требующий пунктуальности. Используешь теги в коментариях типа

VD>
VD>// #фича_ххх
VD>

VD>Ну, и в остальных местах (треккер, гит, доки) используешь эти теги. При этом они должны быть уникальны, конечно. Далее тупой поиск позволяет найти все связанное.
VD>Это и для плюсов катит.

Учту.
Re[5]: Прыжки по коду
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.12.16 22:04
Оценка:
Здравствуйте, licedey, Вы писали:

L>Как можно обуздать сложность, не спрашиваю, но можете рассказать.


Ключевое слова — макросы. Многое можно автоматизировать или сделать оптимально без сильных затрат.

Например, для Nitra
Автор: VladD2
Дата: 18.12.15
делали клиент-серверный IDE-движок. В нем обработка кода ведется на сервере, а общение проводится через сериализуемые сообщения. В результате написали макро-атрибут NitraMessage, который будучи применен к типу генерирует для него эффективый код сериализации. В результате описание типов для сообщений стало выглядеть так:
  [NitraMessage]
  public struct FileEntries
  {
    public File   : FileIdentity;
    public Ranges : ImmutableArray[Range];
  }

Конструктор так же генерируется автоматически.
Полный список всех типов умещается в одном файлике и отлично легко поддерживается.

Сам код макроса находится тут.

Естественно, что сериализация это только пример. Ты можешь сгенерит все что угодно и иметь одни короткий исходник порождающий много кода.

Ну, и сам язык мощнее. Даже C# 7 не включает всех его фич. Да и 8 не будет.

L>Решарпер почему то у меня ассоциируется с громадной универсальной махиной, которая только тормозит студию. Я понимаю конечно, что продукт хороший и повсеместный,

L>но мне тот же visual assist ближе.

Я использовал Visual Assist лет 15 назад. Тогда там функциональность была очень скудная и работал он со скрипом.

Решарпер сейчас работает довольно не плохо. Особенно на фоне новой менеджед-реализации самого Шарпа. И функциональность там просто запредельная.

Навигация очень удобная. Жмешь Ctrl+T и пишешь большие буквы ( hs для поиска HashSet) нужного тебе символа (без оглядки на его тип). Далее из списка выбираешь и ты уже там. Далее очень удобный переход по реализациям интерфейсов и виртуальных методов. Ну, и много всего.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Прыжки по коду
От: Evgeny.Panasyuk Россия  
Дата: 13.12.16 22:36
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Сам код макроса находится тут.

VD>Естественно, что сериализация это только пример.

Примитивнейший пример — подобная рекурсивная сериализация структур и на C++ реализуется
Автор: Evgeny.Panasyuk
Дата: 06.10.14
— десяток/два строк на непосредственно рекурсивный "движок", плюс само собой код сериализации базисных типов.

VD>Навигация очень удобная. Жмешь Ctrl+T и пишешь большие буквы ( hs для поиска HashSet) нужного тебе символа (без оглядки на его тип). Далее из списка выбираешь и ты уже там. Далее очень удобный переход по реализациям интерфейсов и виртуальных методов. Ну, и много всего.


Такое и для C++ есть, даже не в рамках IDE:
https://www.youtube.com/watch?v=5FQwQ0QWBTU
Re[6]: Прыжки по коду
От: licedey  
Дата: 13.12.16 22:56
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, licedey, Вы писали:


L>>Как можно обуздать сложность, не спрашиваю, но можете рассказать.

VD>Сам код макроса находится тут.
VD>Естественно, что сериализация это только пример. Ты можешь сгенерит все что угодно и иметь одни короткий исходник порождающий много кода.

Из бенефитов я извлек только, что конструктор структуры генерится сам. Ну вникнуть конечно время надо и увидеть в действии. Почитаю на выходных getting started.
Работаю тут с человеком

VD>Ну, и сам язык мощнее. Даже C# 7 не включает всех его фич. Да и 8 не будет.


Спорить не буду, массовости не хватает, комьюнити. Чтобы зашел на SO, а там уже 25 ответов на твой вопрос. К слову, пришел несколько лет назад в Microsoft ua, и начал показывать им свой проект, который как я говорил в основе содержал ваш парсер. И они пожимали плечами при слове Немерле. Странно, не правда ли?


VD>Решарпер сейчас работает довольно не плохо. Особенно на фоне новой менеджед-реализации самого Шарпа. И функциональность там просто запредельная.

VD>Навигация очень удобная. Жмешь Ctrl+T и пишешь большие буквы ( hs для поиска HashSet) нужного тебе символа (без оглядки на его тип). Далее из списка выбираешь и ты уже там. Далее очень удобный переход по реализациям интерфейсов и виртуальных методов. Ну, и много всего.

Пока работаю дома, я конечно могу себе позволить им пользоваться. Но у меня сомнения закрадываются что любая контора может позволить себе их прайс. Минимум 300 у.е. в год..кхм. Скоро MS в своем духе сопрет все их фичи и он перестанет быть нужен. Впрочем и visual assist уже не нужен, в последней студии не ставил его, ибо все из коробки.
Re[5]: Прыжки по коду
От: · Великобритания  
Дата: 13.12.16 23:08
Оценка:
Здравствуйте, licedey, Вы писали:

l> ·>В идеале тесты до основного кода пишутся... На основе чего эта тулза должна генерить тесты? Если ты можешь генерить тесты, то чего уж — генери сам основной код... и покрой тестами генератор.

l> Ну я не фанат TDD, не понимаю как это делать. Читал, пытался писать сначала тесты, но привычка знаете, сначала формы шлепать, потом функционал потихоньку добавлять, а потом по требованию правой кнопочкой мыши и Generate Unit Test...
Надо начинать с разделения UI и функционала.
Попробуй писать логику до UI. Когда логика готова — прикручиваешь готовые оттестированные классы к форме.
Ну и ещё надо найти способ тестирования UI... с этом обычно самые проблемы. Не в курсе как это делается в C#, в веб-приложениях хорошо идёт Selenium.
avalon/2.0.1
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[6]: Прыжки по коду
От: licedey  
Дата: 14.12.16 10:21
Оценка:
Здравствуйте, ·, Вы писали:

·>Здравствуйте, licedey, Вы писали:


·>Надо начинать с разделения UI и функционала.

·>Попробуй писать логику до UI. Когда логика готова — прикручиваешь готовые оттестированные классы к форме.
·>Ну и ещё надо найти способ тестирования UI... с этом обычно самые проблемы. Не в курсе как это делается в C#, в веб-приложениях хорошо идёт Selenium.
У меня затык в том, что я не особо визуализирую классы-логики, до появления UI. То есть функционал полностью проясняется, когда перед тобой UI висит.

А второй значимый момент, это то, что клиент (а я фрилансер) всегда ведеться на красивый UI и дает дальше бюджет, и пусть внутри пустота.

Недавно история была, как 4ро парней из команды пыхтели над логикой (под Mac), а я в это время в одиночку красивенько отрисовывал UI (Win). Итог немного предсказуем.
Под Mac Проект заморозили, ибо прошло пол года а ничего не видно ((, а весь груз отвественности и бюджет отдали мне. 4-ых уделал одной красотой.
И в догонку может вы слышали золотое правило шаровары, Market first, Marketing second, Aestetic third and Functionality last. Это про приотеты в разработке своего продукта. Внешний вид получается уделывает фунционал.
Re[7]: Прыжки по коду
От: · Великобритания  
Дата: 14.12.16 10:56
Оценка:
Здравствуйте, licedey, Вы писали:

L>·>Надо начинать с разделения UI и функционала.

L>·>Попробуй писать логику до UI. Когда логика готова — прикручиваешь готовые оттестированные классы к форме.
L>·>Ну и ещё надо найти способ тестирования UI... с этом обычно самые проблемы. Не в курсе как это делается в C#, в веб-приложениях хорошо идёт Selenium.
L>У меня затык в том, что я не особо визуализирую классы-логики, до появления UI. То есть функционал полностью проясняется, когда перед тобой UI висит.
L>А второй значимый момент, это то, что клиент (а я фрилансер) всегда ведеться на красивый UI и дает дальше бюджет, и пусть внутри пустота.
Неужели весь этот код, по которому приходтися прыгать это "красивый UI"? Если так, то вряд ли тут тесты сильно помогут... Ведь свойство "быть красивым" в авто-тесте не проверишь...
А если таки что-то есть функиональное внутри, то его и можно покрывать тестами, независимо от UI.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[8]: Прыжки по коду
От: licedey  
Дата: 14.12.16 11:44
Оценка:
Здравствуйте, ·, Вы писали:

·>Здравствуйте, licedey, Вы писали:


L>>У меня затык в том, что я не особо визуализирую классы-логики, до появления UI. То есть функционал полностью проясняется, когда перед тобой UI висит.

L>>А второй значимый момент, это то, что клиент (а я фрилансер) всегда ведеться на красивый UI и дает дальше бюджет, и пусть внутри пустота.
·>Неужели весь этот код, по которому приходтися прыгать это "красивый UI"? Если так, то вряд ли тут тесты сильно помогут... Ведь свойство "быть красивым" в авто-тесте не проверишь...
·>А если таки что-то есть функиональное внутри, то его и можно покрывать тестами, независимо от UI.

Ну я же не про один проект говорю, на фрилансе такое индусское хауноу попадается, что мучаешься в догадках где достать такую же траву, чтобы постичь глубину их мысли.
Вот там прыгаешь як скаженный.
Re: Прыжки по коду
От: Sharov Россия  
Дата: 14.12.16 13:48
Оценка:
Здравствуйте, licedey, Вы писали:

L>В общем, чтобы не растекаться мыслью по древу, перейду к вопросу. У вас есть монстр, у вас есть задача. Между ними — пропасть реализации. Как удержать в голове и реализовать все микрозадачи?

L>Обычный процесс кодинга идет примерно так (по себе сужу). Вам надо создать класс (в нужной папке), создать в нем свойства, затем связать это с UI, потом поправить класс Settings, чтобы он учитывал внесенные изменения, в другом классе создать объект, перейти в нужный метод итд. В общем случае, мы постоянно прыгаем по коду. Огромному неуправляемому. И как проще сделать, чтобы эти прыжки были более продуктивными и не напрягали весь мозг.

L>Вот мой пример, что для этого делаю я. У меня есть мультизадача, или сверхзадача, которую обозначил заказчик (хотите менеджер). Разумеется я разбиваю ее на более мелкие подзадачи. И далее, исходя из них я начинаю кодить. Но тут и приходиться запинаться все время. Прыг в UI, прыг в конфиги, прыг в класс модели, прыг в класс view-модели,

L>назад в UI. И этот процесс цикличен. Между этими прыжками, можно потерять какую-либо деталь и вообще улететь в космос, размышляя о бытие.
L>Вобщем я пишу все в блокнот, все эти микрозадачи, и при каждом прыжке лезу в заметки, чтобы не забыть. У вас как?

Делайте задачу транзакционно -- не начинайте следующую пока не закончите текущую. Основные идеи, классы, абстракции не гнушайтесь записывать на бумагу. Это реально лучше чем записать в какой-нибудь блокнот на компьютере, больше осмысленности задействуется.

У меня ситуация схожа, хоть я и не фрилансер. Я активно использую R#, настроил его под себя -- свои hot-key'и и т.д. В случае с заказчиком и постоянными требованиями заведите какую-нибудь agile доску типа kanban, jira и т.д. Так легче ему и Вам отслеживать задачи и статус. Что не отменяет ручки и бумаги.
Кодом людям нужно помогать!
Re[7]: Прыжки по коду
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.16 17:07
Оценка:
Здравствуйте, licedey, Вы писали:

L>Из бенефитов я извлек только, что конструктор структуры генерится сам.


Для этого вообще одна строчка кода потребовалась, так как макрос генерации конструкторов уже есть из коробки.

Но ты не правильном мыслишь. Главный бенефит — это то что есть в конкретном макросе, а то, что ты волен создать любой макрос сам. Он, во время компиляции, сгенирирует тебе нужный тебе код по нужным тебе правилам. И когда надо ты подправишь макру и получишь нужные изменения в измененном коде.

Причем делается это все удобно и незаметно для пользователя. Пользователь просто получает готовые решения, которые сложно или невозможно сделать в виде библиотеки. Всяческие генераторы на Т4, посткомпиляторы (вроде Постшарпа) становятся ненужны.

Собственно, чтобы было понятно приведу вариант одного из простейших типов и то в какой код он раскрывается при компиляции:

  Код структуры NSpan
  [NitraMessage, StructuralEquality]
  public struct NSpan : IComparable[NSpan]
  {
    public StartPos : int;
    public EndPos   : int;
    public Length   : int { get { EndPos - StartPos }}
    
    public IsEmpty : bool
    {
      get { StartPos == EndPos }
    }
    
    public IntersectsWith(pos : int)              : bool { pos <= EndPos && pos >= StartPos }
    public IntersectsWith(start : int, end : int) : bool { start <= EndPos && end >= StartPos }
    public IntersectsWith(other : NSpan)          : bool { IntersectsWith(other.StartPos, other.EndPos) }
    public IntersectsWith(other : Range)          : bool { IntersectsWith(other.Span) }
    public IntersectsWith(other : Location)       : bool { IntersectsWith(other.Range) }
    
    public override ToString() : string { StartPos + ", " + EndPos }
    
    public CompareTo(other : NSpan) : int
    {
      def result = StartPos.CompareTo(other.StartPos);
      if (result == 0)
        EndPos.CompareTo(other.EndPos)
      else
        result
    }
  }


NitraMessage — как уже говорилось выше, генерирует код сериализации, дополнительное поле MsgId уникальное внутри модуля и коструктор (добавляет макру Record). StructuralEquality — это макра из стандартной библиотеки реализующая методы эквивалентности путем сравнения всех полей. В результате получаем вот такой код (получено декомпиляцией в C#):

  Декомпилят структуры NSpan
public struct NSpan : IComparable<NSpan>, IEquatable<NSpan>, IStructuralEquatable
{
  public readonly int StartPos;

  public readonly int EndPos;

  public int Length
  {
    get
    {
      return checked(this.EndPos - this.StartPos);
    }
  }

  public bool IsEmpty
  {
    get
    {
      return this.StartPos == this.EndPos;
    }
  }

  public short MsgId
  {
    get
    {
      return 109;
    }
  }

  public int GetHashCode(IEqualityComparer _comparer)
  {
    return this.GetHashCode();
  }

  public bool Equals(object other, IEqualityComparer _comparer)
  {
    return this.Equals(other);
  }

  public static bool operator !=(NSpan first, NSpan second)
  {
    return !(first == second);
  }

  public static bool operator ==(NSpan first, NSpan second)
  {
    return first.Equals(second);
  }

  public override int GetHashCode()
  {
    int hash = 0;
    hash += this.StartPos;
    hash += hash << 10;
    hash ^= hash >> 6;
    hash += this.EndPos;
    hash += hash << 10;
    return hash ^ hash >> 6;
  }

  public override bool Equals(object other)
  {
    bool arg_2E_0;
    if (!(other is NSpan))
    {
      arg_2E_0 = false;
    }
    else
    {
      NSpan x = (NSpan)other;
      arg_2E_0 = this.EqualsImpl(x);
    }
    return arg_2E_0;
  }

  public bool Equals(NSpan other)
  {
    return this.EqualsImpl(other);
  }

  public bool IntersectsWith(int pos)
  {
    return pos <= this.EndPos && pos >= this.StartPos;
  }

  public bool IntersectsWith(int start, int end)
  {
    return start <= this.EndPos && end >= this.StartPos;
  }

  public bool IntersectsWith(NSpan other)
  {
    return this.IntersectsWith(other.StartPos, other.EndPos);
  }

  public bool IntersectsWith(Range other)
  {
    return this.IntersectsWith(other.Span);
  }

  public bool IntersectsWith(Location other)
  {
    return this.IntersectsWith(other.Range);
  }

  public override string ToString()
  {
    return this.StartPos.ToString() + ", " + this.EndPos.ToString();
  }

  public int CompareTo(NSpan other)
  {
    int result = this.StartPos.CompareTo(other.StartPos);
    return (result != 0) ? result : this.EndPos.CompareTo(other.EndPos);
  }

  private bool EqualsImpl(NSpan other)
  {
    return this.EndPos == other.EndPos && this.StartPos == other.StartPos;
  }

  public void Serialize(BinaryWriter writer)
  {
    writer.Write(this.StartPos);
    writer.Write(this.EndPos);
  }

  public static NSpan Deserialize(BinaryReader reader)
  {
    int num = reader.ReadInt32();
    int arg_10_0 = num;
    int endPos = reader.ReadInt32();
    return new NSpan(arg_10_0, endPos);
  }

  [RecordCtor]
  public NSpan([MappedMember("StartPos")] int startPos, [MappedMember("EndPos")] int endPos)
  {
    this.StartPos = startPos;
    this.EndPos = endPos;
  }
}


L>Спорить не буду, массовости не хватает, комьюнити.


А это заколдованный круг. Я много лет назад запарился с ним бороться и плюнул. Люди с удовольствием жрут рекламу, но думать своим мозгом, в большинстве своем, неспособны.

Когда лет 10 назад я пытался продвигать Немерл часть людей не понимала возможностей, часть спрашивал "а почему миллионы мух не пользуются им?", а часть откровенно противодействовала и испытывала батхерт. Я запарился убеждать и плюнул. С довольствием пользуюсь этим языком сам и помогаю другим.

Тем временем C# заимствовал часть фич которые у нас есть уже около 10 лет, но те кто усирался и орал "не нужно" теперь начинаю орать, что "это не из Немерле заимствовано!". А мне на них уже по хрен. Им нужны шашачки, а не ехать.

L>Чтобы зашел на SO, а там уже 25 ответов на твой вопрос.


О чем речь?

L>К слову, пришел несколько лет назад в Microsoft ua, и начал показывать им свой проект, который как я говорил в основе содержал ваш парсер. И они пожимали плечами при слове Немерле. Странно, не правда ли?


Ну, если бы ты пришел к Хельсбергу или тем кто компилятором занимался, то они бы тебе что-то сказали. А ты ведь пришел к каким-то менеджерам.

Потом в МС тщательно подтирали ссылки на Немерле даже в обсуждениях на гитхабе. В начале были ссылки, а потом их тщательно вымарали. У них там большой страх за то, что кто-то на них в суд подаст по патентам и авторским правам. А может просто не хотят рекламировать. Но факт есть факт.

L>Пока работаю дома, я конечно могу себе позволить им пользоваться. Но у меня сомнения закрадываются что любая контора может позволить себе их прайс. Минимум 300 у.е. в год..кхм. Скоро MS в своем духе сопрет все их фичи и он перестанет быть нужен. Впрочем и visual assist уже не нужен, в последней студии не ставил его, ибо все из коробки.


MS вряд ли в скором времени даже к необходимому минимуму приблизится. Я тут начал писать код без Решарпера. Обвесился всевозможными плагинами, но все равно получается не то. Даже если есть фича, все равно качество не то. Тут разве что какой-нибудь Код-Раш будет конкурентом.

А Ассис... раньше там функциональности было мало. Не знаю как сейчас. Если все осталось на том же уровне, то действительно в студии теперь тоже не так плохо.

Что до денег — да, дорого. Но тот же MS закупает лицензии Решарпера тоннами, не скупится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Отредактировано 14.12.2016 17:39 VladD2 . Предыдущая версия .
Re[7]: Прыжки по коду
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.16 17:16
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Примитивнейший пример — подобная рекурсивная сериализация структур и на C++ реализуется
Автор: Evgeny.Panasyuk
Дата: 06.10.14
— десяток/два строк на непосредственно рекурсивный "движок", плюс само собой код сериализации базисных типов.


Языком все делается, а на практике одни проблемы. Ну, и это всего лишь один из простых примеров, который можно легко понять. Макрос штука универсальная. И намного более мощная и удобная эти ваши ужимки на шаблонах.

Потом в наше время мало кто будет писать прикладные вещи на плюсах. У Яве, Шарпе и т.п. никаких выкрутасов на шаблонах нет, так как нет шаблонов.

VD>>Навигация очень удобная. Жмешь Ctrl+T и пишешь большие буквы ( hs для поиска HashSet) нужного тебе символа (без оглядки на его тип). Далее из списка выбираешь и ты уже там. Далее очень удобный переход по реализациям интерфейсов и виртуальных методов. Ну, и много всего.


EP>Такое и для C++ есть, даже не в рамках IDE:

EP>https://www.youtube.com/watch?v=5FQwQ0QWBTU

Это из той же серии как сравнивать макры с шаблонным МП. Вроде как похожие вещи, а возможности несравнимы.

То что в этом видео показано для Шарпа есть из горобки в студии. Это примитивный набор. Он даже не обсуждается. Он только для плюсовиков диковиной является.

Фичи Решарпера по навигации намного круче. А уж рефакторинге и говорить не приходится.

Если бы ваших Емаксов людям хвтало, то такие вещи как CLion никто не затевал бы.

ЗЫ

Уж извини, но пенесометрия с плюсовиками мне совсем не интересно. Живите в своем древнем мирке спокойно. Вас никто не хотел беспокоить. Считайте, что у вас все круче чем у всех. Успехов вам! Денег нет!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Прыжки по коду
От: Evgeny.Panasyuk Россия  
Дата: 14.12.16 19:12
Оценка:
Здравствуйте, VladD2, Вы писали:

EP>>Примитивнейший пример — подобная рекурсивная сериализация структур и на C++ реализуется
Автор: Evgeny.Panasyuk
Дата: 06.10.14
— десяток/два строк на непосредственно рекурсивный "движок", плюс само собой код сериализации базисных типов.

VD>Языком все делается, а на практике одни проблемы.

Приведённый кусок кода из реального проекта паука который облазил P2P сеть в сотни тысяч узлов, протокол общения между узлами как раз на базе структур-сообщений, которые сериализуются этим самым кодом — пример аналогичный твоему. Но ты конечно можешь и дальше болтать про "одни проблемы".

VD>Ну, и это всего лишь один из простых примеров, который можно легко понять. Макрос штука универсальная. И намного более мощная и удобная эти ваши ужимки на шаблонах.


Штука крутая, несомненно. Мой поинт в том что твой пример вообще не раскрывает силы макросов в Nemerle, ибо подобная автоматическая сериализация много где реализуема, и поэтому никакого вау-эффекта не производит.
Пример с пользовательским условным оператором а-ля if, или например реализация интерполированных строк, были бы куда более показательны и эффектны.

VD>Потом в наше время мало кто будет писать прикладные вещи на плюсах. У Яве, Шарпе и т.п. никаких выкрутасов на шаблонах нет, так как нет шаблонов.


А получается так что именно прикладные вещи на C++ и пишутся, а всякие клей-прокладки между БД и UI на C#/Java — собственно скафолдинг и прочий LightSwitch тут не зря был упомянут, ибо подобные прокладки часто типовые.

VD>Это из той же серии как сравнивать макры с шаблонным МП. Вроде как похожие вещи, а возможности несравнимы.

VD>То что в этом видео показано для Шарпа есть из горобки в студии. Это примитивный набор. Он даже не обсуждается. Он только для плюсовиков диковиной является.
VD>Фичи Решарпера по навигации намного круче. А уж рефакторинге и говорить не приходится.
VD>Если бы ваших Емаксов людям хвтало, то такие вещи как CLion никто не затевал бы.
VD>ЗЫ
VD>Уж извини, но пенесометрия с плюсовиками мне совсем не интересно. Живите в своем древнем мирке спокойно. Вас никто не хотел беспокоить. Считайте, что у вас все круче чем у всех. Успехов вам! Денег нет!

Так ты не понял о чём речь, и как обычно продемонстрировал чудеса адекватности. Речь о том что фичи о которых ты сказал есть ДАЖЕ в НЕ-IDE для обхаиваемого тобой C++. Скорей всего у Решарпера действительно есть какие-то крутые фичи для навигации, но ты почему-то вместо них упомянул какой-то примитив.
Re[8]: Прыжки по коду
От: _NN_ www.nemerleweb.com
Дата: 14.12.16 20:01
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Потом в МС тщательно подтирали ссылки на Немерле даже в обсуждениях на гитхабе. В начале были ссылки, а потом их тщательно вымарали. У них там большой страх за то, что кто-то на них в суд подаст по патентам и авторским правам. А может просто не хотят рекламировать. Но факт есть факт.


Есть примеры где подтирали ? Или в некоторых местах забыли ?
https://github.com/dotnet/roslyn/issues?utf8=%E2%9C%93&amp;q=nemerle
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[9]: Прыжки по коду
От: Sinix  
Дата: 14.12.16 20:23
Оценка: :)
Здравствуйте, _NN_, Вы писали:


VD>>Потом в МС тщательно подтирали ссылки на Немерле даже в обсуждениях на гитхабе.

_NN>Есть примеры где подтирали ? Или в некоторых местах забыли ?

Ну вот зачем вы так? Их же теперь расстреляют, как минимум. В самое сердце пробрались.

Если серьёзно — не подтирали, я за issues рослина периодически поглядываю. В моём тикете всё как и было.

Кстати, а в issues гитхаба разве есть возможность удалять чужие сообшения?
Re[9]: Прыжки по коду
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.16 23:26
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Приведённый кусок кода из реального проекта паука который облазил P2P сеть в сотни тысяч узлов, протокол общения между узлами как раз на базе структур-сообщений, которые сериализуются этим самым кодом — пример аналогичный твоему. Но ты конечно можешь и дальше болтать про "одни проблемы".


Это банальное очковтирательство. Ты привел не весь код. Основной код у тебя в библиотеках. И там его овер-дофига. Ты умолчал о куче разных деталей. Я же привел полную реализацию без библиотек и костылей вроде определения классов с помощью черт знает каких макросов.

Когда потребуется сделать, что-то не заложенное авторами этого FUSION-а, придется писать на этом чудо-средстве языке шаблонов самому. А писать на этом мягко говоря не просто.

Вот возникли у меня какие-то проблемы в реализации, я поставил точку остановки и в отладчике разобрался, что не так. А что делать с шаблонами? Там же даже отладочной печати не поставишь.

Ну, и скорость работы опять же не сравнима. Шаблоны — это интерпретация. Да еще и не полноценного ЯП, а эмулируемого на побочных эффектах шаблонов. Макры же — это компелированный код на том же самом языке, что используется для написание гражданского кода.

У меня в проекте 3 вида сериализации. Одна очень компактная и быстрая для сериализации событий. Она использует ряд умолчаний вроде того, что сериализация и десериализация должны производиться одной версией библиотеки. Другая поддерживает версионность для загрузки измененных структур данных из предыдущих форматов и поддерживает загрузку из внешних библиотек автоматом разрешая ссылки и строя граф объектов.

Моя стерилизация знает, что такое наследование и полиморфизм.

Она сериализует некоторые типы из стандартной библиотеки дотнета и нюгетов (которые скомпилированы до моих макросах и на другом языке).

И эти 10 строк меня могут только насмешить, так как в них и десятой доли всех эти нюансов не описать. Я вижу только какой-то шаблон генерящий вызов функций.

EP>Штука крутая, несомненно. Мой поинт в том что твой пример вообще не раскрывает силы макросов в Nemerle, ибо подобная автоматическая сериализация много где реализуема, и поэтому никакого вау-эффекта не производит.


Я же написал, что он писался не в расчете на гуру метапрограммирования на шаблонах С++. Это простой пример понятный дотнетчику.

Я конечно могу расказать про реализацию языка зависимых свойств, например, но боюсь придется сначала прочитать курс лекций по самим зависимым свойствам. А тут все ясно и привычно.

EP>Пример с пользовательским условным оператором а-ля if, или например реализация интерполированных строк, были бы куда более показательны и эффектны.


Они был бы непонятны тому кому я писал. К тому же это расширения языка, которые многие воспринимают в штыки (просто потому, что не пробовали и это страшно).

Примеров, вообще, можно привести много. Но задача же привести пример того как макры могут помочь в своей узкой задаче, а не улучшая язык. Про сам язык я тоже сказал. Но и через 10 лет после появления опережает Шарп. И многие его фичи реализованы, действительно, на макросах. Но вряд ли я сегодя удивлю шарпщика интеполированными (в оригинале сплайсед) строками или оператором безопасного доступа к членам "?.", так как они уже захардкожены в C#, а то что в Немерле еще в Шарп не войте просто будет непонятно шарпщику.

А вот примеры автоматизации и генерации кода они понятны всем и каждому. И что что кое что можно сделать на шаблонном МП в плюсах мало помогает этим шарпщикам.

EP>А получается так что именно прикладные вещи на C++ и пишутся, а всякие клей-прокладки между БД и UI на C#/Java — собственно скафолдинг и прочий LightSwitch тут не зря был упомянут, ибо подобные прокладки часто типовые.


Я не хочу на эту тему спорить. Делаешь, и далешь. На мой взгляд (и взгляд большинства прикладников) это оверкил.

EP>Так ты не понял о чём речь, и как обычно продемонстрировал чудеса адекватности. Речь о том что фичи о которых ты сказал есть ДАЖЕ в НЕ-IDE для обхаиваемого тобой C++. Скорей всего у Решарпера действительно есть какие-то крутые фичи для навигации, но ты почему-то вместо них упомянул какой-то примитив.


Да что-то в твоем видео ничего подобного тому о чем я говорил нет. Где там навигация по переопределениям виртуальных методов? Где поиск символов по всему солюшену в реальном времени? О переходе между гуем и кодом (о котором говорил автор темы) и говорить не приходится, так как этого самого гуя. На шарпе гуй — это какой-нибудь XAML. В нем море слабо типизированного или вообще не типизированного (динамического) кода на птичьих языка. Решарпер делает разные спекуляции и пытается типизироват это длое в IDE. В результате люди получают куда более удобную навигацию по коду и прочие фичи.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Прыжки по коду
От: licedey  
Дата: 14.12.16 23:33
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, licedey, Вы писали:


L>>Из бенефитов я извлек только, что конструктор структуры генерится сам.


VD>Для этого вообще одна строчка кода потребовалась, так как макрос генерации конструкторов уже есть из коробки.


Я не буду что либо высказывать про Немерле, потому что не имею о нем должного представления. Но вы постоянно повторяете про макросы, я в тему не вникал, но догадываюсь что это из области мета-программирования. Если я скажу, что это типа #define в С, или шаблонов в С++, или упомянутый T4. Ну, скажем так, на практике надо приучится к такому подходу, чтобы сначала выявить обобщенный вариант, а затем заделать для него мета решение. Часто ли такое нужно в реальной жизни — незнаю. Мне например нет. Хотя у меня обычно по новому проекту в месяц, и часто используется одно и то же. Пока копипаста — мой друг.
Кстати, с WPF Nemerle дружит? А с ASP.NET MVC? Вот там шаблонных решений хоть отбавляй. Я про UI и всякие авторизации, конфигурации итд. Эти проклятые формы каждый раз с нуля верстать — "одно удовольствие". Если бы можно было как-то шаблонизировать этот процесс...у меня у самого есть несколько идей своего велосипеда, могу поделится

Но возвращаясь к вопросу о комьюнити, то мое мнение такое. Если вы считаете основной фишкой языка те же макросы например, то найдите целевую аудиторию и покажите ей что ваше решение мощное и экономит время.
Я не понимаю, почему те же Python, PHP взлетели, а вы забили на развитие комьюнити. Ок, другой пример. Буквально за 2 года Xamarin превратился из ничего в стандартный тулз для церкви свидетелей Гейтса. Дядя который занимался развитием этой штуковины, даже взымал нехилую мзду за использование. Почему? Ну вы знаете почему, потому что это нужно было людям. Чем учить пресловутый Objective-C и все тонкости iOS, получи пожалуйста все в своем любимом шарпе.
SO=StackOverflow если что
Re[9]: Прыжки по коду
От: licedey  
Дата: 14.12.16 23:37
Оценка:
Здравствуйте, licedey, Вы писали:

L>Здравствуйте, VladD2, Вы писали:


VD>>Здравствуйте, licedey, Вы писали:


L>>>Из бенефитов я извлек только, что конструктор структуры генерится сам.


VD>>Для этого вообще одна строчка кода потребовалась, так как макрос генерации конструкторов уже есть из коробки.


Вижу вы привели примеры, ну это громоздко как-то для getting started, человека который первый раз видит язык и понятия не имеет что из чего получится.
Re[9]: Прыжки по коду
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.16 23:50
Оценка:
Здравствуйте, _NN_, Вы писали:

_NN>Есть примеры где подтирали ? Или в некоторых местах забыли ?


Я специально ссылки не прикапывал. Просто помню, что в первых списках фич и описаниях присутсвовали ссылки на Немерл, а потом незаметно исчезли и были заменены на ФШарп или еще на что-то.

_NN>https://github.com/dotnet/roslyn/issues?utf8=%E2%9C%93&amp;q=nemerle


Посмотрел первые несклько ссылок — это все сообщения от внешних пользователей, а тогда упоминания были в майкрософтовских описаниях.

Точно помню, что при первом описании интеполированных строк были ссылки на Немерл, а в дальнейшем он исчез и появились ссылки на скриптовые языки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Прыжки по коду
От: Evgeny.Panasyuk Россия  
Дата: 15.12.16 01:23
Оценка:
Здравствуйте, VladD2, Вы писали:

EP>>Приведённый кусок кода из реального проекта паука который облазил P2P сеть в сотни тысяч узлов, протокол общения между узлами как раз на базе структур-сообщений, которые сериализуются этим самым кодом — пример аналогичный твоему. Но ты конечно можешь и дальше болтать про "одни проблемы".

VD>Это банальное очковтирательство. Ты привел не весь код. Основной код у тебя в библиотеках. И там его овер-дофига.

Да какая разница если библиотека уже готова и с этим справляется?

VD>Когда потребуется сделать, что-то не заложенное авторами этого FUSION-а, придется писать на этом чудо-средстве языке шаблонов самому. А писать на этом мягко говоря не просто.


Так я не агитирую против макросов, и даже не говорю что шаблоны их полностью заменяют. Я указываю на то что у тебя пример не мотивирующий совсем.

VD>Вот возникли у меня какие-то проблемы в реализации, я поставил точку остановки и в отладчике разобрался, что не так. А что делать с шаблонами? Там же даже отладочной печати не поставишь.


Есть и отладочная печать, и REPL, и трассировщик, и даже подобие отладчика с визуализатором. Но мой поинт был совсем не про C++ и шаблоны.

VD>Ну, и скорость работы опять же не сравнима. Шаблоны — это интерпретация. Да еще и не полноценного ЯП, а эмулируемого на побочных эффектах шаблонов.

VD>Макры же — это компелированный код на том же самом языке, что используется для написание гражданского кода.

Есть constexpr и другие нововведения — приличная часть того что писалось на шаблонах теперь пишется на "гражданском" языке. В частности на основе этих фич и появилась Hana на замену Fusion.

VD>У меня в проекте 3 вида сериализации. Одна очень компактная и быстрая для сериализации событий. Она использует ряд умолчаний вроде того, что сериализация и десериализация должны производиться одной версией библиотеки. Другая поддерживает версионность для загрузки измененных структур данных из предыдущих форматов и поддерживает загрузку из внешних библиотек автоматом разрешая ссылки и строя граф объектов.

VD>Моя стерилизация знает, что такое наследование и полиморфизм.

Это уже относится непосредственно к сериализации, собственно как только есть рекурсивный обход структур — к нему можно прикрутить любую из готовых библиотек сериализации.

EP>>Пример с пользовательским условным оператором а-ля if, или например реализация интерполированных строк, были бы куда более показательны и эффектны.

VD>Они был бы непонятны тому кому я писал. К тому же это расширения языка, которые многие воспринимают в штыки (просто потому, что не пробовали и это страшно).

Так фишка-то как раз в расширении языка. Если язык не расширять, а делать только "внешние" макросы которые где-то в сторонке от основного кода будут что-то генерировать, то это не сильно отличается от обычной внешней генерации (хотя и местами получается действительно очень удобно). Собственно те же C#-программисты вполне себе умеют использовать T4.

На примере той же сериализации: даже если в языке нет абсолютно никакой рефлексии, и есть естественное желание не делать лишние повторения (сначала описать поля в структуре, потом вручную сериализовать каждое её поле) — то без проблем создаётся схема на каком-нибудь XML/JSON плюс небольшой кодогенератор на каком-нибудь Python. Из этой же схемы без проблем генерируется документация, графы, код для других языков и т.д. и т.п., и даже не-программисты справляются с такими схемами. В этом свете преимуществ у макро-сериализации не много — и именно поэтому пример с сериализацией не айс.

А вот какие-то недостающие фичи "внутри" языка (а-ля интерполированные строки) — такой внешней кодогенерацией разруливать трудно — ибо там нужно не только генерировать, но анализировать и "модифицировать" исходный код.
Вот такие примеры и нужно показывать — ибо это главная сильная сторона, ИМХО.

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


Желательно чтобы пример этой узкой задачи не имел лёгкого решения другими средствами.

VD>Про сам язык я тоже сказал. Но и через 10 лет после появления опережает Шарп. И многие его фичи реализованы, действительно, на макросах. Но вряд ли я сегодя удивлю шарпщика интеполированными (в оригинале сплайсед) строками или оператором безопасного доступа к членам "?.", так как они уже захардкожены в C#, а то что в Немерле еще в Шарп не войте просто будет непонятно шарпщику.


Так эти интерполированные строки в C# только-только появились, теперь они их распробуют и не будут лепить blub-отмазки а-ля "да это и не надо" — и пока они тёпленькие на контрасте как раз показать что они вполне реализуются/реализовались средствами Nemerle, не дожидаясь снисхождения ихнего всего.

EP>>Так ты не понял о чём речь, и как обычно продемонстрировал чудеса адекватности. Речь о том что фичи о которых ты сказал есть ДАЖЕ в НЕ-IDE для обхаиваемого тобой C++. Скорей всего у Решарпера действительно есть какие-то крутые фичи для навигации, но ты почему-то вместо них упомянул какой-то примитив.

VD>Да что-то в твоем видео ничего подобного тому о чем я говорил нет. Где там навигация по переопределениям виртуальных методов?

На 13:07: https://youtu.be/5FQwQ0QWBTU?t=787

VD>Где поиск символов по всему солюшену в реальном времени?


Это вообще старая фича — интерактивный fuzzy search (по кусочкам имени) в списках а-ля все пути/файлы в проекте, recent list, открытые файлы, все символы, символы в текущем файле, итерактивный live grep и т.п.
  интерактивный поиск файла в проекте
  интерактивный поиск символов
  интерактивный live-grep


VD>О переходе между гуем и кодом (о котором говорил автор темы) и говорить не приходится, так как этого самого гуя.


GUI на C++ разный бывает — нужно смотреть конкретную среду. В частности переход из дизайнера форм в код обработчика типа OnClick был ещё с незапамятных времён C++ Builder. Как там сейчас дела с навигацией по динамически типизированным штукам типа QML — без понятия, ибо с GUI работаю очень редко.
И я не автору темы про GUI отвечал, а тебе на твои примеры очень удобной навигации РеШарпера.
Re[9]: Прыжки по коду
От: Evgeny.Panasyuk Россия  
Дата: 15.12.16 01:52
Оценка: +1
Здравствуйте, licedey, Вы писали:

L>>>Из бенефитов я извлек только, что конструктор структуры генерится сам.

VD>>Для этого вообще одна строчка кода потребовалась, так как макрос генерации конструкторов уже есть из коробки.
L>Я не буду что либо высказывать про Немерле, потому что не имею о нем должного представления. Но вы постоянно повторяете про макросы, я в тему не вникал, но догадываюсь что это из области мета-программирования. Если я скажу, что это типа #define в С, или шаблонов в С++, или упомянутый T4.

Это ближе к макросам Lisp'а.
Если брать аналогию с T4 — то макросы Nermele это такой T4 который на порядок теснее интегрирован в язык, имеет больше доступа к информации о конструкциях языка, более типобезопасен, гигиеничен, дает ранее обнаружение ошибок и т.п.
Плюс фича по расширению синтаксиса — можно вводить новые конструкции, операторы и т.п. непосредственно в язык. В частности привычные конструкции типа условных операторов реализованы в библиотечном виде. Плюс интеграция в IDE — подсветка этого расширенного макросами синтаксиса.

P.S. Если хочется погрузится, рекомендую начать с презентации VladD2 — https://rsdn.org/forum/dotnet/4280350.1
Автор: VladD2
Дата: 22.05.11
Re[9]: Прыжки по коду
От: Evgeny.Panasyuk Россия  
Дата: 15.12.16 12:29
Оценка: 8 (1) +2
Здравствуйте, licedey, Вы писали:

L>Эти проклятые формы каждый раз с нуля верстать — "одно удовольствие". Если бы можно было как-то шаблонизировать этот процесс...у меня у самого есть несколько идей своего велосипеда, могу поделится


Для шаблонизации "процессов" частенько достаточно простого кодоненератора на каком-нибудь Python, или близкого C#-истам T4.

L>Если вы считаете основной фишкой языка те же макросы например, то найдите целевую аудиторию и покажите ей что ваше решение мощное и экономит время.


Думаю изначально целевая аудитория/платформа выбрана не та, ИМХО.
Во-первых метапрограммирование даёт быстродействие по сравнению с более динамичными решениями. Например та же сериализация на макросах против сериализации на runtime-reflection — возможности примерно одинаковые, но отличается скорость. Для аудитории которая как молитву произносит всёвбазуупирается это в общем-то не интересно. А тем кому всё же иногда требуются — умеют расчехлять T4 при необходимости, и в ус не дуют.
Во-вторых даёт большую типобезопасность по сравнению с теми же динамическими аналогами. Но ради этого преимущества, да и то которое есть только в некоторых местах, вылазить из уютного, знакомого и популярного C#/Java/whatever мало кто будет. Многие вообще используют целиком динамические языки — а уж C# с динамизмом в некоторых местах вообще без проблем переживут.
В-третьих это расширения языка, но по заверениям самого VladD2 "многие воспринимают в штыки (просто потому, что не пробовали и это страшно)" — а уж программисты корпоративных опердней тем более будут воспринимать в штыки.
Коварный .NET — с одной стороны дал Nemerle огромную экосистему, обеспечил кое-какой старт и кое-какую применимость, а с другой обрёк на перманентный маргинальный статус.

А вот если бы был прицел на аудиторию C++, на соответствующую платформу, то это был бы отличный кандидат на пост убийцы C++. Ибо там есть огромный спрос на всякие zero-cost абстракции, метапрограммирование в почёте (даже всякая шаблонная "магия" а-ля enable_if легитимизируется переползая в стандарт), распространены встроенные доменно-специфичные языки и это несмотря на все языковые трудности и перегревы компиляторов.
Отредактировано 15.12.2016 12:56 Evgeny.Panasyuk . Предыдущая версия . Еще …
Отредактировано 15.12.2016 12:40 Evgeny.Panasyuk . Предыдущая версия .
Отредактировано 15.12.2016 12:39 Evgeny.Panasyuk . Предыдущая версия .
Re[4]: Прыжки по коду
От: AleksandrN Россия  
Дата: 15.12.16 15:45
Оценка:
Здравствуйте, Философ, Вы писали:

Ф>>>Далее строй так, чтобы каждая подсистема могла быть изображена семью фигурками на плоскости и т.д.

S>>Вот я бы не стал рекомендовать ничего подобного, т.к в большинстве случаев подобные хитрые схемы вырождаются в слепой карго-культ в стиле трёх сигм или ещё какой мутотени.

Ф>К сожалению твоя общая рекомендация "есть слона по кусочкам" часто приводит к тому, что каждый кусочек слона связан с миллиардом других кусочков слона, и даже просто добраться до кусочка 1ACE8 составляет проблему, не говоря уже о том, чтобы его поправить так, чтобы весь слон при этом не рассыпался. Моя основная мысль заключалась в том, что нужно оперировать разумным кол-вом кусочков за раз. А этого можно добиться только иерархическим проектированием этого самого слона.


Для этого, прежде чем кодить, нужно разбить слона на отдельные части и определить взаимосвязи между ними, при этом стремиться к тому, что бы интерфейс взаимодействия частей содержал как можно меньше функций.
Например — некоторые части слона:
Несущая конструкция, выполняющая так-же транспортные функции (скелет и мышцы)
Система управления, состоящая из ЦПУ, шины данных и датчиков (нервная система, состоящая из головного мозга, нервов и органов чувств)
Продуктопровод с насосной станцией (кровеносная система и сердце)
Система питания (пищеварительная система)
Система вывода отходов

Крупные части сообщаются между собой посредством шины данных и продуктопровода. На низком уровне каждая крупная часть состоит из объектов разных типов, унаследованных от класса Клетка.

Т.е. — имеем составные объекты, у каждого из которых своя функция и сообщающегося с другими по понятному интерфейсу. Каждый составной объект состоит из объектов более низкого уровня. В результате имеем систему с понятной иерархией объектов и конструкцией. Но при этом — в целом это сложнейшая система.
Re[5]: Прыжки по коду
От: Sinix  
Дата: 15.12.16 17:08
Оценка: +1
Здравствуйте, AleksandrN, Вы писали:


AN>Крупные части сообщаются между собой посредством шины данных и продуктопровода. На низком уровне каждая крупная часть состоит из объектов разных типов, унаследованных от класса Клетка.


Не совсем удачная идея

Тут лучше не увлекаться аналогиями и разбирать конкретные примеры на конкретных сценариях. Иначе фигня получается.
Re[6]: Прыжки по коду
От: AleksandrN Россия  
Дата: 16.12.16 08:17
Оценка: +1
Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, AleksandrN, Вы писали:



AN>>Крупные части сообщаются между собой посредством шины данных и продуктопровода. На низком уровне каждая крупная часть состоит из объектов разных типов, унаследованных от класса Клетка.


S>Не совсем удачная идея


S>Тут лучше не увлекаться аналогиями и разбирать конкретные примеры на конкретных сценариях. Иначе фигня получается.


Согласен, что аналогия не очень удачная получилась. А для примера хорошо бы посмотреть архитектуру какого-нибудь проекта топик-стартера и обсудить удачные и неудачные идеи в архитектуре.
Re[10]: Прыжки по коду
От: licedey  
Дата: 17.12.16 00:06
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, licedey, Вы писали:


L>>Эти проклятые формы каждый раз с нуля верстать — "одно удовольствие". Если бы можно было как-то шаблонизировать этот процесс...у меня у самого есть несколько идей своего велосипеда, могу поделится


EP>Для шаблонизации "процессов" частенько достаточно простого кодоненератора на каком-нибудь Python, или близкого C#-истам T4.


Python, T4 — ок. Но громоздко и сложно, особенно для UI. Я считаю должно быть решение "для домохозяйки", уменьшающее риск ошибки и универсальное как Калашников.
А в случае упомянутых тулс, каждый раз — по сути, пиши новый велосипед.

L>>Если вы считаете основной фишкой языка те же макросы например, то найдите целевую аудиторию и покажите ей что ваше решение мощное и экономит время.


EP>Думаю изначально целевая аудитория/платформа выбрана не та, ИМХО.

EP>Во-первых метапрограммирование даёт быстродействие по сравнению с более динамичными решениями. Например та же сериализация на макросах против сериализации на runtime-

Основная аудитория, я так понимаю, сидит тут. Это энтузиасты которые могут позволить себе поковыряться в чем-то новом. У остальных, как вы правильно заметили, дедлайны и тупо нет времени на изучение. Я одним взглядом смотрю на синтаксис и мне страшновато, хотя бы оттого что он не С-подобный. Признаться мне и от Objective-C и Ruby, примерно такие же ощущения-недоумения. А есть еще такие дикие языки как Perl, Haskell и F#. Вот меня точно Высшая Сила накажет, если отправит на проект где они используются.
Ответ прост — я хочу есть и мне нужен молоток.
Я вижу только одну причину развития любого языка — это новая платформа. С++ стал нужен для UI, Java для кросс-платформ и веб, PHP для веба, Objective-C для iPhone. C# тупо, потому что существующие инструменты под Win устарели. Пусть грубо — но я вижу причину только в этом.
Почему бы не адаптировать Nemerle скажем для IoT. Или возьмем более узко — скраперы сайтов. Или тестирование. Да даже если он под мобайл будет заточен лучше Xamarin, я тут же брошусь учить.
Вот лично мне из Nemerle понадобился Peg, 4 года назад, когда не было еще Roslyn, и выбор пал больше потому, что я сидел на этом форуме и слышал про Nemerle.
Необходимость+Огласка там где зависаешь=Популярность языка.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.