671–680 of 717 posts
Earlier quoted context omitted.
I agree - nothing new. Reason: next generation of developers has to make the same mistakes as the previous generation. I mean why wouldn't they? It's not like there is any institutional memory in this profession.
there's the opposite of an "institutional memory" - kind of a continuous revolution where we must forget, repeat and forget and repeat.
Earlier quoted context omitted.
Stored procedures are bad in so many ways - they harder to deploy and revert than code, harder to unit test* , harder to refactor and every implementation that I have ever seen that has business logic in stored procedures instead of microservices/packages/modules have been a nightmare to maintain. * At least with .Net/Entity Framework/Linq you mock out your dbcontext and test your queries with an in memory List https…
> harder to deploy and revert than code Agree. > harder to unit test Disagree. I've implemented unit tests that connect to the normal staging instance of our database, clone the relevant parts of the schema into a throw-away namespace as temporary tables, and run the tests in that fresh namespace. About 100 lines of Perl. That was five years ago. These days, it's even easier to do this correctly since containers allo…
Earlier quoted context omitted.
You are ignoring battery life which is a useful consideration on laptops which appear to be the majority of pcs. You are also ignoring the notion that a user may want to run a variety of apps, and not want to close or have any of the lot swapped out and pretending the hit on performance, resources, and battery life isn't cumulative.
I'm not ignoring them. I just didn't mention them in this comment. They fit in the same rubric. A user can run a few things even on the low-end netbook. Tabs are cheap. And if they hit the limits of their machine, they can either pay in a reasonable number of user-minutes to actively manage resources or a modest number labor-hours to get something beefier. I personally would like to see things better optimized. After…
I wouldn't mind a true low-power laptop which only needed a charge twice a month.
Earlier quoted context omitted.
Again, "anything fancy" here includes something as simple as a localized dialog. In most commercial apps, this means pretty much everything would require "drawing it yourself". At which point you can basically throw the designer away, since you'll be writing code to manage layout for all widgets anyway.
GUI toolkits moved on since the 1990's. Go download NetBeans and create a Swing UI in Matisse. You'll find these issues aren't an issue. You can drag/drop and end up with a flexible, responsive layout that can handle things like strings changing length due to localisation. You can do the same with Scene Builder for JavaFX, although it's not as slick as Matisse. Or even Glade, if you're more a UNIX person. The latter…
Earlier quoted context omitted.
Again, "anything fancy" here includes something as simple as a localized dialog. In most commercial apps, this means pretty much everything would require "drawing it yourself". At which point you can basically throw the designer away, since you'll be writing code to manage layout for all widgets anyway.
Even Windows Forms has a layout manager with data binding, but devs have to explicit take advantage of it, there is no need for "drawing it yourself".
Data binding is better in that regard, but once you start doing complicated nested data bindings, it's rather tedious to do it in the designer (because you can't just bind to "A.B.C" - you have to set up a hierarchy of data sources).
Worse yet, you start hitting obscure bugs in the frameworks. Here's an example that I ran into in a real-world production WinForms app ages ago (side note: I wasn't an MSFT employee back then, so this was an external bug report): https://connect.microsoft.com/VisualStudio/feedback/details/...
Having said all that, the aforementioned app was written entirely in WinForms, using designer for all dialogs (of which it had several dozen - we used embedded controls heavily as well), with dynamic layouts and data binding throughout. And it did ship successfully. So it wasn't all that bad. Still, not the kind of experience I'd want to repeat, when I can have WPF and hand-written XAML.
Earlier quoted context omitted.
It makes sure that all your code is yours and that no matter what stuff makes it into the data stream it will never be able to do anything because it is just meant to be rendered. So abc would go as where datum 1 would refer to the first datum in the data stream, being 'abc' and no matter what trickery you'd pull to try to put another tag or executable bit or other such nonsense in the datum it would never be interpr…
Or, e.g. my preferred encoding of HTML: (html "abc") This guarantees that no matter what is inside "abc" it simply can't escape into the control stream: (html "This is not (malicious \"boo\")") This is just a pretty display of what would actually be these bytes: (4:html29:This is not (malicious "boo")) It doesn't matter what one puts in the atom: it can't escape and damage the control stream.
(html "user content")
user content := " (script "something malicious")"
(html "" (script "something malicious"))
I find this unconvincing. Every negative thing said about the web is true of every other platform, so far. It just seems to ignore how bad software has always been (on average). "Web development is slowly reinventing the 1990's." The 90s were slowly reinventing UNIX and stuff invented at Bell Labs. "Web apps are impossible to secure." Programs in the 90s were written in C and C++. C is impossible to secure. C++ is im…
The security aspect was an interesting part of this piece, because one of the main reasons webapps took over from Windows apps is because they were perceived as more secure. I could disable ActiveX and Java and be reasonably confident that visiting a webpage would not pwn my computer, which I certainly couldn't do when downloading software from the Internet. And then a major reason mobile apps took over from webapps…
Indeed. And then we made sure all interesting data (email, business data, code (github/gerrit etc)) was made available to the Web browser - so pwning the computer became irrelevant.
It's indeed like the 90s - from object oriented office formats, via macros to executable documents - to macro viri - and total security failure. Now we have networked executable documents with no uniform address-level acl/auth/authz framework (as one in theory could have on an intranet wide filsystem).
So, yeah, I kind of agree with the author - we're in a bad place. I used to worry about this 10 years ago, by now I've sort of gotten used to the idea, that we run the world on duct tape and hand-written signs that says: "Keep out - private property. Beware of the leopard.".
Earlier quoted context omitted.
XHTML2 was dead on arrival. Mozilla didn't do anything to sabotage it; it sabotaged itself by completely dropping backwards compat in such a horrible way that you could only implement XHTML2 or something that would render existing websites, but not both, unless you jumped through some pretty ridiculous hoops. It turned out, no one wanted to jump. Plugins were killed by most browser vendors more or less at once, and M…
>>>the W3C process at the time required two interoperable independent implementations, and there weren't any for WebSQL This is a convincing argument that's a stupid rule, not a convincing argument against WebSQL. Standardization processes are and ought to be a means, not an end in themselves. If standards body rules are blocking progress on new features which are eagerly anticipated by developers and significantly i…
> Also, every browser, including Firefox, implements IndexedDB with ... sqlite.
But abstracted away. And, importantly, not tied to a particular version. So if there's a security bug in sqlite (yes, I know, rare), you can just fix it without changing the web-exposed behavior in any way, for example.
I understand that you like sqlite. But it's not clear that having a web standard that says "yeah, just ship sqlite" is the right thing. For one thing, that requires you to ship code in a particular language (C). That's usually something standards try to avoid.
Earlier quoted context omitted.
XHTML2 was dead on arrival. Mozilla didn't do anything to sabotage it; it sabotaged itself by completely dropping backwards compat in such a horrible way that you could only implement XHTML2 or something that would render existing websites, but not both, unless you jumped through some pretty ridiculous hoops. It turned out, no one wanted to jump. Plugins were killed by most browser vendors more or less at once, and M…
XHTML was not "dead on arrival"; that is some seriously fabricated FUD. XHTML came at a time when it was entirely positioned to take over as the proper way of doing things. It had its own mime type to differentiate itself from HTML, in order to allow older content to continue to be served as soup during a deprecation phase. The demand for this strictly validatable syntax was incredible; it was absolutely in a place w…
Are you talking about XHTML in general, or XHTML 2 specifically? They're not the same thing. I was talking about XHTML 2 specifically.
> It had its own mime type to differentiate itself from HTML
XHTML 2 did not have its own MIME type to differentiate itself from XHTML 1. This was precisely the problem, because it used the same MIME type, same namespace, and same localnames to mean different things from XHTML 1.
> today we would have 100% well-formed XHTML.
We can have a long discussion about XHTML 1 and whether it would have seen better uptake with better support. I will only note that all browsers support XHTML 1, with the XML serialization, and have for years. And similar for HTML5 with its XML serialization. Yet neither one has any uptake...
I should also note that your "browser vendors" lumping-in is a bit weird. The only browser vendor that did not support XHTML was IE (admittedly a large fraction of the market, which made deploying XHTML hard). But you make it sound like there was some conspiracy of browser vendors to ignore XHTML, when in reality all of them except Microsoft implemented it fairly quickly.