51–60 of 84 posts
Earlier quoted context omitted.
But are containers portable? Can you take them, send them per mail or put on a USB-stick? And I'm not talking about the recipe for creating them, but the actual container itself.
Yes. The actual image is a tar file, and container runtimes include commands for both exporting and importing. Exceptionally portable. More portable than JAR files and Go binaries, at least.
Earlier quoted context omitted.
You don't like people being hard on Python fine. Don't do the same for Java. Modern Java doesn't have nearly as much boilerplate and is nearly as concise as python. Relying on IDE Python can be great and so can Java. Different strokes. Different use cases.
Modern java relies on Lombak (code generation) and DI frameworks (seriously, fuck DI) to avoid boilerplate. The base language has just as much of it as it always has. And, as I just found out this morning, DI frameworks blow up at runtime despite successful compilation and runs through unit testing.
I suggest reading up on Java 18 and some of the upcoming features.
I don't think the type system particularly matters. You can make something work without assigning a type like "int" to variables. Python doesn't let you do things like "foo" + 3 (while Node is happy to), so even though you're not naming your types, the types are still static. One unexpected downside of static languages are dealing with web services written in dynamic languages. As an example, I was writing a Slack ap…
I was mostly talking about the tooling you find in environments like Zephyr and ESP-IDF. I'd happily accept 500Mb binaries if it meant I never have to spend any time making the tooling work ever again.
How do you feel about containers, OP?
As in building containers to run tooling? I've gone down that route quite a few times and it usually isn't ... terrible. I've had some issues with access to USB and hardware from containers, but I can't remember the details anymore (I ended up ditching the project because of alternatives that were easier to work with). One challenge is that when you work on a team and you know there will be people who have to maintai…
Can confirm, good point.
I'm not upset about your post, I was genuinely curious. To state the obvious, Java JARs have fallen out of favor and containers in fashion. I sincerely think it's a change for the better, but your post raises the interesting point of the parallels.
What a bizarre take. It seems to boil down to: "Tooling should be compiled so it doesn't involve dependencies." If we lived in a world in which most tooling (currently written as python scripts) were actually compiled, we'd be seeing better-reasoned essays begging us to write tooling as easily-editable scripts, rather than closed-off executables. I have had scripts that I needed to edit just slightly almost every tim…
The point is that it doesn't matter what a theoretical developer could do to lower the "cost of ownership" for their end users, but what is actually being done by actual projects. And in the embedded sphere, the situation is pretty sad. You will have to spend a few weeks every year trying to sort out the tooling.
And it isn't like you the user are supposed to hack the tooling. That's not part of the workflow. Or that it is vitally important that one can do quick changes to the tooling while working on it. It really isn't. It just has to work.
Why should the end user have to care about whether you use pyenv or conda? Or have to figure out how to make them play nicely with some code they didn't write and which they only want to run with a minimum of hassle?
It is kind of like demanding you understand and set the timing advance on your car's engine. Why on earth would you even want to know of it, much less fiddle with it?
What a bizarrely arrogant (condescending) way to formulate arguments. "It is okay to feel provoked by this statement. As pointed out previously: you have probably invested a lot of time in Python. You will be inclined to justify and defend that investment. I would urge you to take some time to think about this and try to calm your urge to come up with counter-arguments. Let it sink in and try to be open to the possib…
Did you consider I might have a point and that it might be helpful for people to think about it a bit before just going with their gut reaction?
What a bizarrely arrogant (condescending) way to formulate arguments. "It is okay to feel provoked by this statement. As pointed out previously: you have probably invested a lot of time in Python. You will be inclined to justify and defend that investment. I would urge you to take some time to think about this and try to calm your urge to come up with counter-arguments. Let it sink in and try to be open to the possib…
And yet, if you look at the reactions, it precisely anticipated how people would react and asked them to try to try to be open to the possibility that the blog posting had a point. Did you consider I might have a point and that it might be helpful for people to think about it a bit before just going with their gut reaction?
Instead of reading that sentence above and having the gut reaction of not feeling understood, try and be open to the possibility that you didn't make a very strong argument or perhaps didn't communicate it very well.
Earlier quoted context omitted.
I don't mind people being hard on Python, but the idea of Java over Python "in a pinch" is lost on me, but what do I know...
As a consumer of a program, you don't really care about what language it was written in. But you do care about to what degree you have to involve yourself in the process of getting the software to run. Java was mentioned because it offers a way to package all dependencies in a single file. From a user perspective this is preferable to "here is a program, now you have to gather all the pieces to make it run without br…
Earlier quoted context omitted.
And yet, if you look at the reactions, it precisely anticipated how people would react and asked them to try to try to be open to the possibility that the blog posting had a point. Did you consider I might have a point and that it might be helpful for people to think about it a bit before just going with their gut reaction?
If your point was strong, people would have listened. But it wasn't, so you had to make a meta point which came off as condescending. Instead of reading that sentence above and having the gut reaction of not feeling understood, try and be open to the possibility that you didn't make a very strong argument or perhaps didn't communicate it very well.
What a bizarre take. It seems to boil down to: "Tooling should be compiled so it doesn't involve dependencies." If we lived in a world in which most tooling (currently written as python scripts) were actually compiled, we'd be seeing better-reasoned essays begging us to write tooling as easily-editable scripts, rather than closed-off executables. I have had scripts that I needed to edit just slightly almost every tim…
The place where I run into Python is mostly while doing embedded development as the tooling for platforms like Zephyr and ESP-IDF. And they are notoriously brittle. Which has a high cost in terms of lost productivity. So we aren't talking about scripts I maintain, but scripts that are part of the tooling for platforms I use. The point is that it doesn't matter what a theoretical developer could do to lower the "cost…
Even if the platforms you depend on don't do this, you can do it yourself. It won't fix their bugs, but it will make the development environment more deterministic.
I agree that not all embedded developers should have to work with daily or even monthly. Ideally, all they have to do is run to commands:
./scripts/setup-dev-env
source ./scripts/activate-dev-env