Так задумано, val и var это публичные поля, в большинстве случаев для читателя разницы между ними нет, поэтому хорошо что их запись отличается только одной буквой.
Ваша идея конечно, но с точки зрения пользователя ( меня в данном случае ) задумка странная. Ведь если разницы нет, то и ключевые слова должны это отображать. А тут они вроде как пытаются это скрыть, хотя разница между ридонли и неридонли полями существенная. Меня как пользователя это еще больше запутает - что от меня хотят скрыть, чего стоит опасаться?
При просмотре кода нам ведь обычно не нужно знать где доступны привязки и функции, мы хотим видеть общую структуру, а видим в первую очередь множество private и internal. Может быть потому Питон так и популярен в том числе, что их там нет.
Ну мне кажется всегда есть желание видеть публичный интерфейс как минимум, т.е. все-таки нужно знать где доступны функции. Мне кажется Питон больше популярен вопреки этому, благодаря сумасшедшему хайпу, благодаря которому его пытаются использовать везде где только можно.
В наборе еще fun есть. Сложность пяти ключевых слов компенсируется тем, что для общего понимания кода разницу между ними можно не учитывать.
Опять же вы говорите это, а разные ключевые слова говорят пользователю: "Внимание! Здесь есть разница", и он начинает ее искать. Если разницы нет, то подход как у груви с def смотрелся бы более логично в коде, имхо.
Личное имхо - отступы конечно режут глаз, наверное питонистам будет норм, но после сиобразных глаза не могут собрать код в структуру быстро.
Не совсем понятно освобождение памяти - будет что-то вроде деструкторов? Видел \@owner модификатор, но непонятно, будет ли он освобождать зависимые ресурсы, вроде RAII?
val/var - еще с Котлина заметно было что много перемешанных переменных var и val смешиваются между собой на взгляд, легко перепутать. Тот же const визуально бы гораздо проще было отличать.
Вообще набор var/val/let/def выглядит сложнее чем мог бы на мой взгляд (как работает def не нашел). Если let - это просто модификатор видимости, то имхо проще для чтения кода было бы добавлять отдельный модификатор видимости чем отдельное ключевое слово.
>Именованный кортеж. Может иметь любое количество элементов, но чаще всего элемент один, так как иначе структура часто будет лучшим выбором.
Тут тоже не совсем ясно, зачем вообще кортеж с одним элементом? Не проще ли просто сам этот элемент и использовать?
Но в целом проект очень интересный, буду отслеживать!
Ну это выдача желаемого за действительное. Такие работники не более ответственные чем любые другие.
Люди вынуждены ограничиваться профессиональным ростом лишь в пределах своей специализации
Нанять такого работника сложно.
На мой взгляд у этих двух фактов одинаковая причина - такие работники никому не нужны на практике, несмотря на теоретические причины почему они могли бы быть полезны. Достаточно посмотреть что от кандидата требуют на интервью - а именно как можно более глубокие знания основной технологии. Поэтому люди уходят в специализацию и поэтому же "дженералистов" сложно нанять.
Какая-то немного странная статья из разряда "раньше было лучше", которая смешивает всё подряд в одну кучу - разработчиков широкого профиля и опытных разработчиков.
На мой взгляд дженералист\разработчик широкого профиля\фуллстэк инженер это вполне распространенное понятие, просто в отличие от статьи оно не привязывается к конкретному времени когда разработчик начал работу в сферу. А статья пытается смешать опыт разработчика и специализацию, заявляя что разработчики с опытом 20 лет лучше пришедших недавно потому что они широкой специализации, а не потому что у них на 15 лет опыта больше. И соответственно назначает неопытных разработчиков каким-то нетакими, "недженералистами".
Следуя определению из статьи - да, со временем людей, начинавших на заре не остаётся, просто потому что время идёт вперёд. Значит ли это что исчезнут умелые разработчики? Наврядли.
Хвалить себя статьёй на Хабре конечно приятно, но нужно замечать свои же рационализации.
Да и судя по той же ссылке на типы с точностью не особо, максимальный float 16 бит в коболе против минимального 32 бит в джаве, а bignum арифметику-то можно везде делать.
Судя по IBM документации у них и нет unsigned типов https://www.ibm.com/docs/en/zos/2.4.0?topic=definitions-cobol-data-type А по производительности - если писать на Яве как на коболе, без динамической аллокации памяти - то и работать всё будет как на Коболе/Си. Возможно даже быстрее, благодаря JIT оптимизациям, которые языкам без JIT недоступны.
Это не спекуляция, потому что финансовая отчётность в открытом доступе это подтверждает.
Вот когда рептилоиды и жидомасоны начнут подавать публичные фин отчёты в регуляторы, тогда и возвращайтесь со своими аргументами могут это быть они или нет.
Наверное потому что рептилоиды и жидомасоны официально не отчитываются налоговым органам планеты земля, а вот вполне обычные компании, массово сокращающие работников при рекордных прибылях - это не редкость?
Раньше некая компания получала прибыль в размере X. И могла из этой прибыли платить своим разработчикам зарплату Y.
Сейчас та же компания в силу объективных причин получает прибыль 0.5Х. Из каких денег она должна продолжать платить своим разработчикам прежние зарплаты?
Ещё раз - вы этого не знаете. Это типичная выдача желаемого за действительное. Вы не смотрели финансовые отчёты компании, я более чем уверен. Вы только видите что зарплата упала. А почему она упала - потому что прибыли нет или потому что рынок позволяет меньше платить - неизвестно. Но уж точно никто не будет платить больше, когда можно платить меньше. Понимаю, вам хочется чтобы у всего была логичная причина, но это не всегда так.
Я всегда смотрю в первую очередь на совпадению ключевых навыков.
Вот это меня всегда удивляло, уж кого бы должны были уже заменить хотя бы баш-скрипты
Если мы говорим про Junior, то мне плевать сколько у человека опыта работы.
И тем не менее большинство вакансий с требованием опыта, что и порождает накрутки. Так может опыт на джунов не требовать - они и накручивать не будут?
Резюмируя мне кажется все это больше вскрывает большую проблему - компании не в состоянии оценить навыки кандидата и вынуждены полагаться на косвенные признаки вроде опыта. Это может быть не проблема для HR, но это проблема самих HR, банальная профнепригодность, т.к. это и есть люди, работа которых, в частности, и заключается в том, чтобы оценить насколько сотрудник подходит компании наиболее эффективно.
К сожалению всё так как вы описали. ХР работают по сути как баш скрипты и при несовпадении символов в списке технологий считается что знания у вас абсолютно непереносимые. Я вообще не видел где-либо чтобы брали с на другой язык, тем более с переучиванием. Но у меня больше опыт зарубежных контор.
Ваша идея конечно, но с точки зрения пользователя ( меня в данном случае ) задумка странная. Ведь если разницы нет, то и ключевые слова должны это отображать. А тут они вроде как пытаются это скрыть, хотя разница между ридонли и неридонли полями существенная. Меня как пользователя это еще больше запутает - что от меня хотят скрыть, чего стоит опасаться?
Ну мне кажется всегда есть желание видеть публичный интерфейс как минимум, т.е. все-таки нужно знать где доступны функции. Мне кажется Питон больше популярен вопреки этому, благодаря сумасшедшему хайпу, благодаря которому его пытаются использовать везде где только можно.
Опять же вы говорите это, а разные ключевые слова говорят пользователю: "Внимание! Здесь есть разница", и он начинает ее искать. Если разницы нет, то подход как у груви с def смотрелся бы более логично в коде, имхо.
Промах
Выглядит очень интересно, спасибо!
Личное имхо - отступы конечно режут глаз, наверное питонистам будет норм, но после сиобразных глаза не могут собрать код в структуру быстро.
Не совсем понятно освобождение памяти - будет что-то вроде деструкторов? Видел \@owner модификатор, но непонятно, будет ли он освобождать зависимые ресурсы, вроде RAII?
val/var - еще с Котлина заметно было что много перемешанных переменных var и val смешиваются между собой на взгляд, легко перепутать. Тот же const визуально бы гораздо проще было отличать.
Вообще набор var/val/let/def выглядит сложнее чем мог бы на мой взгляд (как работает def не нашел). Если let - это просто модификатор видимости, то имхо проще для чтения кода было бы добавлять отдельный модификатор видимости чем отдельное ключевое слово.
>Именованный кортеж. Может иметь любое количество элементов, но чаще всего элемент один, так как иначе структура часто будет лучшим выбором.
Тут тоже не совсем ясно, зачем вообще кортеж с одним элементом? Не проще ли просто сам этот элемент и использовать?
Но в целом проект очень интересный, буду отслеживать!
Ну это выдача желаемого за действительное. Такие работники не более ответственные чем любые другие.
На мой взгляд у этих двух фактов одинаковая причина - такие работники никому не нужны на практике, несмотря на теоретические причины почему они могли бы быть полезны. Достаточно посмотреть что от кандидата требуют на интервью - а именно как можно более глубокие знания основной технологии. Поэтому люди уходят в специализацию и поэтому же "дженералистов" сложно нанять.
Какая-то немного странная статья из разряда "раньше было лучше", которая смешивает всё подряд в одну кучу - разработчиков широкого профиля и опытных разработчиков.
На мой взгляд дженералист\разработчик широкого профиля\фуллстэк инженер это вполне распространенное понятие, просто в отличие от статьи оно не привязывается к конкретному времени когда разработчик начал работу в сферу. А статья пытается смешать опыт разработчика и специализацию, заявляя что разработчики с опытом 20 лет лучше пришедших недавно потому что они широкой специализации, а не потому что у них на 15 лет опыта больше. И соответственно назначает неопытных разработчиков каким-то нетакими, "недженералистами".
Следуя определению из статьи - да, со временем людей, начинавших на заре не остаётся, просто потому что время идёт вперёд. Значит ли это что исчезнут умелые разработчики? Наврядли.
Хвалить себя статьёй на Хабре конечно приятно, но нужно замечать свои же рационализации.
Современные решения просто сразу транслируют в JVM байт-код
https://www.microfocus.com/en-us/products/visual-cobol/overview
Да и судя по той же ссылке на типы с точностью не особо, максимальный float 16 бит в коболе против минимального 32 бит в джаве, а bignum арифметику-то можно везде делать.
Судя по IBM документации у них и нет unsigned типов
https://www.ibm.com/docs/en/zos/2.4.0?topic=definitions-cobol-data-type
А по производительности - если писать на Яве как на коболе, без динамической аллокации памяти - то и работать всё будет как на Коболе/Си. Возможно даже быстрее, благодаря JIT оптимизациям, которые языкам без JIT недоступны.
Да без проблем
https://www.sec.gov/Archives/edgar/data/1652044/000165204423000045/goog-20230331.htm
Или ещё какие-то вопросы остались?
Это не спекуляция, потому что финансовая отчётность в открытом доступе это подтверждает.
Вот когда рептилоиды и жидомасоны начнут подавать публичные фин отчёты в регуляторы, тогда и возвращайтесь со своими аргументами могут это быть они или нет.
То что информация о деятельности рептилоидов и жидомасонов не лежит в публичном доступе в разделе "для инвесторов"?
Вот что обычные компании увольняют при рекордной прибыли мы знаем абсолютно точно, про рептилоидов можем спекулировать.
Заканчивайте к строить из себя клоуна, ей богу.
Наверное потому что рептилоиды и жидомасоны официально не отчитываются налоговым органам планеты земля, а вот вполне обычные компании, массово сокращающие работников при рекордных прибылях - это не редкость?
Ещё раз - вы этого не знаете. Это типичная выдача желаемого за действительное. Вы не смотрели финансовые отчёты компании, я более чем уверен. Вы только видите что зарплата упала. А почему она упала - потому что прибыли нет или потому что рынок позволяет меньше платить - неизвестно. Но уж точно никто не будет платить больше, когда можно платить меньше. Понимаю, вам хочется чтобы у всего была логичная причина, но это не всегда так.
Вот это меня всегда удивляло, уж кого бы должны были уже заменить хотя бы баш-скрипты
И тем не менее большинство вакансий с требованием опыта, что и порождает накрутки. Так может опыт на джунов не требовать - они и накручивать не будут?
Резюмируя мне кажется все это больше вскрывает большую проблему - компании не в состоянии оценить навыки кандидата и вынуждены полагаться на косвенные признаки вроде опыта. Это может быть не проблема для HR, но это проблема самих HR, банальная профнепригодность, т.к. это и есть люди, работа которых, в частности, и заключается в том, чтобы оценить насколько сотрудник подходит компании наиболее эффективно.
Наверное потому что то что требуют от кандидата на собеседовании и на работе - разные вещи?
К сожалению всё так как вы описали. ХР работают по сути как баш скрипты и при несовпадении символов в списке технологий считается что знания у вас абсолютно непереносимые. Я вообще не видел где-либо чтобы брали с на другой язык, тем более с переучиванием. Но у меня больше опыт зарубежных контор.
Ну так и поиск работы/проверки это лишний стресс
Вертикально, а что?