621–630 of 688 posts
Earlier quoted context omitted.
I remember being warned about engineers that get used to using frameworks too often. Their ability to work outside of it eventually suffers. We might need less abstraction, and let the engineers work that out.
Yeah, I'm all up for writing everything in machine language using punch cards. Anything else is clearly too much abstraction and obviously a sign of bad engineers.
My theory is that everything is a mess, once you get close enough to notice. Every profession that appears as if its practitioners know what they're doing really is a shocking hodge-podge of temporary solutions, strung together by proverbial duct tape. From doctors to flight engineers to anything else that you thought was running like a smooth machine. Programming is no different.
At the lowest level, things are definitely a horrific mosaic of "temporary solutions, strung together by proverbial duct tape". The good news is that there's a good bit of oversight. Even if my analysis on a flight-critical component is a complete and total abuse of physics (either due to my own incompetence, rushed schedule, or limited budget), it still has to go through my manager, an internal review (with many other experience engineers), validation testing (limit load testing, vibration characterization, etc.), and a third party review by a regulatory agency ALL before first flight. Does it take a while? Absolutely, because the consequences of an incorrect air-frame structural analysis can be dire. Is it perfect? Not even close, but it's pretty good. When field issues DO arise, we have a failure investigation team that works around the clock to address the issue. And this is for unmanned aircraft--in commercial it's even more rigorous. Spacecraft? An even higher level or rigor.
When aeronautical / aerospace engineers DO screw up, you definitely hear about it--usually because lives are lost. A single failure can lead to a company going under and being purchased by a competitor as seen in the consolidation of aerospace companies[0]. In most web programming applications, mistakes are much more forgiving. At worst, a bad commit makes it to production code which usually only manifests as lost revenue (either through security breach, downtime, loss of consumer confidence, etc.). I have to imagine that production code on a medical device (say a pacemaker) is more heavily scrutinized than JavaScript includes in a header file, but I could be wrong. Web is a VERY fast industry because it can afford to be--the reward for using new, bleeding edge technology, is often worth the risk because at the end of the day it's all financial.
I do think "everything is [sort of] a mess, once you get close enough to notice". Some other articles on the phenomenon: 1. Everything is Broken [1]: Since programming technology moves so fast, everything is literally strung together because "if it works, it's good enough".
2. Programming Sucks [2]: Everyone has an opinion and since programming is literally working with pure thought, it's objectively difficult to get people to agree.
3. The Expert [3]: Communication between managers and engineers is (and always has been) terrible--having people who can bridge this gap can really make or break an organization.
4. Apathy [4]: At the end of the day, most people are just collecting their pay check and don't care that much. 5. Bullshit Jobs [5]: Most jobs are not really mission critical.
[0] https://theblogbyjavier.files.wordpress.com/2012/09/3874434....
[1] https://medium.com/message/everything-is-broken-81e5f33a24e1...
[2] https://www.stilldrinking.org/programming-sucks
[3] https://www.youtube.com/watch?v=BKorP55Aqvg
[4] http://www.hanselman.com/blog/EverythingsBrokenAndNobodysUps...
Honestly, pretty much everything is hacks on hacks. As a kernel hacker, hardware is hacks, firmware is hacks, kernel is hacks, it's turtles all the way down. The fact that anything works at all is a miracle. Some systems are better than others, but everything has some duct tape somewhere. Designs and algorithms are abstract, the implementation is never as nice. We as engineers have to make the best of what we have, a…
Could you go more into why hardware is hacks?
Earlier quoted context omitted.
Maybe I'm missing something, but that looks like SQL Injection ready to happen.
sql.query is a function that will receive two arrays, one is the strings part, the other is the injected values... the template processor takes those arrays and turns it into a parameterized query to the database.
Earlier quoted context omitted.
> You can pick a nice ORM (like sequelize) I'm gonna stop you right there. Node is a helpful tool and I enjoy using it, but Sequelize was nothing but pure pain when I used it. You're much better off running raw SQL, or using a query builder like KnexJS. I would never use Sequelize for more than a 1-table read or update.
honestly, in JS/Node, I find it easiest to use a SQL adapter that can handle template strings as parameterized queries... const results = await sql.query` SELECT ... WHERE foo = ${bar} `; if (!results && results.length) return; await myQueue.add(results); Which works unbelievably well... There's not nearly as much need for boilerplate/translation layers in what is already a dynamic environment. I wrote a wrapper for…
Earlier quoted context omitted.
>they sort of force you into a way of thinking that results in a better creative process and ends with better code. That's the first time I've heard that about React, can you elaborate?
Maybe it's just me, but when I'm working in React it really forces me into a more "modular" way of writing things. Sure, I'll write something as a huge file that's a couple of hundred lines but React makes it _incredibly_ easy to step back and refactor to start pulling things out into modules. I guess it doesn't quite _force_ you into thinking a certain way, it just encourages writing code in a more modular and reusa…
Earlier quoted context omitted.
Windows might have its own baggage, but with Windows 8 they have brought the original design of .NET from the ashes and assuming the current path is to maintain, those of us that like Windows will have a nice OO ABI alongside safe languages compiling to native code. All the mobile OS relevant APIs don't have anything to do with UNIX. All the Objective-C, Swift, Java, JavaScript, C++ APIs available on those OSes don't…
I mean, I like C#, but that stuff seems to me to be sitting several levels above the OS anyway.
Also I didn't mention just C#.
Earlier quoted context omitted.
And I have to disagree with you. Doing UIs in native frameworks like JavaFX or even in a pure C++/WinAPI, is much more saner than doing any kind of UI in HTML/CSS. Ignoring flexbox for a second, which is kind of bleeding edge new thing, remind me - how exactly do you vertically center stuff with CSS? :P. My two main issues with doing UIs on the web are: - web stack is terribly unpredicatable; you're trying to force a…
> Ignoring flexbox for a second Not ignoring Flexbox, this is the crux of my problem with web development. There are 8,476 different frameworks, transpilers, toolkits, and what have you that all kinda-sorta do the same things. When first approaching this world you get confronted with alphabet soups of packages all combined to "make front end development sane". Everybody seems to have their own soup, though, and many…
If they do the same thing, pick one and dig in. I really don't get this argument - walking down the cereal aisle will not generate this amount of antipathy despite the amount of choice available; why on earth should development different?
The optimal taste, texture and crunchiness is different for everyone, you can even default to the traditional oats or corn flakes if the newfangled cereals are too brightly-colored or too confusing for you[1].
I love the JS ecosystem and its Cambrian explosion - lots of ideas (good and bad) being tried out by other people[2] and the good ideas tend to be adopted by the more mainstream projects.
1. This is obviously a thinly veiled allusion
2. This is important - don't be the guinea pig and don't jump onto the latest and greatest.
Earlier quoted context omitted.
> Ignoring flexbox for a second Not ignoring Flexbox, this is the crux of my problem with web development. There are 8,476 different frameworks, transpilers, toolkits, and what have you that all kinda-sorta do the same things. When first approaching this world you get confronted with alphabet soups of packages all combined to "make front end development sane". Everybody seems to have their own soup, though, and many…
> Not ignoring Flexbox, this is the crux of my problem with web development. There are 8,476 different frameworks, transpilers, toolkits, and what have you that all kinda-sorta do the same things If they do the same thing, pick one and dig in. I really don't get this argument - walking down the cereal aisle will not generate this amount of antipathy despite the amount of choice available; why on earth should developm…
If I don't like the cereal I've wasted a couple of bucks. Picking the wrong framework can be much more costly in terms of time/money. And with the amount of framework churn you can't even make a good decision because in two years time everyone's moved on to the next big thing.
Earlier quoted context omitted.
> Node allows you to run isomorphic JavaScript that runs on both your server side and client side But then you're writing JavaScript on the server side, and I think I'd rather shove live weasels down my trousers than write one line more of JavaScript than I absolutely must.
JavaScript sucked indeed. ES6 though, has brought many improvements, and the language now is quite decent. With the advent of async/await in ES7 (which is available now if you transpile with Babel), the callback hell is completely gone, and the language is actually beautiful, powerful, and concise.
And in Javascript, it's still a nightmare importing a file. You either have a or you are on nodejs.
