Я изучил много языков и, пожалуй, лучше других понимаю, что разные языки пригодны для разных целей. И лучше пользоваться всеми, чем потрясать каким-то одним со словами: «Вот язык-победитель».
Я изучил много языков и, пожалуй, лучше других понимаю, что разные языки пригодны для разных целей. И лучше пользоваться всеми, чем потрясать каким-то одним со словами: «Вот язык-победитель».
Чушь собачья. Нет никакого "разных целей". Никто не бегает от ассемблера к перлу, замастыривает что-то на JS и потом пыхтит в хаскеле — это всё влажные мечты студентиков, ничего толком в жизни не писавших.
На деле, чем МЕНЬШЕ в проекте языков, тем лучше. Более того — ЯОН для того и придумали, что большинство задач решается при помощи одного языка.
K>Чушь собачья. Нет никакого "разных целей". Никто не бегает от ассемблера к перлу, замастыривает что-то на JS и потом пыхтит в хаскеле — это всё влажные мечты студентиков, ничего толком в жизни не писавших. K>На деле, чем МЕНЬШЕ в проекте языков, тем лучше. Более того — ЯОН для того и придумали, что большинство задач решается при помощи одного языка.
1. Это не мечты студентиков, а слова Кнута или Брукса — не помню у кого читал.
Фраза примерно такая: нет ничего особенного в том, что программист в течение недели пишет на 5 разных языках.
2. Разные языки — для разных проектов, а не в одном проекте.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
K>>На деле, чем МЕНЬШЕ в проекте языков, тем лучше. Более того — ЯОН для того и придумали, что большинство задач решается при помощи одного языка. LVV>1. Это не мечты студентиков, а слова Кнута или Брукса — не помню у кого читал. LVV>Фраза примерно такая: нет ничего особенного в том, что программист в течение недели пишет на 5 разных языках.
Какие в то время были языки? Ассемблер, Си/Паскаль/Фортран, Форт, Пролог, Лисп. Не было фреймворков, лишь самые общие библиотеки.
Понятен, что в то время писать на 5 языках проблемой вообще не было. Сейчас же жесть полная в этом плане, не?
Здравствуйте, LaptevVV, Вы писали:
LVV>программист в течение недели пишет на 5 разных языках LVV>Разные языки — для разных проектов, а не в одном проекте
То есть это типичная ситуация, когда один программист в течении недели работает на 5ью разными проектами? По дню на проект? Вы программиста и студента(у которого каждая лаба — отдельный "проект") не путаете ?
R>Какие в то время были языки? Ассемблер, Си/Паскаль/Фортран, Форт, Пролог, Лисп. Не было фреймворков, лишь самые общие библиотеки.
Ну, тогда чел просто делал новый язык, если ему не хватало текущих...
С/ObjectiveC/С++/Паскаль/Смоллток не дадут соврать.
Мы в середине 80-х делали договор.
Сначала к PL-1 прикрутили Лисп.
Потом придумали новый язык. На PL-1+Lisp написали интерпретатор.
Потом на новом языке написали договор. R>Понятен, что в то время писать на 5 языках проблемой вообще не было. Сейчас же жесть полная в этом плане, не?
Зависит от объема проектов.
Не 5, но 2 вполне может быть.
Сейчас, мне представляется, подобная ситуация в веб.
Можно один относительно небольшой проект делать на php, фронт-енд можно писать на JS.
Или серверная и клиентская часть пишутся на разных языках, например.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Jack128, Вы писали:
J>То есть это типичная ситуация, когда один программист в течении недели работает на 5ью разными проектами? По дню на проект? Вы программиста и студента(у которого каждая лаба — отдельный "проект") не путаете ?
Характерно для мелких конторок с большими амбициями.
кт>Я изучил много языков и, пожалуй, лучше других понимаю, что разные языки пригодны для разных целей. И лучше пользоваться всеми, чем потрясать каким-то одним со словами: «Вот язык-победитель».
думаю нужно два яп — один динамический (можно взять cl) и один строго типизированный статический (типа haskell, но возможно что-то попроще типа F#),
elm как подмножесто хаскела для браузера.
си естественно остается как основа ОС.
Здравствуйте, Kolesiki, Вы писали:
K>Чушь собачья. Нет никакого "разных целей". Никто не бегает от ассемблера к перлу, замастыривает что-то на JS и потом пыхтит в хаскеле — это всё влажные мечты студентиков, ничего толком в жизни не писавших. K>На деле, чем МЕНЬШЕ в проекте языков, тем лучше. Более того — ЯОН для того и придумали, что большинство задач решается при помощи одного языка.
В проекте — да, суммарно — нет.
Вот по тем языкам, которые я знаю и пользуюсь или пользовался:
С — ядро линукс и драйвера, никто его не заменит там, где важна производительность и полный контроль за использованием памяти
С++ — кросс-платформенные GUI с умеренно-низким потреблением памяти
Java — серверные приложения. Если языки получше, но Java знают все и разработчиков найти легко
Kotlin — серверные приложения. Лучше Java, но сложнее найти разрабов и не все доверяют языку одной компании
Scala — серверные приложения. Сложнее Котлина, мало разработчиков, но лучшее решение для высококачественных приложений
Python — скрипты и автоматизация. Не требует компиляции, запускается мнгновенно, потребляет мало памяти, работает везде
JS — единственный выбор для современного и/или качественного UI в вебе.
C# — если нужно нативное приложение под винду, сложно выбрать что-то еще. Не на MFC же писать или насиловать юзеров электроном.
А теперь скажите, какой из этих языков лишний и не имеет право на существование.
scf>А теперь скажите, какой из этих языков лишний и не имеет право на существование.
С++ — кросс-платформенные GUI с умеренно-низким потреблением памяти(ибо есть ДИИИИИИИ!)
Kotlin — серверные приложения. Лучше Java, но сложнее найти разрабов и не все доверяют языку одной компании (деешевая подделка под скалу)
Scala — серверные приложения. Сложнее Котлина, мало разработчиков, но лучшее решение для высококачественных приложений(ибо ДОТТИИИИ!)
Python — скрипты и автоматизация. Не требует компиляции, запускается мнгновенно, потребляет мало памяти, работает везде(ибо убогий синтаксис и интепретатор).
Здравствуйте, varenikAA, Вы писали:
vsb>>А я думаю, что нужен ассемблер и Rust.
AA>ну, это уже очень узкая специализация. конечно и такие будут, я думал о массах.
Почему ты считаешь Rust узкой специализацией? По-мне это универсальный ЯП, пригодный для написания абсолютно любого софта, от драйверов до веб-страниц.
Здравствуйте, varenikAA, Вы писали:
AA>С++ — кросс-платформенные GUI с умеренно-низким потреблением памяти(ибо есть ДИИИИИИИ!)
На D можно писать кросс-платформенный гуй? Насколько я знаю, там даже рантайм не вылизан, не то чтобы кто-то родил качественную библиотеку для гуев или портировал Qt
Здравствуйте, vsb, Вы писали:
vsb>Почему ты считаешь Rust узкой специализацией? По-мне это универсальный ЯП, пригодный для написания абсолютно любого софта, от драйверов до веб-страниц.
блин, сложно сказать, в обществе к нему двойственное отношение.
Здравствуйте, scf, Вы писали:
scf>Здравствуйте, varenikAA, Вы писали:
AA>>С++ — кросс-платформенные GUI с умеренно-низким потреблением памяти(ибо есть ДИИИИИИИ!)
scf>На D можно писать кросс-платформенный гуй? Насколько я знаю, там даже рантайм не вылизан, не то чтобы кто-то родил качественную библиотеку для гуев или портировал Qt
DWT is a library for creating cross-platform GUI applications. It's a port of the SWT Java library from Eclipse. Current supported platforms are Windows, using Win32 and Linux, using GTK.
dlangui
Cross platform GUI for D. Layouts, styles, themes, unicode, i18n, OpenGL, widgets. Android support.
Вот эти два, им уж лет много. не уверен, что dwt поддерживает x64.
Здравствуйте, LaptevVV, Вы писали:
K>>Чушь собачья. Нет никакого "разных целей". Никто не бегает от ассемблера к перлу, замастыривает что-то на JS и потом пыхтит в хаскеле — это всё влажные мечты студентиков, ничего толком в жизни не писавших. K>>На деле, чем МЕНЬШЕ в проекте языков, тем лучше. Более того — ЯОН для того и придумали, что большинство задач решается при помощи одного языка. LVV>1. Это не мечты студентиков, а слова Кнута или Брукса — не помню у кого читал. LVV>Фраза примерно такая: нет ничего особенного в том, что программист в течение недели пишет на 5 разных языках. LVV>2. Разные языки — для разных проектов, а не в одном проекте.
Работа над несколькими разными проектами одновременно не очень хорошая идея. Но несколько языков для разных частей проекта вполне может использоваться, например:
C++ — сервер
Java — десктопный и мобильный клиент
JS — веб-морда
Но как правило, разные части проекта разные люди делают и количество языков, используемых в проекте, стараются уменьшить.
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, кт, Вы писали:
K>
K>Я изучил много языков и, пожалуй, лучше других понимаю, что разные языки пригодны для разных целей. И лучше пользоваться всеми, чем потрясать каким-то одним со словами: «Вот язык-победитель».
K>Чушь собачья. Нет никакого "разных целей". Никто не бегает от ассемблера к перлу, замастыривает что-то на JS и потом пыхтит в хаскеле — это всё влажные мечты студентиков, ничего толком в жизни не писавших. K>На деле, чем МЕНЬШЕ в проекте языков, тем лучше. Более того — ЯОН для того и придумали, что большинство задач решается при помощи одного языка.
K>Чушь собачья. Нет никакого "разных целей". Никто не бегает от ассемблера к перлу, замастыривает что-то на JS и потом пыхтит в хаскеле — это всё влажные мечты студентиков, ничего толком в жизни не писавших. K>На деле, чем МЕНЬШЕ в проекте языков, тем лучше. Более того — ЯОН для того и придумали, что большинство задач решается при помощи одного языка.
Разводить большую кучу языков в одном проекте, конечно, ни к чему, но два языка — очень часто встречающийся вариант.
Например, какое-нибудь ядро или движок пишется на компилируемом языке, а к нему прилагается набор скриптов на каком-нибудь скриптовом языке.
И это если не брать в расчет такие языки "не-совсем-программирования", как SQL с его разнообразными расширениями и языки шаблонов типа XSLT.
LVV>нет ничего особенного в том, что программист в течение недели пишет на 5 разных языках. LVV>Разные языки — для разных проектов, а не в одном проекте.
Эээх, Лаптев, Лаптев... Ты уж хоть иногда голову из своего рыбного педколледжа высовывай — ибо там, в реальной жизни, все ровно наоборот:
— Подавляющее большинство программистов пишут на 1-3 языках. "В течение недели на 5 разных языках" — нонсенс (и почти всегда следствие неправильной организации).
— В пределах одного проекта несколько разных языков — обычное дело.
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
LVV>>нет ничего особенного в том, что программист в течение недели пишет на 5 разных языках. LVV>>Разные языки — для разных проектов, а не в одном проекте. А> Эээх, Лаптев, Лаптев... Ты уж хоть иногда голову из своего рыбного педколледжа высовывай — ибо там, в реальной жизни, все ровно наоборот:
А ты хоть бы прочитал, кому я там возражал.
И ниже тоже — я предположил, что в вебе пишут в одном проекте на нескольких языках.
Что и подтвердили последующие участники.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
кт>Я изучил много языков и, пожалуй, лучше других понимаю, что разные языки пригодны для разных целей. И лучше пользоваться всеми, чем потрясать каким-то одним со словами: «Вот язык-победитель».
Здравствуйте, LaptevVV, Вы писали:
LVV>Фраза примерно такая: нет ничего особенного в том, что программист в течение недели пишет на 5 разных языках.
Я больше чем на двух языках одновременно не писал. И должен сказать, иногда это нехило напрягает. Например, если основной язык проекта Java, и ему требуется что-то от ОС. В таких случаях используют JNI. Мне довелось. Я знал, что синтаксис C и Java похожи, но не думал, что настолько. Правда, опыт написания JNI у меня небольшой. Возможно, привыкнуть надо. Вот если Фортран — Си или Си — Ассемблер, там все намного проще.
Речь идет об использовании двух или более языков в одном исполняемом модуле. exe или jar — неважно.
Книжку, точнее, брошюру, "Комплексирование программ в ОС ЕС" ты, конечно, читал.
K>Чушь собачья. Нет никакого "разных целей". Никто не бегает от ассемблера к перлу, замастыривает что-то на JS и потом пыхтит в хаскеле — это всё влажные мечты студентиков, ничего толком в жизни не писавших. K>На деле, чем МЕНЬШЕ в проекте языков, тем лучше. Более того — ЯОН для того и придумали, что большинство задач решается при помощи одного языка.
В проекте — да, возможно.
Но проектов то много. Или вы как начали в институте один так его до сих пор и пилите?
Здравствуйте, Аноним931, Вы писали:
А> Эээх, Лаптев, Лаптев... Ты уж хоть иногда голову из своего рыбного педколледжа высовывай — ибо там, в реальной жизни, все ровно наоборот: А> — Подавляющее большинство программистов пишут на 1-3 языках. "В течение недели на 5 разных языках" — нонсенс (и почти всегда следствие неправильной организации).
Это программисты недоученные, при чом тут Лаптев?
ansible, perl, python, bash, pwsh, go, js, jinja, lua — вот на этом вот я на прошлой неделе писал, если память не подвела. Всмысле не ровным слоем размазано. А на чём-то несколько дней подряд, а на чёс-то пару строк поправил.
Здравствуйте, scf, Вы писали:
scf>Вот по тем языкам, которые я знаю и пользуюсь или пользовался: scf>С — ядро линукс и драйвера, никто его не заменит там, где важна производительность и полный контроль за использованием памяти scf>С++ — кросс-платформенные GUI с умеренно-низким потреблением памяти scf>Java — серверные приложения. Если языки получше, но Java знают все и разработчиков найти легко scf>Kotlin — серверные приложения. Лучше Java, но сложнее найти разрабов и не все доверяют языку одной компании scf>Scala — серверные приложения. Сложнее Котлина, мало разработчиков, но лучшее решение для высококачественных приложений scf>Python — скрипты и автоматизация. Не требует компиляции, запускается мнгновенно, потребляет мало памяти, работает везде scf>JS — единственный выбор для современного и/или качественного UI в вебе. scf>C# — если нужно нативное приложение под винду, сложно выбрать что-то еще. Не на MFC же писать или насиловать юзеров электроном.
scf>А теперь скажите, какой из этих языков лишний и не имеет право на существование.
В каком смысле "лишний"? Если речь про идеальный мир, то в этом списке всё лишнее — в моем идеальном мире я бы все это выкинул, а добавил D, TypeScript, Rust и Ruby.
Про "не имеет права на существование" тоже не вполне понятно. Раз существует, значит имеет право. Хотя нет, жабаскрипт права на существование не имеет.
ARK>В каком смысле "лишний"? Если речь про идеальный мир, то в этом списке всё лишнее — в моем идеальном мире я бы все это выкинул, а добавил D, TypeScript, Rust и Ruby.
Здравствуйте, scf, Вы писали:
scf>Мечты, мечты. Язык для веба мог бы быть намного лучше, но фарш невозможно провернуть назад. JS — это объективная реальность и замены ему нет.
dart?
Здравствуйте, Kolesiki, Вы писали:
K>Чушь собачья. Нет никакого "разных целей". Никто не бегает от ассемблера к перлу, замастыривает что-то на JS и потом пыхтит в хаскеле — это всё влажные мечты студентиков, ничего толком в жизни не писавших.
Как правило, чем больше проект, тем больше языков в нём будет использоваться!
Кроме основного будет использваться SQL для бд, REGEX для строк, bash, powershell для утилит командной строки. Еще будет нечто для билдов. Если есть серьезный UI, то как правило там тоже будет что-нибудь своё, вплоть до какого css или его подобия.
Если в приложении есть автоматизация, то она будет на каком нибудь языке, типа groovy, js, lua, lisp или еще что, что бы эндюзеры могли худо-бедно писать свои собственные скрипты.
Если есть проектирование аппаратуры, то будет Verilog, VHDL и тд.
K>На деле, чем МЕНЬШЕ в проекте языков, тем лучше. Более того — ЯОН для того и придумали, что большинство задач решается при помощи одного языка.
Большинтсво, но далеко не все.
Более того, любой фремворк это прежде всего не функционал, а расширение языка библиотечным способом или даже язык в языке, internal dsl.
Здравствуйте, AlexRK, Вы писали:
ARK>В каком смысле "лишний"? Если речь про идеальный мир, то в этом списке всё лишнее — в моем идеальном мире я бы все это выкинул, а добавил D, TypeScript, Rust и Ruby.
Зачем в идеальном мире одновременно TS и Ruby, D и Rust?
Здравствуйте, Ikemefula, Вы писали:
I>Как правило, чем больше проект, тем больше языков в нём будет использоваться!
Тут верно, почти
I>Кроме основного будет использваться SQL для бд, REGEX для строк, bash, powershell для утилит командной строки. Еще будет нечто для билдов. Если есть серьезный UI, то как правило там тоже будет что-нибудь своё, вплоть до какого css или его подобия. I>Если в приложении есть автоматизация, то она будет на каком нибудь языке, типа groovy, js, lua, lisp или еще что, что бы эндюзеры могли худо-бедно писать свои собственные скрипты.
Идея дать удочку эндюзером провалилась с треском ещё во времён 1С 6.0! Скрипты прижились, этого не отнять. Но их пилит всё равно отдельно выделенный для этого чел, а не эндюзер.
I>Если есть проектирование аппаратуры, то будет Verilog, VHDL и тд.
Всё вышесказанное — всё не верно. Так-то, я тоже знаю много страшных слов... Вот поручись — это всё делает один чел? Два? Пять? Или всё же отдельные КОМАНДЫ из нескольких DBA, нескольких админов и нескольких программистов?
Здравствуйте, Rhino, Вы писали:
I>>Кроме основного будет использваться SQL для бд, REGEX для строк, bash, powershell для утилит командной строки. Еще будет нечто для билдов. Если есть серьезный UI, то как правило там тоже будет что-нибудь своё, вплоть до какого css или его подобия. I>>Если в приложении есть автоматизация, то она будет на каком нибудь языке, типа groovy, js, lua, lisp или еще что, что бы эндюзеры могли худо-бедно писать свои собственные скрипты. R>Идея дать удочку эндюзером провалилась с треском ещё во времён 1С 6.0! Скрипты прижились, этого не отнять. Но их пилит всё равно отдельно выделенный для этого чел, а не эндюзер.
MS Office, понятно, ты не использовал? https://docs.microsoft.com/en-us/microsoft-365/admin/manage/manage-office-scripts-settings?view=o365-worldwide
САПР тоже не в курсе?
В разработке приходится писать и на таких скриптах, такой вот факт.
I>>Если есть проектирование аппаратуры, то будет Verilog, VHDL и тд. R>Всё вышесказанное — всё не верно. Так-то, я тоже знаю много страшных слов... Вот поручись — это всё делает один чел? Два? Пять? Или всё же отдельные КОМАНДЫ из нескольких DBA, нескольких админов и нескольких программистов?
Один человек. Нет нужды делегировать простой запрос DBA. Более того, такие профессии редкость, бывают только на крупных проектах.
И билд-скрипт написать для своего проекта это так же обязанность разработчика. И фиксануть всякие баш-скрипты для деплоя или сборки докер-имаджа и много чего еще проще одному разработчику.
А вот что посерьезнее, тогда уже делегируется тем же девопсам.
Здравствуйте, Ikemefula, Вы писали:
R>>Идея дать удочку эндюзером провалилась с треском ещё во времён 1С 6.0! Скрипты прижились, этого не отнять. Но их пилит всё равно отдельно выделенный для этого чел, а не эндюзер. I>MS Office, понятно, ты не использовал? САПР тоже не в курсе?
Сорян, с 1С неудачный пример был I>В разработке приходится писать и на таких скриптах, такой вот факт.
Скажем так: напиасние скриптов в разработке — это, имхо, разовые задачи. Настроил/сделал и забыл. А дальше уже педалишь код. В приведённых тобой примерах (и моём) скриптописание не совсем является разработкой с точки зрения программирования.
I>>>Если есть проектирование аппаратуры, то будет Verilog, VHDL и тд. R>>Всё вышесказанное — всё не верно. Так-то, я тоже знаю много страшных слов... Вот поручись — это всё делает один чел? Два? Пять? Или всё же отдельные КОМАНДЫ из нескольких DBA, нескольких админов и нескольких программистов? I>Один человек. Нет нужды делегировать простой запрос DBA. Более того, такие профессии редкость, бывают только на крупных проектах.
Не, ну если партия скажет надо — то конечно. Да и лет 10+ назад мне в радость было и швец и жнец быть. А сейчас уже не в радость. Не стал бы работать там, где несколько ЯВУ в проде.
I>И билд-скрипт написать для своего проекта это так же обязанность разработчика. И фиксануть всякие баш-скрипты для деплоя или сборки докер-имаджа и много чего еще проще одному разработчику. I>А вот что посерьезнее, тогда уже делегируется тем же девопсам.
Мне лично сложно переключаться между, например, Шапром и Явой, хотя ситуация складывается так, что пишу на них попеременно. Полдня-день уходит на вспоминание моторных навыков. Поэтому у нас скриптами и всей обвязкой с деплоем занимаются специальные люди, за что им большое спасибо От меня же требуется только Мавен и норм.
Здравствуйте, Rhino, Вы писали:
I>>MS Office, понятно, ты не использовал? САПР тоже не в курсе? R>Сорян, с 1С неудачный пример был I>>В разработке приходится писать и на таких скриптах, такой вот факт. R>Скажем так: напиасние скриптов в разработке — это, имхо, разовые задачи. Настроил/сделал и забыл. А дальше уже педалишь код. В приведённых тобой примерах (и моём) скриптописание не совсем является разработкой с точки зрения программирования.
Разовых задач не бывает — то миграция, то новые требования, то новые объемы данных, на все случаи скрипт написать невозможно, приходится майнтейнить. Вот прямо сегодня влез в groovy, ненамного, но кое что пришлось подфиксить.
I>>Один человек. Нет нужды делегировать простой запрос DBA. Более того, такие профессии редкость, бывают только на крупных проектах. R>Не, ну если партия скажет надо — то конечно. Да и лет 10+ назад мне в радость было и швец и жнец быть. А сейчас уже не в радость. Не стал бы работать там, где несколько ЯВУ в проде.
Мавен — вполне себе язык. Билд-скрипты тоже будешь делегировать? А сборку доккер имеджа?
I>>И билд-скрипт написать для своего проекта это так же обязанность разработчика. И фиксануть всякие баш-скрипты для деплоя или сборки докер-имаджа и много чего еще проще одному разработчику. I>>А вот что посерьезнее, тогда уже делегируется тем же девопсам. R>Мне лично сложно переключаться между, например, Шапром и Явой, хотя ситуация складывается так, что пишу на них попеременно. Полдня-день уходит на вспоминание моторных навыков. Поэтому у нас скриптами и всей обвязкой с деплоем занимаются специальные люди, за что им большое спасибо От меня же требуется только Мавен и норм.
Здравствуйте, Kolesiki, Вы писали:
K>На деле, чем МЕНЬШЕ в проекте языков, тем лучше. Более того — ЯОН для того и придумали, что большинство задач решается при помощи одного языка.
Однако трудоемкость разработки на разных языках разная. Вот возьмем самый популярный в России язык 1С. Что то там сделать тривиальное, но нестандартное для 1С, по сравнению с нормальными языками — умножай трудозатраты на 10. А то и на 100. А возьмешь язык с минимальной трудоемкостью, так блин тормозит все и памяти жрет до фига, стартует долго. Берешь язык который из железа в состоянии выжать все — трудоемкость некоторых задач получается покруче чем на 1С. Когда у тебя денег неограничено, ты можешь взять один язык. Например JS. Тормозит, да и фиг с ним, вместо одного сервака поставим кластер из тысячи серверов, делов то. Зато все его знают и любят, а те, кто динамическую типизацию не любят — те устаревшие динозавры, не понимающие в современном программировании .
Здравствуйте, ути-пути, Вы писали:
УП>Здравствуйте, Sharov, Вы писали:
S>>TS?
УП>А он где-нибудь непосредственно исполняется? Потому что если единственный вариант — компиляция в ЖС, то он его никогда полностью не заменит.
А ЯВУ где-то исполняется или исполняется ассемблер(маш. команды)? ЖС такой же веб-ассебмлер. Почему
от ассемблера ушли,а от жс не получится?
Здравствуйте, Sharov, Вы писали:
S>А ЯВУ где-то исполняется или исполняется ассемблер(маш. команды)? ЖС такой же веб-ассебмлер. Почему S>от ассемблера ушли,а от жс не получится?
Другая разница в уровнях абстракции. TS в небольших задачах не имеет заметных преимуществ перед ЖС. А на ассемблере и Hello World — та еще песня.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Sharov, Вы писали:
S>А ЯВУ где-то исполняется или исполняется ассемблер(маш. команды)?
Компилируется обычно не в ассемблер, а в объектный код (маш. команды), он выполняется
S>ЖС такой же веб-ассебмлер.
Никакой он ассемблер. Точно такой же ЯВУ, ну только несуразностью от многих других отличающийся.
Здравствуйте, ути-пути, Вы писали:
УП>Здравствуйте, Sharov, Вы писали:
S>>А ЯВУ где-то исполняется или исполняется ассемблер(маш. команды)? ЖС такой же веб-ассебмлер. Почему S>>от ассемблера ушли,а от жс не получится?
УП>Другая разница в уровнях абстракции.
При чем здесь это?
УП>TS в небольших задачах не имеет заметных преимуществ перед ЖС. А на ассемблере и Hello World — та еще песня.
Для проектов json туда/json обратно возможно. А для больших веб проектов чем плох TS?
Здравствуйте, pagid, Вы писали:
S>>ЖС такой же веб-ассебмлер. P>Никакой он ассемблер. Точно такой же ЯВУ, ну только несуразностью от многих других отличающийся.
Именно что ассемблер, попробуйте от него уйти. Т.е. где-то там глубоко все равно будет js.
Здравствуйте, Sharov, Вы писали:
УП>>TS в небольших задачах не имеет заметных преимуществ перед ЖС. А на ассемблере и Hello World — та еще песня.
S>Для проектов json туда/json обратно возможно. А для больших веб проектов чем плох TS?
Здравствуйте, ути-пути, Вы писали:
S>>Для проектов json туда/json обратно возможно. А для больших веб проектов чем плох TS? УП>Ничем не плох. Но речь-то о полной замене
Здравствуйте, Sharov, Вы писали:
S>Почему TS не может полностью заменить жс? Как разница во что он там будет компилироваться?
Потому что жс я с телефона напишу/поправлю, и он будет без всяких транспилеров, бабелей, вебпаков и прочей хрени работать. И такие случаи никуда не денутся. Тут для замены нужна прямая поддержка ТС браузерами, а про нее пока даже разговоров не идет.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, ути-пути, Вы писали:
S>>Почему TS не может полностью заменить жс? Как разница во что он там будет компилироваться? УП>Потому что жс я с телефона напишу/поправлю, и он будет без всяких транспилеров, бабелей, вебпаков и прочей хрени работать. И такие случаи никуда не денутся. Тут для замены нужна прямая поддержка ТС браузерами, а про нее пока даже разговоров не идет.
А в чем проблема поправить и перекомпилировать? Т.е. тут проблема настроить соотв. инфраструктуру?
Здравствуйте, ути-пути, Вы писали:
S>>А в чем проблема поправить и перекомпилировать? Т.е. тут проблема настроить соотв. инфраструктуру? УП>Разумеется проблема, когда кода всего 10 строчек, а инфраструктуры для них на сотни мегабайт и конфигов в 3 раза больше этого кода.
А в чем будет разница для жс на текущей день за исключение одного лишнего шага в виде транспиляции?
По идее все то же самое и будет, та же инфраструктура на 10Мб.
