bromzh

Ты хотя бы почитал, что это такое, прежде чем задавать такие глупые вопросы. 1-е - всего лишь подмножество второго. Без знания SE никакое EE ты не освоишь.

Если нужен именно путь, то используй, как уже сказали, os.path.join, желательно всегда.
Если просто вставить значение переменной(ых) в строку, то используй интерполяцию. Есть 2 варианта: со знаком процента или через метод format:

a = 1
b = 'foo'
c = [1, 2, 3]

s1 = 'string with vars: %s %s %s' % (a, b, c)
s2 = 'string with vars: {} {} {}'.format(a, b, c)
s2 = 'string with vars: {2} {0} {1}'.format(a, b, c)
s2 = 'string with vars: {foo} {bar} {qux}'.format(foo=a, qux=b, bar=c)

Раз пересечения допустимы, то наверное надо построить что-то типа такой штуки en.wikipedia.org/wiki/Geodesic_dome, ну т.е. разбить сферу на правильные многоугольники (скорее всего 5-ти угольники), пускай и не одинакового размера. Главное, чтобы расстояние от центра многоугольника до вершины было не больше заданного радиуса для "кругов". Потом для каждого многоугольника найти центр и провести луч от центра сферы, проходящий через центр этого многоугольника и найти точку пересечения этого луча с поверхностью сферы. Это и будет центр "круга". Важно понимать, то это уже не евклидова геометрия, поэтому некоторые приёмы работать в таком пространстве не будут.
Правда не знаю, будет ли это оптимальным размещением. Возможно даже доказательства его оптимальности ещё нет.

Если у тебя линукс или что-то похожее, то достаточно обычного баша:

#!/bin/sh
now="$(date +'%Y-%m-%d')"
url="http://example.com/$now/$now.mp4"
wget -c -P /папка/куда/сохранять/ $url

И засунуть это в ежедневный крон.

Опции wget посмотри, там куча разных штук, типа повтора при ошибке, выкачивании каталога/всего сайта, и т.д.

Копирую в сублайм в новую вкладку. Если её не закрывать, код остаётся после выхода.

Что значит "одновременно"? 5 сервов должны начать делать 1 задачу в одинаковое время? Смахивает на задачу синхронизации стрелков, которую надо реализовать через очередь сообщений.

Georgia

Погружайся. Очень простой для изучения язык широкого профиля. №1 для изучения по недавним опросам.

Просто посмотри отношение количества идиотских вопросов к общему по ПХП и, например, по питону/руби/яве на тостере.

SICP

Эскобар.жпг. Оба ужасны.
Посмотри, как это реализовано в нормальных фреймворках.

За такие деньги джуниору? Наверное только Java.
А перспективнее - это всякие серверные джаваскрипты, питоны, руби, скалы. Вакансии есть, языки довольно лёгкие (кроме скалы). Только в довесок надо знать ещё кучу технологий: SQL и nosql базы данных, системы контроля версий, автоматического тестирования, сборки, деплоя; уметь в асинхронное программирование, знать и фронтенд немного и т.д.

Да, можно реализовать все паттерны ООП без использования классов, объектов и других вещей. Но по-сути, ООП позволяет это делать наглядее и удобнее в некоторых случаях. Т.е. тебе не нужно реализовывать в своей программе всякие паттерны, это всё сделано в самом языке за тебя. ООП - это некая абстракция для работы с данными, как с объектами реального мира.

Просто есть области, где ООП наиболее лучше подходит для решения задачи. Есть области, где оно не будет оптимальным. Главное - это знать и понимать, где оно нужно, а где нет. Это уже с опытом приходит.

Третий, естественно. Т.к. он развивается и будет развиваться, в отличие от 2-го. Например, недавно появилась библиотека async и специальная форма yield from. Да и все нормальные библиотеки поддерживают третью ветку.
А ещё в нём нормальная поддержка юникода.

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

В общем, как второстепенный язык он неплох. Но выбор его, как первого и основного - плох.

А вообще правильно сказали, важны общие принципы разработки. Можешь начать изучение с SICP, там как раз на диалекте лиспа идёт разработка.

Однобуквенные домены давно уже в ходу. Тот же t.co от твиттера и сотни других. Правда, почти все заняты. Есть свободные на всяких экзотических доменах. Можешь на name.com поискать, а то из российских регистраторов мало кто поддерживает их.

Не проще ли открыть код под GPLv3/LGPL (чтобы его не смогли использовать в закрытых проектах) и предусмотреть коммерческую лицензию для закрытых проектов за деньги? Для некоммерческих и открытых проектов разрешить использовать код бесплатно. Плюс, бери деньги за техподдержку. Так сделано у очень многих проектов (Qt, например).
А то вдруг твоё поделие никто покупать не захочет? Большой проект трудно поддерживать маленьким коллективом (в случае открытых исходников многие смогут отправлять пулл-реквесты). А маленький вряд-ли кто-то купит (если он не обладает какой-нибудь супер уникальной фичей).
Ещё можешь посмотреть, как лицензируются большие движки. Некоторые берут процент с продаж продукта. который их использует, некоторые позволяют использовать движки бесплатно до тех пор, пока прибыль или количество установок проекта не превысят определённую планку.
Вообще, чем более либеральная лицензия, тем больше будет желающих использовать твой движок. Деньги, опять же, можно и с ТП получать (как это делают RedHat. nGinx, и прочие).