Http.get and apis

So - something’s been bugging me. Not badly - kinda like the tag in the back of your underwear when it gets all twisted and you can feel it but you’re too busy to just reach back there and rip it off.

That’s http.get - but not in the way you think.

It’s been suggested that’s a bad name for the function - and arguably, it is. But - its what’s there.

Now, go read this lovely rant: http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/

First off - neat!

Second off - yes, what he said. This is something I was trying to articulate - poorly - perhaps because i cant argue with the gravitas or someone who re-implements OpenGL 1.3 to prove a point.

If we want to normalize things and make a new http.request and so on - cool. But - we should leave http.get alone, so as to not break working code.

Maybe that’s already the plan, in which case - look, x-screensaver!

I now return you to your regularly scheduled programming.

Ps. Sorry I’ve been AWOL - my work tends to come in waves, and I’ve barely had time to come up for breath in the last month, with no teal end in sight. Think good thoughts, be kind to others.

This also applies when - or if - codea should be moved to Lua 5.2. I mentioned before that there are some subtle changes (and some not-so-subtle ones) to the language, and while I feel that we could profit from an upgrade, I think it should be done with a lot of care in order to not break existing code. This is even more important as I see quite a lot of people who start programming with codea and would be stumped if their program suddenly stopped working after they upgraded to a new release of codea for reasons they don’t understand.

This also applies to the suggestions of redesigning the codea apis and putting them in namespaces. While from a software engineering standpoint that might be a sensible approach, it would break everything, and thus is not an option any more.

So, in order to offer a suggestion for the problem at hand: don’t remove deprecated functions from the environment. Remove them from the documentation and maybe offer a warning when they are used that they should not be used any more.

Btw nice find, @Bortels

Hi @Bortels,

Thanks for the post - great reading although he does get a bit worked up in the text and doesn’t hold back. You get the feeling that there’s a hitman on the loose with a list of developers on his list!!!

Anyway, my thoughts:

  • Old systems should always remain available as a library.
  • Each program header should carry code to identify the OS used and language version.
  • There should be a core primary program, initialised first which reads and identifies the latter.
  • Relevant libraries should then be loaded and the app run.
  • Messages to the effect that ‘The application about to run uses deprecated features and you are encouraged to use the all singing/all dancing super dooper OSxxx (that is - for now!!!)’.

Then we wouldn’t have this problem.

However there is the point that hardware changes and we get into emulation. You can never win.

I support your views but think that there are limits and we must draw a line somewhere. Also I think we should email the author and recommend valium.

Jay Asher (Thirteen Reasons Why):

       “You can't stop the future
        You can't rewind the past
        The only way to learn the secret
         ...is to press play.” 

That’s my philosophy - now back to Cargo-Bot.

Bri_G

:slight_smile:

I’ve renamed http.get to http.request, however http.get is left as an undocumented API for backwards compatibility. I’d suggest that people update their code to use http.request when version 1.4.1 comes out (the review is taking some time, since May 29th — and it’s mostly bug fixes).

I don’t see a problem with deprecating some APIs completely, over time. For example, it’s almost time for rsqrt() to disappear. As long as there is adequate warning and a decent amount of overlap between new API and old API for people to adjust.

I disagree with the point made in the linked article. Especially, “thou shalt not break working code.” Code is not sacred, and breaking existing code is not a big deal if a certain amount of warning is given and there is a good reason for doing so.

OpenGL benefits from deleting 80% of the language. When I initially used the new API I missed the immediate mode, and the old way of doing things. But the new API is designed far more around how GPUs actually work now days. Hardware has changed, use cases have changed, and the API has adapted to reflect this. Graphics programmers would be worse off if OpenGL retained the crud from its early days. It would be less competitive with Direct3D and would encourage programmers to write sub-optimal code (because immediate mode is so much easier to write).

Edit: I firmly believe it’s the things you throw away that make something good and focused.

You mean that “Sometimes in order to create you must first destroy?” (the robot in the movie Prometheus)

Perhaps, I haven’t seen Prometheus yet but it sounds good :slight_smile:

I think it’s a matter of context. For applications you can do that more easily than for libraries or programming environments. The go people have had this discussion a lot because in the course of the development of the language the libraries and also the language changed a lot. As the language was still in development, this was to be expected, but they still provided a tool to ease migration to newer versions, because they had already developed a userbase which had created a substantial amount of code. You can’t do such a thing with, for example, codea too easily because people can not run migration tools on their code. http.get vs. request is a small matter because the feature is relatively new and apart from the name nothing changes. Big changes are a different thing. While I basically agree with the “less is more” approach, the advent of shared libraries in major operating systems has changed the game insofar as a new version of a library may break a lot of stuff. This is where major version numbers come into play, and the ability to have multiple versions of a lib around. Which in turn complicates the shared library system… point is, deprecating stuff and thus code that uses it is an issue, and a lot of work is done to handle it. But, honestly, this is way beyond the scope of codea. Presently, at least…

Edit: and yes, Prometeus looks brilliant, but it won’t arrive in germany till august, I think :frowning:

it’s the “… there is a good reason for doing so.” part.

In the OpenGL case, jwz pointed out that to write a compatibility layer took one man 3 days. That’s a minimal cost to not break every bit of 1.3 code out there, and it’s fairly inexcusable that the actual OpenGL devs themselves didn’t do it.

An API is a contract with the programmer - it says “if you do things this way I describe, your code will work”. It’s not something to be broken without good reason. And the credo should really be “thou shalt not break OTHER PEOPLE’S working code” - it’s less important, perhaps, for Codea, where there’s not yet a giant codebase of ancient code to be supported, but it’s very important in principle. When you change an API in a way that breaks code that worked before, you’re breaking your contract with your programmers.

I can’t think of a single good reason to make http.get suddenly stop working, at any point. Oh - I can think of lots of reasons. Just no good ones.

I am just thinking about a time when I was hired to update the code for an energy company that had several systems that needed to be programmed nightly to run on certain schedules and such. The code base was for some apis that made it easy for them to program stuff to run, and it did so by scanning for available systems and creating functions for each one, like it would create a new function called StartSystem1 and StopSystem1, etc. This was a stupid model and caused errors if someone tried to start a system that hadn’t been initialized.

So I rewrote the system and made functions that were more like StartSystems(list) which properly avoided errors and was more efficient. I handed over the new code and they said, nope, it breaks our existing code (which they were cutting and pasting from each night.)

In the end I had to re-implement the old system of creating dozens of these pseudo-functions for them to use, and then each of those functions called my functions with a list of one, making it all much less efficient. I explained at length all the good reasons why they should use the new functions instead, but no one wanted to spend any time or effort learning the new function calls (which would have taken 20 minutes to learn)

In the end, I thought that the correct solution would have been to chage the interface and break the existing code. This would have forced them to make more efficient and less buggy code. Instead, they are probably still using the same crappy programming model. So, in summary, I am not sure that it is not a good idea to sometimes break stuff to fix it.

@Bortels an OpenGL compatibility layer obscures the hardware and encourages you to write bad code. The reason the compatibility layer was stripped is because hardware no longer works that way now. Retaining it would encourage programmers to use it (because its easier) and give people a bad impression of OpenGL.

I strongly disagree about OpenGL retaining a compatibility layer. Since dropping it, I’ve taken the time to learn, improve my graphics programming, and develop a further understanding of GPUs. If the compatibility layer was there I probably would have used that — even for Codea — leading to a less-rich rendering system.

As @Vega said, unless you force people they won’t take the time to learn new, better systems. OpenGL is forcing the issue in this case.

I see no reason to drop http.get() either — so we agree on that particular call. But I strongly disagree with the idea that code compatibility should be kept at all costs, and that code is sacred — it’s not.

You keep adding in things like “at all costs”. That’s not part of the argument.

You break existing code if there is a compelling reason to do so. I don’t see one for http.get (and you’re not breaking it so meh), and I don’t see one for OpenGL.

Providing a new API that is closer to the hardware, good. Encouraging people to adopt the new API by deprecating the old one, fine. Forcing people to adopt the new one by breaking their code - dirty pool.

If Apple decides they don’t like how they’ve been doing graphics in Codea - maybe they have a new processor that is faster, but doesn’t support OpenGL - would it be acceptable for them to just change the API, breaking Codea, and you should just learn and use the new API because it’s better for you, we promise? I don’t think so, and for all of Apple’s “quirks”, they’d never do that. An API is a contract - it’s a promise to users - that if you do it that way, it will work now and in the future. The reason for moving to a new API should be because it’s better, in some tangible way (faster, or cross-platform, or such), not because someone forced you.

Breaking code is not a big deal to me. I re-write it and move on, adapt to the new system and throw out the old one. If Apple had forced certain API changes on me by breaking my code, I believe Codea would be better off for it. And so would Codea users.

To choose a random specific example, if Apple chose to enforce ARC to target iOS 5 — that would have been fantastic. It would have broken all our code, but it would have forced us to move, to keep up to date, and to build better software.

Of course, Apple didn’t do this. We maintain an ARC branch in development but the current version does not use it — so you get stuff like the occasional crashing-on-project-open bug in version 1.4. If we had been forced to use the new system you would have been better off for it. It would have been more work for us, but I want that. I want to be forced to make my software adhere to the most modern system.

And in the linked article the complaint is that OpenGL, on brand new devices, does not conform to the archaic spec that was used with older devices. This is a good thing. It’s a problem if you want to port old software (in this case a screen saver) to a modern device. There should be no guarantee or contract in this specific instance that says iOS should be able to run code written for X all those years ago. That is ridiculous.

I think he put in a great effort and wrote a cool compatibility layer, but that is work he should have been required to do if he wanted to port old software to a new system.

Edit: Just to reiterate, we are not going to go around breaking API calls for no reason. And http.get is safe. I just have a strong opinion about this topic.

so has everyone. As I wrote above, it is a matter of context. For stuff I do for myself I reiterate often and basically am a fan of a small set of orthogonal functionality.

OTOH, just yesterday I installed Oracle 11… they still require old (3.3) gcc libraries. Not providing them would break Oracle. On an enterprise OS, nobody wants to break Oracle…

@gunnar_z Things tend to be a lot more agile on iOS, with apps soon requiring the latest OS after launch, taking advantage of the newest APIs immediately, and so on. This works well for small applications developed by small groups of people.

I like this way of working a lot more, and would not want to be programming systems like Oracle 11.

neither would I, I just have to install it. Other people have to work with it. Poor sods… :wink: