161–170 of 408 posts
I've been working in the tech industry in the US for about 5 years. Ever since I knew myself I've been coding. From middle school to high school, given any problem, like Sudoku, or keeping up daily chores, my solution was Programming! Programming wasy homebase. Then I studied it in uni, thought I was kinda good at it, and loved it. But when I started working in the industry, I realized that it's absolutely exhausting…
While this constant shift may sometimes be seen as tedious or even chaotic, it's also a reflection of our growth as an industry. Each new tool or practice arises from the shortcomings of the previous ones. Serverless wasn't born in a vacuum, it was born out of the limitations of servers. Microservices weren't born out of nothing, they came from the monolithic application era's shortcomings.
The key lies in discerning between meaningful progress and trend-induced churn. Not every new tool or practice is necessarily an improvement, and even those that are may not be the right fit for every organization or use case.
On a personal level, how can one keep up? Find your anchors in the fundamentals. Concepts like abstraction, encapsulation, concurrency, state management, and others are applicable across a multitude of tech stacks and paradigms.
Earlier quoted context omitted.
why not go further, why can't we just write > although now that ="foo" business seems too noisy. how about > also, those angle brackets are too pointy, let's swap them to something more pleasant (tree (leaf :colour green) (leaf :colour yellow))
The change I suggested is backwards compatible - probably a relatively small change to a single method in parsing. You, on the other hand, took the pre-existing syntax and contemptuously threw it out the window - and completely ignored the advantage of widespread tacit understanding.
I've been working in the tech industry in the US for about 5 years. Ever since I knew myself I've been coding. From middle school to high school, given any problem, like Sudoku, or keeping up daily chores, my solution was Programming! Programming wasy homebase. Then I studied it in uni, thought I was kinda good at it, and loved it. But when I started working in the industry, I realized that it's absolutely exhausting…
> Look I'm not even complaining. But it feels like I'm stuck in a Franz Kafka novel. We just keep changing and changing the same things again and again because that's the new way to do. Big distraction. Destroys your workflow. Forget about all the util scripts you wrote last 6 months being useless. Here's how I stay sane -- I focus on the changes. For the technologies that you noted, here are some good questions that…
- it's quite complicated with a lot of niche issues many parsers don't handle nicely
- it has serious issues when it comes to semantic vs. non-semantic white spaces, this happens to not matter for some applications does does matter a lot for others
- it is in a uncanny valley between being good for human writing and good for machine consumption, for most use-cases there are objectively better formats
- people did ran into endless problems with it. Some at it's fault many more not but still associated with it. This gave it a negative image outlasting hype cycles.
- it needs to compete with JSON, which in many use-cases fails by default no matter if it's good choice or not
- compared to some alternatives there are often way too many ways to encode the same thing, this is also an issue e.g. for JSON, but way way worse for XML
- non us-ascii string encoding..., it's old enough for there to be a bunch of legacy messiness, often you can ignore it but not always
Now there are use-cases where XML was and is used with successful and I don't see that changing, but a resurgence of XML in other areas would IMHO be a failure of the IT industry to not learn from past mistakes. For data serialization (even if human readable) you want native support for maps and fully encoded strings (e.g. JSON), for configurations you most times want something more simple (sadly YAML fails this due to some subtle issues). For huge datasets you probably want something more compact then XML. Still there are some good use-cases for XML where it's many machine processed, but not only, not very little amount of data but not a huge amount, need for a lot of annotations, need to coordinate changing schemas of "cold stored" files of that format between different companies, mainly used for encoding in a file, not between life communicating servers. I.e. UI encodings without a custom language, some but not al cases of scientific data, dumps of complicated configurations normally never writing by humans, but sometimes inspected by them.
But please never again tightly couple it with security schemas, especially the way strings are handled in XML makes that a terrible choice for such use cases. And it's also not a grate choice for any life communication between programs.
Earlier quoted context omitted.
The change I suggested is backwards compatible - probably a relatively small change to a single method in parsing. You, on the other hand, took the pre-existing syntax and contemptuously threw it out the window - and completely ignored the advantage of widespread tacit understanding.
Don't sweat it, it was a joke (turning your sample into LISP)
I do however want to write a dialect of it, though mostly for the sake of naming it 'Lithp'.
I worked a decade in public sector digitalisation in Denmark, where for some reason they still use a lot of SOAP and thus XML. I’m not so against XML in theory, but I hate it in practice. You’d have these completely over engineered solutions where you’d basically need to call a separate micro services for every “field” of anything. So if you wanted a name, a ssn, and, an address for a citizen you’d need to make sever…
I think "XML" is way too broad to meaningful discuss anything. XML the data format is pretty great in its basic form. Not space-efficient, but unless you're dealing with bulk data, the inefficiencies don't matter unless you're googlescale or can't spare a millisecond. The format itself doesn't absolve you from the design work of your model; your ssn example is typical of the "CEO said we have to use XML now" rush-job…
I don't understand what you mean by this. JSON supports schemas which can be used to validate input. It's not super advanced, but it's functional.
Earlier quoted context omitted.
You could say the same about JSON. It is arguably closer to how and AST is represented in software as it does not posses the two dimensional notation like XML does. The unique thing about XML is that you can both have children and attributes. My guess it that this is to model OOP-based systems: Attributes are for the constructor or a certain class while the children represent dependency injections. This is IMHO the w…
> My guess it that this is to model OOP-based systems: Attributes are for the constructor or a certain class while the children represent dependency injections. Can't say I've ever thought of it that way - attributes just seemed like a simpler syntax for the common case of basic properties that were sensibly represented as strings (i.e. single, literal values). I don't think it would have made much fundamental differ…
as can be seen to the comments to to my comment, there are quite a number of ideas on the ontology of the XML format. when a single screen worth of text on my phone can hold at least 3 strong convictions on how to use a format, then it is doomed to fail.
It's easy to just mark XML off as one of the many fads in tech given how many there are. But I think it's much more worthwile to dive into the particulars of why it failed. While they're all fads, some of them share commonalities that, in hindsight, I think we can say were major catylsts to their downfall. With XML, it failed because something like JSON was much simpler. Time and time again I see people saying that j…
I disagree. XML isn't that complex. I think it failed because: * It's overly verbose. All those closing tags, ugh. * The data model is not actually what people want most of the time. People are transferring objects, not documents. The fact that XML doesn't have a proper way to represent maps, and you have the redundancy of attributes, inline text, etc... There's a huge mismatch between the data model of XML and the d…
Earlier quoted context omitted.
There is. It's called "the market". A company that wastes too much time and money on non returning investments will not last.
Every non-startup wastes incredible amounts on fads and other inefficiencies while still lasting perfectly fine. It's just business as usual. I could probably save my current largest clients many millions/year on dev if the CTO (& his tech leads) wasn't such a fad guy; he basically pops on Twitter every morning and starts sending over 'new stuff the team should look at'. There are 1000s of applications in that compan…
I don't see anything wrong with it. This is basically how evolution works as well. Take 99% of a proven thing, randomize 1% and then either keep the change or discard it later as not useful.
A lot of things which are now proven successful ideas were once indistinguishable from fads.