Комментарии 251
Adobe Flash, который был единственным рабочим способом реализовать нормальный интерфейс в вебе, к счастью, ныне почил. Правда, на смену единому стандарту пришли три разных фреймворка с абсолютно разными моделями
Blazor, WPF, Xamarin?
всё что есть вместо него это убогие костыли, которые не решают самую главную задачу которую решал флеш — красивая графика, которой можно управлять как раскадровкой так и кодом. на флеше я мог делать офигенно красивые интерактивные анимации, которые весили по 10 кб, мгновенно грузились и которые было очень легко дорабатывать. художник мог настроить какие-то анимации вручную через раскадровку, или даже интерполяцию кадров для анимации форм. и весило это всё копейки. сейчас это дикие танцы с бубном с SVG, какими-то подключаемыми фреймворками в которых чтобы разобраться надо потратить неделю и понять что флеш был лучше. ребята из adobe изза своей твердолобости убили самую крутую технологию десятилетия, которая сделала интернет по-настоящему красивым. досихпор нет инструментов даже относительно приближенным к удобству флеша.
незаменим флеш для обучения — у меня ученики, дети с которымия я иногда занимаюсь по скайпу, на первом уроке делают свою интерактивную игру. на какой ещё среде это возможно сделать?
вот этот образовательный проект мы делали с детьми от 7 до 11 лет, они сами писали код, делали управляемых персонажей, собирали проект, и всё это сделали мы за неделю. это интерактивный фильм с элементами игры
http://3263927.ru/edu/kolobok/index.htm
если кто-нибудь подскажет мне подходящий инструмент, на котором я могу сделать то же самое сейчас, буду благодарен
флеш решает самую главную задачу — он не заставляет программировать то, что проще просто нарисовать
я когда в конкурсе стартапов в Microsoft участвовал там был такой челлендж — надо было своё приложение нарисовать на специальных бумажках, сделать прототип интерфейса. я благорадя тому что знаю флеш быстрее сделал рабочий интерактивный прототип, чем некоторые нарисовали то что хотели. потому что во флеше идеальный баланс между рисованием руками и автоматизацией. там программирование действительно используется по назначению — всё можно автоматизировать, но ты не обязан это делать. то что проще нарисовать руками рисуешь сам, то для чего нужны алгоритмы без проблем автоматизируется. можно на ходу за пару строчек кода конвертировать клипы в битмэпы и работать с ними как с картинками, размывая точки, делать красивые визуальные эффекты очень дёшево с точки зрения усилий и времени.
мне очень не хватает этого удобства в современной разработке
То, что можно будет применять во вред окружающим — будут применять во вред окружающим.
Такая судьба и постигла flash.
P.S. Вспоминаю «Магазинчик Бо» на флэше…
если бы adobe сделала его открытым то это бы изменило всё, они бы и заработали на этом хорошо (на редакторе) и в то же время сообщество приняли бы эту технологию… согласен с вами
Я общался с человеком, который для Chrome Flash пилил — так вот там у них был air gap, сдача телефонов на входе и прочее. Только при таких условиях Adobe соглашался дать Google доступ к коду.
Не знаю уж что там за дикие секреты были — но делать открытый player они не хотели категорически… ну а потом уже Джобс решил его убить… что и проделал «с особенным цинизмом».
мне всегда было интересно, зачем они явно бьют курицу по золотым яйцам? у них был огромный рынок, было время когда вобще всё было на флеше, они могли свою экосистему построить… я с людьми из Microsoft разговаривал, мне по секрету сказали что они не смогли конкурировать с флешем… это что саботаж какой-то или просто скудоумие и отвага? ну тоесть сейчас есть огромная потребность и нет предложения — рыночная ниша свободна. и у адоба есть реальный инструмент, который надо лишь немного допилить… может я чего-то не понимаю
А причина одна: говнокод и отсутствие какого-либо вменяемого плана поддержки (из-за чего старый говнокод так и продолжал спокойно жить, даже когда появлялся новый немного получше).
Проблемы с безопасностью и закрытостью флеш всего лишь добили.
Ответ прост. Flash создали не в Adobe. Вот конечный владелец руками эффективных менеджеров его и убил.
Говорят, что до изобретения StackOverflow приходилось задавать вопросы живым людям.
Я бы лучше написал так: «20 лет назад StackOverflow не было, сейчас есть». Раньше же не только к живым людям лезешь с вопросами, а еще и в документацию и это сильно меняет подход к разработке (примерно как фильмы против клипов).
Оффлайн тоже. Тсссс! Это секрет, никому не говорите! https://stackoverflow.com/questions/50582497/how-to-download-offline-copy-msdn-microsoft-help-documentation
Ещё появилось интересное явление: по некому программному продукту StackOverflow является официальным и единственным каналом поддержки. Да, кому-то платят деньги, чтобы они отвечали на StackOverflow по заданному списку тегов.
Так как у нас появились более быстрые ЦПУ, сложные вычисления мы стали делать на Python, не на Fortran. Так что вычисления занимают примерно то же время, что занимали 20 лет назад.
Имею опыт работы и с Fortran и с Python. Если использовать для вычислений Numpy/Scipy то скорость не особо различается. Например, бенчмарки с решениями СЛАУ «Оценка скорости решения СЛАУ различными средствами»
Более того, Python обходит некоторые не слишком оптимизированные библиотеки под Fortran.
Естественно, если реализовать решение СЛАУ на чистом Python, все будет печально)
скорость не особо различается
Кхм-кхм… В два раза различается.
Цитата из статьи по ссылке:
«Под капотом» у NumPy/SciPy – Intel MKL (интересно, почему это остается бесплатным?). Ожидаем отличную производительность.
Я тут недавно сделал бенчмарк своего кода с numpy/scipy (numpy/scipy.sparse). Пакеты собранные с MKL и с OpenBLAS. С OpenBLAS оказалось быстрее. Проверял на сборке numpy+mkl от gohlke, intel_numpy/intel_scipy и на официальных пакетах с PyPI. Официальные пакеты, собранные с OpenBLAS, оказались самыми производительными. Делаю вывод, что нет больше смысла тащить к себе в проект жирный пропиетарный MKL.
array size — это размер по одной размерности, массив на самом деле двумерный, то есть MxM
«Под капотом» у NumPy/SciPy – Intel MKL (интересно, почему это остается бесплатным?).Почему «это» остаётся бесплатным, кстати понятно.
MKL сильно замедлен на процессорах AMD, так что… «ничего личного, просто бизнес»
Я замерял на процессоре Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
.
После того как получил результаты решил погуглить, оказывается OpenBLAS очень хорошо оптимизирован для параллельных вычислений. Чем больше ядер тем быстрее будет работать. Вот пара других бенчмарков, что я находил:
https://github.com/tmolteno/necpp/issues/18
http://markus-beuckelmann.de/blog/boosting-numpy-blas.html
MKL сильно замедлен на процессорах AMD
Ну что ж, если вспомнить недавний прорыв AMD на процессорном рынке, MKL тем более не нужен. :)
Тесты не совсем идентичны: Фортрановская версия копирует данные в предварительно выделенные массивы, версии на Julia и NumPy каждый раз заново выделяют память.
С другой стороны, матрицы для теста уже достаточно большие, чтобы время на распаковку питоновского объекта, отправку в BLAS и запаковку ответа обратно терялось на фоне времени на собственно решение. А может так оказаться, что решать нужно не матрицы 1000×1000, а 10×10, зато много. Тут уже Фортран и Джулия будут рулить, а Питон курить в сторонке.
Так что эти тесты, в общем-то, просто фантастическое открытие совершают: если к программе на Fortran добавить чуть-чуть Python кода, то она будет продолжать работать с той же скоростью, что и программа на Fortran… фантастика… неожиданная неожиданность…
И в принципе, какая разница на каком языке написана библиотека для меня, с практической точки зрения, если сам язык надежно абстрагирует меня от этого?
Сам CPython написан на С, и когда я использую стандартную функцию sum() я программирую на С или Python?
Если мне удобнее использовать несколько разнородных библиотек, написанных на разных языках, и все они имеют интерфейс в Python, то очевидным выбором будет использовать именно его! В этом вся его суть, это очень удобный язык-клей.
Я вообще не понимаю почему некоторым авторам хочется доказать что их любимый язык так же быстр как С (Если это не раст например конечно, который позиционируется как замена С). Говорить что ваш язык безопасней и удобней — но по скорости зачем сравнивать то.
не надо говорить как сравниватели языков что питон так же быстр как С. Не быстр — априори. Иначе не пришлось бы создавать CPython и PyQt.
Ну если вы говорите о скорости исполнения, то я могу подразумевать, что CPython вы просто перепутали с Cython. Но при чем тут pyQT? Это библиотека GUI, каким боком она относится к скорости исполнения не понял.
…
> смотрение свысока на тех, кто всё это не использует.
Ну эта всегда применялась :D
Если вы про те времена, то тогда NC мало кто пользовался (из программистов).Вот конкретно этим — нет. А вообще — многие пользовались. Но потом пути разошлись — часть перешла на VC (маленький и быстрый), часть на DN (монструозный, но зато куча фичек).
Сейчас NC тоже никто не использует, потому что есть монстр в хорошем смысле Far, который умеет практически всё из коробки, а сверху имеет миллиард плагинов.Никто не использует потому что NC под Windows графический, но хуже, чем Total Commander. Какой в нём смысл?
NC был крут, пока его автор делал… а как большая корпорация его купила и индусам отдала — так он и кончился…
Какая корпорация его купила? Norton Commander всегда писался компанией Symantec Inc. Просто на заре компания состояла из одного Питера Нортона, а потом уже в неё добавились ещё программисты.
Питер Нортон — основатель Symantec
Питер Нортон — основатель SymantecУжас какой. И вы так ещё это уверенно всё это пишите… прям даже поверить можно.
Сходили бы на Wikipedia, что ли, просветились бы. Symantec был основан в 1982 году Гари Хендриксом. Peter Norton Computing — в том же году, но в совсем другом городе, Питером Нортоном.
А Norton Commander вообще писал Джон Соча — первые три версии. А вот когда Peter Norton Computing был куплен — его разработкой занялись эффективные манагеры.
В результате версии с 1й по 3ю — маленькие и быстрые. С 4й и далее — огромные, неуклюжие монстры. Вот тут все версии есть — можете скачать и поиграться…
Статья про то, что поменялось в разработке за 20 лет.
PS: Ваш код от этого стал хуже?
Статья про то, что поменялось в разработке за 20 лет.Вот только «людей не европейской внешности» и раньше хватало. Или Raymond Chen, который работал в Microsoft, когда автора ещё на свете не было или Theodore Ts'o, создавший файловую систему Linux, которой пользуются миллиарды — уже европейцами стали?
А женщих, кстати, в 60е годы в разработке было больше, чем сегодня…
Особенно по расовому разнообразию.
В 60х — меня в проекте ещё не было, но по впечатлениям от прочитанного — основная масса женщин в те времена это были операторы, который занимались довольно рутинными задачами во всяких вычислительных центрах.
После переезда в Европу, у меня сложилось впечатление, что женщин-программистов тут всё же больше чем на пост-советском пространстве (хотя все равно значительно меньше, чем мужчин). Моё личное мнение — это позитивный тренд, и мне лично не попадались в реальности эти страшные истории, когда адекватные люди лишались работы из за «дайверсити» в индустрии.
Я бы добавил, что сложность создания отдельно-стоящей программы Hello World от установки компилятора и до запуска исполняемого кода на целевой платформе (PC или смартфоне), многократно возросла.
Помню:
CSEG segment
org 100h
Begin:
mov ah,9
mov dx,offset Message
int 21h
int 20h
Message db 'Hello, world$'
CSEG ends
end Begin
Компильнул masmом, линкером и получил com файл. А сейчас попробуй сделать это под винду или iOS/Android?
Помню эти чудные былые времена, когда «было все просто» под мобильные.
Сборка под Symbian S60 — когда самому приходилось править глючные заголовочные файлы, или компилятор генерил местами просто мусор. Или незабываемые отношения с код вариором. А следом пошла масса глючных IDE на криво переделанном эклипсе. Были времена. (С J2Me тоже было так же «просто»).
> F12 — Console
> console.log(«Hello, World!»)
До PC было ещё проще — воткнул комп в розетку, напечатал
10 PRINT "HELLO WORLD"
20 GOTO 10
RUN
и никаких компиляторов и линкеров не надо :-)
Хмм, а разве не надо делать push cs; pop ds? 9-я функция int21h просит адрес строки в ds:dx, а тут ds вообще отсутствует. Или у ком-файлов при инициализации регистров ds=cs, а я не знаю?
Если не ошибаюсь, то MS-DOS (в девичестве 86-DOS) разрабатывалась c большой оглядкой на анонсы и инсайды о релизе CP/M-86. Скорее всего такое поведение заимствовано оттуда.
Вот тут всё подробно описано (это блог Типа Патерсона, собственно, человека, который написал
Мне кажется, автор забыл упомянуть системы версионного контроля, как минимум — их переход к децентрализованным схемам.
Возможно, это уже было и 20 лет назад, но такого широкого распространения не было, а сейчас это привело именно к парадигмальному изменению.
Любая на Go? :)
Entity-Component-System в игровых движках, например в Unity. Имплементировано поверх ООП, конечно, с классами компонентов и прочим таким, не на базовых типах. Но игровые сущности именно что композируются (сущность с отдельными компонентами "Модель", "Позиция", "Контроллер поведения", "Механика повреждений" и т.д.), а не наследуются от базового GameCharacter, у которого на все эти случаи были бы методы/аттрибуты.
Только наверное не надо это называть "новой концепций".
Множественное наследование (C++) я использовал те же 20 лет назад…
Как в вырожденном случае (новый класс как результат наследования нескольких), так и в любых смешанных комбинация.
Одно (наследование от базового класса) не отменяет множественное наследование. И нигде не прибито гвоздями на уровне концепций (ООП) как эти инструменты использовать.
Ну новой не стоит, ей лет 10 с небольшим. Но тут не про множественное наследование речь и даже не про миксины, а именно про чистую композицию. Сущность — это такая коробочка для компонентов, которая умеет только их добавлять и удалять, больше ничего. Ну, может быть, всякие полезные мелочи типа быстрой проверки наличия поддерживает. Компоненты — это куски игровой логики, применимые к конкретному объекту. А системы — это процессы, которые с ними происходят.
Например, есть у нас в игре гравитация. GravitySystem
раз в тик опрашивает все сущности: "Есть у тебя WeightComponent
? Если нету — то и фиг с тобой. А если есть — то пусть твой PositionComponent
ускорится вниз на 9.8". Потом рендерер опрашивает сущности, и если их PositionComponent
в пределах видимости — то берёт ImageComponent.current_image
(если это не 3D) и вывешивает его на экран. И вся остальная логика работает так же.
А подход с контейнером для компонентов, внутри которых логика, был в Unity3d на момент выхода движка в 2005-ом. И вряд ли это первый движок, в котором этот подход используется. Тут, кстати, упоминается о других движках:
gameprogrammingpatterns.com/component.html#see-also
Логика, собственно, только в системах
Я бы не сказал. Что сейчас на 1G канале, что тогда на 48к примерно одинаково
Сегодня же нужно скачать и распарсить пару мегабайт, пока хоть что-то увидишь.
Но это, скорее, тенденция последних лет 10-15.
Рантше грузился текст, потом стили и картинки. Сейчас с кастомными шрифтами загружается всё, но текста пока нет...
3kbyte / (56kbit/s) = 0.4s
2MB / (100Mbit/s) = 0.16s
А latency и вообще почти не изменилась — притом что странички вместо одного-двух файлов сегодня их грузят десятками, а то и сотнями…
А latency и вообще почти не изменилась — притом что странички вместо одного-двух файлов сегодня их грузят десятками, а то и сотнями…
Ну по крайней мере в теории latency загрузки кучи файлов должны схлопываться засчёт http/2.
У меня в роуминге скорость мобильного интернета ограничена 256 кб/с или около того. Казалось бы, когда-то о такой могли только мечтать, хватало на всё на свете. А вот заходишь на сайт любого кафе посмотреть меню, а он грузится. И грузится. И через пару минут загружается… крутилка. И крутится еще минут 5. Всё это чтобы показать статическую, по сути своей, страничку на несколько десятков строчек, зачастую даже без картинок. Зато фреймворки, это да.
Сейчас вкладка браузера занимает памяти больше среднестатистического хранилища ПК тех времён
Многие не считают туториалы полезными, если только это не видеоролик. Даже если его просмотр займёт больше времени, чем прочтение текста.
Не только туториалы. Вся информация. Даже та, что не должна.
Видеоролик с таблицами это ужас. Поиск тоже не работает.
Почему, почему этот тренд жив?
P.S. Мне тоже не нравится, что слишком многое стало в видео формате, где куда уместнее текстовый.
Мы выполняем программы на видеокартах.
Помнится, ещё в MS-DOS, можно было использовать память видеокарты для увеличения оперативки, был какой-то драйвер.
З.Ы.
О, нашел! old-dos.ru/index.php?page=files&mode=files&do=show&id=5752
EGA2MEM
Эта утилита увеличивает за счет видеоадаптера основную память DOS на 96 килобайт!
Для программы требуется адаптер EGA или VGA, 640 килобайт основной памяти.
Многие не считают туториалы полезными, если только это не видеоролик. Даже если его просмотр займёт больше времени, чем прочтение текста.
ИМХО большинство "обучающихся" не любит видеоролики и, в основном, предпочитают текст. А вот как-раз "создателям" обучающего контента куда проще сделать видеоролик, чем писать статью, ещё и, не дай бог, с иллюстрациями.
При неизменном количестве функционала…
Java-разработки не в счет. Это всегда была отдельная религия. :)
Раньше и задачи были проще. Вернее многие современные задачи не делались бы по причине "это невозможно" или, в лучшем случае, "займёт годы".
С другой стороны простейшие задачи типа «сделать так, чтобы фон у окна мог быть не только белым, но и чёрным» почему-то превращаются в многолетнюю задачу, которая презентуется примерно как полёт на Луну…
С другой стороны простейшие задачи типа «сделать так, чтобы фон у окна мог быть не только белым, но и чёрным» почему-то превращаются в многолетнюю задачу, которая презентуется примерно как полёт на Луну…
Не скажу за 2000 год, но когда я молодым-зеленым в 2004 году попал к людям, профессионально и уже много лет пилившим код, довольно быстро я стал свидетелем перекрашивания и прочего визуального тюнинга толстого клиента на яве. Эта «простейшая задача» шла уже какое-то время, когда я там объявился, и тянулась потом еще около полугода (так что я самым краем даже тоже там приложился под конец). Пилили это всё, к слову, трое крутых бородатых дядек (а потом под конец еще пару месяцев двое зеленых нас подбирали мелочи).
Такая вот простота ¯\_(ツ)_/¯
Сегодня интерфейс — это множество разнородных вложенных элементов, чего раньше почти не было.Что значит «не было»? С этого, собственно, начались как Windows, так и TUI.
Я в школе с Turbo Vision игрался… так там даже окно и «панель» внутри — это разные компоненты!
У меня есть ощущение, что это типичный случай когда «больше — значит меньше».
В том же Turbo Vision у вас вообще не было способа поменять цвет кнопки. Если у вас есть кнопка — значит есть палитра, а значит вам нужно думать — откуда она взялась.
А все эти «крутые» фреймворки прямое задание стилей поддерживают. Ну, для удобства, типа.
А потом на это «удобстве» вырастают развесистые многоуровневые конструкции из костылей, которые подпираются другими костылями.
Анимации ещё сильнее усложняют ситуацию.Да нет, не слишком. Анимации и треть века назад были… да, текстовые — но что это меняет?
Просто каждое новое поколение считает, что оно самое умное, выкидывает всё, что было наработано предыдущими, городит свои костыли… в конце приходит к тем же проблемам и, в сущности, тем же решением — только с ещё большим количеством граблей.
Но да, конечно, вложенность появилась не вчера. Просто степень вложенности, разнообразие элементов и связей со временем росли, усложняя задачу. Палитра — это ограничение, которого иногда хочется избежать. Есть MacOS где все эти подходы «лучше меньше да лучше» как раз цветут и пахнут. Мы знаем, правда, чего это стоит и что за это приходится расплачиваться гибкостью.
Это похоже на резиновые vs фиксированные интерфейсы. Конечно, в идеале, резиновые лучше, но это сложно. Также и с палитрами, им сложно следовать, хоть это и более универсально и легче поддерживать.
Также и с палитрами, им сложно следовать, хоть это и более универсально и легче поддерживать.Да нет. Сложно убедить им следовать. Следовать как раз несложно — особенно если и фреймворк это поддерживает.
но, иногда, более удобную в данном конкретном случае хрень.В 99% случаев она оказывается более удобной только в больном воображении её авторов…
Но непонятно почему в Turbo Pascal 1/2/3 — это было проблемой, в Turbo Pascal 4+ и Windows 1+ — проблемой быть перестало, а в новейших и крутейших фреймворках — это снова беда, качмар и много лет работы…
Это не проблема во всех тех случаях, когда в проекте есть некое тёмное место с большой надписью «новую тему втыкать сюда». Тему втыкают, всё работает, довольные граждане расходятся по домам.
Во времена дельфей там помнится можно было пачку оформительских констант вытащить в файлик, и потом «сменить тему» за столько времени, сколько уходит на редактирование блокнотом не особо длинного файлика.
Когда такого места нет (по любым причинам) — начитается адъ. В современном вебе, например, о наличии (а точнее, отсутствии) такого места частенько задумываются только тогда, когда уже гром грянул, т.е. когда надо один и тот же продукт по-разному раскрашивать.
Задумываются может и раньше, задавая бизнесу/ПО вопрос: "Тем и других кастомизаций у нас точно не будет?" На что тот отвечает: "Точно никогда. Это же только наше приложение." А потом оказывается, что оно очень удачное и надо его продавать как SaaS и(или) "коробку", конечно, с кастомизацией. Или выходить на внешние рынки. Или просто мода пошла на темные темы. Или маркетологи/сеошники придумали что-нужно дцать сайтов на разных доменах, различающихся только палитрой и другими мелочами.
В современном вебе, например, о наличии (а точнее, отсутствии) такого места частенько задумываются только тогда, когда уже гром грянул, т.е. когда надо один и тот же продукт по-разному раскрашивать.Современный веб — это куча фреймворков. Которые состоят из десятков тысяч сущностей (файлы, обсёрверы, всякие условные «фабрики фабрик»), но при этом, почему-то, не содержат внятных способов кастомизации.
Вот почему, собственно? Turbo Vision, четвертьвековой давности, содержит, Win16/32/64 — содержит (гибкости поменьше, чем в Turbo Vision, но Win16 и появился раньше), а современные фреймворки — нет?
Ну конечно ведь все же эти 40 лет Emacs'оподобных редакторов никогда не существовало.
>Люди занимаются разработкой на Mac OS.
Ну я же говорю, хипстеры. И 15 лет назад в наших краях о маках даже не слышали. Я уж не говорю о том, что как система для программиста, мак уступает по многим параметрам и Windows, и Linux.
>Один гигабайт — недостаточный объём.
Конечно, если «десктопным приложением многие неиронично называют упакованный браузер со страницей по умолчанию и без адресной строки.». Эти помешанные на js, не осилившие ни один нормальный язык, в угоду скорости разработки и всяким рюшечкам заставляют нас страдать. Слава богу, остаются еще адекватные разработчики, которые не ведутся на это.
Раньше разработчики были настоящими, а сейчас всякие js-хипстеры и прочие «вайтишники» позорят нашу отрасль.Не вижу изменений. Да, раньше «ненастоящие» разработчики делали свои поделки на BASIC, потом на Clipper и VBA, сейчас вот до JavaScript добрались… но их всегда хватало.
А сейчас в отрасль пришли люди, которые создавать ПО толком не умеют, зато выглядят с иголочки и имеют развитые социальные навыки.Таких было полно в IBM полвека назад…
- Созданная одним из трейдов FI Desk система обработки котировок и сделок по бондам, выглядащая как десятка полтора Excel таблиц, запущенных/открытых одновременно, и переваривающих информацию, получаемую из Reuters, а также из коопоративной шины от других источников. 120 тыс строк кода на VBA! Я не преувеличиваю — я мерял. Много лет обеспечивала потребности трейдеров в информации.
- Приходит к программисту заказчик, и говорит: нам нужно геокодировать 50 тыс адресов. Адреса в Excel. Программист берет в руки Rest API Google Maps, VBA, VBA-Web, и где-то за полчаса пишет макрос, который тупо геокодирует адреса из колонки таблицы. Заказчик доволен.
Кто из них ненастоящий и почему?
Формально, если использовать ваши критерии — это профессионал и пофиг, что он ни о диафрагме, ни про выдержке не имеет представления.
Вот то же самое и с вашими «разработчиками на VBA»: они могут быть отличными профессионалами, скажем, прекрасными трейдерами… но какое это всё имеет отношение к программированию?
Да, иногда, если выбора нет — настоящий профессионал (особенно репортажник) тоже может на смартфон фоток наснимать (и быстренько отослать в редакцию).
Но профессиональных фотографов на смартфонах — всё-таки не существует, у профессионалов — другие инструменты.
То же самое и с VBA… да, он решает свою задачу… и эта задача — дать возможность, человеку, не являющемуся профессиональным программистом, что-то с делать с MS Office (ну или Photoshop).
На мой взгляд, профессионализм — он исключительно в голове. Рассказываю продолжение истории: приглашают разработчика, назовем его Паша, чтобы эти работающие 120 тыс строк VBA переписать на C#, благо Офис его давно уже поддерживает.
Для начала Паше говорят: сделай так, чтобы этот код был а) в Git б) в виде Excel plugin, чтобы код версионировать и отделить его от данных в таблицах. И на словах несколько раз обсуждается, как сделать, чтобы код был в Git, и в Excel одновременно. Следите за руками? Ожидалось, что файл .xls будет либо собираться из файлов .vba, либо наоборот, разбираться, чтобы их закоммитить.
Далее я, как постановщик задачи, отвлекаюсь, и через какое-то время уточняю, готово ли решение. И что я обнаруживаю? В Git лежат файлы Excel, а вовсе не .vba, .frm и т.п. (то есть, целиком таблицы, пусть и те которые внутри .zip), а во-вторых, этот censored написал инструкцию, что вот так и надо коммитить. И задачу закрыл. А исходных (до внесения им изменений) файлов .vba вообще нигде в Git нет.
Ну вот вам двое. Один трейдер, не программист, и писал на VBA, другой типа C# разработчик. Так кто из них больше профессионал?
Ну вот вам двое. Один трейдер, не программист, и писал на VBA, другой типа C# разработчик. Так кто из них больше профессионал?Судя по описанию… Один из них — хороший профессиональный трейдер, другой — дерьмовый программист.
Я вообще не понимаю о чём тут спорить.
Я практически уверен, что большинство тех, кто считает себя профессионалами, никогда в жизни не писали такое в одиночку.А я практически уверен, что большинство профессиональных монтажников сетей никогда не делали сеть такого масштаба:
Однако… вы всерьёз хотите сказать, что сейчас назовёте людей, сотворивших вот всё вот это — профессиональными монтажниками и администраторами? Да у любого профессионала при одном виде этого… творения — мурашки по коже.
Ну кроме тех, кто профессионал только по титулу, а не по навыкам — как раз как с вашим «профессионалам в C#».
А ведь оно работало. Не один десяток лет работало и куча народы счастливы были.
Вот так же и с вашими 120 тысячами строк на VBA (вы, кстати, так говорите, как будто 120 тысяч строк — это что-то огромное: но по меркам компьютерной индустрии это ведь очень небольшой проект… хотя, конечно, это очень внушительно для проекта, сделанного в одиночку… сравнимо по размерами c TempleOS).
очень любопытно, где такое было вообще?
Сам был в шоке когда увидел… Не верил глазам своим…
И как обычно, монополист провайдер с внутренними коммуникациями обходится коммуникациями снаружи.
Подождите. Насколько я понимаю, социально-экономически доступных вариантов тогда было примерно два: монтировать изображённого монстра или не делать сеть вообще. Люди выбрали первый вариант — и сеть у них работала. Верно ли я понимаю, что профессионалами следует называть тех, кто выбрал бы второй вариант?
Для тех, кто не опознаёт картинку — это общежитие в главном здании МГУ, где-то в нулевых годах.
Верно ли я понимаю, что профессионалами следует называть тех, кто выбрал бы второй вариант?Профессиональным монтажником можно назвать человека, способного сделать сеть хоть с какими-то SLA и такими, которые не позволяли бы всех участвующих, на законных основаниях, отправить «в места не столь отдалённые».
То что в данных конкретных условиях нельзя было создать нормальную сеть в принципе — всё равно не позволяет назвать происходящее на картинке «творением профессионалов», извините.
Потому что с таким подходом, как у вас и «жучки» станут «профессиональными» и установка оборудования без заземления (которое потом горит) и многое другое — тоже. «Ну и что, что кто-то ткнул пальцем и всё сгорело нафиг и 1000 человек похоронили… денег-то не было, значит то, что мы имели — это было супер-пупер-про».
Люди выбрали первый вариант — и сеть у них работала.Ну да — сеть работала и даже без смертельных случаев, насколько я знаю, обошлось. Повезло.
Тем не менее — профессиональным это творение назвать никак нельзя.
Я их, собственно, не виню. Сам такой — у нас в школе был тихо и незаметно перекинут через улицу к соседнему ISP Ethernet-кабель (бытовой прямо, не какой-то специальный, хотя какое-то устройство грозозащиты там было, насколько я помню). Несколько лет работало.
Но назвать это профессиональной сеткой? Я вас умоляю.
Я уж не говорю о том, что как система для программиста, мак уступает по многим параметрам и Windows, и Linux.
По каким же это интересно? macOs — сертифицированный юникс, в отличие от сами знаете.
Вообще-то, Eclipse во-первых всего 18 лет, так что 20 лет назад его не было. А во-вторых, он никогда не был средой для Java только. А как раз средой для разработки IDE вообще, под любые языки, с широкими возможностями расширения в виде OSGI.
Вообще-то, Eclipse во-первых всего 18 лет, так что 20 лет назад его не было.Было. Называлось только по другому.
Сегодня — фиг найдёшь, оч. большая редкость.
20 лет назад кросплатформенной или мобильной называлась программа, которую можно запустить под DOS, Unix на 5 различных архитектурах и OpenVMS.
Сейчас под кросплатформенностью подразумивается открытие сайта в Firefox и Chrome. А термин «мобильный» совсем изменил значение.
А любители LabView так вообще иной раз отжигают, используя ПЛИС для щелкания парой релюшек…
Хуже, что они для таких решений ещё и оправдания находят...
Ну лет 500 назад человек мог быть одновременно экспертом в химии, математике, механике и прочим наукам, а теперь видимо деградировал. Сомневаюсь, что сейчас квалифицированный железячник сможет написать качественный гуй.
в микроконтроллерах меньше учить надо. там нет такого дикого зоопарка фреймворков
Там же зоопарк микроконтроллеров, или нет?
А мейнстрим PHP-фреймворков всего 2 — Symfony и Laravel, и самому молодому из них уже 8 лет, не говоря уже о количестве всяких Laravel-девелоперов(или даже древнего Yii), которые клепают всё на нём и ничего более не умеют.
Да и вообще, давно фреймворки стали чем то сложнее чем набор готовых компонентов реализующих 20-30 лет назад изобретённые паттерны?
Да и вообще, давно фреймворки стали чем то сложнее чем набор готовых компонентов реализующих 20-30 лет назад изобретённые паттерны?С тех пор, как люди стали учить работу с фреймворками, вместо того, чтобы учиться программировать. А вот когда это случилось… не знаю.
Фреймворки — это мелочи, в основном знания утяжеляют всякие «паттерны энтерпрайз разработки» и вот это всё.
Так в том и дело, что много разработчиков останавливаются на шаблонном написании процедур в сервисах на каком-нибудь фреймворке, и этого хватает чтобы на работу брали.
А паттерны… Спросите у какого-нибудь веб-разработчика, в чём разница AR и Row Data Gateway, Repository и Gateway, REST и RPC, MVC и MVA, Coupling и Cohesion, ООП и ПП/ФП, зачем какой-нибудь UoW нужен — в лучшем случае теоретиком далёким от разработки не обзовут.
Видимо, веб-разрабочики не сталкивались с проблемами и не пытались их решить, всё-таки большинство работ довольно рутинные
Разработчики без минимального понимания зачем они что-то выбирают, не сталкиваются, да, они их создают.
Ну и изначально я как раз опровергал тезис о том что в веб-разработке есть какой-то зоопарк фреймворков/паттернов или ещё чего-то.
(Нету зоопарка, порог входа низкий. Результаты, увы, соответствующие)
Паттерны эти сами по себе имеют смысл только в попытках побороть определенные проблемы.
Не я начал про паттерны, но всё же:
AR / Repository / Gateway / UoW — это, вобщем-то, штуки которые используются часто(в любом проекте), и часто используются не по назначению / без понимания.
А ООП / MVC и пр. — мне не нравится то что люди очень любят об этом говорить и не особо вкладываются в изчение. Мода и всё.
Проблема узкого кругозора в том что разработчики не видят тот момент когда что-то идёт не так и что-то стоит улучшить.
Если разработчик не понимает Coupling/Cohesion — по каким принципам он вообще проектирует программу?
Обычно это сомнительные бест практики и то самое шаблонное клепание сервисов, что превращается в слабо-поддерживаемое легаси уже на 50-100к строк.
Плохо только то, что многие сознательно игнорируют best inductry practices, дескать намудрили эти джависты лишнего (питонисты добавляют «из-за ограниченности их языка»). Вот это неполезное распространенное явление, и встречается далеко не только в Web.
А можно пример этих «best industry practices»?
А то есть мысль что «Java Best Practices» действительно чушь в 99% случаев.
Работодатель/заказчик оплачивает не квалификацию, а способность решать его задачи.
из-за расцвета веба веб-кодеров тоже стали называть программистамиКогда было такое время? По-моему, расцвет презрения к Web-разработке пришелся на последние лет 10, когда веб-разработчиков стало настолько много, что стало возможным «элитарное» самоутверждение на них.
Хотя их в лучшем случае верстальщиками можно называть. А то эдак моя теща, которая статьи в латехе набирает, тоже в разряд программистов попадет…
Система управления зависимостями стала жизненно важной частью любого языка. Никто не хочет вручную скачивать или устанавливать что-либо. 20 лет назад, скачав zip архив, распаковав его в папку проекта, мы обновляли файл конфигурации и молились, чтобы ничего не сломалось.
Как же у меня от этого горит порой… Частенько встречаешь «самый простой способ установить плагин — npm instal...». И понеслась. Запускаешь — не работает. Надо импортировать. Опять криво. JS загрузился, а стили отвалились. Лезешь импортировать их — постой, вначале разберись с переменными путей. А все зависимости подгрузились? А файлы?
Зато оказывается сколько сложностей с распаковкой zip-архива…
Я дошел до ручки и отдельно складирую node_modules.tar.gz, чтобы локальная CI не давилась тормознутым инетом и не выкачивала еще раз 40 мегабайт пакетов, чтобы собрать вебмордочку
складирую node_modules.tar.gz
Можно же сделать частичное зеркало npm registry, чтобы при первой установке пакеты скачивались и сохранялись в нем, а в следующий раз устанавливались уже «в оффлайне», без обращения к основному хранилищу где-то далеко в интернете. Это удобнее, чем архивы, тем более, что есть готовые инструменты — не нужно все самому придумывать.
Adobe Flash, который был единственным рабочим способом реализовать нормальный интерфейс в вебе, к счастью, ныне почил. Правда, на смену единому стандарту пришли три разных фреймворка с абсолютно разными моделями.
Ну я бы не был так категоричен:
1. Подавляющее большинство фронтенда все еще на jQuery, который жил во времена Flash. И не знаю что хуже — фреймворки как-то больше дисциплинируют.
2. Веб стандартов не много, они большие и многолики. Да и фреймворки все больше на друг друга похожи. Особенно Vue3 и React
3. Супруга ежедневно посещает онлайн игрушку на флеше, я часто посещаю вебинары, которые тоже работают на флеше. Даже не знаю на скоро его хоронить.
Даже не знаю на скоро его хоронить.У вас остался ровно год. В конце 2020го и Adobe и Google перестанут его поддерживать. Совсем. С концами.
Вот блог-пост от Adobe. Вот от Google.
И да, я больше чем уверен, что будут и петиции и требования вернуть и много чего другого… а реакции… не будет. Всё уже прошли когда отключали Java applets.
Как я уже сказал: шуму была масса — но ничего не изменилось. И инсайд ничего не сделал.
Что-то может сделать только достаточно большой процент пользователей, причём в мировом масштабе, а у Флеша — этого нет.
Ради VK никто ничего поддерживать не будет… они слишком маленькие.
Касательно Нортон Коммандера — я к нему так привык, что у меня FAR стоит на 200+ серверах, с которыми надо работать. Мелочь, а приятно.)
В индустрии гораздо больше талантливых женщин, людей не европейской внешности
интересно, кто-нибудь проводил срез эффективности работы среди женщин и негров?
Поясню сразу для адептов заокеанских стереотипов, слово «негр» в России не является оскорбительным.
Многие не считают туториалы полезными, если только это не видеоролик. Даже если его просмотр займёт больше времени, чем прочтение текста.
Меня совершенно искренне удивляет способность и желание некоторых, вместо нескольких четких и ясных фраз (сотен байт — единиц килобайт за короткий текст) и иногда нескольких четких и ясных картинок (тут по-разному, иногда на единицы и даже десятки мегабайт счет, но чаще сотни килобайт за штуку), производить и потреблять многочасовые неинформативные видеоролики, неудобные для поиска сути и непригодные для этой самой сути понимания в том удобном для себя темпе, который доступен при чтении текста и разглядывания иллюстраций к тексту. И это я молчу о том, что в мире все еще много мест, где ширина канала сильно ограничена и гигабайты (где десятками, где сотнями) бессмысленного видео, вместо единиц килобайт осмысленного текста, внезапно имеют значение.
Нет, не один, но видимо, мы вымирающие динозавры.
Некоторая часть информации лично мне (при моей адской нелюбви к видео, я фильмы смотрю примерно по одному в год) внезапно гораздо лучше доходит именно в виде ролика. Я полагаю, некоторые вещи проще один раз увидеть, чем десять прочитать. Как разобрать заковыристый ноутбук, или подлезть к хитрому узлу в автомобиле.
Хотя конечно, видео на каждый чих — нелепость.
(Тут можно еще развести этологическую конспирологию про первую сигнальную систему и биологическую приспособленность «смотреть, как делают», а не «читать, как делают» — оставим это любителям жанра)
А по программированию, разработке есть подобные примеры, когда видео лучше?
Но поскольку я не программист и не разработчик, то судить об этом могу только с известной осторожностью. Я склонен приписывать такую доходчивость привычному лекционному формату, но могу и ошибаться.
20 лет назад был язык и IDE, специально разработанная для него, вроде Eclipse для Java, Visual Basic, Delphi и т.п
Насчет Eclipse не согласен, сейчас трудно найти более универсальную IDE чем эта. Большая часть компаний — производителей «кремния» в качестве средства разработки предоставляют переделанную Eclipse.
Сейчас упоминание в технической или научной статье ЛГБТ становится чем-то вроде ритуала, в точности, как упоминание съезда КПСС и Ленина в научных статьях недавнего прошлого
Не хочу обидеть молодое поколение, но бывает такое на тостере спрашивают…
Бывает хочешь лишний раз помочь, и думаешь, а надо ли твой ответ. Если человек какую нить контрольную хочет решить, то это я считаю нормально. Но судя по вопросам, это будущий вайтишник, как бы печально это не звучало.
Коллеги хмурятся, когда узнают, что вы храните пароли пользователей в открытом виде. Но ничего не говорят: они сами так делают.
Раньше они просто хранили эти пароли в открытом виде не хмурясь =)
Мы выполняем программы на видеокартах.
Ну а раньше была возможность использовать для ускорения вычисления сопроцессор, так что не сказал бы, что это какая-то новая концепция
Говорят, что до изобретения StackOverflow приходилось задавать вопросы живым людям.
Враки это всё. Всяческие форумы и сайты были уже тогда.
IDE и языки программирования удаляются друг от друга. 20 лет назад был язык и IDE,
не знаю, о чём это автор: vim-у и emacs-у кажется уже под сорокет будет, а nodepad++ появился в 2003м
Набор инструментов при работе с языком гораздо шире. Раньше был только компилятор и, если повезёт, отладчик. Сегодня они обычно идут в комплекте с линтером, средством форматирования кода, шаблонизатором, возможностью самообновления и списком доводов для использования в холиварах против конкурирующих языков.
Форматирование кода было давно (vim autoident, so one), какому-нибудь w3c-шному валидатору тоже лет 20, шаблонизаторы — не новая идея (если имеется в виду template engine). Холивары — они вообще всегда были.
Разве что обновления не лету не припомню
Если брать в целом, то сейчас время, которое раньше уходило на оптимизацию уходит на функционал.
Начинал c Turbo C во времена 386 без мат. сопроцессора и обычное умножение и деление было затратно по ресурсам даже для целочисленного типа.
Выполнять деление числа с плавающей точкой было непозволительная роскошь.
Библиотек на все случаи жизни не было. Даже декодирование формата PCX писал сам. Кто-то еще помнит про вызов функций BIOS через прерывания?
OpenGL был доступен для оооочень взрослых машин. Для реализации софтового рендера для PC приходилось осваивать затенение по Гуро, Фонгу самому.
3dfx с Glide был штукой дорогой и редкой. Потому только софт, только хардкор!
Битовый сдвиг для умножения/деления числе, массив со значениями синусов, косинусов, ассемблерные вставки, экономия каждого байта — реалии тех времен.
Пресловутый барьер по памяти 640кб (которой, как известно, хватит всем :-) ). Достать Watcom C++ с расширителем DOS4GW была та еще проблема.
Потому 4 Мб оперативки вроде и были, но использовать их было не так просто. Использование защищенного режима — та еще забава.
Отслеживание утечек памяти, неиспользуемых переменных и функций, мониторинг ресурсов, автоматическое форматирование кода и прочие вещи, которые сейчас делает IDE, раньше возлагались целиком на вас.
Документации не было толком. Лишь бумажные книги, конференции usenet и MSDN на дисках(это уже позже).
Сейчас есть Unity. Конструктор, где из кубиков можно собрать что-то красивое и бессмысленное буквально за день. Автоматическая сборка мусора, уйма библиотек на все случаи жизни. Тонны документации, примеров в интернете, Ютуб ролики и в целом низкий порог вхождения.
Платой за это является 20 мегабайтный exe с функционалом «Hello World!», сжирающий столько же оперативки.
Но зачем парится, современный компьютер и не такое стерпит.
Людской труд стоит гораздо дороже, чем условная железка. На оптимизацию в текущий реалиях тратится экономически невыгодно. И эта тенденция дальше будет лишь усиливаться.
Даешь больше тактов на сбор мусора, фоновую оптимизацию, интерпретацию, виртуальные машины! Больше гигабайт на обширный runtime, кэшируемые данные и непомерно разросшееся ядро OS!
Чем программирование сегодня отличается от программирования 20 лет назад?