`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Андрей Зубинский

Языки. В том числе и ругательные. Но не только.

+1113
голосов

Тег хороший отыскал в списке - "Кризис в ИТ". Нравится мне он. Потому как этот самый "кризис в ИТ" ощущаю чуть ли не ежедневно. В маленькой фирме, где работаю, закупленная перед Новым Годом техника - иллюстрация к ужасам этого самого "кризиса в ИТ", будь он неладен.

Так что, пятиминутка ненависти, господа :)

И да, котэ тоже негодуэ :)

Языки. В том числе и ругательные. Но не только.

Hate mode on

Так как чёрный пиар - занятие, требующее хорошей оплаты, пальцем тыкать в бренды не буду, но и молчать тоже не могу. Ноутбуки, не нонейм, а как бы и именитые, чуть ли не все прошли через сервис. Серверная материнская плата после установки в PCIe-разъём карты (рабочей, проверено) выдаёт на уровне BIOS критическую ошибку контроллера PCI, и, судя по стонам в уютном интернетике, лечится это только заменой на более позднюю её ревизию. МФУ @%$#^&*!!!. Здесь без вычурной обсценной лексики не обойтись. Чудовищный агрегат, выдуманный отцами-иезуитами для пыток еретиков. Или печатает в цвете, или сканирует, но печатает в ч/б. О работе в wifi-сети с wifi принт-сервером можно сказать очень кратко, букв шесть всего. Но воздержусь. Винчестеры... Отдельная история, питающая неиссякаемый генератор лучиков радости и счастья, направляемых в сторону производителей.

И это всё - с техникой, эксплуатируемой в кондиционируемом помещении, не в круглосуточном режиме, и вообще очень щадяще эксплуатируемой.

Hate mode off

Разве что рабочая лошадка принтер Samsung, мой любимый "сюсик" (нетбук NB30) и телефон LG радуют - делают что должны без малейших нареканий. Корейцы таки сделали то, во что многие не верили. И показали достойный пример всему ex-USSR. Хотя нам это не поможет, наши примеры, похоже, все в телевизоре, в передачах "про зiрок", по-сельски неуклюже копирующих по их разумению красивое и модное. Впрочем, Лесь Подерв'янський в своей последней пьесе "Блеск та нiщета ..." лучше меня сказал, я так не могу.

Hate mode totally off :)

И да, ни Samsung, ни LG мне ни копейки денег не дали. (и это возмутительно, например). Но из песни слов не выкинуть - что вижу, то пою потому что.

Теперь можно и о вещах душеполезных и интересных.

Тут сети притащили мне парочку преинтереснейших для размышлений ссылок. Которыми не могу не поделиться, как и размышлениями. А то мнения у меня всё больше нецензурные получаются, а рассудительность - она как бы сестра культурности.

Итак, хороший ресурс для "шахтёров данных" (dataminers), KDNuggets, провёл очередное голосование среди этих самых "шахтёров" для определения наиболее популярного в их среде "шанцевого инструмента". Иными словами - для выявления самых пригодных для "раскопок в данных" языков программирования. В голосовании приняли участие 570 специалистов - это очень немало, "шахтёров данных" вообще немного и в силу междисциплинарности предметной области, и просто потому, что много их не требуется.

Результаты голосования преподносят разные сюрпризы.

То, что язык и инфраструктура R на первом месте - в этом ничего неожиданного нет. Не буду вдаваться почему, некогда, просто скажу - заслуженно на первом месте. Что SQL на втором месте - тоже не сюрприз, на самом деле SQL используют чуть ли не все "шахтёры данных", просто SQL упрятан в инструменты и его не видно, но саму "породу" данных надо откуда-то выгребать чем-то, а данные залегают, в основном, в реляционных СУБД, и выгребаются оттуда комбайном под названием SQL. Так что SQL даже обижен. А вот третье и четвёртое место с практически равными результатами (1% - не разница) - это уже внезапно. Python и Java. Придумать что-то более разное даже трудно. Злая и строгая очень говорливая (многословная) госпожа Java, сплошные ограничения и кожаная плётка в семь хвостов :) , и Python, изначально создававшийся для "реактивно-эскизного" максимально удобного программирования. Громадная инфраструктура,  образующая Java, и интерпретатор Python. И всего лишь 1% различия в популярности. Очень интересный факт, о котором стоит подумать.

По логике вещей, - чем выше уровень языка, чем компактнее синтаксис и чем богаче семантика, тем язык более применим в прикладном программировании. Яркий пример - R. И, по этой же логике, Python, располагающий прекрасными библиотеками, весьма приятный что в синтаксисе, что в семантике, должен далеко отрываться от сплошных со всех сторон заборов Java. А вот на практике такого не происходит. Стало быть, что-то в логике не учтено.

Я так думаю, что не учтены строгость Java и принятый в Java-мире инженерный подход к программированию. Последний является источником тусклых лулзов для начинающих кодировщиков (начинающим всегда кажется, что они уже всё знают и умеют), но инженеры на своей шкуре проверили работоспособность правила - не надо бросаться за проектирование узла, прежде чем не выяснено, что готового такого узла нет. Ну а строгость... У неё ведь есть и обратная сторона, кроме "мне так неудобно". Строгость даёт возможность реализовать мощную инструментальную поддержку (в инженерии, к слову, тоже; стандарты, допуски, посадки, технологические нормы etc - это ведь всё "излишние строгости", но без них инструменты не сделать). И у Java она выше всяких похвал. И строгость при проектировании даёт возможность проще (безопаснее) повторно использовать уже сделанное. Так что, на первый взгляд внезапное равенство популярности Python и Java оказыватся не таким уж и внезапным, если хорошо подумать.

В результатах есть и смешное. Для тех, кто понимает. Например, паритет между Perl и Lisp. Экие две прекрасные крайности - лавкрафтовский хтонический в синтаксисе Perl и ассемблер весьма специфической (но реализуемой "в железе") машины, практически лишённый синтаксиса Lisp. Хрен редьки не слаще, короче :)

Хочется из всего этого сделать какие-то выводы, но обойдусь. В конце концов, если у кого получается лопатить данные на Perl - почему бы и нет. Лишь бы от результатов не коробило специалистов по мат. статистике :)

Вторая выуженная находка - вот это чистый ужас. Опять же, для тех, кто понимает. Речь пойдёт о преемнике Java - языке Scala, который, по идее, должен быть для Java тем, чем стал С++ для просто C.

(ох, чую, сейчас набигут, хихи)

Если бы этот текст написал, например, я, изучающий Scala из любопытства, фанаты Scala разорвали бы меня в клочья и ещё месяца два кровожадно рычали бы по форумам. Но тут понимаете какое дело... Дэвид Поллак - суровый мужчина, он всё-таки фактически автор фреймворка Lift, Scala-программист, подаривший миру 250 тысяч строк собственного Scala-кода, ну и, наконец, автор очень хорошей книги по Scala. Так что на вякающих из форумов мосек такой мастодонт даже внимания не обратит :) И потому ему можно сказать следующее (не перевожу ввиду простоты текста):

Scala is an inappropriate language for the majority of Java developers and cannot be expected to replace Java because for at least 50% of Java developers, Scala's difficulty outweighs its value.

Вот опять к традиционной инженерии сносит нас. Да. Дело не в том, что Scala - сложный язык. Java тоже не из простых, а уж со всеми нюансами платформ типа JavaEE - так вообще нечто страшное. Дело в традиционном для инженерии компромиссе между затратами на освоение инструмента и отдачей от эксплуатации этого инструмента.

Вообще, крайне душеполезная запись в блоге Дэвида Поллака, очень рекомендую, тем более, что она - результат продолжительной дискуссии между людьми, прекрасно понимающими в своём деле.

Так.

Что-то ещё у меня было забавное.

Ага.

Только вот обмолвился давеча об SDR (Software Defined Radio), как компания Silicon Labs (очень славная компания, вообще-то) выдала на рынок первую однокристальную реализацию всеволнового радиоприёмника Si4840. Достаточно посмотреть на блок-схему "радиотракта" этого приёмника, чтобы понять - это, безусловно, уже больше компьютер, чем радиоприёмник:

Языки. В том числе и ругательные. Но не только.

И сделанный именно так, как упомянул в одной из прошлых записей, - за смесителем (два кружочка с "x" в прямоугольнике) сразу сигнал преобразуется в цифру (два аналогово-цифровых преобразователя, ADC), затем обрабатывается цифровым сигнальным процессором (DSP) и преобразуется обратно в аналоговый сигнал цифро-аналоговыми преобразователями (DAC). Это, вообще-то, очень круто, я считаю. Не потому что красиво и изящно (нет, конечно и потому). Просто радиоприёмник - штука дорогая, потому что аналоговый тракт неизбежно нуждается в настройке. А тут и настраивать-то почти нечего, аналоговая "обвязка" минимальна. В Silicon Labs вообще большие умнички работают и красивые микросхемы делают.

Не к ночи будут помянуты таблеты, но тут уж ничего не поделаешь. По-моему, это красавец, особенно учитывая цену. Продажи обещают с конца октября. Экранчик - 1366х768, очень ОК, остальное - достойное, ну и дизайн приятный. Одно "но". Оно вроде как под Android работает, но не совсем - тут Android так переделали, что маркета Google нет, много чего нет, но обещают, что приложения андроидные бегать на планшетке будут. В общем, дождёмся конца октября, поглядим. Такого ещё будет много.

Ах, ну да, ну да. Ка же это я. Сегодня же вышла вторая версия MongoDB. Что бы кто ни говорил, а нравится она мне при всех её недостатках.

Хорошее кино. Что-то полюбил я смотреть кино. Так что тут его есть, хорошего кино, - в видеоотчётах с конференции по разработке ПО AARHUS.

Польза. "Их есть у меня" (с). Очень понравилась и стала  повседневной утилита синхронизации локальных офсиных файлов с Google Docs iGoSyncDocs. Открытая, кросс-платформенная. И из той же оперы, практически того же назначения, но для скриптов (особенно хорошо для скриптов на Python, потому как гомогенная среда получается) - GDataCopier.

Есть у меня ещё всякого интересного много, но это уже на потом.

В очередной раз откланиваюсь, а то расписался что-то.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+1113
голосов

Напечатать Отправить другу

Читайте также

Полгода назад задумывался Java & Python? На Java после тысячи строк построения всяческих классов (наконец-то) возникает что-то полезное. Python доставляет похожее через 20 строк разреженного кода и выносит этим мозг. Система in-memory анализа неких онтологий на Python тянет строчек на 200, причем включая их вытягивание из интернетов и полноценную реализацию языка запросов. Правда, с неким ужасом наблюдаешь ситуацию, когда для данных в 150M все это разворачивается в 4Г, хотя и летает. Понимаешь, что надо что-то делать, если не с кодом, то программистами. На Jave подобное - это полноценный промпроект. И вот с этого момента все становиться понятно. Именно потому что проект. Если нужна серьезная работа, подтягивается sesame, open sahara, neo4j - и хочется нативного ароматного кофе или скала, на крайний случай. Даже если вокруг него сплошной питон. tomcat негодуэ.

Lisp & Perl из другого, маргинального романа с ними воспитанных классической школой монстров со специальной шишечкой мозга, выращенной правописанием. Lisp прекрасен до слез, особенно если только с do без всякого синтаксического сахара if. Perl после 4-й версии имхо уже не доставляет.

Вот со Скалой не понял, почему это нас должно касаться. Нужно тявкнуть и поправить великого. Он не достаточно специфицировал имхо что имел ввиду в контексте: Scala use is less good than Java use for at least half of all regular jvm-utilized Java projects. Это понятно, ведь для него все проекты очень правильные, а все джава-кодеры - гении. Что подтверждает. А так, не понимаешь замыканий, пользуйся более изящным для себя быдлопроцедурным не по месту стилем с прекрасными джава-библиотеками - и тебя все поймут. Это ведь не русский язык. Вот в подкрепление забавная цитата из книжки про PHP: That which is over-designed, too highly specific, anticipates outcome; the anticipation of outcome guarantees, if not failure, the absence of grace. По моему очень скромному мнению, Скала достаточно не специфичен. То что пришлось пожертвовать в угоду изяшности больше чем хотелось бы, волнует только гениев, они же все исправят. Хоть и мало их. Вот теперь и мы знаем все о Скала, а ведь раньше даже не догадывались что проблема есть. Тесты быстродейсвия и эффективности рассудят.
Остальное (в том числе, незабавные истории персонального шоппинга), рассудит время. ггг

так есть для жабы функциональщина в разных видах и под разными соусами.
работает.
где надо - её пользуют.
где не надо - туда не тянут.

вот приятная библиотечка, например, http://functionaljava.org/
вполне работает.

да и средствами самой жабы нарисовать эквивалент closure немудрено, приёмов много, они несекретные (например, http://gioorgi.com/2010/closure-in-java-fast-and-nice/).

оно ж не панацея на самом деле.
многие императивные программисты такое использовали годами, просто названий мудрёных не знали :)

согласен полностью. но я не о функциональном в джаве конкретно, а немного на другом уровне предметной области: вот если программисты пользовались Вами перечисленным, какие же они после этого императивные?

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

имхо, не нравится лишнее в Скале - не пользуйся, Скала этого не требует. Сравнивать стоит код и pcod. По разумным метрикам выразительность-скорость, вроде бы у Скалы с этим проблем нет. Тут правильный вопрос, сколько за это в ядре платит программист. Отвечать словами на этот вопрос - просто флеймить. Что мы и имеем.

А если тема о том что ненужное в джаве вне ядра, то ведь и ООП штука вредная где не надо. Это касается любых дополнительных слоев формализации и сопряженного с ними меппинга и прочей сахарозы - пока железяки такие вот цифровые. и это хорошо видно для примера в несерьезных штуках типа Python или ECMAScript. В последнем классов вообще нет, а ООП есть. А книг про разные варианты реализации истинного DSL-ООП в js уже, наверное, больше чем про ООП-java.

понятно, что все это не питательная философия. Потому просто нравится Скала, Python и server-side "JS", не люблю Java.
За ссылочки спасибо.

До речі, (спів?)автор Functional Java, він же ж автор Scalaz, Тоні Моріс, в своєму блозі дуже прямо пише, що думає про Java, Scala і Haskell.

А в принципі, інструмент підбирається під задачу. Точніше, на різних етапах вирішення задачі зручними є різні інструменти.

да, сегодня 256 день года. поздравляю.

как я понял Поллака в результате, дело оказалось в социальной инженерии. Обычные трудности переводов.

У Поллака речь не о сбалансированности Скала,
(так же как в приведенной мною цитате Гибсона речь не о PHP)
а о затратах мозгов или даже принципиальной возможности
эфективного исползования Скала рядовым армии Java-кодеров,
соизмеримыми порядку затрат (относительных)
на познание Java в целостности рядовым PHP кодером.

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

по мере чтения до меня дошло, что имею то я дело не с укротителем фруктовых леммингов.
для тру-солдат удачи реклама должна быть соответсвующей: "я как суровый коач утверждаю, что не придется расслабляться, только настоящие люди (не техники, не гики, не сырье для биореактора) смогут. обещаю риск, опасности.
Только 50% из тех кто, сунется в почти милллиардную экосистему разработки на Скала - унесут все деньги".

Классика галимой рекламы. Даже если все правда.

ПС. Сорри что все время вроде бы как о нестыковках в бложиках вещаю. Не со зла это. Интересные темы освещаете, и так хорошо.

Андрей, спасибо за информацию о Si4844! СВ, КВ и FM диапазоны с DSP-обработкой сигнала, встроенный синтезатор частоты! Очень интересно! Надеюсь, эта IC когда-нибудь к нам доберётся...

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT