Is it also too much to ask that someone explain how they think a technology which has been chosen by market participants and is used widely and (apparently) successfully by them does not actually match the real constraints of the market or participants?
And perhaps proposes a concrete alternative that matches those constraints better?
Don't forget to include things like long term support, developer time, interoperability, etc.
> Is it also too much to ask that someone explain how they think a technology which has been chosen by market participants and is used widely and (apparently) successfully by them does not actually match the real constraints of the market or participants?
Kind of, yes. Since instead of evaluating based on an understanding of the technology you're saying "In this universe was chosen for a project, the project was successful, show me the universes where the alternative decision was made".
I'm saying that if you think something is crap and doesn't meet customer needs, at least propose a concrete alternative you believe is better so someone can respond meaningfully! Or concretely what concrete needs are not being met!
Currently, we have one example of something that all evidence leads us to believe fits the universe as it exists, at least in that specific niche.
If you think it doesn't, how doesn't it? Or if you're saying there is something better, are you saying that is hand written assembly? Or TurboPascal? Or ADA? Or some as yet not designed system?
I'm not asking for an alternative universe. I'm asking you to support your statement with enough details it can be assessed in the current universe.
Them: People are using Java for this because there aren't alternatives
You: If it is the convenient alternative than it is a good choice
Me: That is a bad justification for something being a good choice
You: What criteria then?
Me: An understanding of the engineering principals/ domain
Am I accurately summarizing this conversation so far? This isn't about alternatives, or what else they should have done. Something can be a bad fit and the right choice.
As an example, I could say "Java dominates that section due to historical artifacts of business, not technology. Java is a bad fit for this type of work otherwise because of the complexity involved in implementing a Java VM in hardware". I can then also say "Java is the only real choice because of those historical artifacts so I have to recommend that you use it unless you're willing to build your own hardware from scratch".
I actually don't have to propose any alternatives at all, hopefully you can see that - we can just evaluate Java as a language (complex VM, assumes a heavy runtime) against the constraints (custom hardware, low energy) and see that the fit is weak. Obviously people overcame that and made it work, and because of that Java is the obvious choice for this technology.
From an engineering perspective, I don't think it's fair to say something CAN be a bad fit and yet a good choice? At least not without acknowledging it was the best choice available, and therefore not likely actually a bad fit?
In that scenario, it's literally the best possible fit.
That you don't have any viable better alternative at hand may be further evidence of that? (and I don't mean from a standards basis 'well, it's locked into financial rules now, so gov't intervention'). I mean, what else was going to work considering all the factors involved? What else could work better, considering the factors involved?
JavaCard is in fact so widely used and implemented (SIM cards, bank cards, health cards, passports, etc.) that it probably has literally 10's of billions of devices manufactured using it (3.5bln claimed as of 2010 - https://www.oracle.com/technical-resources/articles/javase/j...), in essentially every high value target rich environment niche you can think of, and at extremely low costs. Literally sub-cent per-item.
And with very high environmental stresses (like debit cards getting sat on, left in hot cars, run over, dropped in puddles, jammed into random dirty readers over and over again, etc.), those devices keep working.
And everyone from random countries gov'ts to random financial firms to telcos have managed to implement what they need in it without too much difficulty, and a minimum number of security issues. Which is frankly astonishing if you've ever dealt with folks like that.
So love or hate Java, or JavaCard from a stylistic perspective - any perceived complexity for implementing a Java VM in hardware has had no practical economic effect, or slowed down implementation meaningfully.
It's fit for purpose.
Probably also ugly and feels gross using them sometimes, but a lot of fit for purpose stuff is until you've experienced the alternatives. Hopefully you never have to fix a sewage lift station pump, or clear a clogged sewer line, or clean out a transmission after it's burned out.
Each of these has literally hundreds of years of specialized knowledge and expertise behind their often boring looking facades. They're all amazingly complex if you learn about them. And they're all better than throwing sewage in the street, or carrying everything on horseback. And they're beautiful in their own way when you appreciate why they are how they are.
Even if they're not shiny and flashy, there is beauty in them, because they work well.
And they're still amazing engineering marvels, necessary for our lives as we know them and based on the actual engineering principals involved and the problem domain.
> I don't think it's fair to say something CAN be a bad fit and yet a good choice?
So we fundamentally disagree.
> has had no practical economic effect, or slowed down implementation meaningfully.
This goes back to my "to prove me wrong you have to show me alternate universes where other options had that investment made under the same circumstances".
Hardly. That would require an assertion like 'any perceived complexity for implementing a Java VM in hardware did not exist because it was rolled out in the most economic way possible given non-technical constraints, and it also did not slow down the implementation beyond the minimum absolutely necessary for any technical solution possible.'.
Notice the difference?
To propose alternative solutions based on practical economic effect just requires a reasonable degree of comparison to projects of similar scope at other times, reports of difficulty from various vendors, and comparisons of end price for this solution, end price for other solutions of similar scope, to the overall scope of the solution and value it brings. None of which requires perfect alternative universe A/B testing to come to some reasonable analysis.
If another solution could be done for half the price (say $0.005 per unit, instead of $0.01 per unit) but the perceived value for vendors is $1/unit - then it's hard to say there is any practical economic effect going either way. Neither solution would block profitability or value. That said, they could easily be compared and better/worse solutions could also be determined or tradeoffs analyzed based on that data, also without perfect alternate universe A/B testing to come to some reasonable analysis. Industry does this all the time at scale, including projected costs of implementation of various solutions.
If the solution was rolled out within a timeframe considered useful/expected for this kind of solution, then it also didn't slow down implementation meaningfully - as in it didn't block it, or add serious delay. If there is another solution which could have been done in half the time, that's cool. But it wasn't required. Identifying such an alternative, if one exists, could be done if you have any data, without having to do an alternative universe A/B test. Though since the proof is in the pudding, to REALLY be sure maybe it would. But that's hardly what I've been referring to or asking for, clearly.
Doesn't mean they wouldn't have been better solutions, and proposed them as alternatives can easily be done without parallel universes! In fact, chances are they have already been implemented somewhere in another niche, so there is adequate data to do so.
> If the solution was rolled out within a timeframe considered useful/expected for this kind of solution, then it also didn't slow down implementation meaningfully - as in it didn't block it, or add serious delay.
