Pull to refresh
-3
0

Пользователь

Send message
Вот станете вы гуглить — что это за компания такая (ua-hosting.company), а гугл вам второй ссылкой даст Хабр, а третьей — Гиктаймз. «И вроде сразу отношение другое».
Не, она будет работать хоть в LaTeX, если вы засуните туда теги.

У меня нет опыта с Latex. Покажите пожалуйста как это будет выглядеть для Python — там нет очевидной симметрии у начала и конца блока.

Заменим понятие: предложение — строка

Home, Shift-End, начать что-то писать. Ну или наоборот — End, Shift+Home.
Если уж абстрагировать до такой степени, то давайте сразу и доабстрагиуремся до того, что программирование в конечном счете — это редактирование текста.

Не соглашусь. Программирование — это в первую очередь осознание структуры решения, и только во-вторую — перенос этого осознания в текст. Осознание структуры — это, ИМХО, процентов 90% от всей задачи. Совершенно нормальна ситуация когда 4 часа изучаешь существующий код и тесты к нему, а потом за 20 минут делаешь все нужные правки.

А навскидку — в вебе существует гораздо больший зоопарк технологий, который IDE поддерживать просто не успевают.

Аналогичную мысль я высказывал где-то выше в этом топике — из-за специфики JavaScript нормальная IDE просто невозможна. Та IDE, которая возможна, не будет отличаться от редактора с парой плагинов.

Всякие тесты и CI распространены в гораздо меньшей степени, чем в явамире.

Вы очень неправы — в мире JavaScript есть огромное количество тестовых фреймворков и сопутствующих библиотек на любой вкус и цвет. Есть куча решений для написания тестов в контексте реальной среды исполнения — начиная от Karma, которая гоняет тесты в настоящем броузере и заканчивания Protractor для Angular, который позволяет вообще всё решение полностью запустить, понажимать кнопочки и убедиться, что приложение ведётся себя как ожидается. Про CI не знаю что вы имеете в виду: то что весь опенсорсный JavaScript гоняет тесты на Travis и любит вставлять беджики со статусом билда в README на гитхабе — это факт. А как именно новые билды попадают в репозитории — уже второстепенный вопрос. Обычно либо через тот же Travis, либо какой-то одной командой grunt, которую _при желании_ можно точно так же выполнять через Travis.
Он здесь уместен. Есть программисты, которые просто работают за зарплату. Есть программисты, которым нравится работать круто — тренироваться делать фичи быстрее и качественнее. А есть программисты, которые любят возиться с инструментами надеясь, что как только оно заработает, качество их работы вырастет на порядок и вот тогда-то уж они запрограммируют всё-всё-всё.

Та толпа извращенцев — из 3-ей категории.
Жмякаете dit, удаляете содержимое тега. Есть еще сочетания для удаления всего между {}, [], <>, "", и т.д.

Т.е. замечательно работает для HTML, CSS, C, C++, Java, C#, JavaScript, JSON, XML но вот для Python, JADE и YAML придётся использовать какой-то абсолютно другой подход, потому что там таких явных маркеров начала и конца (тела функции например) просто нет. Возникает небольшое смущение: вроде задача «заменить содержимое блока» есть буквально везде, но решения для этой задачи в Vim будет отличаться для разных языков. Т.е. ваше dit совершенно замечательное, но нифига не универсальное.

Слово, предложение, блок обрамленный чем либо и т.д.

У меня в коде нет предложений. Блоки обрамлённые чем либо тоже не всегда есть — выше привёл примеры.
Хакерский романтизм и шило в заднице — не более.
Вот это:
рефакторить приходится целыми подсистемами, с IDE это проще.

и это:
Программисты там часто берутся из разряда подешевле и побольше

друг другу очень сильно противоречит. Программисты «подешевле и побольше» — это как раз те, от кого код достался в наследство. Программистов с хорошими скиллами рефакторинга — один на сотню и они совершенно точно «подороже».

им нужно поставить IDE которая будет бить их по рукам, и которая не даст сломать процесс, и которая будет заботливо расставлять пропущенные запятые, показывать что вместо = тут должно быть ==, что переменная не используется и т.п…

Снова удивлюсь и не соглашусь. В чём героизм напрягать мозг на рутину типа «переменная _теперь_ не используется и её можно удалить»? Любая работа, которую может делать компьютер, должна делаться компьютером. Компьютер вполне может за меня построить граф всех зависимостей всех классов/методов в проекте и рассказать мне какие классы или методы нигде не используются.

Те кто пишут для веб на PHP, JS, Python, Ruby.

Нет там никакой специфики — везде одно и то же: есть требования, которые нужно выполнять, есть код, который при этом нужно писать, есть тесты, который тоже нужно писать, чтобы получить минимальную уверенность, что всё работает как нужно. И да, в любой программе на любом ЯП рано или поздно возникает момент, когда понимаешь, что какие-то части реализации нужно переделать, чтобы сделать последующие изменения возможными — и вот здесь полноценная IDE помогает порубить всё налево и направо ничего не сломав, а редактор продолжает по-хипстерски подсвечивать синтаксис какой-нибудь темой Monokai намекая, что раз надел кеды и работаешь из кафешки, придётся всё делать руками.
Нет, это моё мнение по поводу вашего «мы имеем дело с обыкновенной вкусовщиной». Вкусовщина безусловно имеет место, но она не на первом месте. На первом месте — специфика ЯП и техническая возможность сделать какие-то плюшки для него. Рассмотрены 2 условных семейства ЯП, показано, что «вкусовщина» более применима к JS и подобным (IDE почти равно редактору с плагинами), а для C#/Java редактором будет пользоваться только извращенец (IDE даёт очень многое).

Резюмируя: вкусовщина не на первом месте.
как юнит-тесты помогут мне в этой задаче?

Никак. Вы прыгнули с задачи про «соединение с БД и поиск ошибки» на задачу а-ля матлаб.

Давайте теперь предположим, что вы дошли до 10-го шага, когда должны получиться там какие-то финальные результаты, но получается полная хрень. И тут вы осознаёте, что ошибка была где-то на шаге 3. Будь это отдельный скрипт — открыли, поправили, запустили и пошли пить кофе. В вашем же случае нужно участие человека.

А теперь давайте предположим, что к вам в команду пришёл новый сотрудник Вася и просит поделиться с ним вашими наработками. Вы ему дамп процесса python снимете и попросите восстановить на его машине? Попутно рассказывая, что первый шаг это 8 раз вверх, второй — 6, а если 4 вверх, то там ошибка, и результаты никуда не пошли?
Развернуть как есть, подключиться с правами DBA, понаделать всё что хочется с юзерами.
всего содержимого текущего тега, или значения атрибута тега

Универсальное решение для замены куска текста: иду в начало, зажимаю Shift, иду в конец, начинаю писать новое содержимое, старое при этом удаляется. Ходить в начало и в конец можно по-разному — зависит от того сколько в нынешнем содержимом строчек, где именно это содержимое начинается. От банального Home, до Ctrl+Left много раз, до банального челябинского Ctrl+A.

выравнивания тела функции

Есть какая-то кнопка для этого и в Visual Studio и в IDEA. Очень редко ей пользуюсь, т.к. обе среды при написании кода сами расставляют все отступы, а при вставке совершенно левого кода тут же его форматируют.

замены текущего слова

Что-то типа Alt+Shift+Up и начать писать новое слово (в IDEA по крайней мере).
Не уверен что с чем я путаю, но ваш подход очень напоминает подход начинающих — когда пишется маленькая демо-программка, которая воспроизводит интересующий сценарий, а после этого благополучно удаляется. Разница между такой программкой и тестом только в том, что тест в итоге остаётся.
Что-то не так с моим комментарием?
У меня 2 вопроса:
1. Что такое enterprise и почему вы его как-то отделяете от остального программирования?
2. Что такое веб-программисты и почему вы их отделяете от Java/.NET программистов?

Дисклеймер: я уже год в проекте с бэкендом на Java (enterprise?) и фронтэндом на Angular (веб?). Действительно пишу бэкенд в IDEA, а фронтэнд — в редакторе. Ответ на вопрос «почему?» очень простой: потому что я не хочу ломать психику завставляя себя понять, что когда я пишу Java — куча плюшек от IDE есть, а когда JavaScript — про плюшки можно забыть. Типа «видишь Atom — забудь про Alt+Shift+R».
Я предпринимал несколько попыток изучить Vim хотя бы на уровне «просто редактирования текста» — без всяких там плагинов и прочего хардкора. Очень удивило, что все туториалы сводятся к решению задач типа «прыгнуть на 3 слова влево и оказаться на первом символе первого слова» или «прыгнуть на строчку 192». Никогда в жизни у меня не было практической задачи «прыгнуть на 3 слова влево». У меня вообще нет привычки считать слова, поэтому я могу видеть куда мне надо попасть, но я понятия не имею сколько у меня слов от курсора до того места. Я не могу вспомнить ни одного файла, про который смог бы рассказать что там находися на какой-то строчке. Действительно кто-то может это запомнить? С другой стороны я совершенно точно знаю, что до тех пор, пока я _итеративно_ двигаю курсор куда-то в сторону куда мне нужно, и вижу, что он туда движется, в какой-то момент я смогу сделать усилие над собой и остановиться оказавшись в нужном месте.

Вы можете привести какой-то практический пример в контексте программирования, когда «попсовый» подход однозначно проигрывает у Vim? Только чтоб не экзотическая задача, которая возникает раз в год, а какое-то базовое действие, которое нужно повторять по несколько раз в день?
Можете раскрыть тему «низкоуровневого редактирования»?
Я искренне не понимаю что вы с этими REPL'ами делаете. Как вы определяете, что остальной код не сломался из-за ваших правок? Тоже REPL руками? Перед каждым коммитом?
Программистам платят за программирование, а не редактирование текста. А программирование это:

1. Изучение существующего кода и зависимостей между разными его частями: навигация по цепочкам вызовов буквально с одного конца проекта в совершенно другой.
2. Отладка либо самого приложения, либо падающих тестов: расстановка брейкпоинтов, разглядывание стека вызовов, и прочее.
3. Упорядочивание структуры кода после внесения очередных изменений: начиная с переименования всяких сущностей в коде и заканчивая перекладыванием одних директорий в другие.
4. И да, иногда ещё редактирование текста.

Совершенно не понимаю, почему всех так тянет почти-отождествлять «удобный процесс программирования» и «удобное редактирование текста». Программа — это нифига не текст. Это текст, оформленный очень определённым образом. Глупо не пользоваться этим нюансом.

Information

Rating
Does not participate
Location
New Jersey, США
Date of birth
Registered
Activity