IT в России и мире в реалиях мирового кризиса
1,284,220 7,813
 

  TAU ( Слушатель )
14 сен 2019 23:33:22

Что нужно знать программисту

новая дискуссия Дискуссия  839

ЦитатаЗамечательно при этом, что сортировки всплывающим пузырьком нет. Это как у радистов не будет преобразования Фурье


Нет - и не надо. Этот способ сортировки - зло. Нечего время тратить, чтобы узнать, как не стоит делать. Лучше сразу - как стоит.
  • +0.00 / 0
  • АУ
ОТВЕТЫ (51)
 
 
  adolfus ( Слушатель )
15 сен 2019 02:57:18

А лучше всего вообще ни на что время не тратить, а сразу юзать STL. Или еще лучше, ничего не программировать, просто использовать готовое.
Вы когда нибудь задумывались, что вроде как  постоянно растет производительность железа, объем памяти, а приложения становятся все более тормозными? А потому, что нечего время тратить на изучение структур данных и алгоритмов, языков низкого уровня, а сразу в котлин, скалу и пайтон.
  • +0.04 / 3
  • АУ
 
 
  Explorer-2000 ( Слушатель )
15 сен 2019 04:19:57

В каком то смысле это верно, 4 недельных курсов MS закрывают весь девелопментПодмигивающий и можно поднимать хорошие бапкиПодмигивающий, не забываем что абсолютное большинство современных програмистов никогда и не сталкиваются ни с какими структурами данных.
  • +0.00 / 0
  • АУ
 
 
 
  adolfus ( Слушатель )
15 сен 2019 12:24:23

Интересно, а какова польза нам от этого "большинства современных программистов" с 4-х недельными курсами MS? Их как-то можно использовать для решения внутрироссийских айти-проблем?
Кстати, а что такое "курсы MS"?
  • +0.00 / 0
  • АУ
 
 
 
 
  Oleg K. ( Слушатель )
15 сен 2019 18:18:13

Я не знаю, что там за курсы от MS, но зато знаю, что нынче на Украине полным полно "бывших домохозяек и грузчиков, которые вошлиВАйТитм" - этот спецтермин означает человека без хороших знаний логики, комбинаторики и дискретной математики, который научился выполнять определенные действия на компьютере и после этого все его называют "программистом": 1) он сам себя так называет, 2) окружающие его так называют, 3) работодатель его под видом программиста продаёт в качестве аутсорс-ресурса (в том числе и в Россию).
Но программистом этот человек не является, и сложные задачи он никогда не решит (это как раз тот случай, когда для решения сложной задачи будет принято очевидное простое и неправильное решение). Пользы от этого "большинства современных программистов" ровно столько же, сколько от "большинства продавцов-консультатов" в какой-нибудь евросети.
  • +0.11 / 5
  • АУ
 
 
 
 
 
  mark.76 ( Слушатель )
15 сен 2019 20:27:48

А когда программисты отличались от машинисток? Человек способный поставить задачу, должен как минимум быть электроником, а этому на курсах и по специальности программирования не учат - не знаешь как работает железо, значит быдлокодер. Так это было всегда.
  • -0.14 / 5
  • АУ
 
 
 
 
 
 
  Explorer-2000 ( Слушатель )
15 сен 2019 20:38:21

Ну вот есть например Сбербанк-онлайн, ну и какие знания в электронике нужны чтобы поставить такую задачуНепонимающий
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
  Oleg K. ( Слушатель )
15 сен 2019 21:45:28

Вы извините, но я ничего не понял. Может раскроете мысль чуть более подробно?
На всякий случай - все нормальные программисты и сейчас, и раньше, и очень-очень давно всегда знали хотя бы в общих чертах, как работают нижележащие уровни (и это может быть совсем не железо). Знать полностью все слои сейчас невозможно.
Вот по поводу "железа" - вы на верилоге или vhdl сможете с ходу обычный сдвиговый регистр написать? Лично я не смогу, хотя и понимаю примерно что там к чему.
Про уровни транзисторов в кристалле процессоров или протоколы взаимодействия с оперативной памятью я молчу. Так до какого уровня должны программисты знать всё, чтобы не быть быдлокодерами?Улыбающийся
  • +0.06 / 2
  • АУ
 
 
 
 
 
 
 
  Удаленный пользователь
16 сен 2019 08:42:40

Вот я, чтобы стать программистом, старательно по каплям выдавливал из себя мышление физика. Потому что сложность высокая и уровней абстракции сильно много, и практически никогда не нужно знать самый низ. Ну или забыть. Мыслишь уровнями, в голове 3-4 уровня максимум. Веришь, что уровни ниже работают как им положено. Если они не работают - я смещаюсь на уровень вниз и вожусь уже с ним, и тогда из кэша вытесняется что-то из уровней выше.
Уж веб-программист точно никогда не доберется до топологии СБИС. Или там разработчик ядра СУБД - ну зачем ему что-то ниже языка С? Я теперь с контроллерами вожусь - и практически никогда даже ассемблер целевой железки не нужен - ну если это не глючной 8051 с глючным же кейлом - но оно, слава Богу, подохло - и туда ему и дорога.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
  Поверонов ( Слушатель )
16 сен 2019 08:49:45

ядро СУБД тесно работает со всеми кэшами ввода-вывода ОС и нередко ( есть опции ) берет их под свое управление
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
  Senya ( Слушатель )
16 сен 2019 08:51:25

Функции операционной системы выше по уровню, чем язык на котором они написаны.
Ниже по уровню - например реализация Skein на С, учитывающая архитектуру процессора и позволяющая задействовать все три вычислительных блока за такт.
  • +0.04 / 4
  • АУ
 
 
 
 
 
 
 
 
 
 
  Удаленный пользователь
16 сен 2019 09:13:08

А, ну да, а ещё всякие Hackers delight и Duff device. Это я люблю.
Кстати, сколько не пробовал - ничего толком duff device не давало.
Premature optimization is the root of all evil.
  • +0.03 / 1
  • АУ
 
 
 
 
 
 
 
 
 
 
 
  Senya ( Слушатель )
16 сен 2019 09:18:37

Вот честно - изначально учил делать низкоуровневую оптимизацию. Но когда компы с трёшек заменили на 486, и оптимизированные и неоптимизированные программы стали давать практически одинаковое время исполнения - завязал с этим грязным делом Веселый
Но с другой стороны другого способа программно обеспечить под 600 мегабайт потокового шифрования в секунду и скажем прозрачно шифровать SSD на сегодня нет.
  • +0.05 / 5
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
  Удаленный пользователь
16 сен 2019 09:31:26

Ну иногда приходится. Нормальный разработчик это чувствует и сразу делает, как минимум, приемлемую версию. Ну или хотя бы обозначит проблему сразу.
Приведенную выше цитату про premature optimization мне выдал представитель заказчика, у которого подсистема хранения и, в частности, деревья были реализованы мм... странно. И заведомо неэффективно. Но типа - пока так сайдет. Ну ок: ты заказчик - я дурак, мне за часы платят...
  • +0.03 / 1
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
  VictorS ( Слушатель )
16 сен 2019 14:07:47

Ответ не на Ваше сообщение. Просто по теме. Сегодня нас программистов поздравляли с прошедшим праздником админы. Они по пятницам не всегда на месте.  Я давно уже не пишу. Все, что прочитал на этой странице, все бла.бла. В 90 годы было время индивидуальных программистов. Среди моих разработок много интересного, которые  были внедрены. Я вовремя понял, что время одиночек прошло. Ушел в другую область. Грустный
А может это главное для программиста, вовремя остановиться, и сменить вид деятельности. Уверен, что, программисты это очень умные люди которым не нужны чужие советы.  
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
  bb1788 ( Слушатель )
16 сен 2019 14:52:50
Сообщение удалено
bb1788
17 ноя 2021 09:20:15
Отредактировано: bb1788 - 17 ноя 2021 09:20:15

  • +0.03
 
 
 
 
 
 
 
 
 
 
 
 
  adolfus ( Слушатель )
16 сен 2019 21:28:00

Встроенный SATA rev.3? Используя процессор нет и никогда не будет. SATA данные берет из ОЗУ. Считаем – кто-то асинхронно, но со скоростью 600 Мбайт/с кладет плайнтекст в ОЗУ (1), крипроалгоритм читает плайнтекст (2), его курочит на процессоре и выкладывает шифртекст в ОЗУ (3), потом интерфейс забирает этот шифртекст из ОЗУ (4) и отправляет в диск. Это если мимо файловой и даже мимо операционной системы. Рядом, соответственно, трудится операционка и куча приложений, котороым также требуется ОЗУ.  Интерфейс памяти в резульате будет полностью перегружен – 25 Гбит/с вынь да положь.
Но выход есть – шифрующий спецконтроллер SATA/eSATA, воткнутый в длинный PCI Express отлично все успевает и грузит память только на 6 Гбит/с.
  • +0.03 / 1
  • АУ
 
 
 
 
 
 
 
 
 
 
 
  adolfus ( Слушатель )
16 сен 2019 20:41:04

Это точно. Гораздо больше можно достичь, умело организуя данные и используя правильные алгоритмы. 
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
  Удаленный пользователь
16 сен 2019 08:53:20

Ещё раз: при чем тут электроника.
Я писал: не надо ниже языка С. Ядро ОС - это выше.
Ну плюс ликбез про то, что у диска головки ездЮЮт. Что-то ещё из железа?
А вот алгоритмов в ядре СУБД - вот этого там овердофига...
Чисто алгоритмы. На С. Много. Ну на С++, может.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
  adolfus ( Слушатель )
16 сен 2019 19:47:00

Это вряд ли. Поженить ООП и SQL пока еще никому не удалось – там противоречия на уровне парадигмы. Поэтому нет никакой необходимости в кишках и недрах СУБД писать что-то на С++ без классов, если тут же рядом есть С, на котором можно написать вообще все.
А для гиков и членов секты свидетелей ООП есть привязки к некоторой части интерфейса к СУБД  и все счастливы.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
  DarkRaider ( Слушатель )
17 сен 2019 00:20:38

Mon cher ami, Вы, как всегда, слишком категоричны.
Во первых, современные СУБД вполне себе официально называются "объектно-реляционными базами данных" и таки имеют достаточно признаков и возможностей на эту тему.
Для примера PostgresSQL вот тут даже в начало статьи гордо вынесли..  MS SQL, Oracle тоже дозволяют многое. И это я говорю лишь о возможностях самих СУБД. Во вторых, если копнуть вопрос НАПИСАНИЯ субд, то без ООП обойтись не получится,если Вы не извращенец и если пишите УНИВЕРСАЛЬНУЮ СУБД (принеси и сохрани то - не знаю что).

ЦитатаПоэтому нет никакой необходимости в кишках и недрах СУБД писать что-то на С++ без классов, если тут же рядом есть С, на котором можно написать вообще все.
А для гиков и членов секты свидетелей ООП есть привязки к некоторой части интерфейса к СУБД  и все счастливы.


Что то  я опять, Вас, не пойму, в чём суть очередного дефиле?
С++ появился путём добавления ООП механизмов в С, откуда взялась идея писать на C++ без классов?
  • 0.00 / 2
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
  adolfus ( Слушатель )
17 сен 2019 10:00:03

"Объектно-реляционный" – это всего-лишь составное слово, ничего не обозначающее кроме модного набора звуков. Что, например, может означать слово "плотно-разреженный"? На самом деле либо объектная модель данных, либо реляционная.  Отобразить таблицы реляционной модели в структуры объектной пока никак не получается – проблема есть такая "object-relation mapping". Вот когда ее математики решат, возможно тогда словосочетание "объектно-реляционный" наполнится реальным смыслом, а так пока всего-лишь попытки забить колышки на участке, который кажется золотоносным.
  • +0.02 / 1
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
  DarkRaider ( Слушатель )
17 сен 2019 17:31:29


"Всё дело, в волшебных пузырьках!", как нас заверяла реклама одной шоколадки.
"Реляционная" СУБД - та, где имеется чёткое соответствие отношений хранимых объектов (идентификатор или комбинация признаков его составляющая). Такая СУБД вполне спокойно хранит любые объекты - в том числе и бинарные, в том числе и классы (например тот же XML имеющий свои методы). Современные СУБД расширяются  внешними и внутренними процедурами, представляющими тоже объекты, в том числе и бинарные. Есть типизация, абстракция, преобразование типов - достаточно признаков чтобы назвать объектно-реляционной СУБД?

Почитаем вики объектно ориентированная база данных.

Сравним признаки?

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

Поддержка индивидуальности объектов. Все объекты должны иметь уникальный идентификатор, который не зависит от значений их атрибутов.
Это скорее свойство реляционных.

Поддержка инкапсуляции. Корректная инкапсуляция достигается за счёт того, что программисты обладают правом доступа только к спецификации интерфейса методов, а данные и реализация методов скрыты внутри объектов.
Чем плоха модель безопасности обычной СУБД?  Монопениссуально.


Поддержка типов и классов. Требуется, чтобы в ООБД поддерживалась хотя бы одна концепция различия между типами и классами. (Термин «тип» более соответствует понятию абстрактного типа данных. В языках программирования переменная объявляется с указанием её типа. Компилятор может использовать эту информацию для проверки выполняемых с переменной операций на совместимость с её типом, что позволяет гарантировать корректность программного обеспечения. С другой стороны класс является неким шаблоном для создания объектов и предоставляет методы, которые могут применяться к этим объектам. Таким образом, понятие «класс» в большей степени относится ко времени исполнения, чем ко времени компиляции.)
Смотрим пункт №1.  Только в разрезе времени выполнения, а не в разрезе управления данными.

Поддержка наследования типов и классов от их предков. Подтип, или подкласс, должен наследовать атрибуты и методы от его супертипа, или суперкласса, соответственно.
   Перегрузка в сочетании с полным связыванием. Методы должны применяться к объектам разных типов. Реализация метода должна зависеть от типа объектов, к которым данный метод применяется. Для обеспечения этой функциональности связывание имен методов в системе не должно выполняться до времени выполнения программы.

Этого нет и врядли когда то будет в обычных СУБД. Нахуа?

   Вычислительная полнота. Язык манипулирования данными должен быть языком программирования общего назначения.
Ну вот обычная библиотека - это ведь СУБД?  В ней хранят книги - это объекты?  Составные?  Сложные?  И метод у каждой книги есть свой (Book.Дряхлеть) ну это тот что присущ объекту самому, без посторонних вмешательств. Какая у библиотеки вычислительная мощность? 3 калькулятора, если по этажам собрать?

   Набор типов данных должен быть расширяемым. Пользователь должен иметь средства создания новых типов данных на основе набора предопределённых системных типов. Более того, между способами использования системных и пользовательских типов данных не должно быть никаких различий.
Смотрим пункт (1).

Итого на мой взгляд: вся вот эта муть написанная про "чистые" ООСУБД = сова натянутая на глобус. По тому, что смешаны понятия управления данными и программных действий над ними производимых. До тех пор пока мы не доживём до появления саморегулируемых цифровых данных. Все СУБД которые занимаются именно ХРАНЕНИЕМ и УПРАВЛЕНИЕМ доступом к данным - можно смело отнести в объектно-реляционным, в том понимании, что они способны хранить сложно-составные данные (сериализованные объекты) и хранимые отношения между ними (те связи которые присущи объектам вне контекста их последующего исполнения).
  • +0.05 / 2
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  adolfus ( Слушатель )
17 сен 2019 20:13:35



Основная особенность всех СУБД, в том числе и реляционных, состоит в том, что никто не знает, какие действия и кем будут предприниматься над данными. Поэтому с ними работают с помощью декларативного SQL, а не лезут к данным напрямую – что и как там крутить решает СУБД. Иногда используют ISAM, но опять же не к данным, а их статичным представлениям, рискуя напороться на конкурентные процессы, изменяющие структуру и связи.
В БД хранятся сущности и отношения между ними. И те и другие представляют непрерывно обновляемые динамические структуры данных. Представить их в виде объектов (в смысле ООП) невозможно – сущности и отношения очень динамичны, в то время как объекты – просто экземпляры класса (типа). Объекты могут представлять лишь моментальный слепок простейших статичных состояний БД, в то время как в процессе работы меняются не только сущности и отношения, которыми управляет пользователь, но и те сущности и отношения, которыми управляет СУБД. Причем последних гораздо больше – каждый запрос генерирует их огромное количество.
Что касается xml, то это очень убогий способ представления отношений, поскольку реальные отношения представляются графами, а не деревьями.
  • +0.02 / 1
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  Поверонов ( Слушатель )
17 сен 2019 21:24:04

В объектно-реляционных СУБД "объектами" ( а точнее классами ) являются не данные, а "процедуры" оформленные в виде классов.  При этом таблица есть лишь способ хранения атрибутов экземпляров класса ( по принципу запись - экземпляр класса ). Все отношения между классами поддерживаются через функции классов, то есть вынесены в процедуры. Собственно СУБД при этом используется лишь для хранения экземпляров классов - по сути это NoSQL, так как всё делается в процедурах  без всяких оптимизированных планов исполнения (execution plan )
  • +0.02 / 2
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  adolfus ( Слушатель )
19 сен 2019 16:21:36

Невозможно отношения вынести в процедуры, поскольку процедуры – это фундаментально статичные сущности, а отношения нет.
Хотя, да на здоровье. Хоть горшком обзови...
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  adolfus
  • Загрузить
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  slavae
  • Загрузить
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  adolfus
  • Загрузить
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  • Загрузить
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  slavae
  • Загрузить
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  TAU ( Слушатель )
17 сен 2019 22:47:31

Справедливости ради, дерево - разновидность графа. 
"Ольга Никаноровна проснулась в холодном поту. Ей привиделся кошмарный сон. Граф в виде дерева". Веселый
  • +0.06 / 3
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  adolfus ( Слушатель )
19 сен 2019 16:45:12

Справедливости ради, не разновидность, а подмножество одной из разновидности – ориентированного ациклического графа.
Дерево может представлять только самые простые отношения – иерархические, когда у объекта есть только одна входящая связь. Чтобы представить произвольную систему отношений на N объектах требуется в общем случае N деревьев, не имеющих общих ребер. Представлением сложной системы в виде набора таких деревьев управлять (добавлять/удалять вершины и связи) очень сложно.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  DarkRaider ( Слушатель )
17 сен 2019 22:53:39
Уважаемый, adolfus, вы фееричны как никогда!!!


Я знаю доподлинно! Данные в базе данных можно добавить, удалить, считать или изменить. Автономную трансмутацию в СУБД пока не добавили. Все дальнейшие действия с данными могут быть произведены только после чтения их из хранилища. Область работы и ответственности СУБД в этом месте заканчивается.

Цитата...  В БД хранятся сущности и отношения между ними. И те и другие представляют непрерывно обновляемые динамические структуры данных...

Правда?  Наиболее распространённый "частный" случай СУБД  - это файловая подсистема любой ОС. Я правильно понимаю, что в файлах (как объектах хранения), постоянно перемещаются байтики туда сюда сами?    Впрочем я совсем забыл про сбойные кластеры! Ведь информацию из них перемещает дисковая подсистема! Правда связи при удачном чтении сбойного сектора всё таки сохраняются, как и целостность объекта хранения.
  • +0.03 / 1
  • АУ
 
 
 
 
 
 
 
 
 
 
 
  Удаленный пользователь
19 сен 2019 07:44:10

Не-не, я не про объектно-реляционность.
Потроха реляционной СУБД отлично ложаться на объектную модель.
Ну, типа, источником данных может быть скан таблицы (с условием-без условия), скан листьев индекса (с условием-без условия), поиск в индексе, результат предыдущего шага исполнения запроса, какой-нибуть хэш-дистинкт, результат джоина, причем надо не забыть про порядок сортировки и использовать его дальше при исполнении запроса и т.д. - отлично на объекты ложится. Результат синтаксического разбора в виде дерева объектов. Транслированный запрос, который умеет себя сохранять или передвать по сети.. Ну и по мелочи внизу - объект на стеке с мутексом внутри, из функции вышли - мутекс отпустили...
Я люблю плюсы. Правда, всё как-то не складывается на них писать. Сплошной "папа может С"...
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
  DarkRaider ( Слушатель )
19 сен 2019 11:33:50


Когда имеешь дело с неопределёнными данными - в реализации приходится уходить на высокие уровни абстракции, там сложно обойтись без объектного подхода.
Вспомни как было легко работать с простыми типами (например с типизированными файлами). Но ровно до тех пор, пока мы точно знали состав записи (входящих в неё типов переменных).
Как только появляется variant в том или ином виде - начинается уже катавасия.
  • +0.00 / 0
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
 
  Удаленный пользователь
19 сен 2019 19:00:51

Ммм - да нет, вполне обходишься С..
Процедурный код - он другой малость получается, но его вполне хватает.
Зато он лучше поддается статическому анализу "глазками". В плюсах зачастую пока отладчиком не встанешь - не разберешься какая из функций когда вызовется.
И ещё: костыль в процедурном коде смотрится не так страшно как костыль в объектном. Ну добавил ещё флажок или проверку - делов-то. А в плюсах может понадобиться перетряхнуть структуру классов.
Ну тут главное не заиграться, а то оглянуться не успел - а всё уже из костылей состоит.
  • +0.05 / 2
  • АУ
 
 
 
 
 
 
 
 
 
 
 
 
  Explorer-2000 ( Слушатель )
15 сен 2019 20:41:53

Так им никто такие задачи и не даёт, IT это огромная индустрия, где полно простой, рутиной работы вот там и достаточно программистов с базовыми знаниями.
  • +0.01 / 1
  • АУ
 
 
 
 
 
 
  Oleg K. ( Слушатель )
15 сен 2019 21:38:09

Кхм... Вы, мягко говоря, сильно ошибаетесь. Представьте, что есть два программиста: Ваня-программист за 3000р в час и Ваня-"программист" за 500р в час. Угадайте, кого выберет заказчик для типовой задачи. Правильно - тот вариант, который по-дешевле. Ну или можете не представлять, если вы сталкиваетесь с этим (я сталкиваюсь, поэтому у меня описание не "гипотетической ситуации", а вполне реальных проектов).
А потом все удивляются, почему от постоянной дешевизны одна страничка новостей на сайте загружается 3 секунды на 100МБитном канале и занимает в оперативной памяти 1 гигабайт.
Да, простые задачи часто делают программисты без большого опыта и знаний. Но если их оставить там одних (без присмотра более опытного коллеги), то они вам там понаработаютУлыбающийся Причём, я не думаю, что в другой области, где нужны знания и т.п. (например, в ремонте автомобилей тех же самых) трудовая деятельность сильно отличается - в конце концов, фразе "каждый суслик в поле - агроном" уже очень много лет.
  • +0.04 / 2
  • АУ
 
 
 
 
 
 
 
  Удаленный пользователь
16 сен 2019 08:34:44

Заказчик вообще не выберет Ваню. Заказчек выберет Джаймина. А Ване придется разгребать тот треш, который Драймин нагородит. Рррр.
  • +0.06 / 3
  • АУ
 
 
 
 
  Explorer-2000 ( Слушатель )
15 сен 2019 20:35:59

MS это MicrosoftВеселый, лет 15 назад были 4 недельных курса по .NET & SQL, которые в целом закрывали весь девелопмент, можно было работать, а через год, получив опыт получать на контракте порядка 100К$ в годПодмигивающий, хорошее время было, сейчас может эти направления и не актуальны так есть другие типа Angular или AWS, но суть то не меняется, да и в России вон Яндекс обещает массово готовить IT-шников, думаете они все будут на уровне математического факультете университетаНепонимающий, я вот думаю что это будет набор неких базовых знаний и только, но такие люди нужны на рынке.
  • -0.02 / 1
  • АУ
 
 
  Удаленный пользователь
16 сен 2019 09:23:41

Угу. Собеседовал кандидата, который пишет драйвера для Линукса, но не представляет себе как устроен список. Ну а что - есть же готовые макросы. Разумеется, про O(n) не слышел (а это, кстати, точно в школе проходят).
Электронщик по образованию, ага. Военка.
Вообще, по моему опыту, радиотехники по образованию обычно посредственные программисты. Хоть железо знают, да.
Вот физики - попадаются хорошие. Но лучше все-таки профильное образование.
  • +0.00 / 0
  • АУ
 
  Explorer-2000 ( Слушатель )
15 сен 2019 04:21:38

И это говорит преподаватель в униерситетеНепонимающий в учебном плане несомненно представляет как пример не эффективного алгоритма.
  • +0.00 / 0
  • АУ
 
  AndreyK-AV ( Слушатель )
15 сен 2019 21:35:31

Даже на уровне школы при преподавании информатики стоит вопрос, а что преподавать, и на что упор, на технологии или науку!?
Если технологии первичны, то результат быстр, а способы сортировки согласно методике типа тому чему сейчас научили... для большинства пользователей и кодёров достаточно...
А если как науку, то первична математика, физика и химия с биологией не помешают, но после первых двух наук, дабы понимали физическую суть явлений, имели качественный математический аппарат, и тогда способ "сортировки" выберут сами согласно задачи, порой лучшей чем советуют преподаватели....
Ах да, логику давать надо и в любом варианте.Подмигивающий 
  • +0.05 / 5
  • АУ
 
  Удаленный пользователь
16 сен 2019 09:20:01

Это все-таки уже первый курс. Вы же не требуете, чтобы в школе учили аналитическую геометрию?
  • +0.00 / 0
  • АУ
 
 
  Senya ( Слушатель )
16 сен 2019 09:27:13

По большому счёту сортировка пузырьком это ещё даже не уровень алгоритмов. Это уровень изучения базовых операций, копирования, сравнения, ветвления на простейшем примере. Алгоритмы будут позже.
  • +0.07 / 6
  • АУ