It is absolutely preferable in that sense. The web-esq interface approach is far harder than it needs to be for small applications with basic interfaces.
The UIs are text only, so they are textual. Modern TUIs may support mouse events. That this tool can export to several TUI frameworks is evidence that these UIs are indeed TUIs, even if not the most traditional.
Exactly, don't know why people are acting like actually makes TUIs, it's just a rough mockup of a TUI for now, with a convoluted figma-like UI.
I guess the headline and website was enough to get all these upvotes. Quite disappointing as someone in the early stages of making a TUI tutorial myself.
I've been juggling some BBS related projects myself that involve some TUI work over raw and web sockets that I've been working on... It's definitely a fascinating space and there's been a lot of relatively recent activity in the space.
> and there's been a lot of relatively recent activity in the space.
100 percent agree. I personally love what the openTUI folks have been up to. As weird as this might be to say, we're still in the early, early stage of TUI adoption.
Another to add to the list:
Allow flexible naming. For example, drilling the two sum problem requires the user name the hashmap prev_map, but I feel memorizing this sort of stuff detracts from the lesson.
Good point, and that matches other feedback I am seeing.
You are right that in the current version the checker is still too literal about names and structure. In two sum for example it nudges you toward my map name instead of letting you use your own, which is not what I want to optimise for once you already know the idea.
The plan from here is to keep an editorial mode for people who want to follow the exact solution and add a more flexible mode that accepts your own names and structure as long as it is doing the same job. Over time the checker should recognise what you actually wrote and adapt its objectives and feedback to that, instead of forcing everyone into one naming scheme.
Ads really aren't that bad. Targeted ads may even help you discover products you'll enjoy.
The ad in the article is pretty obviously an ad to anyone that can read the words, "New Series. Start Watching".
Ads like these that randomly display during idle is hardly what I consider invasive.
Hopefully OP's sister gets her mental health under control, but I wouldn't immediately raise pitch forks to ban an entire industry vital to the economy and business-consumer communication.
And a banner ad may display on a laptop in your home, what's your point? Location or device type matters not. This ad doesn't interrupt the user or demand any attention.
Why should one have to endure the intrusion? Why does every product need adverts as it seems to be the place society is going? They are that bad and their place is only potentially in the places that people are looking for said products.
When every product has adverts, is it a choice any longer? Even finding devices, like TV's without ads is more difficult( no on is advertising them :) ) and paying more is often not an option.
PolyBrute 12 is the most expressive synthesizer ever. With a FullTouch® keyboard, unrivaled sonic palette and advanced software companion - it offers more sonic possibilities than any other analog synthesizer.
Spotlight, notes, and Photos also look at photos and return them in search result. Even going further where you can give a description and find it as well.
> Well, this is just standard Aerospace grade software
Can't be further from the truth. DOD software is given huge budgets where it's not surprising to see 3 separate teams performing QA for one software milestone. It's one of the few sectors that still plan software upfront waterfall style and implement strict procedures for traceability, change management, etc. Who else is using formal methods or safety critical stacks like ADA/Spark?
You have to be kidding! Have you worked on any of these projects?
I wrote DO-178 Software, literally every single project I ever worked on has trivial login credentials.
>DOD software is given huge budgets where it's not surprising to see 3 separate teams performing QA for one software milestone. It's one of the few sectors that still plan software upfront waterfall style and implement strict procedures for traceability, change management, etc. Who else is using formal methods or safety critical stacks like ADA/Spark?
None of this matters or contradicts what I said. You will be able to get into it with user:root password:root or some variation. In all likelihood you will even find a requirement for this, which is of course verified.
If you apply the methodology practiced to a web application, the OP is exactly what you will get.
> Who else is using formal methods or safety critical stacks like ADA/Spark?
This is not actually as common as many people seem to believe. The mandate died almost two decades ago. DOD aircraft fly on Fortran, JOVIAL, C, and C++ more than Ada. And DOD IT systems are a clusterfuck.
> It's one of the few sectors that still plan software upfront waterfall style
That's not the good thing you seem to think it is.
Also, why do you call it ADA? It's not an acronym. Amusingly, SPARK is, or was, and you write it as "Spark". It originally stood for "SPADE Ada Kernel" and the language continues to be stylized as SPARK.
Pedantics aside, not much reasoning against quality. Perhaps I've lucked out, but I've worked in many sectors and do not at all agree with sentiment here about DOD software quality. There is significant formal investment/research in DOD to improve operations, including taking the best of practices in commercial. In my experience, the worst of software is written by teams with little experience improvising under Agile and taking on tech debt with no time/resources to get things done the right way.
Can you point to a successful Waterfall project? A multi-million or billion dollar, 3+ year software development effort where a team figured out all the requirements correctly before writing a single line of code. Where they wrote every line of code correctly before testing it. And where testing was so spectacularly successful that they didn't have to go back and renegotiate the project requirements or dates to get extensions or reduced project scope.
If you can do this, then I might believe you about Waterfall being the best approach out there.
Right now your counter example is "teams with little experience" which is not much of an argument. Teams with little experience fail all the time, because they are inexperienced. Give them a $100 million Waterfall project to plan and execute over 3+ years and their failure would be even more spectacular.
> In my experience, the worst of software is written by teams with little experience improvising under Agile and taking on tech debt with no time/resources to get things done the right way.
Sounds like every DoD software project I've worked on for the past 5 years.
As someone who lives the DoD software delivery process on a day-to-day basis, it's too on the nose to not be satire. Everything is _exactly_ wrong, even the waterfall part (everything's "agile" now!).
Edit: Never mind! I just saw their other comment and it seems more like they are blissfully ignorant of the reality on the ground.
reply