Re[5]: Python в больших проектах
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 15.01.20 09:27
Оценка:
Здравствуйте, Ватакуси, Вы писали:

M>>Ага. pip install bl-bla. Ой, не работает. Гуглим. А-а-а, надо откатить pip на конкретную версию, иначе эту хрень не поставить

В>Никогда не встречал. Может не компилироваться из-за ц++ хелла на твоей машине, это да. Раза 3 или 4 приходилось долго танцевать.

Я пару раз попадал на это
Re[6]: Python в больших проектах
От: Ватакуси Россия  
Дата: 15.01.20 09:54
Оценка:
M>>>Ага. pip install bl-bla. Ой, не работает. Гуглим. А-а-а, надо откатить pip на конкретную версию, иначе эту хрень не поставить
В>>Никогда не встречал. Может не компилироваться из-за ц++ хелла на твоей машине, это да. Раза 3 или 4 приходилось долго танцевать.

N>Я пару раз попадал на это

На ц++ хелл? Или откатывание пипа?
Все будет Украина!
Re[7]: Python в больших проектах
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 15.01.20 09:57
Оценка:
Здравствуйте, Ватакуси, Вы писали:

N>>Я пару раз попадал на это

В>На ц++ хелл? Или откатывание пипа?

На откатывание пипа. Вручную подбирал версию пипа и библиотек.
Re[3]: Python в больших проектах
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 15.01.20 10:21
Оценка: +1
Здравствуйте, kaa.python, Вы писали:

KP>В C++ и маленьких утилитах другая проблема. К тому времени когда ты соберешь в кучу все, что нужно для маленького проекта на C++, проект на Python уже будет радовать результатами.

KP>Можно-можно. Python по-умолчанию доступен много где.
KP>И в Python у тебя уже будет все что хочешь либо из коробки, либо путем добавления одной строчки в requirements.txt. Ну а как дела в C++ с подключением алгоритмов и библиотек, думаю, все и так знают.

Да, знаем.

Например, вот так:
LIBS += -lcryptopp

Или вот так:
LIBS += -lpoppler-qt4

Или даже так:
LIBS += -ldjvulibre

А здесь и вовсе каждый модуль отдельно:
LIBS += -lopencv_core -lopencv_imgproc -lopencv_highgui


Всё, я перетрудился добавляя сторонние библиотеки в свой проект, пойду отдохну. Другое дело, что не нужно заниматься популизмом. Или нужно?

Проблема здесь вовсе не в добавлении сторонних библиотек, а в том, что:

1) Открытый интерфейс этих библиотек не соответствует собственному восприятию понятий, причём в любом языке программирования и практически любой библиотеке алгоритмов. Потому когда кто-то говорит, я сел и написал за 5 минут на Python, и сторонние библиотеки подключил легко, а вот в C++ замучался, очень тяжело. Хочется спросить, а сколько времени ушло на изучение того же Python. То есть я зная как подключить библиотеки в C++ и чисто для примера не зная как это делается в Python, всё равно как бы должен считать, что в Python это всё проще.

2) Это как раз тема топика. Внезапно языки программирования и библиотеки алгоритмов со временем меняются. Чтобы предотвратить отрицательные эффекты в лучшем случае, что можно сделать при использовании сторонних библиотек, это вынести вызов чужих библиотек в собственноручно созданную обёртку и работать с ними только через неё. В противном случае чужой код будет размазан по собственному. Любое изменение чужого кода автоматически может сломать свой собственный. А нужно ли покрывать чужой код тестами, то есть гарантируется ли, что даже не сломавшись он будет отрабатывать так же.

Несколько раз перечитал твои комментарии, но так и не понял смысла. Я не утверждаю, что его там нет, это я просто не понял. Предположим у нас есть учебный пример алгоритма.

Название проекта: project_name
IDE: qt creator

Создаём папку project и копипастим два файла:
project_name
 project_name.pro
 project_name.cpp

project_name.pro
TARGET = project_name
TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle qt
SOURCES += project_name.cpp

project_name.cpp
#include <iostream>
#include <cstdlib>
using namespace std;

int main()
{
    return EXIT_SUCCESS;
}


У нас появилась болванка. В ней можно кое-что поменять но не суть. Дальше размножаем её и в папке верхнего уровня создаём ещё один проект.
examples
 project_name
  project_name.pro
  project_name.cpp
 examples.pro

examples.pro
TEMPLATE = subdirs
SUBDIRS = \
project_name \ # наша болванка
project_name-01 \
project_name-02 \
project_name-03 \
project_name-04 \
project_name-05 \
project_name-06 \
project_name-07 \
project_name-08 \
project_name-09 \
project_name-10


Но вот вопрос, зачем было называть файл C++ project_name. А затем, чтобы положить в эту же папку исходники других языков. Если бы это был hello_world:

assembler
.data
msg:
  .ascii "Hello, world!\n"
  .set len, . - msg

.text

.globl main
main:
  # write
  mov $4,   %eax
  mov $1,   %ebx
  mov $msg, %ecx
  mov $len, %edx
  int $0x80

  # exit
  mov $1,   %eax
  xor %ebx, %ebx
  int $0x80


bash
#!/bin/bash
echo "Hello, world!"


c++
#include <iostream>
#include <cstdlib>
using namespace std;

int main()
{
    cout << "Hello, world!" << endl;
    return EXIT_SUCCESS;
}


go
package main;

import "fmt"

func main() {
fmt.Println("Hello, world!")
}


Java
public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, world!");
    }
}


pascal
begin
    writeln('Hello, world!');
end.


php
<?php
echo "Hello, world!";
?>


prolog
:- initialization hello_world, halt.

hello_world :-
    write('Hello, World!'), nl.


python
print("Hello, world!")


ruby
puts "Hello, World!"


Файлы могли выглядеть бы так:
hello_world.s
hello_world.sh
hello_world.cpp
hello_world.go
HelloWorld.java
hello_world.lua
hello_world.pas
hello_world.php
hello_world.pl
hello_world.py
hello_world.rb


Теперь что касается запусков, оставим пока IDE.

C++ компиляция
g++ hello_world.cpp -o hello_world_cpp

C++ запуск
./hello_world_cpp


Теперь Python.
python hello_world.py


Остальные языки нас вроде бы как не интересуют, но чисто для примера.

Assembler компиляция
gcc -m32 hello_world.s -o hello_world_asm

Assembler запуск
./hello_world_asm


Bash запуск
sh hello_world.sh


Go запуск
go run hello_world.go

или

Go компиляция
go build hello_world.go

Go запуск
./hello_world


Java компиляция
javac HelloWorld.java

Java запуск
java HelloWorld


Lua запуск
lua hello_world.lua


Pascal компиляция
fpc hello_world.pas

Pascal запуск
./hello_world


Php запуск
php hello_world.php


Prolog запуск
swipl -q -l hello_world.pl


Ruby запуск
ruby hello_world.rb


Есть различия в точке доступа в приложение, но вот прямо принципиальной разницы, почему Python (а мне из скриптовых вообще-то нравится лишь Lua) не вижу. Тот же Bash через аргументы командной строки использует другие программы как библиотеки алгоритмов. Но разве это его уникальное свойство.

К тому же, выражение на Python всё есть, но откуда оно там взялось. Ах, да, большая часть это вызовы на библиотеки алгоритмов C/C++. Это логично, потому что скрипты в том числе для этого и созданы. Другое дело, что это не делает скрипты принципиально лучше, ни для разработки, ни для прототипирования. Дописать функционал, которого нет в основной программе, это да, а вот когда пишешь эту самую программу не получаешь никаких преимуществ.

examples
 project_name
  project_name.pro
  project_name.cpp
  project_name.s
  project_name.sh
  project_name.cpp
  project_name.go
  ProjectName.java
  project_name.lua
  project_name.pas
  project_name.php
  project_name.pl
  project_name.py
  project_name.rb
 examples.pro


Ладно, это всё были хелло ворлды. Если не жалко времени приведи конкретный "внушительный" пример, чтобы я мог посмотреть на код и сказать, — "О, Python это круто, а вот тот же самый проект или прототип на C++ полное говно".
Re[8]: Python в больших проектах
От: Masterspline  
Дата: 15.01.20 10:25
Оценка:
N>На откатывание пипа. Вручную подбирал версию пипа и библиотек.

Я на Python не писал ничего серьезного, но давно понял, что любой проект сложнее скрипта из одного файла нужно начинать с установки и настройки virtual environment. Неужели кто-то делает по-другому...
Re[9]: Python в больших проектах
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 15.01.20 10:54
Оценка: +2
Здравствуйте, Masterspline, Вы писали:

M>Я на Python не писал ничего серьезного, но давно понял, что любой проект сложнее скрипта из одного файла нужно начинать с установки и настройки virtual environment. Неужели кто-то делает по-другому...


Я также делаю, но оно же не обязательно будет работать. Ты ставишь requirements для одного проекта, пишешь код, например, сервера. Потом хочешь сделать, чтобы он распознавал котиков на фотках. Находишь предобученную модель, подключаешь tensorflow, а он не работает. Ему нужен другой python, более древний. И какой-нибудь другой protobuf. Или numpy. Потом выясняется, что это старая версия или версия, которая требует строго определённые версии пакетов, ни больше, ни меньше. Не случайно сейчас самые популярные репозитории начинают раздел Install со слов: "Скачайте такой-то Докер..." Как раз потому что в версиях Питона и библиотек разброд и шатание и не так просто подбирать рабочие комбинации для разных библиотек.
Re[4]: Python в больших проектах
От: Igore Россия  
Дата: 15.01.20 10:59
Оценка: +5 :)
Здравствуйте, velkin, Вы писали:

KP>>В C++ и маленьких утилитах другая проблема. К тому времени когда ты соберешь в кучу все, что нужно для маленького проекта на C++, проект на Python уже будет радовать результатами.

KP>>Можно-можно. Python по-умолчанию доступен много где.
KP>>И в Python у тебя уже будет все что хочешь либо из коробки, либо путем добавления одной строчки в requirements.txt. Ну а как дела в C++ с подключением алгоритмов и библиотек, думаю, все и так знают.

V>Да, знаем.

Не похоже

V>Например, вот так:

V>
V>LIBS += -lcryptopp
V>

А так же LIB_PATH, INCLUDE_PATH, а, библиотеку же еще скачать и собрать надо, и хранить, и ключи компиляции/линковки должны совпадать, под Linux еще RPATH или LD_LIBRARY_PATH + возможные зависимости. Еще и инсталятор нужно, под Windows хоть из той же папки грузится, тут хоть архив на первое время можно сделать.

V>Всё, я перетрудился добавляя сторонние библиотеки в свой проект, пойду отдохну. Другое дело, что не нужно заниматься популизмом. Или нужно?

Не нужно

V>Проблема здесь вовсе не в добавлении сторонних библиотек, а в том, что:


V>1) Открытый интерфейс этих библиотек не соответствует собственному восприятию понятий, причём в любом языке программирования и практически любой библиотеке алгоритмов. Потому когда кто-то говорит, я сел и написал за 5 минут на Python, и сторонние библиотеки подключил легко, а вот в C++ замучался, очень тяжело. Хочется спросить, а сколько времени ушло на изучение того же Python. То есть я зная как подключить библиотеки в C++ и чисто для примера не зная как это делается в Python, всё равно как бы должен считать, что в Python это всё проще.

Мелочи.

V>Название проекта: project_name

V>IDE: qt creator
Прелесть Qt в том что тебе в 90% случаях не придется подключать ничего другого, на нём прототипы С++ писать можно относительно легко, или под Linux, apt-get install lib-dev + find_package, или студийный nuget основной сценарий использования стороних либ покрывает.

V>Создаём папку project и копипастим два файла:

Да, для Qt можно

V>Но вот вопрос, зачем было называть файл C++ project_name. А затем, чтобы положить в эту же папку исходники других языков. Если бы это был hello_world:

Да ни для кого hello world почти не нужен, а проблема С++ в скудной stl, чуть в сторону и тебе нужно network, db, xml, ini, json, csv, log, получить директорию пользователя куда можно файлы сохранить, открыть файл системным приложением, etc, и ничего этого нет, вперед читать искать библиотеки который тебе нужны, качать, компилировать, подключать, настраивать, собирать инсталятор, или брать монстров Qt, boost где просто не нужно будет скорей всего ничего другого искать.

V>Ладно, это всё были хелло ворлды. Если не жалко времени приведи конкретный "внушительный" пример, чтобы я мог посмотреть на код и сказать, — "О, Python это круто, а вот тот же самый проект или прототип на C++ полное говно".

Именно что хелло ворлды, хорошо, прототип, отслеживать выложеную в интеренете БД в формате ACCESS, после скачать и обновить данные в твоей локальной postgresql базе, на python-e будет в разы проще сделать. А для C++ можешь попробовать для разных системы прикинуть какие библиотеки тебе понадобятся для реализации этого несложного приложения.
Re[5]: Python в больших проектах
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 15.01.20 11:23
Оценка: +1
Здравствуйте, Igore, Вы писали:

V>>Например, вот так:

V>>
V>>LIBS += -lcryptopp
V>>

I>А так же LIB_PATH, INCLUDE_PATH, а, библиотеку же еще скачать и собрать надо, и хранить, и ключи компиляции/линковки должны совпадать, под Linux еще RPATH или LD_LIBRARY_PATH + возможные зависимости. Еще и инсталятор нужно, под Windows хоть из той же папки грузится, тут хоть архив на первое время можно сделать.

Если вот это файл проекта Qt:

project_name.pro
TARGET = project_name
TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle qt
SOURCES += project_name.cpp


И нужно подключить, например crypto++, то в том же Debian
apt install libcrypto++-dev


И проект соответственно будет:

project_name.pro
TARGET = project_name
TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle qt
SOURCES += project_name.cpp
LIBS += -lcryptopp # подключили


А ещё есть вот такой пакет python-pycryptopp.
apt install python-pycryptopp

PyCryptopp is a set of Python wrappers for a few of the best crypto algorithms
from the Crypto++ library (including SHA-256, AES, RSA signatures and Elliptic
Curve DSA signatures).


Это, конечно, всё здорово и замечательно, но особого смысла не вижу восхищаться обёртками, когда тоже самое можно использовать напрямую.

I>Именно что хелло ворлды, хорошо, прототип, отслеживать выложеную в интеренете БД в формате ACCESS, после скачать и обновить данные в твоей локальной postgresql базе, на python-e будет в разы проще сделать. А для C++ можешь попробовать для разных системы прикинуть какие библиотеки тебе понадобятся для реализации этого несложного приложения.


Тоже самое можно сделать и для C++. Python это обёртки, обёртки и ещё раз обёртки. Возможно меня здесь уже записали в противники Python, но я просто не вижу разницы запускать напрямую или обёрткой. Причём от проблемы версий библиотек алгоритмов мы никуда не ушли.
Re: Python в больших проектах
От: MasterZiv СССР  
Дата: 15.01.20 11:40
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Спрашивается: нахер оно тогда надо, писать нетленку на динамических языках? Только прототипы! Тут же и тесты не особо помогут, потому что и их надо переписывать. Я раньше как-то не понимал всей глубины проблемы,


Ты и сейчас её не понимаешь.
ОНИ СЧИТАЮТ, ЧТО ЕСЛИ ОНИ НЕ ПОДНИМУТ ВСЁ ЭТО ГОВНО, КОМУ-ТО БУДЕТ ХУЖЕ!
вот в чём проблема.
Re[10]: Python в больших проектах
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 15.01.20 12:12
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Я также делаю, но оно же не обязательно будет работать. Ты ставишь requirements для одного проекта, пишешь код, например, сервера. Потом хочешь сделать, чтобы он распознавал котиков на фотках. Находишь предобученную модель, подключаешь tensorflow, а он не работает. Ему нужен другой python, более древний. И какой-нибудь другой protobuf. Или numpy. Потом выясняется, что это старая версия или версия, которая требует строго определённые версии пакетов, ни больше, ни меньше. Не случайно сейчас самые популярные репозитории начинают раздел Install со слов: "Скачайте такой-то Докер..." Как раз потому что в версиях Питона и библиотек разброд и шатание и не так просто подбирать рабочие комбинации для разных библиотек.


Это просто больно читать... virtualenv, venv море других. Просто не надо валить всё в системные библиотеки Питона и всё будет хорошо.
Re[4]: Python в больших проектах
От: Mamut Швеция http://dmitriid.com
Дата: 15.01.20 12:14
Оценка:
V>C++ компиляция
V>
V>g++ hello_world.cpp -o hello_world_cpp
V>

V>C++ запуск
V>
V>./hello_world_cpp
V>


V>Теперь Python.

V>
V>python hello_world.py
V>



Это должно было показать, что нет никакой разницы между питоном и C++, что ли?

C++: создать сборочный файл, запустить компиляцию, запустить файл
Python: python файл_в_котором_кот.py



dmitriid.comGitHubLinkedIn
Re[4]: Python в больших проектах
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 15.01.20 12:15
Оценка: +3
Здравствуйте, velkin, Вы писали:

V>Да, знаем.


Уверен что знаешь? С чего вдруг на машине должен быть QMake (у меня вообще никогда не было)? Показал бы уж как всё легко и просто, ну и конечно кроссплатформенно, на Makefile.

V>Например, вот так:

V>
V>LIBS += -lcryptopp
V>


Отвлеченный вопрос, как ты находишь время такие простыни ответов писать? Их даже читать долго же
Re[2]: Mercurial не нужен
От: $$ Австралия жж
Дата: 15.01.20 12:17
Оценка: -1
Здравствуйте, kov_serg, Вы писали:

_>

_># Mercurial will never work on Python 3 before 3.5 due to a lack
_># of % formatting on bytestrings, and can't work on 3.6.0 or 3.6.1
_># due to a bug in % formatting in bytestrings.
_># We cannot support Python 3.5.0, 3.5.1, 3.5.2 because of bug in
_># codecs.escape_encode() where it raises SystemError on empty bytestring


subj
Re[11]: Python в больших проектах
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 15.01.20 12:18
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Это просто больно читать... virtualenv, venv море других. Просто не надо валить всё в системные библиотеки Питона и всё будет хорошо.


Я же как раз и отвечал, что virtualenv использую. Это работает, когда имеешь дело с одним репозиторием на Гитхабе. Но когда надёргиваешь код из разных источников, то всё ломается и начинаются пляски с бубном. Кажется, что большую программу на Питоне просто так вообще не написать, поэтому и стали популярными Докеры и микросервисы — не только из-за масштабируемости, но и из-за того, что всё работает само по себе с кучей разных библиотек разных версий. Описанная мной проблема как раз и была в отдельном env.
Re[3]: Mercurial не нужен
От: Skorodum Россия  
Дата: 15.01.20 12:19
Оценка:
Здравствуйте, $$, Вы писали:

$>subj
Да пусть свой век доживает, потом само отомрет.
Re[5]: Python в больших проектах
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 15.01.20 12:20
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Отвлеченный вопрос, как ты находишь время такие простыни ответов писать? Их даже читать долго же


Ну, на современном CMake + vcpkg не сложнее, а то и проще. Оно пока ещё не такое гибкое как pip, но уже ближе к нему, чем голый CMake или qmake
Re[12]: Python в больших проектах
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 15.01.20 12:44
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Я же как раз и отвечал, что virtualenv использую. Это работает, когда имеешь дело с одним репозиторием на Гитхабе. Но когда надёргиваешь код из разных источников, то всё ломается и начинаются пляски с бубном. Кажется, что большую программу на Питоне просто так вообще не написать, поэтому и стали популярными Докеры и микросервисы — не только из-за масштабируемости, но и из-за того, что всё работает само по себе с кучей разных библиотек разных версий. Описанная мной проблема как раз и была в отдельном env.


Ну, разве что это особенность ML. Я довольно много делал проектов на Python и с описанным сталкивался только по молодости и глупости, когда про venv не знал
Re: Python в больших проектах
От: Pzz Россия https://github.com/alexpevzner
Дата: 15.01.20 12:54
Оценка: +2
Здравствуйте, Nuzhny, Вы писали:

N>Спрашивается: нахер оно тогда надо, писать нетленку на динамических языках? Только прототипы! Тут же и тесты не особо помогут, потому что и их надо переписывать. Я раньше как-то не понимал всей глубины проблемы, но сейчас удивляюсь, как вообще можно что-то большое делать на динамике. Плюсовые и шарповые проекты не всегда легко, но достаточно уверенно переползают со стандарта на стандарт, на новые компиляторы и платформы. И 100% покрытия тестами в них нет, но кажется, что само переползание чаще лечит прошлые баги, чем добавляет новых.


Дело не в динамике, а в том, что кое-кто, не подумав, вносит ломающие изменения в язык.

Мораль: серьезные проекты можно писать только на языках, для которых верно хотя бы одно из двух: 1) у языка есть несколько независимых, влиятельных реализаций 2) за языком стоят люди, которым можно доверять
Re[6]: Python в больших проектах
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 15.01.20 12:57
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Ну, на современном CMake + vcpkg не сложнее, а то и проще. Оно пока ещё не такое гибкое как pip, но уже ближе к нему, чем голый CMake или qmake


Сложнее всё-же. Во-первых, телодвижений больше чем с Python, хотя и не так много как было раньше. Во-вторых, к проекту нужны тесты, тут еще больше сложностей. В-третьих, если (когда) проект вырастет, CMake превратится в ад. В-четвертых, когда проект вырастет, с большой вероятностью о предсобранных в vcpkg пакетах придется забыть.

C++ зык прекрасный, но вот сборочно-тестовая-деплойная инфраструктура, мягко говоря, оставляет желать лучшего.
Re[5]: Python в больших проектах
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 15.01.20 13:18
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Уверен что знаешь? С чего вдруг на машине должен быть QMake (у меня вообще никогда не было)? Показал бы уж как всё легко и просто, ну и конечно кроссплатформенно, на Makefile.


Я же написал так сказать ручной запуск из командной строки для gcc (g++). CMake применять не вижу смысла, так как пользуюсь Qt Creator, но замечу, что CMake, что QMake везде ручной набор. И касательно систем сборок это дело десятое, их довольно много. Однако никто не мешает добавить тем же способом то, что нужно, тот же Makefile, и даже не обязательно под этим именем. Иными словами идея не только в том, чтобы создавать разные файлы для систем сборок одного языка программирования, так же параллельно можно добавить проекты для других языков, а то и вовсе объединить, пусть даже без прямой поддержки IDE.

project_name.pro
TARGET = project_name
TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle qt
SOURCES += project_name.cpp
OTHER_FILES += project_name.py project_name.lua # ... и так далее

KP>Отвлеченный вопрос, как ты находишь время такие простыни ответов писать? Их даже читать долго же

Не так долго как кажется. В конце концов я сижу на рсдн и по большей части читаю всякую муть, даже не про программирование. Вообще я читал твой блог, то есть это как бы вопрос к себе.

https://sysdev.me/rsdn-the-end/

Времени катастрофически ни на что не хватает, а на ближайший год очень серьезные планы. Одним из главных бессмысленных пожирателей свободного времени, до вчерашнего дня был РСДН, всё остальное давно “похерил”.
Поразмыслив на тему планирования времени, временно ушел оттуда, самозабанившись на 1 год. Жалко, конечно, но реально нужно достать еще свободного времени.


Да, я и на этот блог нашёл время сколько-то лет назад и не только. У кого-то мало времени, у кого-то много, но в любом случае люди движутся к смерти. Каждый сам определяет себе приоритеты.

Мысли:

А если бы все программисты бросили писать комментарии на рсдн и вместо этого писали аналогичный объём кода. Или вот, не только программисты, все люди перестали писать в свои бложики, социальные сети, чаты, а вместо этого стали генерировать хардкорный код. И старушки тоже бы перестали смотреть телевизор и принялись кодить.

Но этого не будет.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.