The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

JavaScript обогнал Java в рейтинге предпочтений разработчико..., opennews (??), 02-Фев-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


47. "JavaScript обогнал Java в рейтинге предпочтений разработчико..."  +/
Сообщение от Sw00p aka Jerom (?), 02-Фев-19, 17:01 
>>даст возможность заработать (больше)

им тогда не в Программисты, а в Предприниматели!

>>разработчики изучают

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

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

51. "JavaScript обогнал Java в рейтинге предпочтений разработчико..."  +/
Сообщение от Crazy Alex (ok), 02-Фев-19, 17:11 
точно прикалываешься
Ответить | Правка | Наверх | Cообщить модератору

55. "JavaScript обогнал Java в рейтинге предпочтений разработчико..."  +1 +/
Сообщение от Sw00p aka Jerom (?), 02-Фев-19, 17:17 
кхмммм, задам такой вот вопрос, существует ли такой алгоритм, который можно реализовать только на языке допустим javascript? Если нет, то в чем прикол?
Ответить | Правка | Наверх | Cообщить модератору

61. "JavaScript обогнал Java в рейтинге предпочтений разработчико..."  +/
Сообщение от Crazy Alex (ok), 02-Фев-19, 18:22 
Да я о другом. Ну ясно же, что большинство разработчиков зарабатывают этим деньги. Понятно, что вопрос "где платят больше" их интересует.

И просто "программных архитекторов", во-первых, мало (скорее, не бывает - те, кто проектирует, и код тоже пишут, и наоборот - все, кто прошёл дальше junior, не только кодят по указанию свыше, но и сами что-то проектируют в своей области ответственности), во-вторых - они тоже имеют свои языки/инструменты - UML и всё вокруг него, а отнюдь не блок-схемы на бумаге рисуют.

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

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

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

Ну вот серьёзно - это ж всё совершенно очевидные вещи, неужели их надо разжёвывать?

Ответить | Правка | Наверх | Cообщить модератору

66. "JavaScript обогнал Java в рейтинге предпочтений разработчико..."  +/
Сообщение от Sw00p aka Jerom (?), 02-Фев-19, 19:24 
>Понятно, что вопрос "где платят больше" их интересует.

Я бы перефразировал бы - "Где меньше делаешь и больше получаешь", так вот я и акцентировал, идти нужно в предприниматели.

>И просто "программных архитекторов", во-первых, мало

Их ровно столько сколько появилось фронтендеров)), помните времена когда бекенд и фронтенд был на одной шее?

>во-вторых - они тоже имеют свои языки/инструменты - UML и всё вокруг него, а отнюдь не блок-схемы на бумаге рисуют.

все начинается с чистого листа (ц)

>Вот лично я не знаю, что эффективнее

а собственно в чем проблема? не знание? или не желание знать? зачем использовать инструмент который однозначно не гарантирует эффективность? Приведу самый тупой пример из мира пхп, что "быстрее" строки обрамленные одинарными или двойными кавычками? ))))) Кто-то воскликнет про "спички" и т.д. (забыли про эту тему). А вот, что касается про данные (объем), то тут нужно обратится к асимптотике, оценке, и соглашусь, будут алгоритмы допустим "быстрые" (временная сложность), но "жручие" по памяти (пространственная сложность) и на оборот, "золотая середина" тоже есть, и собственно идеальные.


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

))) хорошее уточнение "скорости" (скорость написания кода), не придраться.


>И все компромиссы, с ними связанные ....

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

Приведу пример, чтобы была ясна мысль, допустим я решил одним прекрасным днем написать собственную ОСь, так сел и начал думать, что я должен знать и сделать. Допустим надумал, что нужно знать "от и до" машинную архитектуру (хотя бы одну), продумать архитектуру ОС, придумать ЯП, и т.д. Потом прикинул сколько я затрачу на это сил и меня это отпугнуло, почему? Думаю ответ очевиден, - чего ради?

1) Бабло заработать? - не эффективно. Бабла ради, буду искать компромиссы, а ну нафиг свою ОСь писать, можно и существующую взять и заработать на ней. Так я быстрей заработаю. И это все относится только ко мне лично, я один обо всем думаю.

2) Если по фану, то - правильный ответ, этим должна заниматься группа. Разве Торвальдс не это имел ввиду?
Думаете он начал писать ОСь ради бабла? Почему он не начал с создания ЯП, а сразу начал писать ОСь на Си, и то не сразу ОСь, а сначала с миниксом поигрался. Похоливарил с Э. Т.


>Ну вот серьёзно - это ж всё совершенно очевидные вещи, неужели их надо разжёвывать?

Человек идущий во всем на компромиссы, по вашему, очевидность? По мне, очевидно - человек стремящийся преодолевать трудности.

Ответить | Правка | Наверх | Cообщить модератору

96. "JavaScript обогнал Java в рейтинге предпочтений разработчико..."  +/
Сообщение от Crazy Alex (ok), 03-Фев-19, 14:41 
>>Понятно, что вопрос "где платят больше" их интересует.
> Я бы перефразировал бы - "Где меньше делаешь и больше получаешь", так
> вот я и акцентировал, идти нужно в предприниматели.

а чем это принципиально отличается от "выбора инструмента, который гарпнтиркет эффективность?"

>>И просто "программных архитекторов", во-первых, мало
> Их ровно столько сколько появилось фронтендеров)), помните времена когда бекенд и фронтенд
> был на одной шее?

Помню,-конечно, но а делу это не относится. Фронтэндер и проектирует, и код пишет, как и почти любой другой рпзрпботсик. И ссё - привязанное а совершенно конкретным условиям.

>>во-вторых - они тоже имеют свои языки/инструменты - UML и всё вокруг него, а отнюдь не блок-схемы на бумаге рисуют.
> все начинается с чистого листа (ц)

ну давай сначала ещё этот лист делать и алфавит изобретать? Хочешь эффективности - пользуйся инструментами и ограничивай контекст применения.

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

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

> Приведу самый
> тупой пример из мира пхп, что "быстрее" строки обрамленные одинарными или
> двойными кавычками? ))))) Кто-то воскликнет про "спички" и т.д. (забыли про
> эту тему). А вот, что касается про данные (объем), то тут
> нужно обратится к асимптотике, оценке, и соглашусь, будут алгоритмы допустим "быстрые"
> (временная сложность), но "жручие" по памяти (пространственная сложность) и на оборот,
> "золотая середина" тоже есть, и собственно идеальные.

Оно так работает, когда есть ты и голая железка. И то - начинаются вопросы про кэш, производительность i/o  и так далее. А когда есть рантайм, есть ос со своими фокусами (оверкоммит какой-нибудь) и прочее - единственный реалистичный подход - измерять. Я против оценки мложности совершенно ничего ге тмею, но это всё же простая модель, годная только для проствх случаев, которвх всё меньше.

>>Плюс - есть скорость написания кода, сложность тестирования, доступность инструментов и т.п.
> ))) хорошее уточнение "скорости" (скорость написания кода), не придраться.
>>И все компромиссы, с ними связанные ....
> Обычно понятие компромисс относится к личному, в группе нет понятия компромисса, в
> группе один человек по идее должен волноваться за свою "шестеренку", и
> ваша мысль о компромиссах, скорости, эффективности и деньгах - не применима
> для группы.

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

А компромисс "время на разработку против времени на мануальное тестирование против написания автотестов" - он групповой, как и вопрос удобства тнх, кто иишет связанные модули или будет админить продукт. Валом таких компромиссов.

> Приведу пример, чтобы была ясна мысль, допустим я решил одним прекрасным днем
> написать собственную ОСь, так сел и начал думать, что я должен
> знать и сделать. Допустим надумал, что нужно знать "от и до"
> машинную архитектуру (хотя бы одну), продумать архитектуру ОС, придумать ЯП, и
> т.д. Потом прикинул сколько я затрачу на это сил и меня
> это отпугнуло, почему? Думаю ответ очевиден, - чего ради?
> 1) Бабло заработать? - не эффективно. Бабла ради, буду искать компромиссы, а
> ну нафиг свою ОСь писать, можно и существующую взять и заработать
> на ней. Так я быстрей заработаю. И это все относится только
> ко мне лично, я один обо всем думаю.

Если конечная цель - решение конкретной задачи то тоже лучше существующую взять, как правило. Со всеми компромиссами, так как самому всё сделать - никаких сил не хватит.

> 2) Если по фану, то - правильный ответ, этим должна заниматься группа.
> Разве Торвальдс не это имел ввиду?
> Думаете он начал писать ОСь ради бабла? Почему он не начал с
> создания ЯП, а сразу начал писать ОСь на Си, и то
> не сразу ОСь, а сначала с миниксом поигрался. Похоливарил с Э.
> Т.

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

>>Ну вот серьёзно - это ж всё совершенно очевидные вещи, неужели их надо разжёвывать?
> Человек идущий во всем на компромиссы, по вашему, очевидность? По мне, очевидно
> - человек стремящийся преодолевать трудности.

Мы всё ещё о мейнстримной (читай - коммерческой) разработке? Или о хобби?


Ответить | Правка | Наверх | Cообщить модератору

101. "JavaScript обогнал Java в рейтинге предпочтений разработчико..."  +/
Сообщение от Sw00p aka Jerom (?), 03-Фев-19, 15:20 
>а чем это принципиально отличается от "выбора инструмента, который гарпнтиркет эффективность?"

и как собственно выбрать эффективный инструмент не перепробовав все доступные ?

>ну давай сначала ещё этот лист делать и алфавит изобретать?

в предыдущих темах я одному анониму объяснил, что мастер - делает свой инструмент, и катается на своем велосипеде.

>Хочешь эффективности - пользуйся инструментами и ограничивай контекст применения.

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

>что в любой сложной системе таких фокусов хватает

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

>И чем дальше - тем важнее, так каа сложность софта всё растёт.

Какая именно сложность? Временная или пространственная? Любую сложность нужно преодолевать, в этом суть. Убил "время" человека, считай убил человека (ц)

>Я против оценки мложности совершенно ничего ге тмею, но это всё же простая модель, годная только для проствх случаев, которвх всё меньше.

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


>Ну так шестерёнку можно тоже по-разному реализовать.

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

>И с разных проектах размер у них сильно разный. От отдельной фунции через рефакторинг модуля к отдельгой утилите.

Это все навеяно формализмом ЯП, будь один ЯП (асм), такого не было бы.

>Валом таких компромиссов.

А корней проблемы ?

>Если конечная цель - решение конкретной задачи то тоже лучше существующую взять, как правило. Со всеми компромиссами, так как самому всё сделать - никаких сил не хватит.

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

>к ней нет вагона готовых сторонних модулей

На все готовое

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

Легко говорить про компромиссы когда есть варианты, в 70-ых бы почитать ваши коменты.

>Мы всё ещё о мейнстримной (читай - коммерческой) разработке? Или о хобби?

Ну определим сначала, что к чему влечет, мейнстрим к хобби, или хобби к мейнстриму. ))

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру