Программирование[11]

Just.Doit написал 8 минут назад:

каким образом? джава шарп хаскель - высокоуровневые

ты что-то вообще не то понял, лул

Я, надеюсь, ты в курсе, что компилятор си++ тоже генерирует промежуточный код, который затем превращается в машинный. Только для Java по дефолту приложение распространяется в этом промежуточном байт коде, а си++ превращает сразу в машинный код. Но при желании можно в си++ использовать JIT компиляцию, как в Java.

Grohuf написал 1 минуту назад:

Я, надеюсь, ты в курсе, что компилятор си++ тоже генерирует промежуточный код, который затем превращается в машинный. Только для Java по дефолту приложение распространяется в этом промежуточном байт коде, а си++ превращает сразу в машинный код. Но при желании можно в си++ использовать JIT компиляцию, как в Java.

я в курсе

надеюсь что ты в свою очередь в курсе что джаву/скалу/шарп можно компилировать в машинные коды ahead of time и иметь простой бинарник точно также как плюсы

Just.Doit написал Только что:

Grohuf написал 2 минуты назад:

Я, надеюсь, ты в курсе, что компилятор си++ тоже генерирует промежуточный код, который затем превращается в машинный. Только для Java по дефолту приложение распространяется в этом промежуточном байт коде, а си++ превращает сразу в машинный код. Но при желании можно в си++ использовать JIT компиляцию, как в Java.

я в курсе

надеюсь что ты в свою очередь в курсе что джаву/скалу/шарп можно компилировать в машинные коды ahead of time и иметь простой бинарник точно также как плюсы

 

Так почему Java высокоуровневый, а C++ - нет?

GoldRobot написал 11 минут назад:

Тогда жду критерии высокоуровневого и низкоуровневого

четких не будет, тк это фази термин на уровне базворда.

примерные такие:

в основном используется для байтоебства - низкоуровневый

все остальное - высокоуровневый

Grohuf написал 3 минуты назад:

Так почему Java высокоуровневый, а C++ - нет?

я уже писал почему

потому что основные сценарии использования разные

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

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

Кстати, в Java есть всякие мелкие фишки, типа как в си++, что можно написать:

str = str1+str2+str3

или

str = Concat(str1, str2, str3);

и вторая реализация быстрее работает

?

Grohuf написал Только что:

Кстати, в Java есть всякие мелкие фишки, типа как в си++, что можно написать:

str = str1+str2+str3

или

str = Concat(str1, str2, str3);

и вторая реализация быстрее работает

?

да

точнее как. изначально да.

но ты не знаешь как у тебя JIT оптимизирует. он может догадаться и нагенерить код который будет на твоей нагрузке быстрее работать

Grohuf написал 1 минуту назад:

и вторая реализация быстрее работает

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

Just.Doit написал 7 минут назад:

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

Потому что, там, блять, НЕТ статических типов?

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

У меня вот дилема. 

У меня есть система в ней по сути два крупных домена данных. Один домен это приложения, товары в приложениях и тд и тп.

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

Естественно все это сегрегировано по разным рестам /applications и /templates

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

И я хуй знает на каком уровне эти 2 домена должны соединяться.

Грубо говоря 

1) Слой контроллера приложений (Контроллер приложений вызывает сервис приложений, потом сервис шаблонов)

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

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

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

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

из топика понял, что шишарп это низкоуровневый язык, тк в нем есть структуры, которые почти RAII, и fixed, который дает сырые указатели

Index написал 5 минут назад:

У меня вот дилема. 

У меня есть система в ней по сути два крупных домена данных. Один домен это приложения, товары в приложениях и тд и тп.

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

 

Естественно все это сегрегировано по разным рестам /applications и /templates

  Offtopic

Хотя применение шаблона к приложению я сделал как 

@Post("/{applicationId}/templates/{templateId}") чисто потому что я хуй знает как это сделать не вводя отдельный сервисный домен. Хотя блять возможно его и стоило ввести исходя из текста ниже.

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

И я хуй знает на каком уровне эти 2 домена должны соединяться.

Грубо говоря 

1) Слой контроллера приложений (Контроллер приложений вызывает сервис приложений, потом сервис шаблонов)

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

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

 

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

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

 

  Показать содержимое

или сделать блять сервисный домен который будет хендлить и применение шаблона к приложению

и обновление двух доменов с хэпенс бефор

 

выглядит как будто они у тебя и не должны были быть в 2 разных доменах, тк между ними двунаправленная связь, которую ты теперь не знаешь как разбить (ведь это и невозможно)

GoldRobot написал 22 минуты назад:

Потому что, там, блять, НЕТ статических типов?

дак есть чел

ты в какой деревне программированию учился?

Grohuf написал 21 минуту назад:

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

дак не приходится) в 99% случаев

Index написал 20 минут назад:

Грубо говоря 

1) Слой контроллера приложений (Контроллер приложений вызывает сервис приложений, потом сервис шаблонов)

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

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

у тебя какое-то ооп головного мозга

Kant написал 9 минут назад:

Index написал 16 минут назад:

У меня вот дилема. 

У меня есть система в ней по сути два крупных домена данных. Один домен это приложения, товары в приложениях и тд и тп.

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

 

Естественно все это сегрегировано по разным рестам /applications и /templates

  Offtopic

Хотя применение шаблона к приложению я сделал как 

@Post("/{applicationId}/templates/{templateId}") чисто потому что я хуй знает как это сделать не вводя отдельный сервисный домен. Хотя блять возможно его и стоило ввести исходя из текста ниже.

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

И я хуй знает на каком уровне эти 2 домена должны соединяться.

Грубо говоря 

1) Слой контроллера приложений (Контроллер приложений вызывает сервис приложений, потом сервис шаблонов)

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

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

 

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

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

 

  Показать содержимое

или сделать блять сервисный домен который будет хендлить и применение шаблона к приложению

и обновление двух доменов с хэпенс бефор

 

выглядит как будто они у тебя и не должны были быть в 2 разных доменах, тк между ними двунаправленная связь, которую ты теперь не знаешь как разбить (ведь это и невозможно)

Она не совсем двунаправленная. 

Одно направление шаблон -> (применяется к) -> приложение.

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

Т.е с точки зрения внешнего управления есть явная первая связь.

А по волшебной кнопке мне нужно по сути тригернуть вторую.

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

@Controller("/templates")
...
@Put("/{id}") Mono<Template> updateTemplate(@PathVariable Integer id, @Body TemplateRefresh templateRefresh)

Просто блять не атомарно и уебищно выглядит. 

Index написал 21 минуту назад:

У меня вот дилема. 

У меня есть система в ней по сути два крупных домена данных. Один домен это приложения, товары в приложениях и тд и тп.

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

 

Естественно все это сегрегировано по разным рестам /applications и /templates

  Offtopic

Хотя применение шаблона к приложению я сделал как 

@Post("/{applicationId}/templates/{templateId}") чисто потому что я хуй знает как это сделать не вводя отдельный сервисный домен. Хотя блять возможно его и стоило ввести исходя из текста ниже.

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

И я хуй знает на каком уровне эти 2 домена должны соединяться.

Грубо говоря 

1) Слой контроллера приложений (Контроллер приложений вызывает сервис приложений, потом сервис шаблонов)

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

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

 

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

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

 

  Скрыть содержимое

или сделать блять сервисный домен который будет хендлить и применение шаблона к приложению

и обновление двух доменов с хэпенс бефор

 

но вообще сделай контроллер под эту задачу и дергай там оба метода

всё

2 хттп колла это рак ебаный, тк это по сути одно действие бекенда и должно быть атомарным

Just.Doit написал 2 минуты назад:

у тебя какое-то ооп головного мозга

Это не ООП это скорее

https://en.wikipedia.org/wiki/GRASP_(object-oriented_design)

Just.Doit написал 2 минуты назад:

дак есть чел

ты в какой деревне программированию учился?

Ты на полном щас серьезе не можешь отличить тип переменной, от тайп хинта/коментария?

Index написал 5 минут назад:

Just.Doit написал 9 минут назад:

у тебя какое-то ооп головного мозга

Это не ООП это скорее

https://en.wikipedia.org/wiki/GRASP_(object-oriented_design)

object-oriented_design - это и есть ООП

GoldRobot написал 4 минуты назад:

Ты на полном щас серьезе не можешь отличить тип переменной, от тайп хинта/коментария?

huh?

в контексте статической валидации типов - это одно и тоже

либо я не понял твоего тейка

Кароче индекс.

вопрос в том как ты об этом все думаешь

если у тебя само основное дейсвтие - это просто обновить то кидай в контроллер то чего обновляется

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

если ты хочешь бекенду сказать именно - обнови И пересчитай - то тогда отдельный контроллер

Ну валидация типа при компиляции/выполнении - это не тоже самое, что статический тип. Ибо в языке с динамической типизацией нужно использовать переменные что-то вроде variant, которые занимают порядка 16 байтов, когда на плюсах обычный int занимает 4 байта.

Grohuf написал 2 минуты назад:

которые занимают порядка 16 байтов, когда на плюсах обычный int занимает 4 байта.

сука

ты вообще не туда

ребята, вы знакомы с таким разделом знаний как теория типов?

Just.Doit написал 9 минут назад:

Grohuf написал 10 минут назад:

которые занимают порядка 16 байтов, когда на плюсах обычный int занимает 4 байта.

сука

ты вообще не туда

 

ребята, вы знакомы с таким разделом знаний как теория типов?

 

Я самоучка. Знаю только про теорию большого взрыва. Рекомендую первые два сезона