titanix88

How do we know that these solutions don't exist in the training data? It is open secret that they have used pirated materials for training. Perhaps it plagiarized solutions from works of some obscure Belgian mathematician from the sixties, who did not get mainstream acceptance. I wouldn't be surprised if they also got access to mathematics done in the "defense contractor" setting from various three letter agencies.

Without a searchable index of training data, it is hard to put faith into these claims.

Looks like the author have not used software pipelining compiler directives with the kernel loops. AMD AIE architecture has 5 cycle load/store latency and 7 cycle FP unit latency. With software pipelining, they could have 5-10x speed up for long loops.

No. I am using Clojurescript for frontend. What I meant was that my strong point is server side programming and I lack experience and time to master all the nooks and cranies of programming in Javascript.

I built a voice broadcasting service as a side project in Clojure, built on top of freeswitch and Datomic. From low level library (freeswitch-clj) to API server and frontend SPA, all in Clojure(script). The whole system is approximately 32K SLOC, written over 3.5 years. I have tried similar projects with other stack, mainly with PHP+js and python+js. None went as far as this one. Although we are yet to make a profit, I am very satisfied with the whole development process and subsequent maintainability offered by Clojure. In frontend, we are using reframe + antd react UI library, along with other necessary glue libraries from npm.

Project website: https://www.dandydialer.com

SPA: https://app.dandydialer.com

API: https://api.dandydialer.com/public/swagger/index.html

Open source Freeswitch event socket library: https://github.com/titonbarua/freeswitch-clj

Clojure is not easy, but it is simple, as Rich Hicky explained. For the trivial projects, you won’t find yourself bulding products faster in this stack compared to others.

To feel productive, you need to amortize your time spent learning Clojure over the time saved building and maintaining complex, non-trivial projects.

I can’t say for Elm as I never tried it. But, as a mostly backend developer, moving from Javascript to Clojurescript was a huge enablement for me. I am a rather mediocre programmer in a two man team. Still, with Clojure/Clojurescript, I was able to make something I could only dream about before.

Clojure is a great language for small creative teams to achieve great(relatively) things. It's difficult to understand that from a startup mindset of hacker news where money is no problem and peace of mind is an after thought.

If you are a budget constrained individual living in a third world country with nothing to invest but your intellect and time, Clojure is a very good language. It lets you to - 1. Create relatively large systems without pulling your hair out. 2. Juggle between different projects with relative ease. Great for managing a projects in maintenance mode. Great for contractors with long term support contracts. 3. Realize your vision of a complete product with relatively low time and money.

Overall, it's a way of doing effective programming. It's probably not a good way of making money if the focus is to siphon investor money with a large team and millions of lines to show for.

I am building an interactive voice broadcasting solution as a SaaS at http://dandydialer.com . Back-end API is built on Clojure, Datomic and freeswitch. I am using Clojurescript, Reagent, Reframe and Re-com for the front-end. Deployment and system orchestration is built on LXD and Ansible.

Pardon the website, as there isn't much to see there. We are still in alpha stage. Yes, Clojure ecosystem has been a tremendous help in engineering the system. As a former python dev, I think Clojure made a whole lot of mandatory moving parts unnecessary - like celery and redis for designing such a system. Also, ditching Javascript+react ecosystem with better wrappers has been an absolute blast so far.

It's kind of funny to think about how web was supposed to be extensible with 'type' attribute for script and style tags,but everyone forgot to implement anything other than 'text/css' and 'application/javascript'. Why did it happen?

Yes, I did try to comprehend the NMG, but didn't ask for anyones help. But AFAIR, back then (mid 2015), the python specific parts of the packaging manuals were scattered between some presentations and loose documentation here and there. Thanks for the link though. I might get back to it.

Still, I believe that a robust system like debian could be achieved by more simpler means. It's packaging system is an invention of a different era and needs more streamlining to accommodate dynamic language developers. Python was invented in 90's and it's took 20+ years for debian to setup some serious guidelines for python developers. What if I want to package a software written in another dynamic language which was invented a month ago? These questions need to be addressed.

Disclaimer: I am not claiming that I could device a solution. Just that, despite my best intentions and best of efforts, I couldn't handle the difficulty of packaging.

This might be off-topic, but time to chime-in with my experience of packaging an open source software written in python.

Once, I spent a good deal of my time making a grammar-based phonetic transliterator engine for an Indic language. I was mostly a python developer with some prior experience in C and plain Make files. After a couple of rewrites, I was mostly happy with the results. Then was the time for packaging and making it a usable software. The application needed to install some files under root so that linux's input subsystem (IBus) could recognize them. Also, it dependent on some system packages(both python based and non-python based) like dictionaries for generating suggestions.

As I approached the problem, I learned that I had to learn autotools and a bunch of very debian specific scripts which were pretty much focused on packaging applications written in C. It was like an arcane magic. I would probably had to produce & package at least 10 software to make the return of investment on that knowledge. I also tried to use python's setuptools, which felt equally dirty without the benefit of generating a proper .deb package. The impedance mismatch of the whole packaging architecture and dynamic language ecosystem was soul crushing.

In the end, I wrote a python script which dumps the project in /opt and installs/uninstalls the system files and called it a day.

The end result was that user adoption of my software was very low. One reason for that might be the unusual way of installation(download a tar file, unzip and run a installer from command line).

Apparently imperceptible differences in latency can be felt vividly through break of habit.

A couple of years back, I didn't have any experience with online games and was introduced to a popular one by one of my friends. As we were playing some introductory matches, 400ms latency connection felt very instantaneous to me, while he felt super annoyed and advised me to change my ISP. Some months after changing my ISP and regularly playing the game, I could instinctively feel the difference between a 60ms connection and a 120ms connection.

One very important aspect of Clojure is lock-less, STM(software transactional memory) based concurrency that just works. In clojure, shared memory is readily available and with a few lines of code, you can get rid of entire third party projects typically used for in-memory caching, message-passing and background job processing. This is a huge win if you are writing long running server applications.

This! Try to implement a controlled task scheduler using multiprocessing and sooner or later you are going to hit some unexpected behavior, like - multiprocessing.Queue belly-upping for no reason, UNIX signals propagating throughout the process chain and killing them left and right, hitting some data/object which are not serializable etc. Getting multiprocessing to work right takes a LOT of careful efforts, which breaks the whole promise python.

I've since moved to clojure, which is a language designed with concurrency from ground up. Look at clojure's `atom` - it's basically what every beginning programmer expects from globally shared variables, minus the gymnastics of handling race conditions on your own.

Also, `core.async` is such a beautiful thing to work with for writing schedulers. Compared to this, python's asyncio is an unfunny joke.

I don't think python's GIL can be removed with ad-hoc locking. Nothing sort of complete re-implementation will do.