I don't think that's universally true though. An example would be Logic, which Apple kept improving after buying it and it's still a great piece of software.
I don't think so, but imho it would be a no-brainer to have .cursorrules files support the same @Web @...files, @Docs syntax which cursor already has in Cmd+K
Reminds me of Action Script 3 which had XML at the core of the language. It was a fun language to work with, but famously failed to become ES4. Oh well, took us 10+ years to arrive close to that with Typescript and JSX.
https://en.wikipedia.org/wiki/ECMAScript_for_XML - Firefox had it too, but people at large just didn't want it, so it got removed. It got disabled for web pages with the release of Firefox 17, 6 months prior to the first release of React.
People didn't want it because browsers didn't support it (except FF, as you noted). Some of us had our fingers crossed that other browsers would pick it up.
I don't recall being able to do the XML construction inline either, but that just might be my memory.
However, the XML selector syntax was a godsend. Recursively parsing an XML tree is really a pain. E4X would allow you to do things like:
var foo = someXml..childNodes.@attribute;
I'm not even sure if that would work actually. There were a bunch of operators for doing things like getting a collection of children that all had the same tag so you could work with XML like:
Another post here said people didn't want it, but I don't think that was the real reason it was dropped. There was a lot of drama at the time about Flash in general and a massive debacle about EcmaScript 4 (which ActionScript more or less adopted). There was also the whole XHTML thing happening.
Basically JSON as a format won out over XML and ES4/XHTML were ditched. Frankly, a world that revolved around XML/SOAP would have been a nightmare, so I guess killing off the easy processing of XML in JavaScript helped to stave off that potential future. XSS, XSLT and E4X were all casualties.
I think parent must be referring to Flex components. AS3 itself had an XML library which I recall being absolute hell to work with. The better way to send things over the wire with AS3 was with AMF.
Nope. I worked with Flex and it's MXML files extensively. But the parent is talking about E4X, which was an extension to ECMAScript that allowed you to use XML elements inline with JavaScript in a manner VERY similar to how JSX is used today. It also included the ability to much more easily query and otherwise work with those XML document trees in native JavaScript.
Same in Zurich, where the city tries to establish a “Schwammstadt”. But the tree growth is actually negative, because on private properties people are chopping down their trees to build lucrative housing.
If you look at bellevue i personally think it's disgusting, that loveless massive sechseleutenplatz, lot's of cars always using the horn, what a waste of that iconic place constricted between traemli and a always busy street, tbh even Delhi is less stressful, let alone Vienna.
EDIT: Do you mean Schwanstadt right? That lovely smell of birdshit in the sommer plus the massive stink of piss and puke after (and up to 10 days) streetparade is the pure soul of Zurich ;)
No, he means "schwammstadt" (sponge city), the concept idea that you need to create the capacity to soak up excess rainfall and store it like a sponge instead of relying on drainage entirely.
Which isn't a bad idea generally, but for cities like Zurich (and its sister city Geneva which is the same also in this regard) there isn't much need - it sits at the end of a massive lake, most of the city center isn't much higher than lake itself.
Effect of the lake subsides somewhat with distance form it, but it definitely creates its own micro-climate thats always colder and more humid than further away from it. To have more high trees that prevent all that tarmac, concrete and stone from heating up during day is definitely a plus, but these cities are not some scorched Phoenix, AZ equivalent.
Berlin, one of the leading cities in Germany on those concepts is located on two rivers, plenty of canals and between a few lakes. Hamburg is another very active place and it's close to the seaside, with a huge river and plenty of water in the city. A lot of concepts refer back to city planning that Kopenhagen started after a massive rainfall event in 2011 - a city which is fairly flat, has a large river front and plenty of canals.
Still, there's need to evaluate such city planning concepts because the lakes and rivers do not solve all of the problems associated with heavy rainfalls and drought cycles. They do nothing to handle the runoff if you get massive rainfalls in a short period of time because the water management gets overwhelmed. Also, city trees do not benefit substantially from the high ground water level and still suffer in drought.
So while not all of the concepts ideas may be applicable to Berlin, Hamburg, Kopenhagen, Zurich or Geneva, concepts like green roofs, local water storage etc. are still required to respond to the incread frequency of high rainfall events and increasing summer temperatures.
I'm so old I can still remember when Sechseleuten Square was green grass, now replaced with searing heat assemblers of stone....so even the city is working against that sponge thing, but yeah it sounds good from a politician's mouth.
Just 17 milion swiss franks made out of "Valser Quarzit" and a "fountain" that needs constant maintenance because it has to be drinking quality instead of lake-water, just look at that sh*t:
Or a bridge/tunnel before bellvue, and make the whole bellvue+niederdoerfli up to hauptbahnhof carfree...just imagine that! But yeah you are right with those Lärmblitzer too.
Exactly, I've seen this at Sentry where you now have to run Kafka, Clickhouse, Redis, PG, Zookeeper, memcached and what have you. I get it, but the amount of baggage to handle is a bit difficult.
You can slice it and dice it any way you want, really. The constraint is often what data needs to be written within a transaction. You'll have to figure our a way to reliably apply a consistent schema to all these database files somehow and keep track of them.
One of the things I appreciate about SQLite is being able to keep all the schema initialization and upgrades in the application itself, which are then checked into git and can be tested like mad with throw-away copies of the data.
Here's a package in golang I wrote to help with that process:
My city has something similar based on fixmystreet, which is not focused on discussion but more on reporting: https://www.zueriwieneu.ch/reports
I love that my city responds so quick to any issues reported. Usually you get a reply the next day, and minor things are usually resolved within the week. One time a guy even facetimed me to figure out the exact spot where some metal was sticking out of the ground near a playground, which I had reported.
