Где взять 1000 строк кода?

[rockclimber]

Munin
Учитывая предыдущую активность ТС на ниве освоения программирования, мне приходят в голову только предположения вроде того, что он где-то читал что-то про программирование (причем вряд ли высокого качества), увидел там число 1000 как взятую с потолка условную границу между, например, "очень маленькой программой" и "небольшой программой", и теперь хочет на "небольшую программу" посмотреть. Вероятность того, что его кто-то пригласил на собеседование, я оцениваю как нулевую.

[Munin]

Скорее, не "пригласил", а он пытается добыть приглашение. Выполняя вывешенные где-то начальные требования. Некрасивым способом.

[FomaNeverov]

Пишите:

int x;
int y;
int z;
QString str1;
QString str2;
QString str3;

Вместо:

int x, y, z;
QString str1, str2, str3;

И буде у вас 6 строчек кода вместо 2-х.

[A_I]

Просто интересно, - где могут пригодиться тысячи строк на питоне? Например, в ролике (ниже, где производится наладка системы захвата целей от камеры и тепловизора, - я просто держу обе камеры в руке ), питон является оберткой верхнего уровня системы управления автономного дрона. Функции СУ – управление полетным контроллером в автономном режиме, для чего – взаимодействие с внешней (наземной) системой постановки задачи, реализация основных алгоритмов логики, распознавание и категорирование объектов, захват и сопровождение целей. Так, навскидку, (что далеко не все, перечислю только основное) используются библиотеки для работы с интерфейсами, видеокамерами, минитепловизором, OpenCV, аппаратным ускорителем нейросетей, пакетом tensorflow, мат. пакеты и проч. проч. Все библиотеки написаны на сях и плюсах. Если посчитать общее количество строк кода – будет, видимо, миллионы. На питоне же – едва сотня наберется. По-моему, нет необходимости (да и неправильно) скрипты и интерпретации опускать в низкий уровень. Вот в роли обертки – питон самое то…
https://www.youtube.com/watch?v=kUKDmtVScmk

[vitserduk]

У меня то же самое требовалось, на C++. Проблема в том, что нужно не менее 1000 строк кода, чтобы любую программу на любом языке считать "программой", а не демо-версией. Давно читал, что "программой" считается программа, не просто содержащая от 1000 строк, а еще и расширенная своей логикой. Например, невозможно получить лицензию на программу, которая печатает "Hello, world!". Точно так же невозможно и на программу, которая содержит 1000 строк, которые выводят "Hello, world!". Возможно на программу, в которую добавлено не менее 1000 строк кода и есть изобретенный автором алгоритм, не описанный ранее в каких-либо книгах и не содержащийся в других патентах. Ну, например можно и изобрести свой тип файла, по своему его шифровать (как pdf) и по своему расшифровывать. Тогда программа, читающая и записывающая файл, может быть запатентована.
Как-то так.

[realeugene]

vitserduk в сообщении #1389159 писал(а):

Тогда программа, читающая и записывающая файл, может быть запатентована.

Патентоавть можно алгоритмы, а код программ регулируется авторским правом. 1000 строк "Hello, world!" если навесить копирайт - никто не будет иметь права их копироавть в своё приложение.

[rockclimber]

vitserduk в сообщении #1389159 писал(а):

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

Это бред.
Программой является любой выполняемый файл, который можно запустить.
Любой код, который в такой файл компилируется, можно назвать программой.
Количество строк кода - вещь условная, один и тот же код можно переписать сильно по-разному.
Демо-версия - это:
1) или урезанная версия существующей программы для демонстрации возможностей (с целью дать посмотреть демо-версию бесплатно, а за полную версию взять денег)
2) или первая более-менее работоспособная версия ненаписанной еще программы, созданная, например, для показа инвесторам, чтобы выжать денег на дальнейшую разработку с них. Значительная часть функций может при этом присутствовать в интерфейсе, но не работать. В этом случае она часто называется MVP - Minimum Viable Product.
И в любом случае количество строк кода имеет околонулевую важность. Если кто-то вам говорит о важности количества строк кода - значит, перед вами динозавр, который должен был вымереть еще в 90-х, но по какой-то случайности дожил до наших дней.

vitserduk в сообщении #1389159 писал(а):

Например, невозможно получить лицензию на программу, которая печатает "Hello, world!".

Это тоже бред. Во-первых, фраза "получить лицензию" означает "получить право пользоваться программой". С этим никаких проблем нет вообще. Причем с любой программой. Идете к автору, спрашиваете условия пользования, выполняете условия, пользуетесь.
Если вы имели в виду "получить авторское право на такую программу" - то его нельзя получить по другой, очень банальной причине: потому что вы не являетесь автором программы "Hello world". А вот человек, который впервые такую программу написал, вполне может считаться автором и иметь авторские права.
Также, закон об авторском праве ни в одной стране (подозреваю) не накладывает никаких ограничений на длину программы. Если вы первый, кто написал ее текст - вы являетесь автором и имеете права. Если нет - то нет. И всё.

[A_I]

На начальном этапе занятий с детьми по программированию (c#), допустим, начинаем проходить функции и методы. К тому времени уже пройдены циклы, условные переходы и проч.
Одно из упражнений, выполняемых самостоятельно - разработка калькулятора. При этом, "обучаемый" должен сам продумать алгоритмы. Задачу он понимает - сделать примерно также как в "обычном" виндовом калькуляторе - пользовательская форма, кнопки, поле ввода-вывода и проч., но только с простейшим функционалом - сложение-вычитание, умножение-деление.
Выполняют по разному - кто-то быстро соображает, что надо создать отдельную функцию, при нажатии цифры в калькуляторе туда передается один параметр. Некоторые же отдельную функцию не делают, а каждый обработчик нажатия снабжают той же "сигнатурой".. Понятно, что код выходит больше, если считать построчно. Объясняем, что в данном случае, - и то, и другое - верно, однако, гораздо лучше для восприятия, отладки и производительности применять подход разбиения на функции - то есть, по сути, это пример выхода на другой "уровень абстракции".
Хотя, тут же объясняем, что коды, написанные этими двумя различными способами в итоге воплотятся примерно в один и тот же машинный код.
Тут, скорее наоборот, - у кого код будет меньше по объему - тот и "победил"

[Munin]

A_I в сообщении #1389707 писал(а):

Хотя, тут же объясняем, что коды, написанные этими двумя различными способами в итоге воплотятся примерно в один и тот же машинный код.

Зачем обманывать детей?

[A_I]

Munin в сообщении #1389764 писал(а):

A_I в сообщении #1389707 писал(а):

Хотя, тут же объясняем, что коды, написанные этими двумя различными способами в итоге воплотятся примерно в один и тот же машинный код.

Зачем обманывать детей?

Я же указал - "примерно".
JIT все равно должен свести в итоге к одной функции..

[Pavia]

Цитата:

JIT все равно должен свести в итоге к одной функции..

JIT этим не занимается от слов совсем. Вот транспилятор MSIL может сделать подстановку, но только для простых, маленьких функций. А не для всех.

[A_I]

Pavia в сообщении #1389952 писал(а):

Цитата:

JIT все равно должен свести в итоге к одной функции..

JIT этим не занимается от слов совсем. Вот транспилятор MSIL может сделать подстановку, но только для простых, маленьких функций. А не для всех.

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

[Pavia]

A_I
Я думаю тут лучше говорить что, тот кто научится писать функции, тот будет быстрее писать программы. А в вузе потребуется писать более сложные программы из пары десятка функций. Соответственно что-бы не отставать придётся научится пользоваться функциями. Плюс в крупных компаниях есть требования к чистописанию к примеру MISRA который требует что-бы функция не превышала 20 строк. По поводу скорости можно привести пример когда код с функцией работает быстрее чем без неё.

Прата_С.-Язык_программирования_С++._Лекции_и_упражнения-ИД_Вильямс(2012)

Цитата:

В большинстве старых программ было настолько много запутанных переходов
(на профессиональном жаргоне это называется "спагетти-кодом"), что при
прочтении программу практически невозможно было понять, и попытка модифицировать
такую программу сулила одни неприятности. Чтобы выйти из ситуации такого рода,
специалисты по вычислительной технике разработали более дисциплинированный
стиль программирования, называемый структурным программированием.
Язык программирования С обладает всеми возможностями для реализации этого
подхода. Например, структурное программирование ограничивает ветвление
(выбор следующей инструкции для выполнения) небольшим набором удобных и гибких
конструкций. В языке С эти конструкции (циклы for, while, do while и оператор
if else) включены в его словарь.
Другим новшеством было так называемое нисходящее проектирование. В языке С эта
идея состояла в том, чтобы разделить большую программу на небольшие,
поддающиеся управлению задачи. Если после разбиения одна из задач все равно остается
крупной, этот процесс продолжается до тех пор, пока программа не будет разделена
на небольшие модули, с которыми будет просто работать. (Организуйте свой процесс
обучения. Ах, нет! Приведите в порядок свой рабочий стол, картотеку и наведите
порядок на книжных полках. Ах, нет! Начните со стола, наведите порядок в каждом
выдвижном ящике, начиная со среднего. Да, судя по всему, справиться с этой задачей
вполне реально.) Этот подход вполне осуществим в языке С, т.к. он позволяет
разрабатывать программные модули, называемые функциями, которые отвечают за
выполнение конкретной задачи. Как вы могли заметить, в структурном программировании
отображено процедурное программирования, в том смысле, что программа
представляется в виде действий, которые она должна выполнить.
Переход к C++: объектно-ориентированное
программирование
Несмотря на то что принципы структурного программирования делают
сопровождение программ более ясным, надежным и простым, написать большую программу
все еще было непросто.

[A_I]

Pavia в сообщении #1389961 писал(а):

Я думаю тут лучше говорить что, тот кто научится писать функции, тот будет быстрее писать программы.

И я думаю ровно так же, - но, не только быстрее, а более "осмысленно", - как бы на более "верхнем" уровне - уровне абстракций (функций, классов, методов, структур и проч.). А про машинные коды - это просто выдернули какую-то не совсем значимую деталь, обвинив во лжи детям Ну, да ладно, - люди есть люди...
Автономный квадрик - это так, - хобби для занятий с детьми (до этого проекта, к примеру, был проект попроще - автосканер по ОБД).
На работе у нас - СУ некоего транспортного средства. Основные мозги - бортовые компы под управлением осрв QNX.
Общее количество строк кода - не одна сотня тысяч (только интерфейсных переменных, не считая локальных - под десятку тысяч).
Проект выполняется командно.
При этом, системная часть была написана (по мотивам и на базе, конечно же предыдущих проектов СУ) заранее. Причем, требования к системной части, в частности - относительно низкий порог вхождения (собственно говоря, даже программеры си с небольшим опытом могут приступать к работе после небольшой "адаптации" - "место для творчества" минимизировано по возможности).
Далее - разработка по функциональным требованиям, которые пишут соответствующие специалисты (которые, конечно, для любителей уточнять детали, преобразуется в соответствующее ЧТЗ). Всего функций СУ пара сотен.
Система сложная, вернее, по сути - сама логика не сильно сложная (практически на 90% - "релейная", хотя есть, конечно, отдельные функции, требующие "особого" подхода), но слишком много точек связи и взаимодействия между отдельными функциями (я сейчас не о программных функциях, а о функциях СУ).
Хорошо, что системная часть уже подразумевает разбиение на базовые классы и методы. Стандарты программирования ещё более ограничивают возможное "творчество" ..
Без абстрагирования, причем, на нескольких уровнях - очень сложно, хотя и повторюсь, - все сделано, чтобы это облегчить.
Так что умение мыслить абстрактно - наверное, одно из самых важных для программиста...

[A_I]

Условно у нас деление на 4 категории:
1. Самая "низшая" - это даже не "программисты", а, скорее, "кодеры", которые по разработанным сильно детализированным системными инженерами функциональным требованиям и частному техническому заданию пишут программу, используя предопределенные на системном уровне шаблоны, классы, методы и структуры входных-выходных данных. Тут исключительно мало пространства для творчества, работа по большей части "механическая". Квалификация - инженер-программист (без категории). Функций, которые соответствуют этому уровню - больше половины.
2. Часть функций системы управления требуют уже кое-какого "творчества" - то есть, системных объектов уже не хватает, приходится разрабатывать дополнительные. Квалификация - инженер-программист 2, 1-ой категории.
3. "Особый" функционал СУ (процентов 10 от общего функционала) - системные объекты используются только для интерфейсов входа-выхода. Техническое задание написано в общем стиле без детализации. Большой потенциал для творчества - практически полностью своя разработка, как правило, можно сделать разными способами. Необходимо выбрать наиболее эффективный. Иногда приходится переписывать с нуля, что выясняется на этапе интеграции в общую систему. Квалификация - инженер по системе управления высшей категории, ведущий инженер-программист. Себя отношу к этой категории, хотя участвовал в разработке и системной части.
4. Системная часть. Понятно, что разрабатывать функц. требования и ЧТЗ "некому" Полностью "собственная" разработка (конечно, по опыту прошлых разработок и мирового опыта и проч.).
Уровень квалификации - самый высокий (только "ведущие" - инженеры по СУ и программисты).
Соответственно категориям, - и оплата труда.
Бывает, человек, не способный мыслить абстрактно (а скорее, не сильно стремящийся, так как развивается все), так и "засиживается" в "кодерах", выполняя чисто механическую работу...