В F# интересно с точки зрения множественности аргументов: есть каринг (т.е. функция от двух аргументов, это функция от первого аргумента, которая возвращает функцию с примененным первым аргументом:
let f x y = x + y
тогда
f 2 3 вернет 5
f 2 вернет функцию прибавляющую 2 к аргументу
)
это удобно для функционального кода. (map (f 2) — прибавить двойку ко всем элементам списка. Можно написать map ((+) 2) — операторы тоже можно вызывать как функции)
Но можно как вы и предлагаете, сделать функцию от одного аргумента — кортежа. И именно так рабатет вся интеграция с дотнет — наверное потому, что ложно сделать каринг при перегрузке метода по типам параметров. Соответственно карринг по ним не работает.
Их можно вызывать только так:
System.Console.WriteLine(x, y), где скобки это не часть синтаксиса вызова, а констрирование кортежа.
Наверное, это зависит от сообщества и задачи. Тупо, абы что не надо никогда. У нас есть выбор из n вариантов, один из них еще не готов и будет сделан вами. Тут вопрос насколько вы точно оцениваете трудоемкость доведения этого варианта до сравнимого с остальными качества. Как правило, в этом люди оптимистичны.
Еще, я думаю, большую часть, кода, которым вы пользуетесь, вы исключаете из рассмотрения (операционная система, sql server, язык, стандартный фреймворк).
Преимущество общественного транспорта, а не собственного велосипеда, мне видится в первую очередь в снижении затрат непосредственно на кодинг, а над остальным приходится работать.
Кодинг, тестинг (включая in production), документирование, обучение.
Интересно было бы видеть еще какое-то отражение величины проекта (типа колво нерешенных багов на 100 строчек кода) и серьезность (но тут вроде из гитхаба унифицированно ее не извлечь?)
А поскольку приоритеты стороннего разработчика вы не контролируете, то стоит предполагать худшее.
На них можно влиять предоставлением своих ресурсом (деньги, патчи, форк)
Мне интересно качество самой лучшей из библиотек, для какой-то задачи а не большинства. Всегда надо оценивать, что платишь, и что за это получаешь. Но сначала надо хотя бы понять что люди делали до этого когда столкнулись с такой же проблемой. Например, если пишешь статью про велосипеды, надо прочитать существующие статьи, и дописать свое, проставив ссылочки. Про Build vs Buy написана куча материалов — вполне можно их дополнить какими-то своими мыслями или обобщить.
Это если цель сделать что-то полезное, а не просто поучиться это делать. Т.е. как раз для новичков очень полезно писать свои маленькие учебные велосипедики. Или для старичков, которые новички в чем-то еще. В иных случаях как правило создание нового при существующем старом требует обоснования (есть x, y, z, но оно нам не подходит потому, что w).
Идея о том, что новый код лучше старого, явно абсурдна. Старый код использовался. Он протестирован. Множество багов было найдено и они были исправлены. И с этим все в порядке. Код не плодит баги просто валяясь на жестком диске. Как раз наоборот! Программное обеспечение — это что, старый Dodge Dart, который ржавеет просто простаивая в гараже? Это что, плюшевый мишка, который плохо выглядит, если не сделан исключительно из нового материала?
Вернемся обратно к двухстраничной функции. Да, я знаю, это простая функция для отображения окна, но она обросла мусором и прочим барахлом, и никто не знает почему. Ну так я скажу почему: это фиксы багов. Этот кусок исправляет баг, который случился у Нэнси, когда она пыталась установить всё на машину без IE. Этот — тот баг, который происходит при нехватке памяти. А этот — когда файл находится на дискете, а юзер ее выдернул посреди всего. Вот этот вот вызов LoadLibrary ужасен, но благодаря нему код работает на старых версиях Windows 95.
Это, к примеру, относится ко множеству математических построений, которые имеют свои аксиомы (обязательная часть), но примеряются к какой-либо практической (таковой можно считать даже теоретическую физику) области через длительное время после создания.
Не можете привести пример, просто интересно? Например, геометрия Лобачевского сводится к Эвклиду при некоторых параметрах, СТО сводится к Ньютону при скоростях много меньше света.
Что же тогда ограничивает математиков сознательно и подсознательно от генерации огромного множества теорий которые никак не отражают реальность?
Желательно, конечно, сразу использовать эмпирику — для экономии времени.
Но не обязательно? То есть можно создать теорию противоречащую известным фактам — а зачем такая нужна?
Аксиомы — объяснять? :-O Нет, точно, давайте завязывать…
Ну может я не очень правильно выразился, но ход моих рассуждений такой: объяснять — это отвечать на вопрос "почему". Соответсвенно, когда мы про какой-то факт спрашиваем "почему так"? Мы отвечаем "потому, что X" а когда у нас спрашивают "почему X", мы отвечаем "потому, что Y", где X и Y это сумма каких-то утверждений + логика. Соответственно в этой цепочке утверждений мы доходим до "протому, что А", где A это аксиома. В этом смысле аксиома (+ логика) объясняет факты. С моей точки зрения.
Так и капитализм неидеальный. Вообще наверное имеется ввиду просто и быстро вычисляемый численный параметр. Например, прибыль, она не такая (в долгосрочной перспективе).
Расскажите. Я видел только айти, но никаких горизонтальных поручений не видел — только заявки и не персональные. То есть отдел такой-то просит отдел такой-то сделать то-то и то-то. Заявка может быть отклонена или принята в работу.
Причем, по тексту автора у меня сложилось, что, начальство устранилось от управления системой. Например, для меня при немотивированном неудовлетворении заявки естественно пожаловаться наименьшему общему начальнику (разумеется, после попыток горизонтального выяснения дел), а не бомбить чужой отдел заявками в ответ.
Еще мне не очень понятно, почему все заявки считаются одинаковыми как по трудозатратам так и по приносимой пользе (ну или в тексте автора это не видно). Логично же соизмерять цену с ожидаемой выгодой.
А тут предприятие превратили в как бы компьютерную игру не особо настроив игровой баланс и устранились от управления.
В F# интересно с точки зрения множественности аргументов: есть каринг (т.е. функция от двух аргументов, это функция от первого аргумента, которая возвращает функцию с примененным первым аргументом:
let f x y = x + y
тогда
f 2 3 вернет 5
f 2 вернет функцию прибавляющую 2 к аргументу
)
это удобно для функционального кода. (map (f 2) — прибавить двойку ко всем элементам списка. Можно написать map ((+) 2) — операторы тоже можно вызывать как функции)
Но можно как вы и предлагаете, сделать функцию от одного аргумента — кортежа. И именно так рабатет вся интеграция с дотнет — наверное потому, что ложно сделать каринг при перегрузке метода по типам параметров. Соответственно карринг по ним не работает.
Их можно вызывать только так:
System.Console.WriteLine(x, y), где скобки это не часть синтаксиса вызова, а констрирование кортежа.
Наверное, это зависит от сообщества и задачи. Тупо, абы что не надо никогда. У нас есть выбор из n вариантов, один из них еще не готов и будет сделан вами. Тут вопрос насколько вы точно оцениваете трудоемкость доведения этого варианта до сравнимого с остальными качества. Как правило, в этом люди оптимистичны.
Еще, я думаю, большую часть, кода, которым вы пользуетесь, вы исключаете из рассмотрения (операционная система, sql server, язык, стандартный фреймворк).
Кодинг, тестинг (включая in production), документирование, обучение.
Интересно было бы видеть еще какое-то отражение величины проекта (типа колво нерешенных багов на 100 строчек кода) и серьезность (но тут вроде из гитхаба унифицированно ее не извлечь?)
На них можно влиять предоставлением своих ресурсом (деньги, патчи, форк)
Это если цель сделать что-то полезное, а не просто поучиться это делать. Т.е. как раз для новичков очень полезно писать свои маленькие учебные велосипедики. Или для старичков, которые новички в чем-то еще. В иных случаях как правило создание нового при существующем старом требует обоснования (есть x, y, z, но оно нам не подходит потому, что w).
Имхо, это значит что у вас не велосипед а нечто другое со своими требованиями.
… напишет, отправит в эксплуатацию, исправит ошибки и учтет замечания пользователей, сделает редизайн на основе полученного опыта :)
https://habr.com/post/219651/
По поводу дневников мне вспомнилась поучительная история: Сначала они воруют, а когда ты побеждаешь, то тебя убивают
Не можете привести пример, просто интересно? Например, геометрия Лобачевского сводится к Эвклиду при некоторых параметрах, СТО сводится к Ньютону при скоростях много меньше света.
Что же тогда ограничивает математиков сознательно и подсознательно от генерации огромного множества теорий которые никак не отражают реальность?
Нельзя
Но не обязательно? То есть можно создать теорию противоречащую известным фактам — а зачем такая нужна?
Ну может я не очень правильно выразился, но ход моих рассуждений такой: объяснять — это отвечать на вопрос "почему". Соответсвенно, когда мы про какой-то факт спрашиваем "почему так"? Мы отвечаем "потому, что X" а когда у нас спрашивают "почему X", мы отвечаем "потому, что Y", где X и Y это сумма каких-то утверждений + логика. Соответственно в этой цепочке утверждений мы доходим до "протому, что А", где A это аксиома. В этом смысле аксиома (+ логика) объясняет факты. С моей точки зрения.
А при их создании не учитывают существующий к данному моменту опыт? Они не должны объяснять известные к этому моменту явления?
Причем, по тексту автора у меня сложилось, что, начальство устранилось от управления системой. Например, для меня при немотивированном неудовлетворении заявки естественно пожаловаться наименьшему общему начальнику (разумеется, после попыток горизонтального выяснения дел), а не бомбить чужой отдел заявками в ответ.
Еще мне не очень понятно, почему все заявки считаются одинаковыми как по трудозатратам так и по приносимой пользе (ну или в тексте автора это не видно). Логично же соизмерять цену с ожидаемой выгодой.
А тут предприятие превратили в как бы компьютерную игру не особо настроив игровой баланс и устранились от управления.