i think at least a lot of things (if not most things) that i pay for have an agreed-upon result in exchange for payment, and a mitigation system that'll help me get what i paid for in the event that something else prevents that from happening. if you pay for something and you don't know what you're going to get, and you have to keep paying for it in the hopes that you get what you want out of it... that sounds a lot like gambling. not exactly, but like.
In the US? No, you actually do not need to pay for the service if you deem the quality of the output to be substandard. In particular with art, it's pretty standard to put in a non-refundable downpayment with the final payment due on delivery.
You only lose those rights in the contracts you sign (which, in terms of GPT, you've likely clicked through a T&C which waves all right to dispute or reclaim payment).
If you ask an artist to draw a picture and decide it's crap, you can refuse to take it and to pay for it. They won't be too happy about it, but they'll own the picture and can sell it on the market.
There must be artists working on an hourly contract rate.
Maybe art is special, but there are other professions where someone can invest heaps of time and effort without delivering the expected result. A trial attorney, treasure hunter, oil prospector, app developer. All require payment for hours of service, regardless of outcome.
It'll mostly depend on the contract you sign with these services and the state you live in.
When it comes to work that requires craftmanship it's pretty common to be able to not pay them if they do a poor job. It may cost you more than you paid them to fix their mistake, but you can generally reclaim your money you paid them if the work they did was egregiously poor.
This is one reason why I prefer keyboard-based UIs that do not automatically change anything that affects the UI while the UI is active (and being able to select things by entering a number or a name also helps, rather than having to use the arrows). (I also dislike touch-screen for many other reasons.)
My opinion of LOOP started to change when I read (the much maligned) "Land of Lisp" and went over that "periodic" diagram in TFA. Seeing the elements of LOOP broken down like that went a long way to get me to overcome my original aversion to it.
Huh, didn't realize that beach didn't like it so strongly. Still, hardly "much maligned"... My impression was that most people enjoyed it, even though it definitely has some weaknesses and could (especially now 15 years later) use a second edition, if for no other reason than to move off CLISP to SBCL. This seems supported by its high reviews on Amazon and GoodReads. (Of course overall I liked it too, and we got the best music video about lisp out of it.) FWIW my own criticisms were largely style-based: too much of it felt like Scheme code rather than Lisp code, even outside of emphasizing/educating about the more primitive features, with lots of things like inner functions, recursion where looping would have IMO been clearer, and so much use of raw car/cdr/caadr/caddr/whatdr instead of more clearly structured structs or classes or just helper functions called intuitive things like get-foo. (The book Calendrical Calculations: The Ultimate Edition uses lists for all its data structures but helpfully creates many functions to both construct and access their parts. e.g. generic dates are a (year month day) list, but the definition and exclusive use of standard-year, standard-month, and standard-day for getting at them would let one refactor it into a class. There are also functions like gregorian-date, julian-date, and egyptian-date that have exactly the same implementation (making a list of the 3 passed params) but serve as 'typed' list constructors, and indeed could be refactored into something that carried along type information without changing other code.)
I like LoL alright too. I was only maybe a year or so into CL when I read it, so I didn't really notice a lot of what it's criticized for. On the one hand, I'm a little sad that I see it bagged on so much (that link from beach's site, IRC, reddit) since I felt I got decent enough value out of it, but OTOH it's good and healthy to point out problems.
The abstractions used in Calendrical Calculations sound good - and echo what I've seen elsewhere - so, based on your comment I'm now more likely to read it, so thank you for that.
This matches my understanding too, at least how it works with Open AI. To me, that would explain why there's a 20 or 30 question limit for a conversation, because the necessary context that needs to be sent with each request would necessarily grow larger and larger.
reply