Integer division: I think the best thing to do is to produce an exact rational, like Clojure that was mentioned, and most Lisps, where it got that from.
Lisps do NOT do textual inclusion. Lisp systems are created from code, not text.
I guess that the author only saw the use of `use-package' or the `:use' option of `defpackage', but this is not necessary (and not generally used) to refer to other namespaces.
The actual use of `defpackage' is often quite close to how Clojure does it.
Lisps in fact do textual inclusion. In ANSI Common Lisp, when you (load "foo.lisp"), and foo.lisp isn't a compiled file, it gets read and processed as text.
The symbols in the compiled file get read in the current package. The <star>package<star> variable is dynamically rebound, over the lifetime of the load, to its existing value, so that if the file happens to change it, that effect is undone when the load finishes.
The loaded file source can arrange for its bulk to be read in its own namespace, or it can be processed in the parent namespace, which is the best of both worlds.
When a file is compiled, then it's no longer textual inclusion: best of both worlds again.
This is all so reasonably designed that I copied the salient aspects of things like load and compile-file and all that jazz nearly as is into TXR Lisp, which isn't an ANSI CL implementation and free to do anything differently.
From my german perspective, every assumption in this article looks quite gross and barbaric.
Here, everyone is insured. If you break your arm, you get it fixed. If you get cancer, you get therapy. If you get the flu, you get a prescription. The overall cost is paid by the entire population, through the insurance system.
For what is the alternative? Maybe the overall monetary cost would be lower if everyone had to watch the price, but you would pay for it in human lives and suffering, when people have to decide between dying of illness or dying of hunger, or between lifelong pain or clothes for their children.
From my American perspective, the national health systems of other countries have their own barbarities. There is a reason why so many people from other countries come to the US for health care.
When I was looking to have a very serious health problem taken care of, I heavily researched getting the procedure done anywhere in the world. It was pretty obvious that all the best places to have it done were in the US. The facility we went to had quite a few patients from other countries - and we're not talking 3rd world countries. Many of these patients had already had care in their own country, where the care was botched or insufficient. They were coming to the US to get it done right. On their own dime.
Not sure how Germany is, but average wait time for an MRI in Canada is over 10 weeks.
In northern Italy‘ve gone ”right into” an MRI with the public health system twice (once when I had a migraine aurea of incredible intensity with visual hallucinations and disorientation) and another time when I had smashed up my ankle so badly they needed to figure out the effect on the soft tissues after a bunch of X-rays in the broken bones. There’s a lot of myths about queues and waiting times (in my experience at least). When I was in the UK (of which I am also a citizen) while studying in very early 2000s I had slightly longer waiting times for specialist visits (allergy specialist, and then a dermatologist) but certainly not the kind of waiting times I hear tossed around now (on the order of a couple of weeks, tops).
Well, actually, at least the reason why the very rich nationals from my country elect to have surgery in the U.S. is because the very best doctors are there - possibly because they're extremely well remunerated there, and the best research is done in the U.S. as well.
I wonder if the insurance we're talking about covers the kind of procedure people from other countries do in the U.S.
I absolutely trust medical professionals in my country and I believe we have some of the very best healthcare in the world - way better than in the U.S. - wait time for an MRI is same-day if needed (same as you say for the U.S.), surgery is 13 days and the cost is maybe 30 dollars for the ticket. No deductibles, no hidden costs. Zero people became bankrupt due to medical emergencies in my country (plenty of other causes like high taxes, but nothing directly medical-related).
But if I had the millions and I had to have open-heart surgery I would possibly choose the Cleveland Clinic, and similarly for other very serious health problems, the equivalent top clinic.
This implementation always moves the nth item, it should only do it most of the time, it could never return the starting array but needs to be able to.
Lisp's problem is rather that so many people play around with it, but not long enough to develop /good taste/ in it, and finally loudly complain about the language when their real problem is their lack of imagination.
You discovered structs, but you should not have stopped there. Structs can be configured. You can declare boa constructors (yes, really, By Order of Arguments). You can configure the names of the accessors. You might even create a little reader macro for creating them. You might want to write a little with-3dvecs macro for quick destructuring. When structs do not have everything you need, maybe go to CLOS classes.
In Python, “there is only one way to do it”. In Perl, “there is more than one way to do it”. In Lisp, there are thousands of ways to do it. If you haven't found a good one for your problem yet, keep looking. I promise, there is at least one.
By the way, you also have no idea of Clojure, but I have only been using it for a few years, so I feel not confident to give meaningful hints.
Lisp's problem is that almost nobody plays with it, but they know that it's that language that relies a lot on parentheses. When they do rarely come across the odd example it is full of unfamiliar symbols: car, labels, mapcan, assoc, setf and so on. Depending on the code, it's possible that not a single thing means anything to even be able to guess.
Valid points, but not _the_ point. There is a big difference between allowing and supporting something.
OO languages _support_ hidden inputs and outputs as well as programming by mutation. They _allow_ programming in a functional style, but you will have to be inventive for it.
FP languages _support_ immutable values, referential transparency and all that. They _allow_ programming by mutation and hidden inputs and outputs, but you will have to be (sometimes very) inventive for it.
Starting points matter, but this depends on the programming situation. That's why you use OOP or FP where it is most appropriate or suitable. Neither OOP nor FP is a panacea. Neither OOP nor FP is the universal programming tool.
