281–290 of 369 posts
Earlier quoted context omitted.
I was thinking of arrays of objects, where the keys are repeated for each object in the array.
Then use compression. gzipped json is highly efficient over the wire. https://blog.octo.com/en/protocol-buffers-benchmark-and-mobi... The primary purpose of binary data formats is that they can be parsed quickly and some even allow direct access without a parsing step.
Earlier quoted context omitted.
> So where I would normally tell people who boo php to use whatever language they prefer, and get over it, that's not possible with js. Maybe 5 years ago. For nowadays, I beg to differ: https://github.com/jashkenas/coffeescript/wiki/list-of-langu... A significant amount of the choices there produce generally better-performing code than the hand-written JS, there's also the WebAssembly.
While technically true, don't you still have to debug and diagnose issues from the generated JavaScript? I'd love to write front-end code in anything else, but if I have to know exactly how it gets converted to JavaScript it kind of defeats the point.
Earlier quoted context omitted.
You can always cherrypick advantages and disadvantages to make a language look "bad", or make another language look "better".
what can you cherry pick from javascript to make it look good?
Lambdas, First class functions, and closures are a great feature missing in basically every other popular language (things like Javas lambdas or function pointers aren't even close in real world use).
Proper tail calls is another feature missing from that list and despite some browsers refusing to honor the spec they ratified, it's still implemented in Safari/javascriptCore, XS6, duktape, node 6-7, etc.
The interplay between js dynamic objects and closures is difficult to describe, but a thing of beauty when fully understood. Object literals are also basically unique to js on that list as well.
There's a lot to love about most languages and JS is no exception.
Earlier quoted context omitted.
This is the one criticism of Haskell that in my opinion has no merit. Programming languages are not intuitive. They are a learned skill. You know the saying (sometimes said as a joke) "such-and-such language failed because it didn't have C-like syntax" -- but C-like syntax is NOT intuitive! Reading C code is a learned skill. Maybe it could be amended to "since many programmers learned to program using languages with…
> Programming languages are not intuitive. They are a learned skill. I can teach someone Python or JavaScript in a few weeks, at a casual pace, where they can accept input from STDIN or a file, do some calculations, and produce output to STDOUT or another file. Haskell? I'd need a dedicated fucking thesaurus on-hand for them to grok the paradigm, and it would take a few months before they could achieve the same resul…
Earlier quoted context omitted.
> Programming languages are not intuitive. They are a learned skill. I can teach someone Python or JavaScript in a few weeks, at a casual pace, where they can accept input from STDIN or a file, do some calculations, and produce output to STDOUT or another file. Haskell? I'd need a dedicated fucking thesaurus on-hand for them to grok the paradigm, and it would take a few months before they could achieve the same resul…
That's a fallacy. Just because something is harder to operate doesn't mean it can't be better. Example f1 cars vs normal cars, two propeller ships vs single propeller ones.
Where did I say it "can't" be better?
Earlier quoted context omitted.
Ehhhh...it works okay but the same fundamental serialization problem exists. The fact that dict can be roughly equivalent to JSON helps, but as soon as you start including more complex types you're going to have to use something to handle serialization/deserialization. Which really isn't that complex with Java if you're using a few convenience libraries: gson, orika/mapstruct, lombok all make it a lot less painful to…
The most common issue I run into is with datetime objects, but there are well documented workarounds. For more complex objects such as ORM objects, I think a lot of people use Marshmallow. That being said, I don't have a lot of experience, so I could be missing something obvious. What issues have you had with Python JSON serialization?
I forgive Javascript any "language flaws" it might have. Why? Because the truly beautiful thing about Javascript is that you can write a program, send anyone a URL and they can run it. No compilation, no installation - just open the URL in any browser. No other language in the world can do this in such a universal way. Simplicity is bliss.
Earlier quoted context omitted.
> Web Assembly is not supposed to remove javascript, it is supposed to be used in addition to it when you need high performance. If people try to promote it as a way to not have to use javascript, it will just result in a more fragmented client-side programming situation, where libraries are not available for particular languages, etc. I guess you have been missing the news what is being done in Go, Java, .NET, Rust,…
There's currently zero support for efficient garbage collectors and no Dom API access. Until a few more primitives are added, wasm is a pipe dream. Even once support exists, there's a payload issue. Nobody wants to spend loads of bandwidth downloading runtimes.
It is certainly possible to package a runtime way smaller that the analytics crap most people have to endure.
Unity WebAssembly games are just a few hundred KB.
Who cares about DOM, WebGL takes care of the UI part.
Earlier quoted context omitted.
Haskell is used in the industry, see: https://wiki.haskell.org/Haskell_in_industry You could start your own project. You could contribute to an existing project. You could evangelize Haskell at your job, if possible. All of these are hard, of course. It'll be easier to use a more mainstream language. But if Haskell strikes your fancy, maybe it's worth the effort?
> maybe it's worth the effort? Yep. Sure. Just as soon as I get done shaving this Yak ;-)
Earlier quoted context omitted.
If you don't need to exchange the data with other apps, serialization in Java is actually quite decent.
You still need to make `ObjectStream os = new ObjectInputStream(new FileInputStream(filename))); MyObject mo = (MyObject) os.readObject();` which is the most basic form I can think of (you've got to put in all them bloody `try/catches` as well don't forget, along with `public class MyClass { public static void main(String[] args) { ...` etc. etc.). Whereas javascript you can just go `require(myjsonfile)` I love java,…
I'm not current on Node features, but that looks dangerous to do. Is that equivalent to reading the file and `eval()`ing it?