а пользовались ей?

Mi

Я не пользовался

Стилсериес пользовался и логитек

Я нет, увидел вот недавно в продаже, в киеве она вообще 67$, интересно попробовать что за зверь

выглядит нормально, цена тоже ок. жаль не черная)

Я бы не стал брать

Глянь отзывы лучше на уже популярные продукты

И выбери из них

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

я механику не юзал никогда

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

Это и для игр не нужно

Просто удобнее и приятнее пользоваться

отклик самой клавивиши быстрее?

Привыкаешь к свитчам и печатаешь со скоростью света

Ну да, тебе не надо до конца нажимать на клавишу

Достаточно довести до щелчка

Долговечность еще один из плюсов

Ее супер легко чистить

Ну пока моя 2 года живет

Ну в общем, наверное можно и ми взять

Она стоит дешево

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

я смотрю что на амазоне от $35 есть механика, ну и в райное 60-70 варианты тоже есть

Всем привет, кто то слышал что то про микрокернелы на jvm ?

какие то пейпары или статьи ?

извините не микрокернел а юникернел

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

4 года на мембранке со слим клавишами и малым ходом , полет нормальный. И вин и мак. Скорость печатки высокая. Тактильные ощущения есть, щелчки присутствуют. Относительно полноразмерной механики тихая, но чуть чуть громче и жестче чем клавиши на макбуке) Полностью ни разу не чистил. Пробег космический. Работает как часы. https://market.yandex.ru/product--genius-slimstar-i222-black-usb/6845216

/stat@combot

combot.org/chat/-1001034178083

О! У Алексея 666 с юбилеем так сказать @fomkin

Ребят, а какой нейминг вы предпочитаете для тайп параметров? Короткие типа [A, B] или говорящие, типа [In, Out]? И почему именно такой предпочитаете?

Когда параметр один - достаточно одной буквы обычно, два - it depends, три и больше - подробное название

говорящий - потому что понять легче потом что это

говорящий - потому что понять легче потом что это

даже если параметр один?

для одного параметра соглашусь с комментом выше

А если один параметр всегда несет какой-то бизнесовый смысл?

если можно объяснить смысл параметра словом, не запутав человека - то говорящий

иначе лучше A,B,C

я бы один пар-р назвал, если на него есть ограничения, типа TUser <: User

contramap

я бы один пар-р назвал, если на него есть ограничения, типа TUser <: User

Плюсую

говорящий - потому что понять легче потом что это

А почему тогда пацаны из всяких scalaz так не делают?

у них другой уровень абстракции

Ну там же тоже можно как-то более менее по-человечески обозвать, хотя бы также In, Out

я когда параметр один использую "осмысленую букву" например, R for Result

я когда параметр один использую "осмысленую букву" например, R for Result

А почему не написать Result?

А почему не написать Result?

в случае одного параметра - субъективно не вижу очевидных преимуществ

просто когда речь заходит про нейминг переменных все соглашаются, что нужно иметь говорящие названия. А когда речь идет о типах, то там везде торчат T, F, A, R

только ситхи всё возводят в абсолют)

T - type , F -function, A - ahuiegoznaet, R - Reducer ?

T - type , F -function, A - ahuiegoznaet, R - Reducer ?

R - Result :)

F, A, B - это все общеупотребительные названия. F - имя для конструктора типов, A и B - это когда есть функция/преобразование из A в B

Откуда вообще пошла эта практика коротких названий типов?

наверное впадлу клацать :D (мне лично впадлу, если из контекста все понятно)

названия же понятно называть тебе не впадлу?

всм переменные

ну то есть какое приемущество у коротких названий перед длинными, кроме как "впадлу писать"?

ну я пишу "r" вместо "result", "xs" - где 1 список/массив/…, "x" - для лямбд с 1 параметром

R - Result :)

тож можно

ну я пишу "r" вместо "result", "xs" - где 1 список/массив/…, "x" - для лямбд с 1 параметром

Это если локальный скоуп или лямбда однострочная. Ты же не будешь свойство класса называть xs?

А тайп параметр имеет обычно довольно большой скоуп

а чо _ уже не модно?)

а чо _ уже не модно?)

а если "x" - это объект, и в лямбде операция над двумя свойствами?

А тайп параметр имеет обычно довольно большой скоуп

я бы не сказал. зачастую только сигнатура метода

ERROR: S client not available

а если "x" - это объект, и в лямбде операция над двумя свойствами?

какая плохая лямбда

а если "x" - это объект, и в лямбде операция над двумя свойствами?

lenses!

А много тут людей работают используя скалу?

А тайп параметр имеет обычно довольно большой скоуп

если класс большой, то соглашусь, лучше нормальные тайп-параметры писать (In, Out вообще отлично). А еще лучше не писать большие классы

lenses!

у меня смузи из монитора потекло

у меня смузи из монитора потекло

не в падлу, набери для меня

:D хорошо, будет с привкусом макбука

Мне кажется, что любое наименование - компромисс между подробностью (лёгкостью первоначального понимания) и удобством последующего использования. В каком-нибудь List[T] почти сразу ясно, что T - тип параметра и если назвать не T, а Item - это будет только мельтешить перед глазами

Мне кажется, что любое наименование - компромисс между подробностью (лёгкостью первоначального понимания) и удобством последующего использования. В каком-нибудь List[T] почти сразу ясно, что T - тип параметра и если назвать не T, а Item - это будет только мельтешить перед глазами

тип какого параметра?

я бы не сказал. зачастую только сигнатура метода

Опять же, даже если про сигнатуру. Ты ведь скорее всего называешь параметры метода каким-то нормальными челоческими словами, а не a, b, c? Почему тогда с тайп параметром иначе?

тип какого параметра?

тьфу) тип элемента листа

Мне кажется, что любое наименование - компромисс между подробностью (лёгкостью первоначального понимания) и удобством последующего использования. В каком-нибудь List[T] почти сразу ясно, что T - тип параметра и если назвать не T, а Item - это будет только мельтешить перед глазами

Спорно. Вот не думаю, что если бы был List[Item] или List[Elem] в стандартной либе, то кто-то бы возмущался.

Опять же, даже если про сигнатуру. Ты ведь скорее всего называешь параметры метода каким-то нормальными челоческими словами, а не a, b, c? Почему тогда с тайп параметром иначе?

действительно, давайте посмотрим какие имена дают параметрам в scalaz https://github.com/scalaz/scalaz/blob/series/7.3.x/core/src/main/scala/scalaz/Applicative.scala

def qwee[A,B](in:A):B - в принципе по сигнатуре понятно что мы принимаем один аргумент типа A(к тому же у него есть имя), и вероятнее всего преобразуем его в тип B

А почему тогда пацаны из всяких scalaz так не делают?

в слике у родительских параметров словами, а у алиасов уже сокращение до первой буквы abstract class Shape[Level <: ShapeLevel, -Mixed_, Unpacked_, Packed_] type Shape[Level <: ShapeLevel, -M, U, P] = lifted.Shape[Level, M, U, P]

мне кажется, сейчас List[T] тоже никого не возмущает. Это же стандартная либа, которая (кмк) должна быть примером для всех разработчиков

a,x,fa,l,ab

Спорно. Вот не думаю, что если бы был List[Item] или List[Elem] в стандартной либе, то кто-то бы возмущался.

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

А почему тогда пацаны из всяких scalaz так не делают?

потому что они крутые теоретики, а не жалкий плебс </сарказм>

всем должны быть очевидны их гениальные мысли!

F[_], A, B - в коде "с монадами" эти имена уже де-факто имеют некоторую дополнительную семантику

потому что они крутые теоретики, а не жалкий плебс </сарказм>

завис в поисках открывающегося тега

завис в поисках открывающегося тега

он импилистно в начале

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

астыньте, это маркетинг

поздно я

Хм, готов за 60 касарей научить скале ?

тут в этой схеме препод в лучшем случае 5 получит

def qwee[A,B](in:A):B - в принципе по сигнатуре понятно что мы принимаем один аргумент типа A(к тому же у него есть имя), и вероятнее всего преобразуем его в тип B

Вот из примера выше: def traverse[A, G[_], B](value: G[A])(f: A => F[B])(implicit G: Traverse[G]): F[G[B]] Уже как-то не очень-то понятно, не считаешь? Может быть было бы лучше, если было вот так: def traverse[In, NewFunctor[_], Out](value: NewFunctor[In])(f: In => Functor[Out])(implicit NewFunctor: Traverse[NewFunctor]): Functor[NewFunctor[Out]]

он импилистно в начале

и нахрена ты закрыл его? теперь всерьёз что ли писать?

тут в этой схеме препод в лучшем случае 5 получит

какая-то неправильная экономика

тут в этой схеме препод в лучшем случае 5 получит

мда, печально.

Вот из примера выше: def traverse[A, G[_], B](value: G[A])(f: A => F[B])(implicit G: Traverse[G]): F[G[B]] Уже как-то не очень-то понятно, не считаешь? Может быть было бы лучше, если было вот так: def traverse[In, NewFunctor[_], Out](value: NewFunctor[In])(f: In => Functor[Out])(implicit NewFunctor: Traverse[NewFunctor]): Functor[NewFunctor[Out]]

ты привёл отличный довод в пользу однобуквенных названий, спасибо

ты привёл отличный довод в пользу однобуквенных названий, спасибо

Стало длиннее, но намного проще