Работаем два года по GitFlow (на самом деле, rebase flow) в команде из 5 разработчиков над относительно крупным проектом с высокой плотностью как мелких, так и крупных задач. Все очень легко и понятно, возможные нечастые конфликтные ситуации (случаются не часто) обсуждаются в команде и легко решаются. Накладные расходы на содержание feature веток минимальные. Поэтому я как то в упор не вижу проблем, описанных автором и не понимаю, зачем так жестко критиковать хорошо зарекоммендовавший себя за много лет механизм.
Про оду JQuery. Я давно уже не использую в новых проектах, и ничуть жалею. Обнако, недавно имел удовольствие лицезреть при отладке старого кода, ЧТО под капотом делает метод JQuery.remove для элемента. Я думал это примерно как Node.removeChild, оказалось- там множество циклов и кода при вызовах различных достаточно непростых функций. Весьма любопытно, как такое скажется на прризводительности...
OMG, очень интересная статья «Объяснение коллбеков в Javascript», особенно пункт «Parameters to callback functions». Может вы и не заметили, но такие статьи крайне вредны при изучении JavaScript…
Придерживаюсь такого же подхода. Программа должна быть читаемой и объяснять _что_ требуется выполнить, а не _как_. Оптимизировать нужно только те места, где реально необходима оптимизация. На С сам давно не писал, но могу предположить, что в приведенных выше примерах компилятор вполне может выполнить оптимизацию так, чтобы эти примеры выполнялись абсолютно одинаково как по скорости, так и по результату. А если не видно разницы — зачем усложнять понимание?
Не будем мы через 20 лет ООП использовать, сегодняшние концепции точно отомрут. Это либо будет эволюция в сторону декларативно-функционального программирования, либо совсем новый подход. Я говорю об этом исходя из того, что в наше время очень активно развиваются ИИ технологии, много новых языков и подходов к программированию. Лично для меня очевидно, что через 20 лет ООП вообще перестанет существовать, если воспринимать его в классической интерпретации.
Бритва Оккама для языков программирования, по сути. «Не следует множить сущее без необходимости» («Не следует привлекать новые сущности без крайней на то необходимости»).
Наивно рекоммендовать всем отказаться от кэширования только из-за того, что если в одной конкретной архитектуре одного конкретного приложения с одним конкретным стеком технологий кэширование оказалось неэффективным.
Спасибо Вам что указали на ошибку. Полностью переписал пост, надеюсь стало лучше:) Кстати, на знаю, связано ли это как то с ИИ, но в списке планируемых возможностей на картинке reasoning.info/examples.htm значатся Machine Learning, Text Analysis. Я правда не совсем понял, что подразумевается под этими терминами.
Хитрая это штука, программирование...:) У меня так в жизни получилось (таких думаю очень много), что в детстве я делал весьма сурьезные штуки на ZX Spectrum на его простеньком ассемблере, для меня в то время это было сложно, поэтому мегаинтересно, куча бессонных ночей, можно сказать у меня был проект, который практически смыслом существования. После поступления в ВУЗ, осознания того факта что платформа Z80 приказала долго жить все поменялось, и я бы сказал лет за последующие лет 8 я ничего по настоящему серьезного и стоящего как программист не создал. Сейчас вот пытаюсь догнать упущенное, и да, вспоминаю/учусь заново, что делать с интегралами:)
вообще, я высказался не совсем точно, C#/Java тоже можно в нативный код скомпилировать, и C++ под виртуальной машиной запустить, еще и со сборщиком мусора:) но нативный код, т.е. код исполняемый процессором в общем случае быстрее кода исполняемого виртуальной машиной, тут думаю доказательств не нужно.
3. Красота кода (тема для отдельного поста)
4. Расширябельность
5. Тотальный контроль
Примеров можно привести много. Я просто думаю, «а вдруг...» Захочется мне например, или сочту нужным, операцию умножения чисел
типа double переопределить как
Double result = (float) a * (float) b
либо переписать сам на ассемблере, либо таблички какие нибудь задействовать, либо еще что:)
а чем такая задача плоха? сейчас просто занимаюсь написанием трассировщика лучей, планирую реализовать фотореалистичный рендеринг. и планирую оптимизировать, учитывая каждый такт процессорного времени…
С#/Java все же несколько уступают по производительности ЯП компилируемым в нативный код, не берусь оценить насколько. А для меня производительность — это ОЧЕНЬ важный показатель… хотя, как уже писал выше, писать код на C# к примеру мне приятно, мозг меньше напрягается:)
sizeof по идее должен вернуть sizeof от приватной переменной _value. Переопределение типов может и дело вкуса, но у меня вот такой вот вкус, понравились некоторые моменты написания кода на C#, хотя я и предпочтаю С++.
Для меня, если честно, оно уже потеряло свою привлекательность при решении довольно большого множества задач. Но, ведь наука не стоит на месте. И рано или поздно то, что я выше написал будет возможным, то есть можно будет провести диалог типа:
(Я, Комп)
Я: Нарисуй ка ме круг с радиусом 10 в центре 0.0 на стандартном экране
Комп: — Нарисовал, но на белом фоне с красным цветом линии, и зеленой заливкой, да и антиалиасинга нет, может че подправить?
Я: — Да, пожалуй круг надо исправить, вообще давай ка ты мне лучше сферу отрендери с фотонными картами и материальчиками.
Комп: — Будет сделано!:)
Просто можно ведь сделать чуть чуть умнее наш калькулятор, а самим заниматься более интересными задачами. Само собой, научить думать программы мы вряд ли сумеем, но умнее сделать их я думаю нам под силу. Мне просто жутко лень, я cверхленивый программист:)
Интересно, почему OpenCL, а не Vulkan? Vulkan для GPGPU сегодня вроде как более современная и перспективная технология.
Про оду JQuery. Я давно уже не использую в новых проектах, и ничуть жалею. Обнако, недавно имел удовольствие лицезреть при отладке старого кода, ЧТО под капотом делает метод JQuery.remove для элемента. Я думал это примерно как Node.removeChild, оказалось- там множество циклов и кода при вызовах различных достаточно непростых функций. Весьма любопытно, как такое скажется на прризводительности...
1. Краткость записи
2. Кроссплатформа
Да, и для этого тоже.
3. Красота кода (тема для отдельного поста)
4. Расширябельность
5. Тотальный контроль
Примеров можно привести много. Я просто думаю, «а вдруг...» Захочется мне например, или сочту нужным, операцию умножения чисел
типа double переопределить как
Double result = (float) a * (float) b
либо переписать сам на ассемблере, либо таблички какие нибудь задействовать, либо еще что:)
Вот не знаю, надо мне и все:)
(Я, Комп)
Я: Нарисуй ка ме круг с радиусом 10 в центре 0.0 на стандартном экране
Комп: — Нарисовал, но на белом фоне с красным цветом линии, и зеленой заливкой, да и антиалиасинга нет, может че подправить?
Я: — Да, пожалуй круг надо исправить, вообще давай ка ты мне лучше сферу отрендери с фотонными картами и материальчиками.
Комп: — Будет сделано!:)
Просто можно ведь сделать чуть чуть умнее наш калькулятор, а самим заниматься более интересными задачами. Само собой, научить думать программы мы вряд ли сумеем, но умнее сделать их я думаю нам под силу. Мне просто жутко лень, я cверхленивый программист:)