Ну, можно использовать stash вместо временной ветки, но в SourceTree нет такой свободы действий с ним.
TortoiseGit – не уверен, вроде нет (собственно, политика git с его индексом не способствует реализации такой фичи, это меркуриал с его mq как бы намекает – сделай, мол). В SourceTree – точно нет.
Но это не основная моя претензия к git (в конце концов не так часто приходится нарезать несколько коммитов из рабочей копии), так, мелкое неудобство. Просто вы сказали, что якобы в git это удобнее, что противоречит моему опыту.
Процесс именно что усложнился. Сейчас мне проще с той же целью (чтобы что проверил – то и закоммитил) закоммитить во временную ветку, вернуться на рабочую и по частям переносить из временной, собирая отдельные коммиты. Заметное усложнение, так что я, честно говоря, редко так делаю, чаще коммичу вслепую :-)
Ну и инструмент у меня был как раз "в коробке", я в те времена ставил TortoiseHg, там работа с shelve (продвинутый аналог git stash) очень удобная.
1 – поспорил бы. В hg у меня для таких случаев был подход: убираю в stash (ну или как он там назывался, давно дело было) все изменения, кроме тех, что нужно закоммитить (есть удобный инструмент для переноса их туда-обратно, вплоть до отдельных строк), компилирую-проверяю, коммичу, переношу из stash следующую порцию и так далее.
Т.е., грубо говоря, что не в индексе – того и в рабочей копии нет, можно проверять перед коммитом.
Было удобно. А с переходом на git – стал делать то же самое вслепую: выбрал файлы в индекс, закоммитил. Потому что процесс, аналогичный привычному, резко усложнился.
Вот да, после полноценных бранчей гитовское поделие родом из CVS – боль... Но, увы, в битве систем контроля версий победил гит, приходится приспосабливаться, добавлять костыли...
Из инженеров – это уже почти что не свитчер, техническое высшее и все основные тараканы уже есть, надо только знаний по теме набраться (а так мы все в некотором роде свитчеры, языки и фреймворки время от времени меняются)
Вот как раз эти два года у вас есть все шансы нагнать, если будет желание. Основы закладываются на первых курсах, а к старшим "методичка есть? Сейчас докурим и пойдём сдавать". Ну то есть на старших – важна доступность знаний (а сейчас вы их сможете найти, было бы желание), а умение планомерно учиться уже есть.
Тут трудно сказать, до какой степени вышмат помогает, а до какой – человек, который имеет способности к нему (и, соответственно, выбравший это направление учёбы), обладает и способностями к программированию.
Я, честно говоря, увидев ваше "избавляемся от переменных", ожидал увидеть переход к SSA и далее к чистым функциям, и не понимал, как это укладывается в выходные)))
Хороший вопрос, жаль, моей квалификации не хватит, чтобы на него ответить. Тут недавно кто-то выкладывал цикл статей по теории оптимизирующих компиляторов, может быть, на этом уровне найдётся пример оптимизации, преобразующей рекурсивный вызов f(n) в рекурсивный же вызов f(acc,n) и разворачивающей, где надо, цепочку вызовов. Но не уверен, что такая оптимизация справится с более сложными задачами. Как пример – берём наивную рекурсивную реализацию qsort. Там есть хвостовой вызов, но фокус в том, что из двух вызовов хвостовым может быть только один, и чтобы минимизировать использование стека – нужно выбрать, какой из двух вызывать рекурсивно (тот, что для меньшей части массива), а какой подвергнуть TCO (тот, что для большей).
У преподавателей, насколько я знаю, с этим не так хорошо, как у программистов. Если программист, учась, вкладывается в себя – то преподаватель вкладывается в общество, и прямой выгоды может не получить (а косвенную получат его дети или даже внуки).
Корявый перевод слова hack.
Смотрю на слово "extends" вместо значка ⊂ (является подмножеством) в применении к второму аргументу Pick и грущу.
Ну, можно использовать stash вместо временной ветки, но в SourceTree нет такой свободы действий с ним.
TortoiseGit – не уверен, вроде нет (собственно, политика git с его индексом не способствует реализации такой фичи, это меркуриал с его mq как бы намекает – сделай, мол). В SourceTree – точно нет.
Но это не основная моя претензия к git (в конце концов не так часто приходится нарезать несколько коммитов из рабочей копии), так, мелкое неудобство. Просто вы сказали, что якобы в git это удобнее, что противоречит моему опыту.
Процесс именно что усложнился. Сейчас мне проще с той же целью (чтобы что проверил – то и закоммитил) закоммитить во временную ветку, вернуться на рабочую и по частям переносить из временной, собирая отдельные коммиты. Заметное усложнение, так что я, честно говоря, редко так делаю, чаще коммичу вслепую :-)
Ну и инструмент у меня был как раз "в коробке", я в те времена ставил TortoiseHg, там работа с shelve (продвинутый аналог git stash) очень удобная.
1 – поспорил бы. В hg у меня для таких случаев был подход: убираю в stash (ну или как он там назывался, давно дело было) все изменения, кроме тех, что нужно закоммитить (есть удобный инструмент для переноса их туда-обратно, вплоть до отдельных строк), компилирую-проверяю, коммичу, переношу из stash следующую порцию и так далее.
Т.е., грубо говоря, что не в индексе – того и в рабочей копии нет, можно проверять перед коммитом.
Было удобно. А с переходом на git – стал делать то же самое вслепую: выбрал файлы в индекс, закоммитил. Потому что процесс, аналогичный привычному, резко усложнился.
Вот да, после полноценных бранчей гитовское поделие родом из CVS – боль... Но, увы, в битве систем контроля версий победил гит, приходится приспосабливаться, добавлять костыли...
Я нагуглил про оптику, с роботом, но принцип именно тот, что вы описали: https://www.optic-electric.com/78.html
А тут не будет "решением по умолчанию" priority queue? Ну там, бинарная куча (но вообще в Java она, наверное, есть в стандартной библиотеке)?
Потому как хэши и всё такое – думать надо, а тут сходу log(N), редко когда есть необходимость оптимизировать дальше.
А я вот про свой знаю, он мне раз в 24 года пригождается – то в госконтрру устроиться, то разрешение на работу в другой стране оформить.
Чую, наберётесь опыта в программировании и уйдёте опять в менеджмент, уже на новом уровне :-)
Из инженеров – это уже почти что не свитчер, техническое высшее и все основные тараканы уже есть, надо только знаний по теме набраться (а так мы все в некотором роде свитчеры, языки и фреймворки время от времени меняются)
Вот как раз эти два года у вас есть все шансы нагнать, если будет желание. Основы закладываются на первых курсах, а к старшим "методичка есть? Сейчас докурим и пойдём сдавать". Ну то есть на старших – важна доступность знаний (а сейчас вы их сможете найти, было бы желание), а умение планомерно учиться уже есть.
Тут трудно сказать, до какой степени вышмат помогает, а до какой – человек, который имеет способности к нему (и, соответственно, выбравший это направление учёбы), обладает и способностями к программированию.
Да, оно самое.
Я, честно говоря, увидев ваше "избавляемся от переменных", ожидал увидеть переход к SSA и далее к чистым функциям, и не понимал, как это укладывается в выходные)))
Хороший вопрос, жаль, моей квалификации не хватит, чтобы на него ответить.
Тут недавно кто-то выкладывал цикл статей по теории оптимизирующих компиляторов, может быть, на этом уровне найдётся пример оптимизации, преобразующей рекурсивный вызов f(n) в рекурсивный же вызов f(acc,n) и разворачивающей, где надо, цепочку вызовов.
Но не уверен, что такая оптимизация справится с более сложными задачами. Как пример – берём наивную рекурсивную реализацию qsort. Там есть хвостовой вызов, но фокус в том, что из двух вызовов хвостовым может быть только один, и чтобы минимизировать использование стека – нужно выбрать, какой из двух вызывать рекурсивно (тот, что для меньшей части массива), а какой подвергнуть TCO (тот, что для большей).
Нет, конечно. Ведь после рекурсивного вызова нужно выполнить умножение.
У преподавателей, насколько я знаю, с этим не так хорошо, как у программистов. Если программист, учась, вкладывается в себя – то преподаватель вкладывается в общество, и прямой выгоды может не получить (а косвенную получат его дети или даже внуки).
Надо на каждый ещё архив флибусты залить)
Учитывая Эппл – скорее "почему не Swift?"
Его после такого мог изрядно расстроить работодатель.