-
BSON fixes some of that shit but just use protobufs or something instead.
Binary. Yuk. I can see so many annoyances with that. Like having to use form-mutlipart MIME and all that good stuff over HTTP. Needing encoders, decoders and having binary blobs in your unit tests.
XML is just too bloody heavy and slow or cumbersome to parse/generate. -
(*) Most of which confuse the DOM with JS, and/or can't grasp why JS is no C nor JAVA: different scoping rules, closures, prototypal inheritance, no classes, asynchronous/evented execution, etc.
We can disagree on the language. I worked with developing Javascripts frontends for several years in the past and I still hate it.
It's really scheme or closure with scheme/closure crossed out and Java written in as a marketing ploy. Until the ECMA standards came in it wasn't really a language at all, it was a collection of hacks each one different in each browser. In part it STILL is. It's just that we have frameworks today that hide this and work around the browser implementation oddities.
There is your error, again: JS is and has always been 100% compatible among browsers, the DOM is what is not.QuoteIt's dynamic typing is fairly retarded and sometimes extremely irritating. The scope is bonkers. Everything seems to be a function that takes a function as an argument and returns a function that takes a function as an argument. Recursion and callback-tastic. It's object orientation is just broken.
Dynamic typing is fine, automatic type conversion (casting) not so much, you've got to be careful and know what you're doing or if not avoid it altogether, which is easy to do.
The scope thing is not a problem unless you tend to write too long (in LOCs) procedures (functions), which is not a good idea anyway.
The everything is a function and the callback-tastic thing you mention is done exactly like that in C too when/if your program is event-driven, but, as C has no closures you've got to create tons of structures, or objects in C++, in which to save the context that you've got saved for you for free, in the closures in JS.
Wrt the objects, that's what people coming from classical inheritance repeat ad nauseam, but you know what? More often than not there's no need to classify objects, nor any need to declare classes, and most of the times you don't even need your objects to inherit nothing at all. And there you go: in JS you can simply create them as you like as you need on the fly at runtime (procedurally not declaratively) without any hassles.
As I said before "haters can't grasp why JS is no C nor JAVA: different scoping rules, closures, prototypal inheritance, no classes, asynchronous/evented execution, etc." and you've just now proved my point again.QuoteThe only good thing that came out of Javascript was JSON, which thankfully shut the XML fan boys up enough that we managed to get away from slow, verbose, cumbersome DOM structures and immensely inefficient parsing.
Yep, and this is what Dave Winer (of xml fame) had to say about it: "Who did this travesty? Let's find a tree and string them up. Now.". Lol, nobody sane uses xml anymore. -
We still use XML. Find me a better interchange format for financial data. One that doesnt have arbitrary precision depending on which vendor’s butt you sniff, has full schema validation, signing, binary embedding that we can stream on the fly about 50 gig of it in one stream with an event driven parser...
Thou who doesn’t understand XML is doomed to reinvent bits of it poorly.
Dynamic languages can fucking die. We’re too dumb to even manage strict typing. Let’s make things even less correct so the monkeys can dance around the pile of shit that has been created (incidentally I’ve written hundreds of thousands of lines of python and it’s horrid).
As for JavaScript, it barely works. It’s the next php. -
Well yes perhaps banks can't change, but paypal is 100% xml-free.
-
Dynamic typing is fine, automatic type conversion (casting) not so much, you've got to be careful and know what you're doing or if not avoid it altogether, which is easy to do.
If it's only easy to avoid, then with enough programmers and enough LOCs it won't always be avoided in the end. That's why large companies have been forcing statically typed variants on their programmers. Not possible is better than easy to avoid. -
But static typing only saves you of a very tiny % of program errors and can generate others of its own (e.g. could not load this or that DLL version), so I gladly prefer to be relieved of the slavery of having to choose and type every fucking var type beforehand for not much benefit if any. And I'm not saying it's not ok for C and systems programming, I'm just saying that for apps and the web it's not a must, it's more a needless hassle.
-
Well yes perhaps banks can't change, but paypal is 100% xml-free.
PayPal’s logic and use cases are pretty trivial in the scale of things. They just do a lot of trivial things at once.
Try financial compliance or product sales. That’s a different ball game. -
But static typing only saves you of a very tiny % of program errors and can generate others of its own (e.g. could not load this or that DLL version), so I gladly prefer to be relieved of the slavery of having to choose and type every fucking var type beforehand for not much benefit if any. And I'm not saying it's not ok for C and systems programming, I'm just saying that for apps and the web it's not a must, it's more a needless hassle.
Unfortunately Javascript has migrated to server side. Dynamic typing with automatic casting is one of those features which just have an inordinately high chance of creating exploitable bugs, doesn't belong on anything internet facing which deals with sensitive data. -
Try stock exchanges order entry or market data. Most systems will have raised a dozen orders before your Sax parser has parsed the first message. FIX or binary variants.
XML is great for B2B communications when neither end could previously agree on a standard format let alone properly publish what they format actually is. Now everyone has an XML Schema for their messaging and if you don't like it pass it through XLST and make it what you want. But... it's incredibly expensive. On the wire XML is usually 60-80% meta data.
It's all tools for the job. You don't put an buck converter into a 12V circuit to run a 3.3V MCU that pulls 20mA. Yet some people hate linear LDO regs and vice versa.
If you want to grep a log file and produce a summary or extract a one flow from 100 concurrent ones, you don't write a C program to do it. You would use perl or python.
The more tools you have in the box the better, as long as you know when and where to use them. If I need to do something dynamic in a browser I will use JS, but I won't like it. I still wish there were better alternatives.
And... as to JS <> DOM. Can you explain to me what exactly you can do with JS in a browser that doesn't involve the DOM? It's a bit daft saying that JS is fully 100% compatible across all browsers, it's the browsers that have different DOM and Window and API implementations etc. etc. Without those things JS is pointless and mute. -
Unfortunately Javascript has migrated to server side. Dynamic typing with automatic casting is one of those features which just have an inordinately high chance of creating exploitable bugs, doesn't belong on anything internet facing which deals with sensitive data.
Nice try, sounds good, seems plausible! But no. And again, Paypal... for example (and a zillion other online businesses).
https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/ -
And... as to JS <> DOM. Can you explain to me what exactly you can do with JS in a browser that doesn't involve the DOM? It's a bit daft saying that JS is fully 100% compatible across all browsers, it's the browsers that have different DOM and Window and API implementations etc. etc. Without those things JS is pointless and mute.
That one is easy: without the DOM (*) JS can do nothing.
(*) this is from the ecma specification. JS (the language) provides no means for I/O, look:
"Overview
This section contains a non-normative overview of the ECMAScript language.
ECMAScript is an object-oriented programming language for performing computations and manipulating computational objects within a host environment. ECMAScript as defined here is not intended to be computationally self-sufficient; indeed, there are no provisions in this specification for input of external data or output of computed results. Instead, it is expected that the computational environment of an ECMAScript program will provide not only the objects and other facilities described in this specification but also certain environment-specific host objects, whose description and behaviour are beyond the scope of this specification except to indicate that they may provide certain properties that can be accessed and certain functions that can be called from an ECMAScript program."
JS on the server side (node.js) has no DOM, but provides other objects to do I/O (that are not part of JS "the language"). -
What have I triggered...
-
But static typing only saves you of a very tiny % of program errors and can generate others of its own (e.g. could not load this or that DLL version), so I gladly prefer to be relieved of the slavery of having to choose and type every fucking var type beforehand for not much benefit if any. And I'm not saying it's not ok for C and systems programming, I'm just saying that for apps and the web it's not a must, it's more a needless hassle.
Static typing is very useful. Nothing, including static typing, is a complete panacea.
Thus spake someone that hasn't had to contend with "doesNotUnderstand" messages (or more recent variants of the same concept!) appearing at runtime - rarely and unpredictably. Doubly so when part of the code that might be the cause was written by somebody else in a different company that no longer exists.
Thus spake someone that, when trying to use such code libraries, hasn't cottoned on to the wonders of accurate cntl-space completion. -
Ohh yes, the wonders of auto-completion: when in doubt hit ctrl-space.
-
Followed by Visual Studio has stopped responding.
-
Ohh yes, the wonders of auto-completion: when in doubt hit ctrl-space.
More than just "when in doubt" - also very good for "I can't be bothered to type all that" methods of reducing risk of RSI!
I've never understood why people rail against Java for too much typing, since that is very significantly reduced by cntl-space. My best guess is that they have come from a C/C++ background where autocompletion can never be as good. -
Indeed. Cut and paste and Ctrl+tab your way to a finished product.
Java is really just glue for all the nice canned libraries out there that do all the hard stuff. When knocking anything Java out I have to write very little code. I mean hardly anything. Data import, meh import smooks and cut and paste for 20 minutes and you've got CSVs, XML being streamed into hibernate ... -
Indeed. Cut and paste and Ctrl+tab your way to a finished product.
Java is really just glue for all the nice canned libraries out there that do all the hard stuff. When knocking anything Java out I have to write very little code. I mean hardly anything. Data import, meh import smooks and cut and paste for 20 minutes and you've got CSVs, XML being streamed into hibernate ...
I've never been able to cut-and-paste my code!
But the not having to write much Java code is significant. When I started using it (in 1996/7 when it had only just been released) I was pleasantly surprised at how easily I could obtain interesting relevant special purpose high-quality libraries in a way that had C++ had failed to do in a decade. And all the libraries played nicely with each other, cf C/C++.
A very pleasant vindication of my belief that Java was worth learning - in a way that Delphi/C++/C# weren't. -
Nice try, sounds good, seems plausible! But no. And again, Paypal... for example (and a zillion other online businesses).
What about PayPal? They use Java server side.
Meanwhile Facebook, Microsoft and Google all have their own version of typed Javascript (with a few more out there). -
It's all tools for the job. You don't put an buck converter into a 12V circuit to run a 3.3V MCU that pulls 20mA. Yet some people hate linear LDO regs and vice versa.
Actually, there do exist micropower buck converters for where even that tiny amount of power matters.
https://www.maximintegrated.com/en/products/power/switching-regulators/MAX17530.html -
Come the revolution we kill the programmers first. The lawyers can wait.
Seriously, having spent a lot of time fixing a few million lines of other people's code, I have little more than contempt for most programmers' work product. I wrote a couple of 15,000 line libraries that had NO bugs found in almost 20 years of use. Can it be done? Yes. Is it easy? No. You actually have to care about what you do. And write meticulous test cases.
My most outrageous experience was a conversation with the support guy for a piece of software my employer paid $80,000 a year in support costs. I had gotten involved when it would not work on multiple systems. After several days of BS, the guy said, "If you find a fix, please send it to me so I can give it to the other customers." They had to peel me off the ceiling with a putty knife.
I've got 80 feet of computer books to go with my attitude. And, yes, I've read them, except for things like the X11 and Motif manuals which are just for reference. -
The big issue is when there is no failover plan or redundancy. In this case, something as simple as tracking number of calls should NOT actually affect the possibility of those calls going through. Zero reason for that. It should raise an alarm that the service that tracks it is not working but the calls should still go through.
Software/technology should enhance things but those very things should still be designed in a way that they can work without those enhancements, if they are life critical.
I've worked IT in a hospital and it's scary how many critical things rely on some crappy piece of software running on an old Dell Optiplex GX1xxx era PC sitting inside the ceiling or behind a desk somewhere that nobody really knows about - not even IT.
I work in telecom now, and it's incredible how redundant and robust stuff is designed - especially the older stuff like DMS switches. -
I've got 80 feet of computer books to go with my attitude. And, yes, I've read them, except for things like the X11 and Motif manuals which are just for reference.
I think you mis-spelled "... for punishment". -
I work in telecom now, and it's incredible how redundant and robust stuff is designed - especially the older stuff like DMS switches.
Yes indeed. Until you see how various systems are patched together.
The top-level deployment level diagrams for telcos resemble cold spaghetti. There are even companies that make software whose sole purpose is to connect two different systems together. -
Java is really just glue for all the nice canned libraries out there that do all the hard stuff. When knocking anything Java out I have to write very little code. I mean hardly anything. Data import, meh import smooks and cut and paste for 20 minutes and you've got CSVs, XML being streamed into hibernate ...
I like to make an analogy with those fancy 'Corian' or whatever kitchen worktops - mostly made up of ground-up hard stuff like quartz or granite, bound together and made shiny by the smallest possible quantity of plastic resin. The hard stuff is like the libraries, the soft resin is the code you have to write make it all stick together and look shiny.