Then you'll need to create own version of migrations, routing, configure asset building pipeline etc etc etc. Phoenix have everything in place, without need to re-implement lots and lots of basics
I think you’re making the mistake of equating Christianity and Catholicism. They have the same roots but all of the things you’re assigning to Christianity is really the machinations of ‘The Church’ weilding Christians beliefs as a cudgel for the aspirations of ruling bodies.
There is definitely a fine line between the two that is often blurred, but Christianity at its core is about people who are oppressed finding freedom in faith. It’s one of the reasons it is easy to ‘spread’; every culture on earth has oppressors and oppressed.
I think your other point is super interesting however, in that when the oppressed are ‘free’ and become the majority, Christianity doesn’t have much to offer and then becomes the weapon of the ruling class ( or majority ) keeping people ‘in line’.
> "I think you’re making the mistake of equating Christianity and Catholicism. They have the same roots but all of the things you’re assigning to Christianity is really the machinations of ‘The Church’ weilding Christians beliefs as a cudgel for the aspirations of ruling bodies."
I grew up in the rural South. I assure you churches serving as the cudgel of ruling classes is not limited to a single denomination. Catholics are barely represented here, the pattern is nevertheless the same.
I think you'll find that historically, due to the interference from Rome, Catholicism was the denomination that resisted this the most, and that this was in fact a large part of the reason for Protestantism to come into existence in the first place.
Completely agree, I'd dive in with both feet. The lame hardware support still bothers me. I remember being amazed at being able to restart servers, like say if the sound died. I've been watching Haiku and the progress...
And this comment is just a subtextual justification for making sure you still feel valued for not doing anything unusual.
This could go round and round. The point is that there SEEMS to be a correlation with people who learn things for the sake of learning them and folks who do well at exercises that test for adjacent skills.
you still feel valued for not doing anything unusual
I didn't really express any thoughts or feelings about doing unusual things, real or perceived. Doing unusual things can be great! Telling yourself you are awesome can also be great! I do think, though, that the type of thought expressed in the "The Python Paradox" and related writings (say, the bit about blub language programmers) is pretty lousy. It was lousy then and has aged even more poorly.
Or someone who lives in SF and likes doing startups, or someone who is terrible at finding a position that is the right fit for them, or someone who is terrible at recognizing terrible working environments, or someone who...
Obviously you're being sarcastic, but they're not just dumping netgear routers on walls and saying "TADA! MESH!"... They're actually using industrial grade equipment to do this.
I missed the "industrial grade equipment" part in the arcticle, TBH. In fact I saw no real technical details at all. "Mesh" isn't even really defined. You'd think they'd at least mention what firmware they're running on their gear to implement "Mesh".
What're they going to say? "CORBA was a giant shitpile and created tire fires for several years but since this is an academic paper, we have to present historical context for our ideas"...
Your CORBA experience depended on how you used it. If you used the IDL and messaging and plugged in your own backend it could work quite well. People are still reinventing new IDLs to this day.
Just like RMI, CORBA was fine if you knew the boundaries where distribution started/ended. The issue with CORBA was the transparency and was apparent since NFS. If you used CORBA tastefully, it was fine.
People have been reinventing IDLs since forever and a day.
S-expressions are the oldest serialization format that I know of. ASN.1 is a fairly ancient IDL that was used for RPC back in the early 80s (ISODE/ROSE). There's ONC RPC, with XDR as the IDL. There's DCE RPC (and MS-RPC). And many many many many others. There's tons of serialization formats, and they all tend to have one or more related sort of RPC frameworks, ad-hoc or otherwise. Perl5 has several, no?
This is the space of NIH.
Take protocol buffers. It's supposed to be an anti-ASN.1, but it's actually remarkably similar to ASN.1's DER (distinguished encoding rules), which means it has lots of the same mistakes. It's all very sad.
If you actually read the paper, we talk about ASN.1 and why it's insuffient for what we are doing. That's clearly stated, and it's clear you didn't read that paragraph.
I was responding to a comment, not TFA. I had not read TFA at all at that time. Looking at the one paragraph that mentions ASN.1 (skimming the rest for context), I cannot help but wonder how familiar you are with ASN.1. SNMP is not a good example of how to use ASN.1. To be fair you're referencing a paper that discusses SNMP's use of ASN.1, but... you say nothing at all about how ASN.1 is inadequate, or what might be missing from it! What gives. Did you actually read anything about ASN.1? Did you even skim the ITU-T x.68x and x.69x document series?
[EDIT: I missed the second citation about why ASN.1 is inadequate. I will have to read that, though I'll admit that I am skeptical. Keep in mind that ASN.1 has been extended over time, so that one good question might be: what is missing that cannot be added? This is especially a good question when the alternative is to start from scratch.]
Note that I am [and my earlier comment certainly was] not defending or promoting ASN.1. I am saying that we have had a lot of reinventions of IDLs.
Now I'm also adding that a lot of ASN.1 haters don't really have a clue about ASN.1. Typically what they hate is a) the tag-length-value encoding rules (but not all ASN.1 encoding rules are TLV!), BER/DER/CER, and b) the syntax (which, whatever, it's just syntax).
The ASN.1 haters completely miss out on: the rather vast literature on encoding rules (including PER and OER which most closely resemble XDR), advanced features (e.g., the Information Object System), and especially the related SDL (which, granted, I believe simply hasn't had much use at all, at least that I'm aware of, but it's a very interesting idea that deserves more study). Instead, the ASN.1 haters generally produce or choose alternatives which either have roughly the same darned problems (Protocol Buffers, I'm looking at you), or a completely different set of also-obnoxious problems (e.g., JSON's escaping requirements for strings).
And so the circle of NIH [bad] wheel reinvention goes.
Another common objection to ASN.1 is lack of open source tooling. However, this is not really true anymore, with several decent open source ASN.1 compilers in existence. Of course, if you choose to invent a new IDL, then initially there will be no open source tooling for it!
I'm perfectly happy to not use ASN.1. I'll be perfectly happy if someone else doesn't use it. I'm not happy to see ASN.1 haters toss the baby (ASN.1's good ideas) out with the bathwater only to then reinvent the wheel badly. Your exceedingly-light on the evidence dismissal of ASN.1 is par for the course, and does not help.
EDIT: Note that I'm not calling you an "ASN.1 hater".
I have looked at that second reference[0] (your reference [9]). That's a paper from 1994! The ASN.1 Information Object System was brand new, as well as parametrization, and the paper does make use of them. That paper does not even reference any of the ASN.1 specifications(!) -- this is infuriating but understandable given that those ITU-T specs were not freely accessible back then, which is even more infuriating, but still, you'd expect academics to still include references to them, and even to purchase access.
More importantly, there are NO conclusions in [0] (your [9]) that would support your dismissal of ASN.1. On the contrary, I would think it's the opposite. My conclusion is that you did not read your own references and did not do the research you should have done. This is, of course, par for the course in this sub-field of computer science. Everyone seems to always think they know better without actually making sure that they do. Some of this, of course, is due to the sheer cognitive load of the literature to which you and everyone else seem eager to add without doing anything to make it easier on the rest of us. You've taken the easy, lazy path. I'm not expecting you to do a full survey of IDLs, and I'm not expecting you to look at ASN.1 and say "aha! they have all the answers", but I am expecting you to have more than no idea about it when you reference it, or if you're going to use a reference as authoritative for some statement, make sure that it actually is.
If I've made a mistake chasing down references, please let me know. I'm eager to understand why you reject ASN.1. I'm particularly interested in what it is missing or does badly. Thanks.
I still think the saddest thing I ever saw in the wild was a Smalltalk shop using CORBA. Doing IDL for Smalltalk VM to Smalltalk VM communications is just wrong.
If I have a Smalltalk VM and I'm only talking to other Smalltalk VMs then a native Smalltalk solution without the foolishness of using CORBA is preferable. Its just an insane bit of added plumbing.
Having at least your interfaces defined in something resembling DCE IDL can give a useful amount of confidence that the system could plausibly interop with something else. (RPC, COM, etc.)
First, its something you don't need at the start (and frankly they didn't need for at least a decade), and it not only complicates the code, it also complicates the maintenance and support burden. Interop is probably going to be some other mechanism and should be done only when you need it and have a clear understanding of what actually needs to be done.
One can call anything "an insane bit of added plumbing" if it's truly not needed, but that doesn't add much to a discussion of distributed applications.
I think it speaks to the complication people add to distributed applications when something like CORBA is on the table without an actual evaluation if it is really needed. It is most definitely not the only solution.
About 4 years ago, I needed a car to drive into the ground that got good gas mileage. I got a pretty good deal on a Kia Rio and I drove it 100 miles a day and it was good on gas and low maintenance. It is just me, so room wasn't an issue.
I suppose I could have bought a Cadillac Escalade and spent a lot more on gas and maintenance while being able to haul a lot of people which would of never happened. It also would have cost quite a bit more than my Rio.
So, its not absurd to buy a Kia if it meets your needs instead of an Escalade, quite the opposite in fact. Just as it is really foolish to use CORBA when all you really need are the facilities already included with most Smalltalks. Just because I'm doing communications doesn't mean I need the big, expensive solution.
I think its totally fair to criticize something, especially if it is part of its design tenets. Just because they designed it for interop doesn't mean I cannot evaluate it for the situation I am in. I've never been one for programming dogma. If I was using NeXTSTEP only at the time, CORBA would never have come up because of PDO.
I would suggest that part of the reason is that it comes across as you having an axe to grind, rather than what you’re saying. The conversation was one party agreeing with you about there not being great treatment options until recently when studies have finally been conpleted with you saying, ‘you’re wrong, my experience proves it, anything you say is an attempt to invalidate my experience’
That is quite probably not at all what you intended but that is how I interpreted that exchange.
The enormous degree to which I am repeatedly invalidated is apparently lost on you. If I were being taken at all seriously then people would be asking me how on earth I am doing this, not being faux respectful on a foundation of "obviously she is full of crap and knows nothing."
Doctors never have any interest whatsoever in how I am getting healthier. They merely assure me it has zero relevance to anyone else on the planet.
That's a very ugly personal attack. And suggesting I am a narcissist doesn't rebut anything I have said, so it sort of admits that you don't actually have a good argument at all.
The level of pure bullshit that is part of the hiring process these days is mind-boggling. An recent example:
I interviewed for company X, where I spent an entire day with more than a dozen engineers, answering the same types of questions over and over again: "Here's our platform, how would you fix it". At every turn, I would speak about X,Y,Z issues that would need to be solved and how this or that technology might be applicable in a broad case. Diligently, in every session, the interviewers were taking copious amounts of notes about what I was saying... NOT how I was doing on the interview, but rather, the content of what I was saying. "How do you spell Corfu?" (as an example).
At the end, they told me they really liked me, and would have an offer for me in the next day or two... Two days passed and they called with "We're sorry, but you're just not technical enough for us".
I basically gave them a free day of consulting.
I'm not sure HOW to fix the problem, but it is definitely getting worse.
Encountered such situation couple of times. Pokerface interviewers asking in-depth questions (e.g. domain knowledge, not necessarily data structures or algorithm smartassery), with minimal feedback. Learning basically. Quite cynical because it's good to talk basically, exchange knowledge and experience - I've always taken it as a common sense. Once I detect pokerface jokers I answer "no clue" for the simplest questions.
You made me realize I’ve been in interviews like that too. This is frustrating to think about. I’m gonna try the “no clue” method with these people, the interview’s a wash at that point.
https://hexdocs.pm/plug/readme.html