So I have to admit I am myself not really sure. It has been posted on r/haskell where recently there have been several posts about some kind of less-is-more approach when writing Haskell (for example [1]).
I would say it's some kind of informal manifesto to write Haskell code, that does not use too many or advanced features. The C++ community had and has similar discussions where people banned specific features and agreed on (admittedly different) subsets of the language. These endeavors have been more or less successful, but in general I agree that there is the danger of having a too powerful language, where people go off the board and write code that is hard to read.
These might be reasonable functions to implement in a standard library, so having them it makes sense to use them. I rather feared Idris does not have some IO abstraction (reading/writing) files at all. Maybe I am conflating languages and libraries here, but they often go hand in hand.
My practicability expectations for languages implementing dependent types are pretty low.
All major Linux distributions are doing very well with systemd and it makes sense to have some kind of supervizor service (or collection of tools) on top of `init`. You can still tie together your applications with shell scripts and not run systemd. Since systemd it is simpler to admin different linux boxes - at least that is my personal experience - before that every distribution shipped their own shell scripts.
Systemd is fine and if it is so inferior to simple POSIX applications glued together, people should provide a better alternative. The grieve that people have against Lennart is overblown - we should thank him for his contributions.
Wow, thanks for the response - that actually looks like Haskell and if its performance is not that abysmal (let's say slower than Python), that is pretty cool.
This actually looks quite reasonable - usage string included, I like it. Hats off to you, I will try to compile it to a binary now and do some benchmarking.
Yeah ... but how does that look? A "naive" wc implementation (counting the character '\n') is <50 lines of code (if we have modern file IO in the standard library) in a practical PL.
But maybe there is a too big difference between the concept of "files" (as seen by OS developers that view them as a byte-blob in a hierarchical name system) and language designers that want to represent a file as a collection of lines (and probably would like your command line interpreter not allow to call "wc" on a file that contains non UTF8 encoded data) - but this is still a pretty big step for our current computation environment (where I can call programs by name that are also files).
For many people (including me) a "practical" programming language needs an implementation that can generate (compile) an executable or interpret a file representation of its source. Otherwise its a proof assistant.
Maybe we have to merge the concept of data in terms (no pun indented) of bytes (types?) in-memory and collections of bits and bytes that have a lifetime longer than the program (if it's not a daemon)?
> [...] Idris is a lot more practical than I thought.
This may sound like a stupid question (but is probably necessary in a thread about the convergence of proof systems and static typed functional programming languages):
"How can i implement something like unix' wc?"
So just a program that counts lines (forget words and bytes for now) of a file. This means we need to support (at least in some kind of standard library) basic IO stuff like files, processes and environments. If the language talks about how "simple" (in terms of code/term length) it is to define a binary tree ... the integers >= 0 (the famous Nat = Zero | Succ Nat) example, or beware the Fibonacci sequence - most people won't be impressed.
Because that's what is associated with "programming language" (as compared to "proof assistents").
Sorry that sounds a bit like a rant, but after 5 minutes of searching I couldn't find an example how to read a file in Idris. The closest I found was: http://docs.idris-lang.org/en/latest/effects/impleff.html but it did not tell me how to open a file ...
> In addition subtitles, secondary audio, descriptive video, and multi-view video etc. are all things which we mandate by law which do not work well in a file base expierenced.
That's just not true - VLC has many more features than all the web-based (or "app"-based) popular streaming players. Granted, I checked and my VLC does not have "thumbnail scrubbing", but although that is nice, I don't think this is a big deal and if it's really popular, it will be added to VLC (or it may already be there, I did not check).
I guess people would even pay for Spotify, if it's DRM free (which means the stuff on it can be copied), but that is still considered "radical" (in the Overton window) for shareholders of media distributors.
That "Save your music offline" is a feature in 2019 is ridiculous.
Although I am a customer of some streaming services (they are convenient and have good and bad stuff), it is often nice to just get a file for a specific song or movie - and that is most convenient via torrenting.
People do sign up for streaming services, but not for like, 10. Furthermore torrenting got really convenient and is very fast with adequate Internet (let's say 10MByte/s), so you get a decent quality movie in under 5 minutes (obviously only if there are enough seeders - but the availability of torrents completely dwarfs the availability of streaming providers - if it's really unpopular and maybe a little bit older you just won't find it on streaming services).
Beside the fact that BitTorrent is an interesting protocol in itself, imagine just how much simpler Netflix or Spotify could be implemented, if we wouldn't stream DRM encrypted blobs, but download files? You just need many big fat file-servers and put your media there - if we wouldn't have DRM (AFAIK all streaming providers enforce DRM), this is technically a solved problem.
I agree with your parent. When I started with (Python) webdev some years ago I picked Flask, but nowadays I use Django, as it has superb documentation and useful things built-in. In particular I miss the user-management, authentication and authorization in Flask.
Personally I consider Django without any additional apps less complex than Flask with apps (or "plugins" in Flask jargon) to handle basic stuff like auth.
If performance is a concern, both of them are insufficient and I would rather pick another language like Rust, Go or even Java.
Do you just kill the process (or stop the container)? In essence Jupyter is a graphical rich shell, so you providing free *nix machines - don't underestimate how this feature can be exploited (e.g. CoCalc limits at least internet access for free instances).
> We've been recently working in a FREE hosted version [...]
Oh no, you make it sound like this is a good thing. It only means I can't take you serious.
Don't make it free. That is not a feature for a computation environment, it will only cause headaches on your side and people get wrong (bad) impression about the performance (assuming free accounts get some limited shared instances).
I rather pay a monthly fee for a good application, than a pseudo free instance, where you get limited resources. Do you have your credits forever?
There is a software for modelling drainage systems called SWMM (Stormwater Management Model) that has been around since 1970s (!) and is programmed in C and released as free software. Still most modern drainage and sewer research is modelled via this software and there are several companies that built a GUI for simpler usage. However the core is often still based on this nearly 50 year old software which I find amazing [edit: it has been updated since then and originally it was written in Fortran].
The model has hydraulics and hydrology capabilities [0], i.e. it can model stuff like pipe pressure but also takes infiltration of stormwater (aka "rain") into the surface into account. When using it you have to define your sewer (which is mostly a directed graph) and so called catchments where you define which areas drain into which nodes (inlets) by defining parameters like impervious area, slope, etc. You can then let it rain on your area of interest (e.g. a city) and find out which nodes get flooded at specific points in time (or hopefully not).
My test for "non-native" Vim is always 'q:' which should open a command line window of previous commands at the bottom of your screen - unfortunately that does not work.
Furthermore I can't use 'Ctrl-v' that let's you select a column of text (EDIT: correction, this does work).
'q:' should not be captured by the browser? Nevertheless impressive work.
I would say it's some kind of informal manifesto to write Haskell code, that does not use too many or advanced features. The C++ community had and has similar discussions where people banned specific features and agreed on (admittedly different) subsets of the language. These endeavors have been more or less successful, but in general I agree that there is the danger of having a too powerful language, where people go off the board and write code that is hard to read.
[1] https://www.reddit.com/r/haskell/comments/eg25xt/a_plea_to_h...