В примере демонстрируется не какая-то библиотека, а динамические возможности Delphi при интеграции ActiveX компонента. Т.е. там дельфи не знает про excel, а знает только про IDispatch.
Зависит от разработчика. Для .NET разработчика posh очень удобен тем, что можно использовать свои знания и инструменты там — весь фреймворк нативно доступен.
Возможно, для веб разработчика баш удобнее тем, что с ним все равно знаком по серверному линуксу.
Ну вот вам самому не кажется, что наличие intellisense в PS — это как бы сами разработчики расписались в том, что они сделали настолько плохо, что без подсказок с этим уже как бы и нельзя нормально работать?
Нет. Просто с подсказками удобнее чем без подсказок.
Я честно не представляю человека, который в это вот всё полезет добровольно.
А как вы без гугла добрались бы до команды dir?
Можно help Get-* узнать все команды которые что, что получают
Про параметры есть справка (наберите help dir или dir -?)
Или intellisence.
Свойства есть в intellisense или ls | gm
Просто нужно несколько базовых приемов работы знать. Попробуйте логически понять как вы разобрались с командами cmd — скорее всего гуглили.
А сейчас есть powershell_ise с intellisense и справка в которой есть поиск и способ изучить структуру выхлопа при помощи gm
Наверное, подразумевается что чаще вы будете запускать powershell и в нем что-то делать а не апускать каждый раз отдельную команду и покидать и тогда вам потребуется профиль чтобы написать туда всяких удобных фукнций и команд
Мы говорили про методы try* — они не возвращают ничего о причине, потому, что считают ровно одну причину не исключением, а нормальным ходом выполнения.
а теперь там эксепшн падает и до него выполнение не доходит
Если там было что-то связанное с РСУБД то такой ситуации нет — там и раньше могло упасть.
"Cannot convert ParseError to io::Error"
Как в Java checked exceptions, только там, похоже, многие признают это не очень удачной идеей.
Наличие триллиона TryXXX методов показывают, что всё не так просто. Почему Parse не возвращает Option, а бросает исключение? Почему нет способа получить значение из словаря которого там может не быть (кроме того же неуклюжего TryGetValue)?
Возможно, потому, что nullable появились не сразу.
Короче нет, эксепшны это хорошо когда их не надо обрабатывать, но обычно надо обрабатывать или нет знает только код выше.
Поэтому оно обычно просто передается наверх до того кода, который знает как его обрабатывать.
Это не монотонное засорение. Так, например, если функция раньше всегда возвращала знчение а теперь может упасть, это ломающее изменение.
Наверное, в системных языках это важно. Потому что есть частый случай когда функция не может упасть и важно его поддежать. В прикладных скорее проще принять, что все может упасть.
И если у вас там какие-нибудь CommitTransaction() за вызовом этой функции были то очень желательно учесть, что транзакции теперь иногда могут отменяться.
Тут см выше. Транзакции, наверное, бывают разные но в РСУБД, практически все внутри транзакции может упасть.
В-общем, насколько я понял, из-за упора на системность и быстродействие "исключения везде" для раста не подходят, потму, что это не zero cost abstraction.
Я бы тогда согласился с предложением, как здесь сказали, do-нотации, чтобы хотя бы вопросики ставить не на каждуй строчку, а на блок.
Вот тут мне интересно. В дотнете, например они по умолчанию стандартными обработчиком — выводятся пользователю.
В моей практике в большинстве ситуаций с исключениями ничего не надо делать особенного — просто передать на уровень абстракции выше. На каком-то уровне они записываются в лог или показываются пользователю или заворачиваются в исключение более высокого уровня.
Очень редко нужно делать что-то кроме этих нескольких вариантов (например сгенерировать дамп при oom, retry при разных ситуациях с сетью и блокировках).
Т.е. умолчания с моей точки зрения позволяют не засорять код монотонным повторением "здесь все как и везде".
А как у вас? Какую особенную обработку исключений вы делаете?
"Субъективно красивый" это все равно что "хорошо работает" только первое выдает натренированная нейросетка непонятно каким образом. Она натренирована на некотором наборе компромиссов (читаемость против скорости, читаемость против быстроты разработки, концептуальная целостность против практичности и т.д.) и может работать хуже на другом.
Этот набор компромиссов везде свой, даже у каждого программера свой собственный опыт.
Если вы идете в другую область или у вас разногласия с другим человеком или у вас новый иструмент, проверяйте красивость логическими рассуждениями.
Если вам нужно быстро и область привычная дайте поработать нейросетке — она оценит быстрее.
Это не с вашей точки зрения — это ваше предположение о том, что человек который решил опорожнить свой мочевой пузырь на вашей кухне не путылся вас оскорбить. По мне так это предпложение излишне
Тут наверное зависит от опыта. В моем случае, 100% таких людей были маленькие дети.
Вот это вам непонятно. Причем временно — все поймете в конечно итоге
ну это то понятно — мои интересы вас не волнуют :)
Это вы про что вообще?
он просто захотел пописать и реализовал свое желание там, где ему было удобно
С моей точки зрения это не "он пытается меня оскорбить" это "он делает что-то, что я воспринимаю как оскорбительное", "пытается" подразумевает целенаправленную деятельность.
В-общем, мне непонятно, почему проверка знаний путем задания вопроса это оскорбление, а путем предложения задачки — это нет.
Жалко, мне интересен был бы ваш опыт. У меня лично часто оказывается, что разговор про опыт дает более оптимистичное представление о человеке, чем решение задач/вопросы о концепциях.
расщифровываю — представьте, что вам задают вопросы вроде «а вы моете руки после туалета?»
Ну для меня определение желание оскорбить тут зависит от контекста (какова веротяность что на данном этапе собеседник видел людей не моющих руки, например). Т.е. желание оскорбить здесь если человек испытывает какую-то эмоцию по поводу метода equals И он считаете что вы оскорбляетесь от того, что не знаете метода equals. Т.е. даже сомнение о каком-то уровне вашей квалификации оскорбительно. С другой стороны, зачем проводить интервью, если сомнений нет?
только мне лень читать чужой код.
А вы в code review в основной работе участвуете? В чужом коде разбираетесь на основной работе? Просто по моей оценке те примеры, которые можно написать на собеседовании мизер по сравнению с тем что надо читать на работе.
Я думаю, в реальности это смесь. В инструкции всего не напишешь и от понимание уборщицей своих целей будет зависеть несколько она будет удобна окружающим. Соответственно, ее будут больше ценить при прочих равных и больше платить.
А как вы узнаете что им на самом деле нужно? С моей точки зрения так категорично судить о влиянии Инстаграма на жизнь людей можно либо тщательно изучив все прямые и косвенные последствия, либо имея склонность очень уверенно судить о вещах в которых не разбираешься.
Полезность и уникальность это разные вещи. Уникальность зависит от точности сравнения. Может потребителям нравился другой цвет иконки или другое расположение элементов управления.
Доширак не хуже обеда в ресторане, он просто для других целей.
В примере демонстрируется не какая-то библиотека, а динамические возможности Delphi при интеграции ActiveX компонента. Т.е. там дельфи не знает про excel, а знает только про IDispatch.
Зависит от разработчика. Для .NET разработчика posh очень удобен тем, что можно использовать свои знания и инструменты там — весь фреймворк нативно доступен.
Возможно, для веб разработчика баш удобнее тем, что с ним все равно знаком по серверному линуксу.
Нет. Просто с подсказками удобнее чем без подсказок.
Он удобнее чем CMD только тормознее.
А как вы без гугла добрались бы до команды dir?
Можно help Get-* узнать все команды которые что, что получают
Про параметры есть справка (наберите help dir или dir -?)
Или intellisence.
Свойства есть в intellisense или ls | gm
Просто нужно несколько базовых приемов работы знать. Попробуйте логически понять как вы разобрались с командами cmd — скорее всего гуглили.
А сейчас есть powershell_ise с intellisense и справка в которой есть поиск и способ изучить структуру выхлопа при помощи gm
Я не вижу там вообще powershell
Наверное, подразумевается что чаще вы будете запускать powershell и в нем что-то делать а не апускать каждый раз отдельную команду и покидать и тогда вам потребуется профиль чтобы написать туда всяких удобных фукнций и команд
Тут имеется ввиду время старта.
JFYI
Мы говорили про методы try* — они не возвращают ничего о причине, потому, что считают ровно одну причину не исключением, а нормальным ходом выполнения.
Если там было что-то связанное с РСУБД то такой ситуации нет — там и раньше могло упасть.
Как в Java checked exceptions, только там, похоже, многие признают это не очень удачной идеей.
Наличие триллиона TryXXX методов показывают, что всё не так просто. Почему Parse не возвращает Option, а бросает исключение? Почему нет способа получить значение из словаря которого там может не быть (кроме того же неуклюжего TryGetValue)?
Возможно, потому, что nullable появились не сразу.
Поэтому оно обычно просто передается наверх до того кода, который знает как его обрабатывать.
Наверное, в системных языках это важно. Потому что есть частый случай когда функция не может упасть и важно его поддежать. В прикладных скорее проще принять, что все может упасть.
Тут см выше. Транзакции, наверное, бывают разные но в РСУБД, практически все внутри транзакции может упасть.
В-общем, насколько я понял, из-за упора на системность и быстродействие "исключения везде" для раста не подходят, потму, что это не zero cost abstraction.
Я бы тогда согласился с предложением, как здесь сказали, do-нотации, чтобы хотя бы вопросики ставить не на каждуй строчку, а на блок.
Что вы об этом думаете?
Вот тут мне интересно. В дотнете, например они по умолчанию стандартными обработчиком — выводятся пользователю.
В моей практике в большинстве ситуаций с исключениями ничего не надо делать особенного — просто передать на уровень абстракции выше. На каком-то уровне они записываются в лог или показываются пользователю или заворачиваются в исключение более высокого уровня.
Очень редко нужно делать что-то кроме этих нескольких вариантов (например сгенерировать дамп при oom, retry при разных ситуациях с сетью и блокировках).
Т.е. умолчания с моей точки зрения позволяют не засорять код монотонным повторением "здесь все как и везде".
А как у вас? Какую особенную обработку исключений вы делаете?
"Субъективно красивый" это все равно что "хорошо работает" только первое выдает натренированная нейросетка непонятно каким образом. Она натренирована на некотором наборе компромиссов (читаемость против скорости, читаемость против быстроты разработки, концептуальная целостность против практичности и т.д.) и может работать хуже на другом.
Этот набор компромиссов везде свой, даже у каждого программера свой собственный опыт.
Если вы идете в другую область или у вас разногласия с другим человеком или у вас новый иструмент, проверяйте красивость логическими рассуждениями.
Если вам нужно быстро и область привычная дайте поработать нейросетке — она оценит быстрее.
Тут наверное зависит от опыта. В моем случае, 100% таких людей были маленькие дети.
Вы меня переоцениваете.
Это вы про что вообще?
С моей точки зрения это не "он пытается меня оскорбить" это "он делает что-то, что я воспринимаю как оскорбительное", "пытается" подразумевает целенаправленную деятельность.
В-общем, мне непонятно, почему проверка знаний путем задания вопроса это оскорбление, а путем предложения задачки — это нет.
Жалко, мне интересен был бы ваш опыт. У меня лично часто оказывается, что разговор про опыт дает более оптимистичное представление о человеке, чем решение задач/вопросы о концепциях.
Ну для меня определение желание оскорбить тут зависит от контекста (какова веротяность что на данном этапе собеседник видел людей не моющих руки, например). Т.е. желание оскорбить здесь если человек испытывает какую-то эмоцию по поводу метода equals И он считаете что вы оскорбляетесь от того, что не знаете метода equals. Т.е. даже сомнение о каком-то уровне вашей квалификации оскорбительно. С другой стороны, зачем проводить интервью, если сомнений нет?
А вы в code review в основной работе участвуете? В чужом коде разбираетесь на основной работе? Просто по моей оценке те примеры, которые можно написать на собеседовании мизер по сравнению с тем что надо читать на работе.
Я думаю, в реальности это смесь. В инструкции всего не напишешь и от понимание уборщицей своих целей будет зависеть несколько она будет удобна окружающим. Соответственно, ее будут больше ценить при прочих равных и больше платить.
А гэнти гэмбуцу — японцы!
А как вы узнаете что им на самом деле нужно? С моей точки зрения так категорично судить о влиянии Инстаграма на жизнь людей можно либо тщательно изучив все прямые и косвенные последствия, либо имея склонность очень уверенно судить о вещах в которых не разбираешься.
Полезность и уникальность это разные вещи. Уникальность зависит от точности сравнения. Может потребителям нравился другой цвет иконки или другое расположение элементов управления.
Доширак не хуже обеда в ресторане, он просто для других целей.
У кого? Другого бизнеса? Значит есть бизнес который производит птичье молоко?