В качестве введения написал небольшой скрипт, который в цикле for суммировал числа от 1 до 5 и спросил аудиторию, какой будет результат.
Я сказал, что 500. Все в аудитории посмеялись. Кто-то крикнул, что получится 15. Преподаватель запустил скрипт. 500 Server Error. Он пропустил точку с запятой.
Я в 1992-94 г.г. баловался Бейсиком. По образованию юрист, по профессии (тогда) преподаватель. Даже написал самостоятельно парочку работающих программ по своим предметам (психология; уголовное право, общая часть), они сами курсантам выставляли оценочки, а я только собирал их с экранов себе в журнал.
Пож., опишите мой портрет. У Вас очень красиво получается, со смаком. Я б так не смог. Честно.
Прошу прощения за вторжение монстра из прошлого века в молодежную аудиторию.
К сожалению, указанных данных для портрета недостаточно :)
А вообще, баловство с любыми языками - такая же хорошая вещь, как и любое другое хобби. Всё-таки программинг - инструмент для решения задач, и когда человек копается в нём на уровне "дай погляжу, что за зверь" - это замечательно.
Но здесь, как и в других профессиях, главное - трезво оценивать свои навыки и не лезть с любительскими познаниями в серьёзную разработку. Одно дело уметь ковыряться в машине, и совсем другое - чинить машины другим людям, которые надеются на то, что специалист понимает свою работу и верно оценивает все риски и последствия.
Что касается вековой дифференциации - в интернете важен психологический возраст, реальный тут силы не имеет. Так что меньше извенений, больше ощущения своего равенства :)
С разу видно, что Вы человек разбирающийся в этой убласти, может расскажете чем можно заменить "ПОХАПЕ" и перейти на более профессиональный уровень (после соответствующего обучения, конечно)?
Я не уверен, что переход на более профессиональный уровень обязательно связан с уходом с похапе. Он неплохо подходит для большого круга задач, важно лишь научиться аккуратно его применять.
Волшебной пилюли нет, курсы - товар на n часов увлекательных но бесполезных монологов, книги - в первую очередь товар на определённое количество страниц.
Код из-под образованных и начитанных господ и средних программистов чаще всего по качеству различить не выйдет, 90% КРИТИЧЕСКИ ВАЖНЫХ знаний, проверяемых на собеседованиях "профессионалами", раздувающими от важности щёки, на практике бесполезны, потому что умные все только в теории, а в коде всё-равно насрано.
В общем, счастливого пути :)
Все эти возгласы про бородатых дедов в очках и засаленных свитерах, пишущих на c++, про школьников, пишущих на пхп и яваскрипте - просто приём в специальных олимпиадах на тему "какой язык лучше". Профессионалы в них не участвуют. Профессионалы умеют писать и на том и на том, но выбирают язык под задачу, а не под мнение школьных экспердов.
Больше требований к себе, больше строгости к архитектуре, больше здравого смысла, и основной минус похапе - возможность сделать всё через жопу, нечитаемо и неподдерживаемо - станет не страшен.
На чём опыта набираться по большому счёту не так важно, однако работы для похапешников всегда достаточно. А там всё-равно захочется поковыряться в других языках.
А за что его любить? Кривой by-design, небезопасный by-design, провоцирующий ошибки by-design, вобщем говно. By-design.
Пхп отлично подходит для того сегмента, который он занимает. А социальные сети никто на нем писать не будет
vk, facebook на php и написаны. У них уже свой php с преферансом и поэтессами, но тем не менее изначально это был тот самый php и проекты таки взлетели
Тем, что это демоны, так или иначе, которые работают хреново по определению. И есть очень мало хостингов, на котором это можно запустить. Только выделенный сервер. Но там уже можно и ноджс поднять, и не извращаться.
Тем, что это демоны, так или иначе, которые работают хреново по определению.
это не аргумент без пруфов
очень мало хостингов
кто-кто еще использует шаред хостинги? разве что для визиток, для которых вебсокеты не нужны
ноджс поднять, и не извращаться
можно, кто спорит, я это и выберу. но если человеку не вариант обучаться ноде
Читай внимательно сообщения, прежде чем нести херню. Сам что-то выдумал и пошел кидаться говном.
малость промахнулся. связал 5 комментов от разных пользователей и подумал что ты даун какой-то. извиняюсь
"Тем, что это демоны, так или иначе, которые работают хреново по определению."
- они работают также, как и в nodejs, тот-же eventloop 1 в 1, при этом можно использовать и stream_select и libev, libuv - тотже, что и в nodejs. Падать при отсутствии обработки ошибок будут они одинково
"И есть очень мало хостингов, на котором это можно запустить"
- после этих слов, ваш текст нельзя воспринимать всерьез. Любой vps за 100 рублей это позволяет. Если вы до сих пор пользуетесь хостингами - все с вами понятно.
"ноджс поднять, и не извращаться"
- А в чем разница между reactphp:
$server = new React\Http\Server(function (Psr\Http\Message\ServerRequestInterface $request) {
return new React\Http\Response(
200,
array('Content-Type' => 'text/plain'),
"Hello World!\n"
);
});
И node.js аналогичным кодом?
Если вы не понимаете, что работают они 1 в 1, то вы и node.js знаете на уровне быдлокодера...
Забыл про пхп уже давно, но проблема reactphp и daemon'a в том, как пхп играет с памятью, достаточно легко зарубить себя даже не совершив никаких ошибок и возможно получить рассинхрон параллельных/конфликтующих запросов, что например при работе с деньгами очень даже сильно влияющий/определяющий фактор выбора платформы для разработки. Ну и еще одна проблема это блокирующие операции. Но у нас все равно все пишут на пхп и похуй какие операции там крутятся. Ведь дешевле нанять русского васю написать код, а затем русского петю чтобы починить его.
В PHP 7 все отлично с памятью, сборщик работает, отстрелить себе ногу можно только циклическими ссылками и то, если руки из заднего места.
"рассинхрон параллельных/конфликтующих запросов" - в любом языке будет аналогично.
"что например при работе с деньгами" - вам в любом языке либо придется ждать, либо проверять статус платежа получая оповещения от пс.
"блокирующие операции" - потоки неблокирующие, кроме файлов в винде, но это уже проблема ос, в linux все отлично переключается в неблокирующий режим.
Бд также имеет неблокирующие операции.
Вы назвали проблемы - которых в итоге не оказалось.
Большинство таких людей как вы - хают один язык и восхваляют другой, но в итоге не знают, что под капотом находится что у одного, что у второго...
Сейчас еще есть и swoole, что аналогично серверу от nodejs, расширение написанное на c, и в недавнем соревновании highload парень с ним обгонял решения на nodejs с лихвой.
Про глобальную установку расширений пишут только идиоты. Создаем отдельный файл конфигурации и включаем только нужные расширения.
Если человек не может запустить скрипт с определенным файлом конфигурации - это даже не junior.
Где в итоге реальные проблемы?
У меня много написанного кода на пхп до 2015 года, сейчас я легко пишу код на ноде, го, питоне и даже не задумываюсь смотреть в сторону php 7.0. Он бессмысленный. Зачем он нужен, если уже есть хорошие инструменты заточенные под асинхронную среду, поставляемые пакеты уже умеют в синхронные/асинхронные интерфейсы. Бомбить с пеной у рта доказывая няшность пхп тут не нужно, плез. Я слез и желания возвращаться честно нет.
Я не говорил, что стоит писать только на php и не смотреть на другие языки. "Бомбите с пеной у рта" только вы доказывая, что php калл и нужно использовать что-нибудь другое. В вебе везде не нужна асинхронность. Легче прицепить swoole или reactphp к проекту для нужных мест, чем написать на nodejs огромную бизнес-логику с кучей сущностей. Это не значит, что так нужно делать, хотите - пишите на nodejs, хотите на питоне, хоть на ассемблере, но ненужно говорить о других языках плохо, если вы их совсем не знаете.
Вы так и не привели не одного примера, почему не стоит использовать php, кроме того, что вы так считаете)
"Я не пишу на php" - это как веганство, только у веганов это началось недавно, а с php такое уже больше 5 лет, и это только при мне. Сколько его хаят, сколько ему пророчат смерть, но в вебе он закрепил лидирующие позиции в своей нише. nodejs он фору даст с лихвой. А там, где python и go, нишу держат как и держали c++, java.
Да, его мало кто использует для асинхронности, но это пока.
Чет если посмотреть со стороны, то именно ты как-то сильно больно реагируешь на то, что есть люди обходящие твой любимый пхп стороной. Я вполне обхожусь без пхп и умею писать код на разных языках. А то, что там возможно пхп даёт фору ноде, не смешите мои яйца, писать на ноде невероятно удобно.
Вчера я писал простой прокси сервер, все что он должен был делать это получать трафик по tcp расшифровывать его и кидать в локалку, с локалки забирать шифровать и кидать клиенту, я написал его на го. Месяц назад я писал интегрирующуюся dll для отлова событий в памяти процесса одной игрушки, написал я её на с++. Вторично пишу веб сайт на связке node+react. Ну и почему я должен взять пхп, если у меня отвращение от его нелогичности и дизайна и из того что я умею он ничем не выделяется, а лишь пытается догнать? Я не пророчу ему смерть, в своей нише быстро-сайтов, он лидирует и будет. Вы не поверите сколько я видел кода на пхп, где сайты с виду выглядят очень круто, а когда меня просили что-то поправить, это было жесть. С этим предпочитаю больше не работать. Бай.
Perl неудобный язык сам по себе (имхо, его слишком переусложнили не по делу), но даже близко не такое говно как php.
Знаете, я пишу на generic/ANSI C.
Он не кривой и не говно, но убиться на нем ТАК легко ! Особенно для МК разработчика.
У нас на старте дебагеров не вагон, обычно их нет вовсе (ну STM32, да, там все почти сразу и почти супер, молодцы) но для большинства других архитектур на старте у Вас только нога или две со светодиодиками :)
Недавно сперва с бутлоадером (очень жесткий регламент на объем кода, часто некуда воткнуть даже светодиодик на ножку), а потом в скетче МК приложения.
А потом я сел писать часть хоста.
И когда я заявил TStrigns у меня на глаза навернулись слезы.
А потом я целый день просто добавлял функционал и прямо рядом со средой разработки его запускал, видел, поправлял, вообще не скупясь. Ни на циклы записи флэш, ни на сам факт необходимости залить код в кристалл.
-------------------------------
ХУЛЕ ТЫ НОЕШЬ !!! ???? :)))))
> Знаете, я пишу на generic/ANSI C.
Вам поаплодировать? Нормальный язык. Как он относится к сообщению, на которое вы ответили - не ясно.
И, кстати говоря, никогда не понимал этих стенаний от разработчиков программ для микроконтроллеров: "О, жёсткий регламент на объём кода", "Ах, ассемблер/C", "О боже, обработка прерываний!". Блин, да по сравнению с какой-нибудь маленькой ошибкой в глубине сторонней библиотеке на несколько сотен файлов/десятков мегабайт исходников, это просто отдых. И по сравнению с "найди ошибку в многопоточном приложении, которая возникает исключительно в ясные ночи при свете большой медведицы" - тоже.
А кто заставляет юзать стороннюю библиотеку ? Я ? Если не довольны результатами чужих - правьте их.
Пишите свои. Что впрочем Вас не убережет. Вы давно ловили утечку памяти не в сторонней библиотеке, а в DLL от поставщика ОС ? (Да-да, Microsoft). Я вот совсем недавно.
И был вынужден реализовать код в обход рекомендаций MSDN. Успешно.
А средняя сборка USB стека на устройство у меня, кстати включает много библиотек. LUFA. Кое-что правил, кое что, из библиотеки перетащено в свой инклюд, экономии памяти ради.
Кое-что вообще упразднил для своей конкретной задачи.
Тут уж выбирайте. Или библиотеки и "я-не я", или библиотеки и "ноша все равно моя".
PS А стенания: у нас нет, как правило нормального (или вообще никакого) отладчика. Мы - архитекторы птиц, которые летят хвостом вперед. Мы видим по реакции изделия то, что УЖЕ произошло. Но почти никогда не видим когда и как это случилось.
PPS Почти все системы взаимодействия хост-девайс это многопоточные приложения с разной степенью асинхронности во все стороны. При этом девайс, как правило тоже реализует асинхронность. Но реализуя фактическую многопоточность в одну нить.
> А кто заставляет юзать стороннюю библиотеку ?
Необходимость? Речь вообще о том, что в микроконтроллерах сложность кода существенно ниже, поскольку меньше слоёв абстракции между кодом и железом, меньше взаимодействия с ОС и сторонними компонентами.
> у нас нет, как правило нормального (или вообще никакого) отладчика
Как правило? Что правда: ни эмулятора, ни отладчика, ни возможности скомпилировать в тестовой среде? И в любом случае проблемы с отладчиком бывают и на десктопе/вебе.
> Мы - архитекторы птиц, которые летят хвостом вперед
eye-roll...
меньше взаимодействия с ОС и сторонними компонентами
Оп...
И да, есть эмуляторы, правда они ниочем. Есть и дебагеры. Правда для работы с девайсом при периферии, где задействованы аппаратные прерывания в пару сотен наносекунд все описанное бесполезно.
Компилируй сколько влезет. В любой среде. Да, в любом случае бывают проблемы, и веб-клиент в отношении отладки довольно похож, согласен.
Вот только туда можно голову сунуть. В МК - нет.
> Вот только туда можно голову сунуть. В МК - нет.
В теории. А на практике, когда у клиента возникает странная проблема при странном расположении звёзд - ну ок, попробуй сунуть туда голову. Обычно остаётся только гадать на внутренностях лемминга о причинах проблем.
ЗЫ. Я слегка наезжаю на вашу область, поскольку, имхо, в ней сильно перегибают палку: она не сложнее чем любая другая, но ЧСВ разработчиков ПО для микроконтроллеров временами пронзает небеса.
И обычно это оправданно. Вы легко можете не увидеть лажу интерпретатора. Мы, кристальщики видим все. Профайлинг на наносекуды, временные диаграммы, почти полный отказ от абстракции - наше все. Вы даже не представляете как наш брат порой передает указатели из бутлоадера в основную программу при сбросе кристалла по таймеру сброса.
Подавляющее большинство ВЕБ программистов (я не о Вас конкретно) вообще не думают об архитектуре. Это и хорошо (за нас уже придумали) и плохо - Вы полностью оторваны от земли и от физики.
Задирать нос до небес я лично не намерен. Но вы работаете только с кодом и результатом визуализации. При этом ресурсов у вас хоть жопой ешь. Мы работаем с кодом и аппаратурой. ресурсов обычно выше крыши (любой вменяемый мк программист почти всегда берет с запасом, да запас с прогрессом идет в гору, скоро наверное сравняемся). Но изредка все очень впритирку. Настолько, что я в недавнем проекте унес код функции в тело основной программы. Сэкономил 2 байта и втиснул таки загрузчик в 4 кб.
Вы давно писали приложение с реализацией аппаратного стека, протоколом и шифрованием, которое влезет в 4 кб ? я думаю, простите.. никогда.
> Задирать нос до небес я лично не намерен.
То есть выше чем сейчас у вас не получается? Не удивлён, выше задрать нос без риска свернуть шею сложно.
> Вы давно писали приложение с реализацией аппаратного стека, протоколом и шифрованием, которое влезет в 4 кб ? я думаю, простите.. никогда.
Я думаю, что Ванга из вас хреновая. Вот просто вообще.
Кстати, вы это так описываете, словно это сколь-нибудь сложно.
BTW. Вы не опровергли ни того, что ЧСВ у вам подобных просто космически раздутое, ни завышенного мнения о сложности разработки для МК.
BTW2. Вы книги случаем не пишите? Или лекции может читаете? Речевые обороты очень своеобразные.
Читал лекции. сетевые технологии и низкоуровневое программирование.
Нет, это не сложно. Просто специфично. Настолько, что многим кажется сложным. Хотя в принципе это очень банальные основы. Нужно уточнить, что в мое время схемотехник редко был программистом и наоборот. Потому что для достаточного уровня освоения в двух профессиях обычно требовался хотя бы десяток лет. Возможно сейчас что-то изменилось.
Ну а по существу обсуждаемых аспектов мнение будет ?
> Ну а по существу обсуждаемых аспектов мнение будет ?
А у вас было что-то по существу? Не могли бы вы процитировать?
А пока давайте я вам просто мой тезис напомню:
Программирование для микроконтроллеров существенно проще, так как отсутствует огромное количество абстракций и сторонних библиотек с поведением "чёрного ящика", кроме того обычно не приходится беспокоиться о многопоточности и проблемах с ней связанных.
(Я не отрицаю, что там есть свои особенности - например аппаратные недочёты, список которых прилагается к некоторым контроллерам, могут изрядно осложнить жизнь)
> Вы даже не представляете как наш брат порой передает указатели из бутлоадера в основную программу при сбросе кристалла по таймеру сброса.
Вы, видимо не слышали о методе возврата в реальный режим 80286. Если слышали, то что вы такого удивительного написали?
> Настолько, что я в недавнем проекте унес код функции в тело основной программы. Сэкономил 2 байта и втиснул таки загрузчик в 4 кб.
Оптимизация алгоритма, чтобы втиснуть его в tiny-модель памяти (jxx на +/-127 байт) считается? В школе это казалось сложным, да.
Но понимаете, всё вышеперечисленное - это "не по существу", это банальная фаллометрия. Вы приводите какие-то свои случаи, я на них что-то отвечаю - я могу начать приводить забавные случаи, вроде "Проект на Java EE (JPA2 - Hibernate ORM), в какой-то момент запрос возвращается пустым - попробуй раскопать что именно и где в этом нагромождении абстракций сработало неправильно и почему. Документации нет, готовых ответов нет, зато есть исходные тексты Hibernate в которых чёрт ногу сломит (Хинт - проблема была в инициализации HashMap константными значениями вместо реальных глубоко в библиотеке - бага Hibernate)".
А по факту, когда есть возможность обозревать весь код (4КБ это сколько - 15-25КБ исходников?) - это резко упрощает работу.
Хорошо. Давайте так:
Вы мне скидываете свою задачу, я Вам свою.
Не важно как именно она будет решена, условие только одно: Мы оба назначаем одну произвольную аппаратную платформу, она должна быть доступна либо в качественном эмуляторе, либо в железе.
Ограничения на время реализации - на Ваше усмотрение.
Старт по договоренности, наверное неплохо подойдут предстоящие новогодние праздники.
Задача обязана быть тестовой, некоммерческой, достаточно несложной (на честную троечку по представлению каждого) и не слишком ёмкой (ну не хочется же просидеть все выходные ради измерения длины).
Готовы ?
Эээ... вам напомнить о чём спор был? О разнице в комплексности задач для микроконтроллера и "больших" приложений. А вы предлагаете "скинуть достаточно несложную задачу". Никаких противоречий не видите?
Нда. Нахожу. Ну что-ж, если мы оба на равных позициях, у меня нет опыта в разработке действительно масштабных приложений, а у Вас, предположительно, нет опыта в разработке под сигнальную аппаратную архитектуру.. И раз уж при этом мы оба придерживаемся позиции, что сложна именно его область, то видимо следует признать: сложны обе области. Каждая по своему. Вот только возразите мне, что Ваша сложнее ! :)
Вы этого вероятно не знаете. Разве что раскопали уже стек USB, симулировали i8042 или еще что-то подобное.
Я открыто признаю: нет, я не работал с разработками на левых библиотеках с огромным количеством кода. И в принципе наверное у меня нет права судить тех, кто с этим живет.
Не с того он начал лабу им делать. Не с того.
Научу как надо.
Для начала определимся с глобальными переменными, что из них точно volatile, потом плавно переходим к static и жестоко совокупляем в попу за лишнюю public переменную.
Постепенно поясняем когда имеет смысл определять #define, а когда нет. И к моменту, когда наконец-то до нее дойдет, что однократно применяемая функция обязана быть в коде, а не обособлена - шли ее нахер. Программера ты из нее все равно не сделаешь.
Нередко это хороший подход для любого языка.
Если Вы пишете не личную утилиту, а продукт, пусть и для небольшого рынка, увидев хреновую архитектуру - просто забираем оттуда все части (а если Вы прошаренный и сразу побили на функцианальные библиотеки - то только их) и строим каркас с нуля. Лучше не сходу, а (не)поспав пару ночей. И вот - хорошая архитектура. Вот, изящный костяк.
Ну пока, по крайней мере.
PS Ох, давно regexp не использовал. Года три. или четыре. Но когда использовал - полностью оправдалось. Писал мидварь между системой сбора данных и рассылки на табло по modbus-485. Когда оказалось, что входные данные не всегда укладываются в формат (у них видите ли "-INF" бывают на выходе, типа ошибка) - потребовалось лишь продиктовать что вписать в строку ini файла. НЕ ПЕРЕПИСЫВАТЬ ПРИЛОЖЕНИЕ. только исправить строчку в INI.
Клянусь, не вру.
Изучайте Python.
Ruby, безусловно, классный, но вот скажите честно, Вы стрижете свою бороду в барбершопе?
Я вот кстати до этого момента всегда ратовал за Pascal в качестве начального языка. Но вот сейчас решил прям конкретно задуматься. И пришёл таки к выводу, что начинать с питона - не такая плохая идея, как мне раньше казалось.
1. Люди сразу приучаются к структурированию кода (а некоторые IDE ещё и выделяют места, которые не соответствуют PEP8. То бишь, человек сразу понимает, как лучше писать код)
2. PyGame. Ты можешь за 40-50 строчек написать простенькую игрушку на двоих (без сети, два сета контролов на одной клаве). Это просто ахуенная мотивация. Серьёзно, я не смогу придумать лучшего способа завлечь практически любого человека. Кто, чёрт возьми, не хочет написать своими руками игрушку, в которую будет интересно играть?
Но тут есть очень большой вопрос о том, что в питоне нестрогая типизация. Я не знаю, что чувствуют люди, которые переходят из нестрогой в строгую. Тут возможны жёсткие анальные боли и прочая негативные эффекты. А может и не возможны. Хз. Но точно знаю, что есть далеко ненулевая вероятность не пропатчить свой мозг правильным способом мышления, которые необходим при строгой. А шанс того, что на фирме будет использоваться какая-нибудь Java, а значит и того, что переход этот придётся осуществить, очень и очень высок, ибо Java и её производные везде, это факт.
Наверное, идеальный вариант - это так, что ты втягиваешься в питон, пишешь простенький проект, а потом у тебя забирают питон и пока ты нормально не перепишешь этот проект на что-нибудь строгое, не отдают.
За изложение плюсну.
Структурные языки, pascal в частности дают возможность относительно быстрого входа и не искалечат новичка. Высокие стандарты оформления кода большинства современных структурных языков приучают к дисциплине и существенно облегчают чтение как своего, так и чужого кода. Это очень важно.
Кто-то остановится на формальном уровне исполнения и не поднимется выше кодера, но сам вход в профессию однозначно предлагает веер развития.
Не хочешь ниже ? не понимаешь и не желаешь понимать разницу между record и packet record, прочей ерундой линковки, сборки и конкретного нижнего уровня ?
Ну так иди по пути python. Там почти нет таких заморочек.
Видишь, что для твоей задачи важен контроль до байта - очевидно С.
Pascal нечто среднее. Если на оптимальность результата компиляции плевать, но немного поиграть с низким уровнем, указателями и памятью напрямую все-таки хочется, то pascal хороший выбор для старта. А потом уже можно определяться куда дальше.
Сам начинал с pascal. Да и сейчас на delphi много пишу. И на С тоже много.
Во-первых, у питона нормальный синтаксис, и используется он сейчас очень много.
Во-вторых, можно читать про алгоритмы хоть до старости, но вот только если их не писать и не использовать где-то - толку будет с этого 0.
И какой язык - не пофик, если есть хоть какие-то планы насчет его использования в дальнейшем.
Руби не плохой язык, но... я не видел ни одного проекта на нём который бы не безбожно тормозил. В принципе всё зависит от того что вы планируете делать, но в качестве базового Питон действительно не плох.
Я неплохо знаю ассемблер x86, AVR и PDP-11. За редким исключением непонятного мне результата компиляции я смотрю в lst/lss. Это почти единственная ситуация, когда asm нужен среднему разработчику. Ну мне еще иногда требуются asm вставки, поскольку иногда после установки определенного флага требуется выполнить изменение регистра в пределах 4 тактов максимум, так что да, я лично, хоть и довольно ограниченно пользуюсь. Но если честно - он современному программисту нахер не нужен. Безусловно знание не помешает, но для подавляющего большинства - не нужен.
Простите, но вынужден перефразировать:
"Хочу научиться убивать, что посоветуете ?"
Как Вы понимаете политики, бойцы на ринге, военные, полиция, бандиты..
Что именно Вы видите своей целью ?
Видите ли, я программировал PC на низком уровне на уровне WINAPI, имел дело с веб, был программистом (так называли) телефонных станций, разработчик микроконтроллеров, короче это теперь очень и очень разные профессии. Скажите, что Вы имеете ввиду ? Чего Вам хочется ? (И не стесняйтесь мечтать, я в свое время стеснялся, в итоге я хороший низкоуровневый разработчик и API программист - мечта сбылась, и я не жалею, но зарабатывают сегодня специалисты другого профиля).
Итак: Зажмурьте глаза и скажите: я хочу делать.....
Для второго хорошо подойдет HTML5/flash. Наиболее удобным вариантом на сегодня будут веб приложения. Но поскольку речь о приложениях для детей Вам потребуется скилл художника и аниматора. Программинга как такового там обычно не так уж и много, куда больше понимания педагогики и предметной области, причем с прицелом на ЦА. Если Вы этим обладаете - однозначно надо пробовать.
Ну а первое - тут наверное опять же первичны знания в конкретной области. Сам сбор данных довольно тривиальная задача. Анализ - сильно будет зависеть опять же от конкретики. Вообще нередко в такой области программистами работают профессионалы других направлений науки, так как в разы проще научить химика кодить на таком уровне, чем профессиональному программисту обьяснить суть работы.
Да, я читал об этом, причем не в 2017, а пару лет назад, это был не официальный пресс-релиз, но намекалось, что flash уйдет в прошлое. Сказано, HTML5/flash
Насчёт сравнения: понятно что надо использовать строгое сравнение, но, с другой стороны, в принципе наличие нестрогого сравнения это уже бред. То есть, я не могу представить ситуацию, когда бы (например мне) потребовалось бы сравнение, работающее именно таким образом.
Ну, допустим, это притянутый за уши пример. Что если пользователь введёт "де-вити итажки"? Или "2х метровые потолки"? Если уж такие случаи действительно обрабатываются, то в них используется нормальное нестрогое сравнение, с анализом языка, а не неуклюжий костылище.
Вы можете сравнивать недостаточно обработанные данные, пришедшие, от пользователя вместо непосредственно строки "2я долбоеб".
А стоило бы. По крайней мере в js нужно бить по лицу тех, кто не юзает сравнение с учётом типа.
я программирую на php и зарабатываю 100к в месяц, а вы можете дальше его ненавидеть, меньше конкурентов будет (magento dev)
Программисты на COBOL ещё больше вашего зарабатывают. Это никак не говорит о качествах и дизайне самого языка программирования.
Почему вы сейчас сравниваете Ruby on Rails и php? Первое - это фреймворк, второе - язык. Корректнее тогда сравнивать с Symfony, а не с php - как ни странно, там тоже надо постараться, чтобы написать неправильно. Точнее, чтобы там что-то написать, нужно сначала научиться писать правильно. Да и вообще "написать через жопу" - зависит от программиста, а не от языка.
Ну вот, например: https://habrahabr.ru/post/142140/
Товарищ @pirojok167 говорит, что в php7 много чего исправили, но я, если честно, не понимаю, зачем держаться за язык, который с рождения лишён дизайна.
Дизайн c и c++ тоже многим не нравиться, но это не заставляет эти языки покидать свои лидирующие позиции.
У них хотя бы есть дизайн :) PHP вышел далеко за пределы того, для чего он изначально задумывался, поэтому вышло что попало.
К слову, я подозреваю, что C++ со временем потеснят какие-нибудь раст или свифт.
IT-юмор
5.6K постов52.5K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору