Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "why can't they just use lua?"
-
curl cheat.sh — get an instant answer to any question on (almost) any programming language from the command line
tldr
do curl cht.sh/go/execute+external+program to see how to execute external program in go
And this question: why I actually should I start the browser, and the browser has to downloads tons of JS, CSS and HTML, render them thereafter, only to show me some small output,
some small text, number or even some plot. Why can't I do a trivial query from the command line
and instantly get what I want?
I decided to create some service that will work as I think such a service should work.
And that is how wttr.in was created.
Nowadays you probably know, how to check the weather from the command line, but if not:
curl wttr.in
or
curl wttr.in/Paris
(curl wetter in Paris if you want to know the weather in Paris)
After that several other services were created (the point was to check how good the console
can solve the task, so I tried to create services providing information
of various nature: text, numbers, plots, pseudo graphic etc.):
curl rate.sx/btc # to check exchange rate of any (crypto)currency
curl qrenco.de/google.com # to QRenco.de any text
And now last but not least, the gem in this collection: cheat.sh.
The original idea behind the service was just to deliver a various UNIX/Linux command line cheat sheets via curl. There are several beautiful community driven cheat sheet repositories such as tldr, but the problem is that to use them you have to install them first, and it is quite often that you have no time for it, you just want to quickly check some cheat sheet.
With cheat.sh you don't need to install anything, just do:
curl cheat.sh/tar (or whatever)
you will get a cheat sheet for this command (if such cheat sheet exists inf one of the most popular community-driven cheat sheet repositories; but it surely does).
But then I thought: why actually show only existing cheat sheets? Why not generate cheat sheets or better to say on the fly? And that is how the next major update of cheat.sh was created.
Now you can simply do:
curl cht.sh/python/copy+files
curl cht.sh/go/execute+external+program
curl cht.sh/js/async+file+read
or even
curl cht.sh/python/копировать+файл
curl cht.sh/ruby/Datei+löschen
curl cht.sh/lua/复制文件
and get your question answered
(cht.sh is an alias for cheat.sh).
And it does not matter what language have you used to ask the question. To be short, all pairs (human language => programming language) are supported.
One very important major advantage of console oriented interfaces is that they are easily
programmable and can be easily integrated with various systems.
For example, Vim and Emacs plugins were created by means of that you can
query the service directly from the editor so that you can just write your
questions in the buffer and convert them in code with a keystroke.
The service is of course far from the perfection,
there are plenty of things to be fixed and to be implemented,
but now you can see its contours and see the contours of this approach,
console oriented services.
The service (as well as the other mentioned above services) is opensource, its code is available here:
https://github.com/chubin/cheat.sh
What do you think about this service?
What do you think about this approach?
Have you already heard about these services before?
Have you used them?
If yes, what do you like about them and what are you missing?26 -
PineScript is absolute garbage.
It's TradingView's scripting language. It works, but it's worse than any language I have ever seen for shoddy parsing. Its naming conventions are pretty terrible, too:
transparency? no, "transp"
sum? no, cum. seriously. cum(array) is its "cumulative sum."
There are other terrible names, but the parser is what really pisses me off.
1) If you break up a long line for readability (e.g. a chained ternary), each fragment needs to be indented by more than its parent... but never by a multiple of 4 spaces because then it isn't a fragment anymore, but its own statement.
2) line fragments also cannot end in comments because comments are considered to be separate lines.
3) Lambdas can only be global. They're just fancy function declarations. Someone really liked the "blah(x,y,z) =>" syntax
4) blocks to `if`s must be on separate lines, meaning `if (x) y:=z` is illegal. And no, there are no curly braces, only whitespace.
There are plenty more, but the one that really got me furious is:
98) You cannot call `plot()`, `plotshape()`, etc. if they're indented! So if you're using non-trivial logic to optionally plot things like indicators, fuck you.
Whoever wrote this language and/or parser needs to commit seppuku.rant or python? pinescript or fucking euphoria? or ruby? why can't they just use lua? or javascript? tradingview17 -
My work product: Or why I learned to get twitchy around Java...
I maintain a Java based test system, that tests a raster image processor. The client is a Java swing project that contains CORBA bindings to the internal API of the raster image processor. It also has custom written UI elements and duplicated functionality that became available in later versions of Java, but because some of the third party tools we use don't work with later versions of Java for some reason, it's not possible to upgrade Java to gain things as simple as recursive directory deletion, yes the version of Java we have to use does not support something as simple as that and custom code had to be written to support it.
Because of the requirement to build the API bindings along with the client the whole application must be built with the raster image processor build chain, which is a heavily customised jam build system. So an ant task calls out to execute a jam task and jam does about 90% of the heavy lifting.
In addition to the Java code there's code for interpreting PostScript files, as these can be used to alter the behaviour of the raster image processor during testing.
As if that weren't enough, there's a beanshell interface to allow users to script the test system, but none of the users know Java well enough to feel confident writing interpreted Java scripts (and that's too close to JavaScript for my comfort). I once tried swapping this out for the Rhino JavaScript interpreter and got all the verbal support in the world but no developer time to design an API that'd work for all the departments.
The server isn't much better though. It's a tomcat based application that was written by someone who had never built a tomcat application before, or any web application for that matter and uses raw SQL strings instead of an orm, it doesn't use MVC in any way, and insane amount of functionality is dumped into the jsp files.
It too interacts with a raster image processor to create difference masks of the output, running PostScript as needed. It spawns off multiple threads and can spend days processing hundreds of gigabytes of image output (depending on the size of the tests).
We're stuck on Tomcat seven because we can't upgrade beyond Java 6, which brings a whole manner of security issues, but that eager little Java updated will break the tool chain if it gets its way.
Between these two components we have the Java RMI server (sometimes) working to help generate image data on the client side before all images are pulled across a UNC network path onto the server that processes test jobs (in PDF format), by reading into the xref table of said PDF, finding the embedded image data (for our server consumed test files are just flate encoded TIFF files wrapped around just enough PDF to make them valid) and uses a tool to create a difference mask of two images.
This tool is very error prone, it can't difference images of different sizes, colour spaces, orientations or pixel depths, but it's the best we have.
The tool is installed in both the client and server if the client can generate images it'll query from the server which ones it needs to and if it can't the server will use the tool itself.
Our shells have custom profiles for linking to a whole manner of third party tools and libraries, including a link to visual studio 2005 (more indirectly related build dependencies), the whole profile has to ensure that absolutely no operating system pollution gets into the shell, most of our apps are installed in our home directories and we have to ensure our paths are correct for every single application we add.
And... Fucking and!
Most of the tools are stored as source bundles in a version control system... Not got or mercurial, not perforce or svn, not even CVS... They use a custom built version control system that is built on top of RCS, it keeps a central database of locked files (using soft and hard locks along with write protecting the files in the file system) to ensure users can't get merge conflicts by preventing other users from writing to the files at all.
Branching is heavy weight and can take the best part of a day to create a new branch and populate the history.
Gathering the tools alone to build the Dev environment to build my project takes the best part of a week.
What should be a joy come hardware refresh year becomes a curse ("Well fuck, now I loose a week spending it setting up the Dev environment on ANOTHER machine").
Needless to say, I enjoy NOT working with Java. A lot of this isn't Javas fault, but there's a lot of things that Java (specifically the Java 6 version we're stuck on) does not make easy.
This is why I prefer to build my web apps in python or node, hell, I'd even take Lua... Just... Compiling web pages into executable Java classes, why? I mean I understand the implementation of how this happens, but why did my predecessor have to choose this? Why?2