Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Программист, который не знает, сколько стоит каждая структура данных — не программист

Отсюда: djinni.co/q/6d8d482f

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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

В 50х, если ты разбирался в автомобилях и тонкостях их устройства, ты был крут и афигенен. Сейчас, если ты разбираешься в машинах, ты — автослесарь.

по стилю изложения автор обьявления видится очень большим звиздаболом.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Как-то интересовались здесь на ДОУ простыми вопросами для собеседований. Вот положим, такой кандидат попался — «знаю цену структурам данных».

Вот вам вопрос. Дана таблица 16 x 16. В нее врисованы картинки-буквы-значки. Конкретно — ASCII таблица. Найти причину именно такого расположения картинок внутри таблицы.

Смотрим, сколько времени понадобится и как будет рассуждать. Конечно, если он просто знает ответ, то умение рассуждать не проверим, но хотя бы узнаем, что структурами и в самом деле интересовался/интересуется. )))

Вот вам вопрос. Дана таблица 16×16. В нее врисованы картинки-буквы-значки. Конкретно — ASCII таблица. Найти причину именно такого расположения картинок внутри таблицы.
А можно узнать правильный ответ и для какой кодировки он будет правильный?

Хорошая идея, но я бы задал вопрос про ебздик (EBCDIC), т.к. если человек не знает правильного ответа, можно узнать многое о том, что он знает просто следя за идеями.

EBCDIC
 Да, согласен, EBCDIC очень интересен.
Но сегодня человек младше 30, может, и не слышал о таком. Вопрос хорош тогда, когда расспрашивают о чем-то привычном в пользовании, и понимает ли человек то, чем пользуется.
Вот вам вопрос. Дана таблица 16×16. В нее врисованы картинки-буквы-значки. Конкретно — ASCII таблица. Найти причину именно такого расположения картинок внутри таблицы.
И что этот вопрос проверяет?
А то как-то он похож на dou.ua/...ums/topic/7670

Про водопроводчиков это en.wikipedia.org/...i/Fermi_problem , глубинный смысл задачи про таблицу я пока не распознал.

глубинный смысл задачи про таблицу я пока не распознал.
Он не настолько глубинны. Если говорить про младшую таблицу 8×16, то это сортировка. Если говорить про старшую 8×16 таблицу, то у KOI8 — это транслитерация, CP1251 — это сортировка, CP866 — попытка вместить кириллицу в IBM CP437. И т.д.

Это вопрос проверит, сможет ли человек оценить разницу в стоимости реализаций работы с входным потоком байтов, а) при незнании структуры таблицы ASCII, то есть, предполагая, что там хаос; и б) стоимости реализации, полагая, что там _должна_ быть структура.

То есть, первой фразой в ответе человека, сказавшего, что знает стоимость структур, должна быть вроде такой:
«Конечно, полагая, что таблицу ASCII создавали умные программисты в 60-х, эта структура должна быть намного дешевле, чем просто хаос в такой таблице.» Разница в стоимости будет заключена в том, что ....

То есть, первой фразой в ответе человека, сказавшего, что знает стоимость структур, должна быть вроде такой:
«Конечно, полагая, что таблицу ASCII создавали умные программисты в 60-х, эта структура должна быть намного дешевле, чем просто хаос в такой таблице.»
Поздравляю! У вас талант!
Вы смогли засунуть в 1 вопрос и неопределенность/непонятность вопроса про люки и бесполезность вопроса про все методы класса из стандартной библиотеки.

если бы я был человеком, который не знает стоимость всех структур данных, но что-то знает о вероятности встретить какой-то символ в тексте — то я бы пожалуй рассуждал бы следующим образом:
мы имеем структуру данных, которая содержит постоянное число символов, извлекать эти данные мы можем по ключу. ключ имеет постоянную длину (2 байта). Символы в этой структуре данных хранятся просто по алфавитному порядку, а вовсе не по вероятности нахождения символа в тексте . эту структуру создавали умные люди. следовательно время извлечения символа не зависит от значения ключа или этой зависимостью можно пренебречь.
ну и вот путем таких простых умозаключений я делаю вывод, что если я расположу символы в любом другом порядке — то структура не будет работать медленнее

Вот рассуждения, которые мы надеялись бы услышать...

В программах слова-операторы (напр. ключи в командной строке) обычно делают безразличными к регистру. Иначе придется проверять и отклонять у пользователя ввод типа YeS, yes, yeS, YES, требуя однообразия. Первый минус в стоимости такой программы — раздражение пользователя. Он скажет боссу, босс вторую программу закажет не у вас. Второй минус, программист должен и сам морочиться с проверками. В итоге, время работы, размер, скорость и надежность программы — всё это тоже идет в минус программисту.

Избавляются от этих минусов одним махом: и пользователю свобода, и программисту легче. Как? Программист обычно переводит любой буквенный ввод в верхний регистр. Математически, он производит свертку функции. Значит, проверка нужна только одна: это YES или нет.

Вообще, можно математически показать, что уменьшив диапазон входных значений в системе, пропускная способность функций этой системы возрастает. А также, надежность, помехоустойчивость, вандалоустойчивость и пр. плюсы. Зная это, программисты Майкрософт сделали поиск в файловой системе независимым от регистра в названии файла. Программисты Линукса тоже парни ого-го, но... каждый может убедиться в индексации 200 Гб мелких файлов в NTFS и 200 Гб тех же мелких файлов в Ext3. Разница — примерно порядок. Майкрософт нанимала классных и математически образованных программистов, а кто-то сомневался? :)))

Теперь смотрим в таблицу ASCII. Как перевести в верхний регистр? Замечаем, что между всеми строчными буквами и прописными одно и то же расстояние в байтах. Вуаля! значит, вычитая из значения байта 0x20 мы поднимаем в верхний регистр. И прибавляя 0x20, опускаем. К этому еще нужно сделать проверку, в каком из двух диапазонов лежит значение байта, чтобы не получить кракозябры.

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

Если же человек еще и знает математику, то он скажет по-другому.

Перед нами функция W, заданная таблицей. Каждому значению A байта, равному его ординалу N (порядковому номеру), ставится в соответствие порядковый номер ячейки таблицы (ASCII, KOI-8,...). Порядковый номер байта пробегает все значения от 1...255. Оставшаяся пустой ячейка таблицы байтов левее N=1 не входит в определение функции W, но ее заполняют просто исходя из того, что она однозначно сопоставима с первой ячейкой таблицы 16x16 (ASCII, KOI-8,...).

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

Математик (и хакер):), задут, вероятно, один и тот же вопрос: а почему смещение между регистрами 0x20, а не скажем, 0x22? Откуда следует этот выбор?

На самом деле, при рассмотрении двоичных кодов, мы замечаем, что все строчные буквы отличаются от прописных одним битом. Вот это да! Ай да программисты 60-х! Это ведь насколько дешевое решение. Ведь теперь достаточно определить, что это вообще буква, и :
and ah,11011111b
или
or ah,00100000b

Всего одна инструкция процессора, да еще независимо, какая именно это буква.

Может, вы подумали, что на двоичном представлении структуры закончились? Нет, и добро пожаловать в настоящий мир структур, в математику.

А ведь наверное, можно увидеть и наивный (индусский?) код, где кто-то вознамерится для перевода в другой регистр искать в словаре парное соответствие строчных и прописных...

Я предпочел бы иную присказку, чем название топика: «настоящий программист через пол-секунды называет для десятичной цифры ее двоичный код». Даже спросонья и после выпивки )))

Я предпочел бы иную присказку, чем название топика: «настоящий программист через пол-секунды называет для десятичной цифры ее двоичный код». Даже спросонья и после выпивки )))
Это все может и было актуальным лет 40 назад, но вроде как не сейчас.
Это все может и было актуальным лет 40 назад, но вроде как не сейчас.
Если у меня будет <<высоконагруженный>> сервер с отдачей статических файлов, я выберу MS сервер с NTFS ;)

Вот так далеко распространяются ошибки в оценках стоимостей разных структур, и стоимость кучи без структуры (множества), сделанные без научной оценки.

В файловой системе 100500 других более серьезных затыков окромя перевода в регистры, поэтому твою оценку научной уж никак не назовешь. 1.bp.blogspot.com/...ch_overview.png

Неплохая задача, но все-таки это не признак «настоящего программиста». Просто потому что «настоящий программист» это как «настоящий мужчина». У каждого свой образ.

Мне очень понравилась) Я сейчас мало пишу таких низкоуровневых штук и прямо с удовольствием прочел.

в русской части таблицы уже не такая сильная магия

Ай да программисты 60-х!
Почему программисты 60-х начали буквы не с 0×40, а с 0×41 ?

Они выравнивали на границу 0×20 начала двух байтовых отрезков, и при этом должны были поместиться в 127 клеточек первой половины 16×16.

Почему только 127? Потому что перфоленты имели только 7 линий. В них надо было закодировать и данные, и команды.

А я слышал, что когда располагали символы в ASCII, то решили сделать совместимость с каким-то древним борадатым стандартом у которого «A» имела позицию 0×41.

Кстати, забавная ахинея, я вот интернетики почитал и обнаружил что так сделали что бы клавиатуры легче делать было, типа не хранить в клавиаторы две таблицы для разных регистров, а просто выставлять бит согласно значения capslock/shift.

А ничего, что клава фактически отдаёт код пересечения строки и столбца и нумерация идёт так, как выглядит клава, т.е. слева направо, сверху вниз?

Я не уловил, в АСКИИ таблице буквы отсортированы в алфавитном порядке. На клавиатуре нет. Можешь привести пример твоей теории?

Клавиатура не применяет никаких модификаторов при нажатии на shift/capslock — для неё это обычные клавиши, такие, как и все остальные.

Ок, т.е. когда я нажимаю вначале шифт, и держу его, и нажимаю цифру А то что отсылается компьютеру? Ты сейчас говоришь об IBM PC, или о компах которые были когда изобретали ASCII раскладку?

Ок, т.е. когда я нажимаю вначале шифт, и держу его, и нажимаю цифру А то что отсылается компьютеру?
Если левый шифт, то 0×2A, если правый то 0×36, затем код «A» 0×1E. Затем 0×9E — отжатие «A», и 0xAA или 0xB6 при отжатии шифта.
Ты сейчас говоришь об IBM PC, или о компах которые были когда изобретали ASCII раскладку?
Коды выше от IBM PC, у более старых компов другие коды, но ни те, ни другие к ASCII никакого отношения не имеют.

Ок, но у тебя есть уверенность что во всех компах до PC-шной эры клавиатуры компутеру посылали именно скан коды которые потом ПО трансформировало в ASCII? Ведь может быть так что какие нибудь PDP терминалы высылали именно ASCII на TTY или его аналог?

Ведь может быть так что какие нибудь PDP терминалы высылали именно ASCII на TTY или его аналог?
Так в PDP были не клавиатуры, а телетайпы, которые можно назвать миникомпьютером в себе. Это тоже самое, что сказать, ZX Spectrum — это клавиатура, работающая в режиме ASCII.

Классно, но ты я так понимаю не в курсе как они устроены, и есть ли там скан коды на нажатие и отжатие шифта.

Там нет скан-кодов, т.к. это не клавиатура, а аппаратный телетайп, который реализовывал какой-нибудь VT278 и т.п.. Как и IBM’овские аппаратные терминалы типа 3270 аппаратно генерировали кода в EBCDIC кодировке.

В любом случае,

я вот интернетики почитал и обнаружил что так сделали что бы клавиатуры легче делать было, типа не хранить в клавиаторы две таблицы для разных регистров

это не имеет ничего общего с клавиатурами, а только для сортировки. В те времена применяли 6-битовую передачу со вставками shift-in/shift-out, что было эффективнее, чем 7-битовая кодировка с upper/lower case символами для текстовой информации, которую в 90% случаев и использовали тогда.

Причём, по мере развития электроники клавиатуры упрощали как могли, а не наоборот, как и уходили от аппаратных терминалов. SGI и Sun это сделали первыми.

Кстати, забавная ахинея, я вот интернетики почитал и обнаружил что так сделали что бы клавиатуры легче делать было, типа не хранить в клавиаторы две таблицы для разных регистров, а просто выставлять бит согласно значения capslock/shift.
Правильно.

И не только не хранить на передающей стороне, но и не хранить на принимающей. Двойная выгода.

Рассуждение такое. Если есть две последовательности одной длины, различающиеся одним признаком, то этот признак помещается в один бит. Теперь вопрос только создать структуру данных под эту задачу.

Она и была создана.

Я предпочел бы иную присказку, чем название топика: «настоящий программист через пол-секунды называет для десятичной цифры ее двоичный код». Даже спросонья и после выпивки )))

Для сишников и эмбедеров наверное да. Для всех остальных гораздо больше выиграша для бизнеса если человек знает фреимворки и паттерны.

Вспоминается старый анекдот, когда
на первом курсе: «2×2= ? — Четыре!»
На пятом: «2×2= ? — Я не обязан помнить все константы!»

Шутка-шуткой, но знание «констант» программистом не делает.

upload.wikimedia.org/...ics_-_Cover.png
кто не открывал эту книгу тот не програмист.

я открыл, даже главу прочитал, все, я пришел к успеху!

Я здесь самый умный, так как принимаю ноотропы и познал силу Firebird. Кто-нибудь здесь хочет оспорить моё лидерство?

стимуляторы, галлюциногены и эйфоретики доказывают, что рай умещается в пакетике

Alexandr Gavriluk — Новодворская нашего DOU

Новодворская девственная, как и Анатолий Вассерман.

С чего это? Чего ты знаешь такого, чего не знает никто на планете?

Продается массив. Недорого...

Да- программист -который не знает структур данных и алгоритмов- и их применения- плоховастенький программист/веб программист
Хотя что я рассказываю. Вот на днях решил задачки решать . И что в итоге- мозг закостенел. три дня решал задачку простяцкую.(точнее три подхода делал) А потом- по одной за полчаса, главное втянуться.

Можете называть меня на форумах “не программистом”, “бідлокодером”, как угодно, обычная синьйорская ЗП меня вполне устроит.

учитывая что он джавист а не ембеддер — я сильно сомневаюсь в правдивости его слов ...

по стилю изложения автор обьявления видится очень большим звиздаболом.

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

Если буквально понимать тест — сколько стоит «каждая» — то и Кнут не пройдет, ввиду бесконечно большого числа возможных структур данных и способов работы с ними :) Но у программиста должны быть заметны хотя бы следы чтения кнута/седжвика/кормена, и способности анализировать соответственно.

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

Умножить.

минимум на два

На ноль.

На шарлатана-махінатора схоже. Того ж порядку, що й архітекти, які не вміють писати код :)
«Я сработаюсь с маленькими и молодыми.» Ахаха)) «Облапошу нєсмишльонишей» ))

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Я понимаю, когда таким страдают в анменеджит мире, но для джаваиста... Толку то тушить забор, когда дом горит.

В джаве сортировка (не radix) не за O(n log n) делается? Минимум O(n^2), потому что джава?

С практической точки зрения в J2EE никто не сортирует в памяти списки/массивы размером более 1000-10.000 элементов собственным алгоритмом. Обычно делается на уровне базы/хранилища (SELECT ... TOP 10 ... ORDER BY ... ASC).
Это актуально для всякого рода NoSQL (Cassandra, Hadoop, ...) когда мы бросаем в распределенное хранилище свой «вычислитель», но, надо признать, это уже не J2EE работа, а именно распределенное хранилище на Java.

а order by работает на каком-то квантовом компьютере :)

Дело в том, что order by уже написан до нас. В чем я соглашусь с Иваном, так это в том, что в секторе enterprise приложений задачи самостоятельной реализации сортировки, поиска и т.п. алгоритмически нетривиальных вещей возникают крайне редко.

Писать, конечно, не нужно, а понимать «сколько стоит каждая структура данных», о чем и речь в старттопике, нужно, кем бы не было это уже написано до нас.
И противопоставление managed/unmanaged в контексте сложности алгоритмов доставляет.

а зачем разбираться, если писать не нужно?

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

можете как-то пояснить свою точку зрения? что значит отгребаешь по полной?

Ох, ну если не понимать, что order by не может делать то, что он делает а) линейно б) используя минимум памяти, то можно легко отгрести ситуацию, когда запрос в простгресе работает день, ты ждешь результата с утра, а потом обнаруживаешь утром, что он свалился, т.к. не хватило тупо не только рамы но и диска, чтобы датасет просортировать. Это реальный пример. Это конечно многие терабайты и вообще архитектурно там по-другому надо было делать, но вот если знать алгоритмы, то можно додуматься до «по-другому» еще до того, как уперся в реальные проблемы, и сэкономить месяц-другой.

когда запрос в простгресе работает день, ты ждешь результата с утра, а потом обнаруживаешь утром
На пне втором крутится сервер ?

:) Ну вот живое подтверждение просто!

Ладно, еще один пример, недавно один менеджер, не совсем понимающий сферу своих компетенций, проигнорировал предупреждения о том, что его алгоритм экспоненциальный, и пошел строить систему, утверждая, что уж железа вкинуть для него — не проблема. Жопа придет после нескольких месяцев (или лет, как повезет) разработки, если, конечно, она не загнется по другим причинам. Причем в самом начале на небольших тестовых объемах будет все хорошо. А на нормальных рабочих — нет. Менеджеру не надо писать код, для него новая система — это как для вас Array.sort(). А принимать решение — надо.

ну вы ведь сейчас о полной безграмотности говорите.

Самые яркие примеры, чаще всего, конечно, не так драматично, но все то же самое.

ну всё же вся эта информация о стоимости основных операций для основных структур данных — это можно сказать справочная информация. и ничего не мешает мне подсмотреть в интернете на сколько подходит для моих задач выбранная структура данных и если не подходит — подыскать другую.
в случае же с запросом — это полная безграмотность человека как sql разработчика и она имеет мало общего с топиком

Да, но для этого и нужно *понимать* идею того, что разные алгоритмы и структуры данных имеют разные trade offs. А если этого понимания нет, то такие вопросы даже и не возникнут.

ну я еще раз повторюсь. между знанием стоимости всех структур данных и незнанием, что у этих структур данных есть какая-то стоимость — пропасть.
вовсе не обязательно уметь писать с ходу идеальный код. достаточно уметь находить узкие места в неидеальном коде и иметь какие-то базовые понятия чтобы разобраться почему тут возникло тонкое место

Кроме того, в жабе собственно существуют всякие Arrays.sort и Collections.sort
И вместо них писать пузырьковую сортировку вручную считаеться большим моветоном.

И вместо них писать пузырьковую сортировку вручную считается большим моветоном.

А смысл в ней если проще написать приватную реализацию(класс) IComparer

А смысл в ней если проще написать приватную реализацию(класс) IComparer
Джуниоры (и не только) часто не знают об компараторах.

Разговор не об этом. Вам, как преподавателю, стоило бы это понимать.

Я полностью согласен с тем, что senior и выше обязан иметь профильное фундаментальное образование (или самообразование), которое включает в себя Алгоритмы и Структуры Данных, Дискретную Математику, Многопоточные и Распределенные Системы и т.д.
Но в каждый отдельный момент времени работа в J2EE — это попытка оживить Франкенштейна из кучи фреймворков (Hibernate, JAXB, Spring, Spring MVC, JAX-RS, ...). Тут скорее нужны паттерны (GoF, J2EE, Фаулер, ...), а не алгоритмы.
Просто защищаю честь мундира:). А то недоброжелатели создают образ явиста как некого глупого, ограниченного селянина (без знания структур данных).

Недавно писал контест, куча людей получило TLE из-за того, что Arrays.sort() может работать и квадрат.

«Знаю почему медленно работают большие приложения и умею это улучшать,»
Гы , так я тоже это знаю, как ускорить производительность. Нужно написать все на С !!!

только ассемблер, только хардкор!

Нифига. Правильнее всего переписать ТЗ, выкинув оттуда кучу чьих-то хотелок, которыми воспользуются пару раз от силы.

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

Никакая железка не спасет вас от чьих то кривых рук, если ктото засунул O(n*n) сортировку внутрь или линейный поиск подстрок или <подставьте свой учебный или слабый алгоритм>, то приростите хоть 10кратно железо, вы не получите необхоимой скорости выполнения

ктото засунул log(n*n) сортировку
это очень-очень-очень крутая сортировка, если что:)

Квадратичное время, крута сортировка? Ничего не путаем?

log(n*n)

это квадратичное время?

Логарифм по какому основанию не написано, расходимся

<facepalm>, видимо не выспался. сейчас поправлю, конечно же имел в виду О(n*n). спасибо

А ведь есть еще и О(n*n!) сортировка... :)

есть еще и О(n*n!) сортировка
не есть еще, а все известные сортировки такие

Обана, а я думал, что бинарная сортировка — известна. Я,внезапно, обладатель секретной сортировки O(log N)

Вам действительно очень повезло.
Вы первый человек который знает сортировку с такой временной оценкой в худшем случае.

Ну да, чукча посмотрел-подумал после того как отправил коммент, есть такой грех за мной. O(N log N) имелось ввиду. Так сильно съязвить хотелось, что своего бревна не заметил :)

O(N log N) имелось ввиду.
А твоя секретная сортировка stable & in-place?

Як мед так і ложкою

in-place, yes. Stability can be added, if necessary, without significant degradation of sorting time.

Может вы и обладатель секретной сортировки, но точно не обладатель знания, что такое O-большое:)

но точно не обладатель знания, что такое O-большое:)

Oh, really?! И что же изменилось в определении О-большого с конца восьмидесятых, когда я учился в универе?

А может Вы тогда объясните каким образом нужно сортировать массив чтобы для этого потребовалось n*n! (! = факториал) операций? Мой «секретный» алгоритм требует n^2 операций в худшем случае.

Википедия в помощь, для освежения знаний:)

Ты сам бы сходил туда сначала и почитал про быструю сортировку. Не учи дедушку кашлять.

Ты сам бы сходил туда сначала и почитал про быструю сортировку. Не учи дедушку кашлять.
Вот оно — невежество во всей красе:)

Ах да, ты ж Php developer, как-то я не обратил внимания поначалу... Ну поучи, поучи тогда. А то ведь дедушка старый, а кашлять толком не умеет.

Я может и php девелопер, а вы просто дурак, выпячивающий свое невежество напоказ.

Оппа. Даже так. То есть, по существу предмета ответить нечего, факториал считать не умеем, переходим к оскорблениям.

Ты может посчитаешь факториал для n=100, хотя бы. И прикинь, сколько будет работать такая сортировка, если, скажем, операция над одним элементом будет выполняться 1 мкс.?

По существу предмета я ответил выше, предложив пойти освежить знания о том, что такое О-большое.
Для дедушек в танке — O-большое — ограничение сверху.
т.е. n^2 -> O(n^2) и O(n^3) и O(n!)

Если нужно показать обе границы — нужно использовать биг-тета.
Другое дело, что исторически сложилось указывать в алгоритмах наиболее сильное ограничение сверху. Но это никак не отменяет того факта, что квиксорт ограничен по веремени факториалом сверху

квиксорт ограничен по веремени факториалом сверху

А вот за такое уже надо отвечать. А то приколупался к о-большому. Вики нам говорит «Худший случай даёт O(n²) обменов» (ru.wikipedia.org/...трая_сортировка) — опровергни или извиняйся.

Вы хотите сказать, что квиксорт не ограничен сверху факториалом?:)

Шутник, блин. Сам же сказал

исторически сложилось указывать в алгоритмах наиболее сильное ограничение сверху.

Давайте теперь везде указывать показательные функции или полиномы. Все будет формально верно, а по сути — издевательство.

Да нет, просто зарплату таким деятелям нужно платить «до 4000$».

n! < n*n, при n=2
Так что теоритически, на этом участке Вы не правы. А практически — никто не говорит о сложности алгоритма при таких числах :)

n! < n*n, при n=2
на самом деле в определении big-O, идет речь о некотором x0, после которого все работает:) Ну и не забываем о константе:)

O() - это характеристика производной, по сути, так что константа пофиг. Ну а x0 тут вроде не обсуждалось :)

обсуждалось big-O. И x0 и константа там есть.

Да это просто демагогия. О(f(n)) означает, что затраченное время не может рости быстрее чем f(n). Т.е. формально Kirill Sablin, конечно, прав, но смысла в завышенном ограничении нет.

Эт прям как у моего провайдера было — «скорость ДО 4мб. У вас меньше? ну значит всё ок».

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

От кривых рук — да. Но одни только прямые руки не стоят 4500. Если же дело только в объёме кода, например за счёт растягивания пунктуации, излишнего именования и прочего «структурного подхода» — то давайте говорить честно: на работе кода это не сказывается никак.

Однако согласен, редкий джун не напишет в код заветного слова synchronized. Избавление от подобных багов — задача лидера, и да, если человек умеет организовать чтобы их не появлялось — это дорого стоит. [потому что избавляет не только от этой, а от тысяч подобных проблем времени исполнения]

Единственная загвозка — самым существенным способностям сложно пройти через призму понимания HR. Почему: самые сильные скиллы задевают за живое самые неприятные моменты. А HR-ам свойственно позитивное мышление и улыбчатые разговоры.

С другой стороны, в Джине не обязательно собеседовать будет рекрутер. И с человеком который компетентен в ключевых скиллах — разговор состоится, и с вероятностью положительного исхода. Но ему-то не стоит говорить о «стоимости структур» :)

Увы, делить надо далеко не 2

В 50х, если ты разбирался в автомобилях и тонкостях их устройства, ты был крут и афигенен. Сейчас, если ты разбираешься в машинах, ты — автослесарь.

Знаете, что вообще пишут в техническом паспорте «Роллс-Ройса»?
«Если Ваша машина сломалась: ВАШ ВОДИТЕЛЬ ЗНАЕТ, ЧТО ДЕЛАТЬ».

«Обратитесь к вашему системному администратору»

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

Механики звездной болезнью не страдают.

шутки-шутками, но многие программисты действительно не задумываются над «стоимостью» структур и функций, а также не понимают основ параллелизации. Ведь и нагрузочные тесты проводятся ой как мало где. Да, я помню, преждевременная оптимизация, но ведь и перед релизом мало кто профайлер запускает!

И то, что как минимум половина из тех, кто называет себя программистами, таковыми не являются — тоже верно.

а также не понимают основ параллелизации.
Если под основами параллелизации подразумевается знание хотя бы принципов AMP или SMP, я уже не говорю про древнюю и ставшую вновь новомодной NUMA, то количество программеров можно делить смело на 200.

да фиг с ними, с типами доступа и вычеслительных систем — большинству программистов(особенно web) к этому действительно руки не придётся прикладывать. Но понимать чем грозит простой ядра, большое колличество потоков и какой будет толк от паралелизации части программы — всё таки стоит.

SMP vs MPP?)

MPP для программера выглядит гораздо проще.

Ну тут нечего возразить. Я не с точки зрения программера на это смотрю, но это я так... Всегда удивляли эти бесконечные баталии продавцов больших ящиков с целью втолкнуть в массы идею что их MPP(SMP) круче чем другие...

шутки-шутками, но многие программисты действительно не задумываются над «стоимостью» структур и функций
Зависит от задач.
Дубовой реализации через Arrays.sort часто очень достаточно как и для приложения, так и с точки зрения работодателя в плане стоимости кодерочка.
а также не понимают основ параллелизации.
Ну тут не то что «основы паралезации», а адекватно поразмышлять об избитых вещах вроде синхронизации и деадлоков — мало кто может... зато каждый синьйор с закрытыми глазами спринг подключит :-)
Дубовой реализации через Arrays.sort часто очень достаточно как и для приложения, так и с точки зрения работодателя в плане стоимости кодерочка.

Если недостаточно, то не так уж и сложно взять код другого. Если класс реализует IComparable то вообще нет проблем с заменой.

Если недостаточно, то не так уж и сложно взять код другого. Если класс реализует IComparable то вообще нет проблем с заменой.

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

Да сейчас в куске проекта что я делаю, очень хочется чтобы тупо согласились «докупить оперативки». Так как код использует где-то 18-20 байт на пиксель и 40 Мпикс картинкам гигабайта не хватает.

Сейчас приходится изобретать другой подход.

Видимо, это только для сортировок основанных на сравнении.

Назовите сортировку основанную не на сравнении? Кроме разве что объединения двух отсортированных массивов.

Ооо, профи алгоритмисты на марше. Про counting sort, radix sort не слышал?

А в чем преимущество radix sort перед heap sort

O(nlogn) по сути чаще всего лучше чем (nk), так как даже если ключ integer то k = 32, а 4 гигабайтные данные редко кто сортирует. Да и ключи сейчас в базах часто GUID (или внутренние вариации) вместо Integer. Так что в данном случае k может быть и 128.

Сounting sort Опять же специализированный алгоритм, используется например для подсчета гистограммы для определения предела методом Отса.

По сути и тот и другой алгоритм слишком специализированы и чаще всего являются неотделимой частью других алгоритмов.

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

Опять же, указанные тобой сортировки используются чаще всего в специализированных алгоритмах и являются их частью. Так что вне алгоритма их польза и знание о них сомнительно.

Можешь не оправдываться уже. Слишком поздно!

а поясните, как это О(d*n) у поразрядной сортировки «чаще всего» лучше, чем О(n*log(n)) у пирамидальной. Есть конечно один минус у поразрядной ( и у блочной в т.ч.) — это большой объем мало отличимых элементов вызывает сильную деградацию. Но и один плюс — линейное время.

Когда logn < d, т.е. например для чисел практически всегда, потому что нужно сортировать квинтилион лонгов что бы d было меньше logn.

Я говорил наоборот.

К примеру сортировка массива с 10^5 значений и ключом в 128 бит намного быстрее будет проводится сортировкой
с nlogn 10^5 * 17
вместо nk 10^5 * 128

Наверное, не стоит так сравнивать без учета констант и других факторов

Проблема в том, что человек может использовать сортировку, чтоб вытянуть минимальный элемент массива (ну а фигли — работает же).

Т.е. для многих программистов «мало строк» = «быстрый код». А что там «внутри» происходит — не задумываются

Та вы о совсем какихто индуских бідлокодерах говорите. Наши 23-х летние синьйоры вполне могут справиться с задачей нагугления стандартного встроенного метода поиска мин/макс через коллекции (для жабы, для других, думаю. тоже).

Назвал просто для примера.

Из реальной жизни — поиск по массиву, в часто используемой функции осуществлялся перебором по значениям (есть такая функция в php — in_array). Замена этой части кода на поиск по ключам (+1 строчка кода) дало х16 прирост производительности этой функции, и вдвое снизило нагрузку на сервер.

P.S. а «сениоры» были там разные. Некотором — даже много за 30. Но судя по тому, что вместо профайлеров использовались самописные таймеры — толку от этого мало.

Ну это ж похапэшники, что с них взять.

Я знал оочень крутого джавера (СТО крупных проектов, участник конференций), который свой сайт всё равно делал на пхп...

Так что — «всё не от питания, всё от воспитания».

P.S. это я ещё про случаи в .net бекенде не рассказывал просто. В одной компании была борьба за «создание пользователя меньше чем за секунду» (на пустом сервере) — перемудрили с количеством сообщений.

Я знал оочень крутого джавера (СТО крупных проектов, участник конференций),
Регалии мало говорят о мозге человека, особенно если это болтун на конференциях. Я в соседнем топике код создателя питона запостил как доказательство.
Регалии мало говорят о мозге человека, особенно если это болтун на конференциях
Зато унижение неизвестного человека говорит о мозге говорящего достаточно.

Я не работал с питоном, но по отзывам вполне вменяемый иснтрумент. За это, я бы простил создателю мелкие огрехи (ну а кто среди нас не без греха)

И да, ждём Ваши успешные продукты в тред

Зато унижение неизвестного человека говорит о мозге говорящего достаточно.
А неумение читать еще больше говорит о мозге человека. Я нигде твоего кореша не оскорблял, ты сам сделал свои выводы.
Я не работал с питоном, но по отзывам вполне вменяемый иснтрумент. За это, я бы простил создателю мелкие огрехи (ну а кто среди нас не без греха)
То что питон стал таким каким он есть заслуга очень большого числа людей, а регалии достались одному, который к тому же оказался гавнокодером. О чем и речь, регалии ничего не значат.
И да, ждём Ваши успешные продукты в тред
Ну жди.
Van Rossum is Python’s principal author, and his continuing central role in deciding the direction of Python is reflected in the title given to him by the Python community, Benevolent Dictator for Life
Но нам ведь пофиг на комьюнити, они ничего не знают...

P.S.

А неумение читать еще больше говорит о мозге человека
The phrase originated in 1995 with reference to Guido van Rossum, creator of the Python programming language.[1][2] Shortly after van Rossum joined the Corporation for National Research Initiatives (CNRI), it appeared in a follow-up mail by Ken Manheimer to a meeting trying to create a semi-formal group that would oversee Python development and workshops.
В 1995-ом году питон был кусочком кала, а “комьюнити” на “выборах” состояло из 8-и человек, и никаких выборов не было, один чел придумал название. П.С. Ну ты понел.
Я знал оочень крутого джавера (СТО крупных проектов, участник конференций), который свой сайт всё равно делал на пхп...

Инструмент инструменту рознь, редко есть смысл делать мелкий сайт на жабе, если можна за день накидать пыху.

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

быстрота, простота, дешовый хостинг (был), етц.

Так а где простота и быстрота? Что именно проще?

дешовый хостинг (был)

А почему был? Вроде и есть... Несколько месяцев назад интересовался вопросом, PHP/Python хостингов находилось гораздо больше, чем с поддержкой Java.

Спвременные дешевые хостинги — это vps, там хоть джава, хоть похапэ запускай.

Если я еще могу верить своим глазам и памяти, то shared хостинги с поддержкой исключительно похапэ/питона (и иногда — руби) были заметно дешевле, чем VPS.

Сейчас vps идут от 5 баксов. Да, можно сэкономить 2-3 бакса в месяц наверное на шаренном хостинге, но это же смешно просто.
К тому же есть еще ГАЕ, на котором вполне резвая бесплатная квота.

Главная прелесть пыхи(и других интерпретируемых) — время между внесением изменений и проверкой на сервере. + Возможность залезть и поправить откуда угодно.

Ну и да, готового для мелких нужд вроде больше

Ну править код на боевых серваках — сомнительное преимущество.

Ну мыж за мелко-блог говорим.

А за боевые проекты — я как вспомню «да-да, щас строчку поправил, через полчаса билд будет готов» — так в дрожь бросает. Хотя, если человек внимательный — то это не страшно

В джаве на самом деле тоже есть аналогичные технологии, которые можно при желании юзать, например это встроено из коробки в sbt, оно слушает изменения в файле, в бекграунде компилит их и деплоит в jvm.

Не буду спорить, не сталкивался с подобным на боевых серверах.

Кстати, как оно себя поведёт, если файл не скомпилируется?

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

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

Проблема в том, что человек может использовать сортировку, чтоб вытянуть минимальный элемент массива (ну а фигли — работает же).

За O(1) между прочим ) при постоянном поддержании сортированности коллекции. Хорошо при редких записях и частых чтениях

Ты в своем репертуаре, для этих целей придумали heap.

Ты прямо открыл для меня целый мир сакральных знаний

Опять троллишь в попытке скрыть вопиющие пробелы в образовании? Не получится!

Сарказм сарказмом, но heap из n элементов можно построить за O(n), а это не то же самое, что:

при постоянном поддержании сортированности коллекции

По сути да, минимальный элемент через order by и Linq

от 5300 : а не слипнется? народ реально страх потерял. В какой Европе он столько на руки зарабатывать собрался, я наверное в другой Европе живу?

в соседней ветке говорят что в Британии

ну где то после налогов так и получится, надо сказать 65К в Англии это очень круто.

В Англии если вы не вытягиваете деньги со своего СПД, а держите на счету, то налоги вы не платите. Вытягивать можно кажется до 3000 фунтов в месяц, тогда будет лишь 5%. А за то что осталось на СПД можно купить дом в кредит, оплатить медицину или образование детей, тоже не заплатив налоги. Correct me if I am wrong

интересный поворот, не знал.

А я, наоборот, готов порадоваться за парня.
Может он сейчас работает на $4500. И готов сменить работу, если предложат $800 с верху.
Разумный подход. Если получит сколько просит — значит молодец.

Не нужно удивляться большим запросам. Рынок всё сам отрегулирует.
Ну просит Java Junior $5K — это его право. Да хоть 10.
Если верит, что найдет такую работу — пусть ищет.
Не найдет — согласиться на меньше.

Ну просит Java Junior $5K — это его право. Да хоть 10.
Хіба джуніор?оО Написано: Team Lead, Architect, CTO

человек просит — сколько хочет. Работодатели платят — сколько готовы. При чем тут страх?

Дык, джин. Загадывать можно любое желание, хоть два мульйона в час.

В Москве меньше чем за 5к приличные программисты даже разговаривать не хотят, если конечно не аутсорсинг.

А Вы в Европу за зарплатой ехали, что ли?

я да, в 2000 нам с семьей нехватало на жизнь, зарплата на западе была в 15 раз больше. сегодня бы не поехал

Нельзя же настолько сидеть в танке.

Срочно доктора!
У него преждевременная оптимизация!!!11

преждевременная оптимизация
is root of evil
))

Падхади налетай, я тебе целую кучу продам за 250! Не вэришь, а дэрэво за 300?

>>Relocate в США или Европу.
Англійська сумнівна. Не звертаючи уваги на слова з різних мов (цим зараз всі балуються) — побудова речення досить крива; з точки зору обох мов.

В принципе еще можно ослабить требование «Программист, который не заботится, сколько стоит каждая структура данных — не программист». Ведь можно что-то и не припомнить. Но когда не припоминаешь, а объем данных большой, пойди проверь в справочнике

Ну да, не программист, а как щас это называется... говнокодер stuff engineer.

Массив — 3 бакса, куча — 9?

Свяжитесь с нами, если вам необходим поиск за О(n).

Возможен O(log n) за дополнительную плату, оговаривается отдельно.

Возможен O(log n) за дополнительную плату, оговаривается отдельно.

Без предварительной обработки не возможен. А вот определить когда О(n) дешевле чем O(log n) -это и есть чуйка программиста.

Маленькие вчерашние кучи по 3, большие сегодняшние кучи по 5.

представил себе линейный поиск в куче по 5 ))

Массив — 3 бакса, куча — 9?
Эт мы продаем или покупаем?©

Десять баксов за гектар! (или почём щас оперативка, напомните).
Так вот, этот таварищь предлагает давать ему 5 тонн баксов в месяц за разовую экономию 10 баксов? Макс, следующим проектом после Джина должен стать зажрались ДОУ-Зважені-та-щасливі.

Десять баксов за гектар! (или почём щас оперативка, напомните).

Обычная философия формошлепа. Пральна, зачем использовать моск, если можно докупить оперативки? Зачем вообще тогда парицца и делать переиспользуемый код? Можно докупить рабов — индусов — джунов и все копипейстить.

Никогда не видели, как датасеты растут экспоненциально, соответственно, и затраты на железо, в то время, как можно было бы избежать экспоненциалнього роста стоимости железа сделав несколько мелких правок, что покрыло бы стоимость найма инженера?

сделав несколько мелких правок
как все оказывается просто
как все оказывается просто

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

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

Обычная философия формошлепа. Пральна, зачем использовать моск, если можно докупить оперативки? Зачем вообще тогда парицца и делать переиспользуемый код? Можно докупить рабов — индусов — джунов и все копипейстить.

Та ладно вон уже компы по 16 терабайт ОЗУ на борту
habrahabr.ru/...bm/blog/150748

Скоро в каждом смартфоне по терабайту будет.

Угу. А тормозить будет, как яейчас. Как грицца, сколько явошарпею оперативки не дай, а сиравно тормозить будет.

Скоро в каждом смартфоне по терабайту будет.
Не факт что вся эта ОЗУ будет доступна приложению^ скорее далеко не вся.
Ну и куда более важный момент: проц там будет совсем не серверный,
а структуры данных — это не столько про размер данных в памяти (хотя это так же важно), сколько про обработку этих данных процессором (скорость доступа/выполнения действий).

Если эта философия в итоге даёт выгоду по деньгам — почему бы и нет?

Если эта философия в итоге даёт выгоду по деньгам — почему бы и нет?

Эта философия не дает особой выгоды исполнителю, т.к. он не поднимает свою рыночную стоимость. Именно посему в Украине сидит куча синиор — формошлепов, котоыре за бугром не потянут и на джуна. А компании, естессно, выгодно, если есть куча копеечного хлама, который можно дешево продать.

Не всегда «затраты на найм инженера» покрываются. Представим себе случай: есть проблемы с performance и/или capacity, которые можно решить либо переписыванием проблемного куска кода (~1 человеко-неделя программиста Васи) либо добавлением серверов к ферме (~$50K и проблема временно решена). Так вот, нередки случаи, когда неделя работы Васи в режиме реализации новых фич (вместо оптимизации производительности старого кода) дает выигрыш по деньгам гораздо больше, чем стоимость тех самых серверов.

Так вот, нередки случаи, когда неделя работы Васи в режиме реализации новых фич (вместо оптимизации производительности старого кода) дает выигрыш по деньгам гораздо больше, чем стоимость тех самых серверов.

Но ведь нередки и обратные случаи, ди?* А если бы программист ВАся еще и сразу правилньо писал, то и фиксить не пришлось, бы и докидывать 50к, нет?

Да, но я и не утверждал, что это происходит _всегда_ :) It depends. А насчет сразу сделать правильно... Представьте, что у вас есть стартап. Выстрелит-не выстрелит — неизвестно, но вы изначально оптимист и оптимизируете его под, скажем, 50К пользователей. Через несколько лет ваш стартап преобразуется в компанию с многомиллионными оборотами и ~5 млн. пользователей. Вот тут-то и начинаются проблемы с производительностью... Но если бы стартап изначально затачивался под 5 млн. пользователей, то он бы никогда не взлетел, поскольку это затачивание бы потребовало дополнительных полгода работы, за которые его сто раз обогнали бы конкуренты. Вопрос как раз в поиске баланса.

есть проблемы с performance и/или capacity, которые можно решить либо переписыванием проблемного куска кода ... либо добавлением серверов к ферме
Фишка в том что чтобы можно было решать проблемы можно было решать добавлением серваков — уже стоят немало в разработке, а если еще хочетсо линейного(+) масштабирования, то еще дороже.

Иногда можно написать такой код, что будет 10 запросов в сек, вместо 1000. И тогда математика такая — 1 машина или 100

Верно. Но в большиснвте случае квалификации мидла хватает чтобы такого не писать. Случаи где действительно нужны R&D скиллы в алгоритмах — редки, и лучше сразу искать работу в Гугле.

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

Если бы юзеру можно было добавить денег так же просто, как в программе задействовать лишних 100к оперативки — да, спецы в алгоритмах были бы вершиной эволюции и стоили бы столько денег. Пока что — алгоритмы и оптимизация это скорее административные навыки, чем навыки кодера. А вот неумение [нежелание] применять администраторов и их заниние на этапе разработки программ — к сожалению проблема вечная.

Доллар на старте проекта, и доллар после прихода пользователей и инвистиций — это совсем разные деньги :). Так что лучше выстрелить и потом нанимать крутых инженеров (а главное, на это будут деньги), чем годы пилить идеальный код на асме.

без крутых инженеров, пороха может не хватить

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

если я правильно помню, там было 2-е, писали 2 недели, и уже не далеко не студенты.

Ок, сделанная задача всегда выглядит проще. В любом случае согласитесь — это не сверх сложная задача, на которую надо нанимать сверхинженеров. Мидла — хватит с головой.

если продавать тушек тогда да, можно продать джуна по цене мидла

если на результат пофиг, можно делать как попало

Простите, в вашей паралельной реальности, для выполнения достаточной простой задачи (назовите в бете твитера/гроупона хоть одну сложную функцию), нужен специалист высшего класса?

Или и правда, у нас сениором считается тот, кто может джумлу поставить?

www.linkedin.com/...hina/46/756/aa6

Senior PHP developer
Softheme

Privately Held; 51-200 employees; Information Technology and Services industry

June 2012 — March 2013 (10 months) Ukraine

с вами все понятно))

Умница, у меня эта ссылка в профиле. Слив не засчитан

Так что лучше выстрелить и потом нанимать крутых инженеров (а главное, на это будут деньги), чем годы пилить идеальный код на асме.

Проэкты, и модели бизнаса разные бывают.
Можно попытаться «продать» твитор, который наколбашиваеться за пару недель.
А иногда у вас — предметная область, крупные заказчики, и сроки. На такой проект лутше сразу нанимать спецов, ибо г-код который вам зделают «„мидлы“» потом тупо не поддерживаемый будет. И в итоге вы проиграете.

Заказчики и «стартап» это уже понятия не совместимые. Давайте не путать, ладно?

Когда у вас есть заказчики — у вас сразу есть деньги. И сразу есть развернутое ТЗ.
Когда вы делаете стартап, у вас не так уж и много денег, и не очень понятно что надо сделать.

Стартап стартапу тоже рознь. Опять же таки, вы можете делать твитор, а можете, ворлд оф танкс.
Если ваши танки будут сходу тормозные и глючные, их у вас тупо никто не купит.

Я не отрицаю, что есть технологичные стартапы. Но во-первых их явное меньшинство (тот же амазон на старте был заурядным магазином), а во-вторых, даже технологические стартапы фокусируются вокруг одной фишки (поиск, распознавание, граф. движок). Согласитесь, пока у вас 100 первых пользователей, вам не нужен идеальный код на сервере. Даже если танки будут иногда подглючивать — не страшно, извинитесь, дадите бонусы, поправите.

Если же сразу нанимать хороших и, естественно, дорогих инженеров, то весьма вероятно вы «проедите» бюджет раньше создания прототипа, и тогда точно уже, никто никуда не поедет :)

Мое мнение, как программиста с некоторым опытом таково: В случае с твитором и амазоном, по мере роста числа пользователей не такая уж и проблема выкинуть ядро и написать все с ноля. В случае с теме же танками это будет проблематично. Танки, даже в прототипном варианте вы будете писать не неделю и не месяц. Может получиться гораздо дешевле написать «нормально» сразу.

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

Я работаю в 5м стартапе, из них в трёх на стадии рождения, и в двух «уже успешных»

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

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

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

Угу, только цена такого спеца несколько высше, чем программиста который хорошо знает структуры данных; не находите ? :-)

Конечно, это ведь и не программист в чистом виде уже.

Підписатись на коментарі