What if Javascript Wins?
May 16, 2018 12:52 PM   Subscribe

What this suggests is that JavaScript may be reaching escape velocity as a network, and as an ecosystem of related technologies. To be clear, there’s no winner-takes-all here — domain-specific languages will always have their uniquely valuable areas of focus. But for general-purpose coding? Everything from spreadsheet macros to Internet of Things hardware seems to default to having JavaScript be one of the primary ways to make things programmable.

[Glitch previously]
posted by Sokka shot first (96 comments total)

This post was deleted for the following reason: Poster's Request -- Brandon Blatcher



 
Of the many things that shock me after coding for the Internet these last 20+ years, the ascension of JavaScript is among the craziest.

Given the absurdity of the rest of existence nowadays, I chalk it up to yet more evidence I got trapped in a very different surreal timeline.
posted by Celsius1414 at 12:59 PM on May 16, 2018 [30 favorites]


if?
posted by Thorzdad at 1:06 PM on May 16, 2018 [3 favorites]


}
posted by oulipian at 1:14 PM on May 16, 2018 [12 favorites]


If the Atom ecosystem is any indication, that means almost a dozen different attempts to build a spell-checking plugin, three with commits in the last six months, and none that actually provide a usable spell-checker.
posted by GenderNullPointerException at 1:15 PM on May 16, 2018 [18 favorites]


Of the many things that shock me after coding for the Internet these last 20+ years, the ascension of JavaScript is among the craziest.

I think there are very few people who weren't surprised by this. I remember the moment that Javascript seemed viable to me: the first time I saw a web app that had been ported to Angular. It ran so much faster than its servlet-based counterpart that I was literally convinced in less than ten seconds that this was the way to go.

As for the article, yes, JS is becoming super-popular. I don't know if I buy into this "network" idea; Java, C# and all mature enterprise languages have extensive ecosystems, too.

Why is it becoming so popular? I'd say there are two driving factors. There is of course the fact that it is supported by every browser to run code client side. That's a huge game changer, even though it's always been there. The thing that really opened the floodgates was the rise of functional programming. I'd point to Ruby as paving the way for FP - once it was (for a short time) the "cool kid" on the block, it suddenly made weakly-typed languages acceptable to many programmers.

I'm still not convinced by the FP paradigm. It doesn't seem substantially different from OO design. The main differences that I perceive are (1) yes, it's a bit more flexible, but (2) at the expense of being a bit harder to debug. With strongly-typed OO languages, you know exactly what each object has to offer without any debugging.

Is the flexibility worth the ambiguity? Ask me what I think in two years. Because I think JS will still be dominating at that time, and I'll have fully assimilated by that point. I could even be wrong about the trade-off - things are moving so fast in JS land that they may already have a solution that I don't know about.
posted by Edgewise at 1:16 PM on May 16, 2018 [6 favorites]


Although I admit that my Atom experience is enough months out of date that maybe someone has done it. Of course that means it's likely one month from being abandoned.
posted by GenderNullPointerException at 1:18 PM on May 16, 2018 [1 favorite]


It's a bit early to declare Javascript to be the End of Programming History when its eventual doom (in the form of WebAssembly) is already on the horizon.
posted by Pyry at 1:20 PM on May 16, 2018 [12 favorites]


C++ also "won". That doesn't make it good.
posted by dilaudid at 1:21 PM on May 16, 2018 [11 favorites]


Nooooo it's shit and needs things like Typescript to impose sanity on it.
posted by GallonOfAlan at 1:24 PM on May 16, 2018 [8 favorites]


Edgewise, there's nothing preventing strong typing in FP. Haskell, Ocaml, F#, and Idris come to mind.
posted by The Gaffer at 1:28 PM on May 16, 2018 [9 favorites]


I liked this:

The truth is, we’ve never seen one open language become a nearly-universal programming language for coders. We don’t know what kind of benefits might accrue if the majority of coding effort starts to happen in one language [...]

I think the benefits will be huge. It reminds me of the position of English in the world. English, like Javascript, is perhaps not the most elegant language. It has its quirks and irregularities, for sure. Esperanto and Interlingua may be easier to learn.

But those things don't matter much because of the sheer ubiquity of the English language and the value we derive from having a global second language.
posted by Triplanetary at 1:29 PM on May 16, 2018 [7 favorites]


I'm still not convinced by the FP paradigm.

Nor I, I'm a lot happier when I have memory pointers.
posted by johngoren at 1:29 PM on May 16, 2018


> Atom ecosystem...

That's CoffeeScript, not JavaScript. In a way that's splitting hairs, but in a way it isn't.
posted by ardgedee at 1:33 PM on May 16, 2018 [1 favorite]


I'm still not convinced by the FP paradigm. It doesn't seem substantially different from OO design.

I generally like FP but some of what it seems particularly good at - large-scale parallelism or Erlang-esque systems - is... not really done that often in JS? I always thought the association of FP with JS was sorta - "hey, we realized this existing paradigm allows us to make sense of Javascript!"
posted by atoxyl at 1:36 PM on May 16, 2018 [5 favorites]


Edgewise, there's nothing preventing strong typing in FP. Haskell, Ocaml, F#, and Idris come to mind.

Yeah there's a whole side of that world that is very into types.
posted by atoxyl at 1:41 PM on May 16, 2018 [4 favorites]


I like Anil well enough but this essay seems basically like "JavaScript is popular! Also, use Glitch!"

Yes, JavaScript is popular.

And Glitch seems fine.

And Anil likes writing.
posted by GuyZero at 1:42 PM on May 16, 2018 [10 favorites]


Adobe is pretty far ahead of the curve here, for better or worse; ActionScript in Flash began converging towards the ECMAScript standard in 2000 and was effectively a dialect of ECMAScript by 2006. JavaScript has been Photoshop's cross-platform scripting language from 1999-ish until it also moved to ActionScript.
posted by ardgedee at 1:43 PM on May 16, 2018 [3 favorites]


the rise of Electron and the implicit idea that native apps aren't worth doing is really frustrating to me.

JS as a language is fine but like C or Java is pretty bare-bones.

What most people like about JS is that it lives in a browser. And jamming a whole browser in an app is, yeah, not optimal. Either that or it's really hard - I've seen customized Chromium builds put into products but it takes a lot of work to intelligently downstream Chromium into your own code base. More than people care to do. Anyway, Electron is the triumph of easy over optimal.
posted by GuyZero at 1:48 PM on May 16, 2018 [2 favorites]


I always thought the association of FP with JS was sorta - "hey, we realized this existing paradigm allows us to make sense of Javascript."

20 years go, all of the JavaScript tutorials emphasized Object-Oriented Programming. I think it's become more popular these days to talk about code as functions that produce well-defined return values than objects that "hide" all their data behind functions that produce well-defined return values. Wrestling with abstractions like MVC isn't strictly necessary when those objects have already been defined and you're scripting glue between them.
posted by GenderNullPointerException at 1:54 PM on May 16, 2018 [3 favorites]


I've been writing client-side JS for... 22 years now? (wow). It works, and its gotten much better (both in terms of cross-browser support and in terms of frameworks, transpilers, etc).

I still don't see any point to server-side JS except people being too lazy to learn a new language? I mean, it's not really hard to pick up a second/third/fourth/nth programming language. You *can* use JS, but I still don't really see why when you could instead use almost anything else (personally I'd go Python or C++, but there are a million options. The point of client-side JS is you don't actually have many other options without requiring people to install software).
posted by thefoxgod at 1:57 PM on May 16, 2018 [6 favorites]


there's a whole side of that world that is very into types.

JavaScript has TypeScript and Flow. These are type systems for JS, they are fabulous. Incremental, structural compile-time types on a dynamic language is fabulous. It's not OCaml but it is better and more usable than Java (boring nominal types), Python/mypy (Py community doesn't seem too into this) or ruby (which is nice if you liked Perl).

This is the kind of dynamism that exists in JS. There are at least two type systems that you can add to JS. TypeScript is releasing a couple times a year.

If you haven't tried these give them a go. With VSCode and TS you are typing along and it's giving you type-precise autocomplete inside of JSX/TSX templates. And TS is expressive enough that you can write a type for a function that takes as the first arg a string or list of strings or a dict or a function that takes something of the same type as the second arg and returns a list of strings.

JS as a language ... is pretty bare-bones.

Decorators? Promises? Template literals? Generators and Coroutines? No problem Bable has you covered you can use these on browsers today. Look back on Perl and remember how more syntax doesn't mean more 'powerful' it means write once.
posted by bdc34 at 2:12 PM on May 16, 2018 [2 favorites]


Anyway, Electron is the triumph of easy over optimal.

Electron isn't even that easy. Certainly I think that desktop GUI frameworks like Java Swing or wxWidgets or even ImGui are all vastly simpler than Electron + some overcomplicated JS framework like Angular or React. The real advantage of Electron is that it's easier to make distinctive and 'beautiful' apps, whereas every Swing app will look like Swing, and every wxWidgets app will look like it was assembled out of stock OS components (because it is). If anything, Electron is the triumph of stylish over optimal.
posted by Pyry at 2:13 PM on May 16, 2018 [5 favorites]


JS has some insane quirks but they are pretty easy to stay away from. An excellent book "You-Dont-Know-JS" states that it's actually a compiled language, very late compolation but not interpreted. Most of the performance issue in the browser are DOM issues. On the server side most frameworks are entirely event driven which is better than OO for focusing code for fast performance. In any environment a computationally intensive scientific loop will be rather slow compared to C/Java.
posted by sammyo at 2:18 PM on May 16, 2018 [1 favorite]


I work in the embedded field so thankfully I don't get exposed to this as much, but the dam is chipping away each and every day.

Every time I see someone running node.js on a Raspberry Pi and calling it embedded makes me weep and also insanely scared for the future at the same time.
posted by JoeZydeco at 2:23 PM on May 16, 2018 [11 favorites]


I, meanwhile, am still stuck on Grails on a daily basis and work on a team where our UI is considered an afterthought at best so it's not like I'm getting many opportunities to use it on the front end. Like, we're doing new development, we're just still using Grails even though half our plugins don't work anymore. I daydream about a land where JavaScript is really winning and I'm not stuck trying to cobble stuff together from advice gleaned from StackOverflow answers from 2012. Which is to say, it's a weird war that you can win while most people are still doing the same thing they've ever done.
posted by Sequence at 2:31 PM on May 16, 2018 [2 favorites]


I work in the embedded field so thankfully I don't get exposed to this as much, but the dam is chipping away each and every day.

While we deeply regret the loss of life, we ultimately feel that responsibility lies with leftpad's author.
posted by The Gaffer at 2:43 PM on May 16, 2018 [7 favorites]


JS as a language ... is pretty bare-bones.

Decorators? Promises? Template literals? Generators and Coroutines?


Ok, sure, it's got more modern features than C or Java. But any actual guarantee about what the execution environment it? Compiled vs an optimized JIT? A GUI framework?

My point is that people don't like JavaScript per se, they like writing code in a browser. JS has a lot of cool features that are useful in the intensely async browser environment like promises etc. Template literals are circa 1990 bash syntax, but sure, super useful.

Clearly it makes a lot of sense for JS to have language features focused around async execution given that's it's predominantly used for network & user interaction but that's a result of it being in a browser, not the cause of it being in a browser.
posted by GuyZero at 2:51 PM on May 16, 2018 [3 favorites]


The real advantage of Electron is that...

The real advantage of Electron is that you share desktop code with your web client (and probably much of your mobile client depending how you wrote it).

If you want to write a multi-platform app but only have one codebase, your best bet today is to write a web app.
posted by GuyZero at 2:53 PM on May 16, 2018 [3 favorites]


If you want to write a multi-platform app but only have one codebase, your best bet today is to write a web app.

I'm kind of hoping Qt for WebAssembly gets into better shape and puts up a fight.
posted by JoeZydeco at 2:55 PM on May 16, 2018 [3 favorites]


Oh dear. I hope this is not true. Never in my 20+ years of programming has a language been so popular that was so unsuitable for large code bases.

Like JoeZydeco, I hope that WebAssembly takes off.
posted by KaizenSoze at 3:25 PM on May 16, 2018 [3 favorites]


As a C++ trading system dev I had to raise an eyebrow when I saw this article.

I can do everything I need to do about as efficiently as I need to without leaving the (portable, maintained by the same organization as the language) STL. Is there actually any such thing as working in JS without also choosing which third party framework you will live in? Because if not you might as well say LLVM is the fastest growing language.
posted by PMdixon at 3:26 PM on May 16, 2018 [5 favorites]


you might as well say LLVM is the fastest growing language.

Probably some LLVM dev has also written that article.
posted by GuyZero at 3:28 PM on May 16, 2018 [5 favorites]


The whole idea of JavaScript prevailing and becoming the one language that everyone who isn't a compiler/microcode engineer uses for everything might possibly be plausible if Moore's Law was to keep accelerating, giving us exponentially increasing amounts of RAM and CPU cycles to play with. Instead, it looks like the exponential curve is really a S-curve that's beginning to flatten out as the limits of physics impinge on the size of transistors (and the number of powered transistors per square centimetre). Which means that a lot of 90s/00s-vintage certainties are looking a lot more dated. Everything being done in dynamically-typed, garbage-collected high-level languages? All intermediate formats being human-readable XML, just in case? /usr/bin/dwim, which infers what you want and does it without you having to nail down the precise details? That's not going to happen. Instead, we're relearning the arts of optimisation.

We can have languages and systems that do a lot of the heavy lifting for us; but that's going to happen at compile-time. Rather than having a nice text file of a JavaScript or Python or AppleScript (or, heavens forfend, some form of BASIC) running on our devices, we have powerful compilers, and spend the RAM and CPU cycles to reduce our high-level code to tightly optimised native machine code. Every year, the compilers get better and the runtime gets leaner.
posted by acb at 3:49 PM on May 16, 2018 [4 favorites]


Metafilter: [S]plitting hairs, but in a way it isn't.
posted by riverlife at 3:50 PM on May 16, 2018 [2 favorites]


And jamming a whole browser in an app is, yeah, not optimal.

“And vice versa...” he muttered into his pint glass while glaring at the Modern Web party hooting and hollering on the other side of the pub.
posted by Celsius1414 at 3:57 PM on May 16, 2018 [11 favorites]


“And vice versa...” he muttered into his pint glass while glaring at the Modern Web party hooting and hollering on the other side of the pub.


Huh. Apparently Lynx is still under active development. Maybe I should give it a shot.
posted by PMdixon at 4:01 PM on May 16, 2018 [1 favorite]


needs things like Typescript to impose sanity on it.

Holy hell I hate Typescript, CoffeeScript and all opinionated JS metalanguages. They make the simplest things so needlessly difficult just because some programmers wish Javascript was some other langauge.
posted by eustacescrubb at 4:04 PM on May 16, 2018 [10 favorites]


I wrote an opinionated JS metalanguage, because Javascript is a shitty language; only marginally less garbage-bad than PHP. A critical saving grace is that it isn't Java.

What JS has going for it, which outweighs the fact that it's a shitty language, is that it is also the base of the closest thing we have to a ubiquitous computing platform -- node.js. Node more or less runs everywhere, on everything, using a common library system that means you don't really have to give a shit whether it's windows or mac or linux or a thousand blades on a rack in Baltimore or a Raspberry PI in a shoebox. Javascript + Node is the closest we've ever gotten to write once, run anywhere. And that's incredibly powerful.

JS is a shit language, but the compiler technology it sits on is outstanding. So if you can create a metalanguage that compiles to trustworthy, easy-to-compile JS -- using it as an assembly language -- the mother fucking world is at your fingertips.

I hate JS. But node is changing the world of programming in a very, very good way.
posted by seanmpuckett at 4:18 PM on May 16, 2018 [6 favorites]


If you want to write a multi-platform app but only have one codebase, your best bet today is to write a web app.

The problem with this is that this pushes the problem of code complexity and performance onto your users. You save money on hiring developers to rewrite the app in a tight, native platform, and the users pay for it incrementally by having huge browser-based processes chewing up 1Gb of RAM and 15% of CPU on their top-end MacBook Pros while idling.

The mindset of “just slap Electron around the web app and ship it” seems, to me, not too dissimilar to taking advantage of lax pollution regulations to maximise profit margins at the expense of whoever's breathing the air, or exploiting a reserve army of precarious workers to drive Uber cabs or Deliveroo meals. It's basically “externalities? what externalities?”
posted by acb at 4:21 PM on May 16, 2018 [6 favorites]


Holy hell I hate Typescript, CoffeeScript and all opinionated JS metalanguages. They make the simplest things so needlessly difficult just because some programmers wish Javascript was some other langauge.

How do you get anything like type- or interface-checking without them or a home-rolled-and-therefore-less-usable-by-others-type-system though --- or else how do you have anything that accepts user input that isn't unusably prone to runtime errors without something equivalent to type checking?
posted by PMdixon at 4:22 PM on May 16, 2018 [2 favorites]


It's basically “externalities? what externalities?”

It's basically Electron or no desktop app.

I agree 100% but users want what they want. Why it matter to have a separate app as opposed to another Chrome tab I dunno, but to some people it's a thing.
posted by GuyZero at 4:26 PM on May 16, 2018 [1 favorite]


I wrote an opinionated JS metalanguage, because Javascript is a shitty language; only marginally less garbage-bad than PHP. A critical saving grace is that it isn't Java.


OK, I'll bite. What's a good language?
posted by GuyZero at 4:26 PM on May 16, 2018 [5 favorites]


How do you get anything like type- or interface-checking without them or a home-rolled-and-therefore-less-usable-by-others-type-system though --- or else how do you have anything that accepts user input that isn't unusably prone to runtime errors without something equivalent to type checking?

Simple, just don't throw any runtime errors. 3 + 4 + "5" = "75". "3" + 4 + 5 = "345", 3 + true = 4. Now you may have garbage input but at least your program won't crash. And hope that your unit tests catch anything too crazy.
posted by dilaudid at 4:32 PM on May 16, 2018


It's basically Electron or no desktop app.

If they have a reasonably well-architected mobile app, parts of the code (outside of the UI layers) could be reused for a desktop app. One can share the model layers between an iOS app and a macOS app, for instance. I don't know enough about Android to know if it's possible to make an app that shares code with a desktop Java/Kotlin app, but there'd be incentive for someone to have written a toolkit. And then there are Microsoft's experiments with C#-based frameworks that bake down to near-native apps on other platforms; that's not even mentioning Qt. A big pile of garbage-collected JavaScript moving around DOM elements in a browser window is in no way the only alternative here.
posted by acb at 4:36 PM on May 16, 2018 [2 favorites]


JS is a shit language, but the compiler technology it sits on is outstanding. So if you can create a metalanguage that compiles to trustworthy, easy-to-compile JS -- using it as an assembly language -- the mother fucking world is at your fingertips.

https://github.com/ocsigen/js_of_ocaml
posted by bdc34 at 5:02 PM on May 16, 2018 [4 favorites]


or else how do you have anything that accepts user input that isn't unusably prone to runtime errors without something equivalent to type checking?

Testing? I'm all for real type systems but it's not as if people have never succeeded in developing working apps in dynamic languages. Gets harder when shit gets really big, sure.
posted by atoxyl at 5:05 PM on May 16, 2018 [4 favorites]


OK, I'll bite. What's a good language?

Perl is the JavaScript of good languages, so let's go with that.
posted by rhizome at 5:22 PM on May 16, 2018 [2 favorites]


Perl is a mess. The syntax is all over the place, with different kinds of entities being governed by entirely different rules (one example: file handles are not expressions or variables, but an entirely different element of syntax altogether). It's great for its original remit—being a better Awk—but it's inadvisable to write more than a screen's worth of Perl code in any one project. (Perl's author, Larry Wall, was a missionary linguist by training, and his language seems to inherit the twin confusions of theology and natural languages.)

If one compares Perl to JavaScript as languages for the development of non-trivial programs, JavaScript comes out decisively more suitable. Yes, it's slow and inefficient (despite having driven forward JIT research to mitigate this), but it has a reasonably clean conceptual model of how it works, and lends itself to various types of architectural composability.

As for better languages than JavaScript for GUI apps, anything that is compiled into native code is a good start. Swift is good. Rust has its followers, who have good things to say about it. Kotlin is an improvement on Java, as is C#. Failing that, you could use C++ (the Qt library is fairly elegant). And if they're too tainted by worldly considerations, you can write GUIs in Haskell should you desire to (that's where functional reactive programming, as seen in React and Rx, was invented).
posted by acb at 5:45 PM on May 16, 2018 [1 favorite]


How good is the Javascript community for women or POC? I ask b/c it seems like different languages have different communities.
posted by Going To Maine at 5:47 PM on May 16, 2018 [2 favorites]


How do you get anything like type- or interface-checking without them

You do realize that it is possible to do this kind of validation and error checking with vanilla JS, because TypeScript and CoffeeScript compile to JS, right?
posted by eustacescrubb at 5:50 PM on May 16, 2018 [1 favorite]


It’s deeply amusing to see Perl5’s history repeating with JavaScript. Everyone says it’s underspecified and too lax, lots of people try to rewrite it from the ground up with helper languages and entirely new approaches bolted on top, repositories self-evolve into mission criticality.

So to draw a lesson from Perl5, JavaScript is a success precisely because of its combination of powerful capability, available everywhere, and lackadaisical “do whatever you like” approach. If it had strictly defined itself to prohibit the problems that everyone is trying to solve in it, it would never have been such a valuable language for everyone involved.

I wish someone would port a 65c02 assembler to it so that I could code webpages in Apple IIgs assembly code, because as long as I can compile down to JavaScript, I’m good to go!

I also wish someone would take Rust and implement JavaScript with it, complete with untypes variables and everything, so that when I need to do something truly serious I can drop to Rust for that segment, and otherwise continue coding in freewheeling JS. Perl tried this out with Inline::C which was amazingly great in theory but had very rough edges. I miss having the flexibility to write scripting code mostly and only a bit of C where it mattered most. JS still lacks that capability. I would nominate Rust rather than JS for the parasitic option, though!
posted by crysflame at 5:58 PM on May 16, 2018 [3 favorites]


You do realize that it is possible to do this kind of validation and error checking with vanilla JS, because TypeScript and CoffeeScript compile to JS, right?

as I said:
or a home-rolled-and-therefore-less-usable-by-others-type-system
posted by PMdixon at 6:01 PM on May 16, 2018 [3 favorites]


> Perl is a mess

Yes, it really is! But it’s an effective, production-tested mess. Sometimes humans build better things out of messy parts than they do with a drafting board and materials engineers. People commonly underestimate IMO the value of “barely sufficient” / “no better than necessary” design. Perl5 and JavaScript both fit that bill to a T.
posted by crysflame at 6:02 PM on May 16, 2018 [2 favorites]


home-rolled-and-therefore-less-usable-by-others-type-system

Is === really that hard to use? Or typeof? Or parseInt() ?
posted by eustacescrubb at 6:11 PM on May 16, 2018 [1 favorite]


How good is the Javascript community for women or POC? I ask b/c it seems like different languages have different communities.

In my experience (as someone who is neither a woman, nor POC, and is not a frontend developer, but is underrepresented in the tech industry), not the worst, but far from the best. The perpetual framework-of-the-month thing, the ever-increasing toolchain and that people like to shit on Javascript (see this thread) isn't a combination that brings out the best in many people.
posted by hoyland at 6:12 PM on May 16, 2018 [4 favorites]


JavaScript is 'inspired' because when you shoot yourself in the foot with JavaScript, you can redefine the bullet, the gun, and the foot at runtime. And the bullet, gun and foot can use a different version of underscore.js simultaneously.
posted by quillbreaker at 6:27 PM on May 16, 2018 [9 favorites]


JavaScript is certainly what one might call a Stroustrup language, in that it is one that people use and complain about, sometimes even with good reason. There's also a significant mass of the hate for it that is overblown. Usual suspects include:

(a) people who prefer JS's dynamic scripting siblings that are essentially equivalent in power/convenience (Ruby and Python). *Especially* those that are snobby about Perl, many of whom have never spent any serious time with it.
(b) people who go on about "strong typing." You get a pass from me if you're coming from a language with a type system that builds roads as well as takes prisoners and knows inference and minimal ceremony are good things, but the number of languages that meet this requirement is low enough that you probably don't.
(c) people who fundamentally like JS semantics but just wish the syntax had their personal aesthetics (lookin' at many of you CoffeeScript fans). Along with moar build steps, before build steps were cool.*
(d) people who think the browser is or should be just another VM

If I look back to imagined alternate pasts, I don't really see a better likely path for the industry than the place JS took. If we'd gotten 1995 Python instead we'd just have a different set of warts on a similar language to have complained about in the intervening time. TCL or Scheme might have been a novel future but again with the warts for the former and holy high hell the bikeshedding and complaining that would be happening over the latitude the latter allows *after* we got done talking about parentheses which might be never. Lua? Might have been nice, but wouldn't have forestalled complaints about.... Strong typing? Another VM? Again, depends on what you *mean* by that, but we got to taste what web development with Java and ActionScript 3 were like and it wasn't all roses and song, and the next step sure won't be either if we get the idea that the problem with JavaScript is that it's not enough like Go or something equally tragic.

The good news for everybody who feels picked on by my words here: WebAssembly means that group (d) is going to move through the industry like a bowling ball tossed in a bathtub, all the other groups in tow, and I have no idea whether it means we're going to make something better and move on or just lose the good things about the web that we have a tenuous hold on now without learning much of a lesson.

I'm actually happy that JS is probably not going away entirely soon, though. We really could have done a lot worse for a lingua franca; arguably we did, several times, and despite no small opposition, JS won out anyway.

* build steps still aren't actually cool. They're sometimes useful or necessary.
posted by wildblueyonder at 7:08 PM on May 16, 2018 [8 favorites]




Oh that article is hopelessly out of date.
posted by Pyry at 7:21 PM on May 16, 2018 [12 favorites]


The whole idea of JavaScript prevailing and becoming the one language that everyone who isn't a compiler/microcode engineer uses for everything might possibly be plausible if Moore's Law was to keep accelerating, giving us exponentially increasing amounts of RAM and CPU cycles to play with. Instead, it looks like the exponential curve is really a S-curve that's beginning to flatten out as the limits of physics impinge on the size of transistors (and the number of powered transistors per square centimetre). Which means that a lot of 90s/00s-vintage certainties are looking a lot more dated. Everything being done in dynamically-typed, garbage-collected high-level languages? All intermediate formats being human-readable XML, just in case? /usr/bin/dwim, which infers what you want and does it without you having to nail down the precise details? That's not going to happen. Instead, we're relearning the arts of optimisation.

I think this gets at the heart of it. I really believe we’re on the cusp of an era in which the ease-of-use that dynamically-typed languages afford (with things like good type inference reducing cognitive load in the small, traits/protocols/structural typing enhancing the ad hoc extensibility of existing types, reification of data ownership obviating the overhead of garbage collection) will be largely adopted by compiled languages, and along with the value of things like predictable memory layout will make them the increasingly more obvious choice even for young and highly-iterative projects.
posted by invitapriore at 7:22 PM on May 16, 2018 [1 favorite]


My hope is that as webasm matures a little more, a zillion languages will compile to it and javascript hegemony is broken once and for all.
posted by Zed at 7:57 PM on May 16, 2018 [3 favorites]


>In short, the people who make software got networked just like their
>computers had been in the preceding decades.
[...]
>For knowledge about coding issues, and answers to common questions,
>Stack Overflow rose and quickly became a dominant source of reliable
>information about programming.


So, Usenet then.

>A similar pattern followed for collaborating around code:
>GitHub rose a decade ago as a powerful platform for sharing each commit to a project.


Ah, CVS and its predecessors. Yes.

>Finally, there are the networked information sources for news and discussion,
>primary among them being Hacker News.


Usenet again.


I dunno what will happen with JavaScript, but I can tell you that the reason won't be because programmers suddenly started interacting in 2008.
posted by Tell Me No Lies at 9:05 PM on May 16, 2018 [7 favorites]


JS itself is incredibly overwhelming to me, but the JS community in my midwestern city, I will say, has been about as good as I possibly could have expected as a woman coming to development in my 30s, and the local JS community feels more checked-in with diversity stuff than, say, the Java people. Yeah, in some ways the toolchain feels unmanageable, but then I don't think working on the JVM is actually simpler, like, at all, and in JS, you're more likely to find a recent guide from someone else on how to do what you're trying to do, even if it's annoying that it's different than the way you were "supposed" to solve the same problem twelve months ago.
posted by Sequence at 10:56 PM on May 16, 2018 [3 favorites]


I was wondering how long it would take for the comments to get to Perl. There was a talk by mst at The Perl Conference last year[1] about how the latest version of JavaScript essentially puts it where Perl was about 15 years ago. Some of us in Perl niche have been saying the same as crysflame for the past few years, that it's interesting (and also amusing) to see history repeating itself and all the JavaScript hype even though Perl gets shat all over by most software developers.

Anyway, I wrote about this recently[2]. JavaScript might "win" but lots of other languages have "won" over the decades but that means nothing. No language "wins" for the long term, so you should be able to program in a handful of them at least.

[1] https://www.youtube.com/watch?v=OwCAFPKwAyE

[2]
https://leejo.github.io/2017/12/17/tpc_and_the_end_of_language_dominance/
posted by lawrencium at 11:40 PM on May 16, 2018 [2 favorites]


And then there are Microsoft's experiments with C#-based frameworks that bake down to near-native apps on other platforms; that's not even mentioning Qt.

Google is attempting to do this with Flutter, their Unity for mobile apps (and Fuchsia), and with Dart, their attempt to build a new JavaScript.

(b) people who go on about "strong typing." You get a pass from me if you're coming from a language with a type system that builds roads as well as takes prisoners and knows inference and minimal ceremony are good things, but the number of languages that meet this requirement is low enough that you probably don't.

Objective-C?
posted by Apocryphon at 12:28 AM on May 17, 2018


I wish someone would port a 65c02 assembler to it so that I could code webpages in Apple IIgs assembly code, because as long as I can compile down to JavaScript, I’m good to go!

You'd want a 65816 assembler for that, not a 65C02 one.
posted by flabdablet at 1:40 AM on May 17, 2018 [2 favorites]


Functional Programming is a Very Good Thing. The main feature I like in JavaScript is that it's easy to use a functional style. For example I routinely use functions that return other functions. It's ability to chain functions is another good feature.
JS has some truly horrible parts. The native object model is beyond obscure. I've spent many, many days trying to understand it and I'm still confused. Object models built on top of the native capabilities seem rickety to me. They always seem to be not quite as good as implementations in other OOP languages.
Types in JS are ugly. Having to understand the difference between "==" and "===" is an example. The need for hasOwnProperty is also ugly. The language is rife with these kinds of gotcha problems. It's not a good first language as a result.
Node is just out of control. The continuously expanding number of packages in NPM is a symptom of a larger problem. The community is focused on cool new stuff at the expense of making a better ecosystem and having maintainable code.
Functional programming is harder to learn at first, but the payout is more robust and more maintainable code. The functional paradigm also scales to very large systems. When languages like JS and PHP go big they are terrible to debug, maintain, or change.
I've switched from JS to Python. A big reason is that Python has high quality and well documented existing libraries. My observation is that JS replaces quality with a vast number of packages with questionable utility.
JS and Node don't have much support for non-web oriented problems. For example, I had to implement basic graph traversal algorithms from scratch. Python has existing support for all kinds of computing problems, not just web centric applications. And it is currently expanding into the lite weight server side niche.
I think the wrong question is being asked about JS. It's not if JavaScript is going to take over the world, but if it's the next Basic.
posted by Metacircular at 1:58 AM on May 17, 2018 [7 favorites]


I'm a cynic, but I feel like there's a tendency for people to see their pet programming language/framework/paradigm as a hammer for every nail and this article feels like an example of that. I don't touch Javascript at work* and it's completely unrealistic to expect that I ever will in my current job, so I guess Dash wants to dismiss the things I do use as "domain-specific languages", i.e. things no one cares about outside a particular niche. But is there really such a thing as a "general purpose" language? I'd be pretty happy if I could just use Scala all the time, but that makes no sense--there's all sorts of things I do that are drastically easier from Python (never mind that Tensorflow only supports training from Python**). And I ultimately need to write a library that'll be called from Java, so I should probably just write it in Java, rather than insist on it being Scala and either make other people deal with the interop goofiness (bad), or write tortured Scala to make it nicely usable from Java (removing the Scala fun, anyway). Because that's my world, I'm likely going to use Python for my little utilities, but that doesn't mean Python is somehow "better" than Javascript, it means that Javascript is fairly removed from the world in which I operate, as if it were a domain-specific language.

A few years back, it did seem like every random little utility was actually a Ruby gem and now that's moved to Node or Go. But I don't think that's the same as being "general-purpose".

*I have in the past, but it has never been a core part of my job.
**It seems they've just released TensorflowJS which supports training in the browser. I have no idea how that's supposed to be practical.

posted by hoyland at 4:16 AM on May 17, 2018 [2 favorites]


It seems they've just released TensorflowJS which supports training in the browser. I have no idea how that's supposed to be practical.

AFAIK, TensorFlow just sets up the neural network structures; the heavy lifting is done in native code.

TensorFlow appears to be branching out from its Python dependency; they now have a Swift interface (worked on by Swift and LLVM creator, Chris Lattner, who now works in Google's machine-learning division).
posted by acb at 4:26 AM on May 17, 2018


As a follow up to my previous comment in this thread, I would like to refer to a video I found just after I posted: Lisp, The Quantum Programmer's Choice.
The video was put online on May 18, 2018. The description is: "Robert Smith of Rigetti Quantum Computing explains why he uses this 60 yr old language for cutting-edge work."
Smith talks about the learning curve of LISP and why the computing model it uses is still very relevant. He emphasizes that learning LISP makes one a better programmer no matter what language they are using.
posted by Metacircular at 5:28 AM on May 17, 2018 [2 favorites]


Javascript is pretty weird and unique, but it was there. And languages do get critical mass. I certainly happened with C forty or so years ago. I guess we thought (or Sun told us) it was going to be Java in the 90s.

DOS and Windows is an example of a platform that became ubiquitous because it was what was available on ubiquitous PC's, not because of any revolutionary design. (Same with JS and web browsers.) And it was pragmatically evolved picemeal while preserving (most) backward compatibilty, not according to some grand genius plan.
posted by thefool at 5:44 AM on May 17, 2018 [2 favorites]


AFAIK, TensorFlow just sets up the neural network structures; the heavy lifting is done in native code.


That's correct, but you can't really do that from some user's browser. Or can you? I feel like I'm missing some conceptual piece here. I see how inference would work, but not training.

(You can't train from Java Tensorflow at the moment, but you can from C++, I think, which would make sense.)
posted by hoyland at 6:00 AM on May 17, 2018




I've been a full-time, full-stack, Javascript developer for around five years now.

I followed a path I now see many others following:

1. Learning Scheme to find out what this "functional programming" business was all about. Decide types are bad, because I was conflating typing with Object Orientation (a virtually unmitigated disaster).
2. Going wild trying to write everything in a point-free style with libraries like Lodash and Ramda. Developing in the REPL.
3. Realizing that untyped lisps are strictly inferior to typed lisps (like OCaml or F#), thanks to Flow.
4. Realizing that bolting a static type system onto a language not designed for static checking makes all of that languages flaws glaring apparently.
5. Realizing that the Flow-typed subset of Javascript you now restrict yourself to is basically OCaml without a good module system or typed libraries.
6. Thinking about how best to get your peers to move through these steps as quickly as possible. Mulling over the relative merits of encouraging the adoption of Flow versus Reason versus OCaml (via Bucklescript) per se.
posted by phrontist at 7:07 AM on May 17, 2018 [4 favorites]


but that doesn't mean Python is somehow "better" than Javascript

no, it is.
posted by Going To Maine at 7:32 AM on May 17, 2018 [9 favorites]


I like the idea of WebAssembly - all I need are some Web2716's, a WebDataI/O19, a WebHP1611A and I'll be in business !
posted by rfs at 8:44 AM on May 17, 2018 [3 favorites]


people who prefer JS's dynamic scripting siblings that are essentially equivalent in power/convenience (Ruby and Python

Definitely didn't used to be equivalent in convenience but the sorta-neat-sorta-scary thing about JS is the way that stuff gets filled in.
posted by atoxyl at 8:48 AM on May 17, 2018


Does Python still have the Global Interpreter Lock? When I last seriously worked in it (in the 2.7 days), the fact that in Python all data is mutable made it impossible to parallelise code safely, and required the interpreter to lock accesses to variables altogether. Which, of course, was perfectly fine when Guido first came up with Python, as presumably he had no intention of it running on Crays or Transputer hypercubes or whatever, but in today's world of parallelisation, multiple cores and increasing influence from the functional world, such a thing is an increasingly unreasonable bottleneck.
posted by acb at 9:35 AM on May 17, 2018 [2 favorites]


There are non-CPython implementations like Jython or IronPython that don't have the GIL.
posted by GuyZero at 10:15 AM on May 17, 2018 [1 favorite]


This last weekend was the annual language conference where Pythonistas got together to talk about such problems. Here's a production engineer from Facebook summarizing the current state of parallelism in Python.
With the combined powers of AsyncIO and multiprocessing, we'll redesign an old multithreaded application limited by the GIL into a modern solution that scales with the demand using only the standard library.
posted by persona at 10:21 AM on May 17, 2018 [3 favorites]


we'll redesign an old multithreaded application limited by the GIL into a modern solution that scales with the demand using only the standard library.

Event loops and callbacks and background I/O, oh my.

I'm old enough to remember co-operative multitasking being held to be this limiting and convoluted kind of thing that designers were all dead keen to dump in favour of the much simpler, much cleaner, much more performant multithreading. We AmigaOS fans used to have fun snickering at Windows 95 and Mac OS for exactly that reason.

I wonder how long it will take before bell bottoms come back into style.
posted by flabdablet at 10:36 AM on May 17, 2018


I've dabbled with JavaScript, but my favorite language these days is Haskell. There are many things that are actually fun to code in Haskell, so far GUIs are not among them — I'm excited try writing for the browser in Haskell using GHCJS.
posted by thedward at 11:18 AM on May 17, 2018 [3 favorites]


I have a really hard time dealing with dynamic, interpreted languages. I want compile time checks. I don't even terribly mind type annotations but real languages don't need them often.

There used to be a site that ranked programming languages by how applicable various statements were to that language, like "This language is a small combination of orthogonal features", or "This language has an extensive standard library". But one statement from that site nails the Javascript experience for me: "The thought that I may still be using this language in twenty years time fills me with dread".
posted by a snickering nuthatch at 12:05 PM on May 17, 2018 [4 favorites]


I'm a crusty old programmer who did 6502 assembly and Common Lisp in the old days, and I think Javascript is awesome--both the language and its entire incredible ecosystem of ubiquitous high-powered programming language availability (imagine being a 10-year-old nerdy kid and having Javascript available, connected to the web, with one keystroke). We've never seen anything like it before.

I personally don't always have Javascript as my first preference, but in the past couple years at work I've written C++, Java, Python, C#, Clojure, Clojurescript, and Racket, and Javascript is more or less a peer--it has its strengths and weaknesses, and warts, just like every other language.

how do you have anything that accepts user input that isn't unusably prone to runtime errors without something equivalent to type checking?

I'm guessing you mean static type checking? We've been writing very large and complicated systems in dynamically typed languages for decades. Google/ITA's airfare system is on the order of a million lines of code, and deals with something much scarier than user input: legacy mainframe-era data formats.

>For knowledge about coding issues, and answers to common questions,
>Stack Overflow rose and quickly became a dominant source of reliable
>information about programming.

So, Usenet then.


I was there for usenet. It's hard to remember, because we kind of take internet search for granted now despite its profound, society-changing effects, but there was basically no search, and no archives. That is not a small difference. Yes, you could post a question on usenet, but how many times do you think people post a question on Stack Overflow vs. how often they search and find a previous poster's question, and answers that may have been refined over the course of years? Knowledge that isn't archived is, asymptotically, meaningless.

>A similar pattern followed for collaborating around code:
>GitHub rose a decade ago as a powerful platform for sharing each commit to a project.

Ah, CVS and its predecessors. Yes.


I was there for CVS. And RCS. If you don't see the, again, profound differences in what CVS and github offer re: the ability for collaboration, then I think you might just be feeling a little curmudgeonly today.

I'm old enough to remember co-operative multitasking being held to be this limiting and convoluted kind of thing that designers were all dead keen to dump in favour of the much simpler, much cleaner, much more performant multithreading. We AmigaOS fans used to have fun snickering at Windows 95 and Mac OS for exactly that reason.

Thinking of it as the cooperative multitasking of 30 years ago isn't really helpful. There's a reason that so many recentish frameworks and programming languages have green threads/cooperative multitasking/coroutines/eventing/etc., and it's not because it's slow--when it's appropriate, it can be much, much faster. A green thread can have all the overhead of an if statement, vs. creating a new native thread.
posted by jjwiseman at 12:59 PM on May 17, 2018 [9 favorites]



I was there for CVS. And RCS. If you don't see the, again, profound differences in what CVS and github offer re: the ability for collaboration, then I think you might just be feeling a little curmudgeonly today.


Are we talking about cheap SCCS copies again?

We AmigaOS fans used to have fun snickering at Windows 95 and Mac OS for exactly that reason.

Show me an Amiga with 16 cores and then we can discuss the pros and cons of preemptive low-level multithreading.
posted by GuyZero at 1:39 PM on May 17, 2018 [2 favorites]


I've dabbled with JavaScript, but my favorite language these days is Haskell.

I've gotten into Haskell recently as well (well, last year); I kept hearing about it (I worked in Scala for a year and a half, and then in Swift), and ended up committing to actually learning it after seeing some talks on it at a conference last year. So far, I've written a few small things and one practical project (a last.fm listening summariser intended as a self-hosted alternative to tweekly.fm that can post to Mastodon).

Coding in Haskell is a big paradigm shift; for one, functions are all pure and can't have side effects or return different results for the same output; which makes no sense if a program is to actually do anything, so instead the functions that do have side effects or read from the outside world instead return an opaque object named IO, whose value cannot actually be extracted; so instead of, say, taking the value of the file you opened and doing something with it, you throw the functions that process this file through the same black hole the reading function opened, and they do their work on the other side of the event horizon. Secondly, you can do a lot with functions, and if you think of them as concrete bits of code that compute something and return a result, your head will end up hurting a lot. Learning Haskell is a good way to exercise mental muscles you might have forgotten you had. (Right now I'm trying to grok how Haskell's printf implementation manages to get variadic arguments working using the type system.)

I suspect Haskell won't ever become the next big thing, unless some shock scares everyone away from mutable state and side-effects. However, parts of it keep making their way to the impure world. Scala is, of course, Java wishing it were Haskell, Swift has inherited much of its type system from Haskell (though it's not yet strong enough to have protocols that match Haskell typeclasses like Functor and Monad, though hopefully it'll get there). And if Haskell is ever exhausted as a source of new ideas, there is always Idris.
posted by acb at 2:16 PM on May 17, 2018 [2 favorites]


IIRC Idris has been just murdered by dependent type implementation in Haskell. Haskell really seems like it's burgeoning, eating the ML world, and building a robust ecosystem - which either means we're headed towards a glorious, formally verified future or there are enough turbonerds to make a healthy niche community.

Don't get me wrong, I don't have a gothic belly tattoo saying 'monoid in the category of endofunctors,' but I'm honestly excited.
posted by The Gaffer at 2:50 PM on May 17, 2018 [4 favorites]


Haskell really seems like it's burgeoning, eating the ML world, and building a robust ecosystem

So, somewhere between CPAN and pip/PyPA? ;)
posted by rhizome at 3:13 PM on May 17, 2018 [2 favorites]


I feel like Javascript's gotcha list is way too long and extensive for it be worthwhile for humans to program in it. My urge is to rant about some of them.

But I'm also a Perl apologist of long standing and I've heard its gotchas trotted out lots of times and I've wanted to shout "Of course we know all that! No one understands its flaws better than those who love it best!"

So I'm holding myself back. But it's tough.

Darn you, Javascript. Now you've made me sympathize with Perl-haters.
posted by Zed at 4:46 PM on May 17, 2018 [5 favorites]


there are enough turbonerds to make a healthy niche community.

I know you mean 'healthy' in terms of size, but I've never found the Haskell world (as I've intersected with it online) particularly welcoming, and I'm someone who found the "monoid in the category of endofunctors" paragraph in Categories for the Working Mathematician illuminating. (The phrase alone isn't. It's also totally disconnected from how functional programming people seem to talk about category theory.) I've sort of backed away from Haskell as a result, even though there's plenty I like about it.

(I'm kind of in love with Clojure at the moment. And Clojurescript, but I don't know if that's because I'm in love with Clojure or because it let me opt out of sorting out the Javascript toolchain. I was shocked that it more or less "just worked". I've wasted hours mucking about with Grunt figuring I should learn something about frontend development tools.)
posted by hoyland at 7:25 PM on May 17, 2018 [1 favorite]


I was there for usenet. It's hard to remember, because we kind of take internet search for granted now despite its profound, society-changing effects, but there was basically no search, and no archives. That is not a small difference.

We appear to have different memories about the availability of Usenet archives, but you are right that most people just asked their question and one of the many people who haunted the group on a regular basis gave an answer. It wouldn’t scale to today’s levels but it was a very workable form of information sharing at that time.

Knowledge that isn't archived is, asymptotically, meaningless.

Knowledge built up and passed on collectively by groups worked for years before the computer was even invented. Or paper, likely.

If you don't see the, again, profound differences in what CVS and github offer re: the ability for collaboration, then I think you might just be feeling a little curmudgeonly today.

Github is a far better tool than what came before, but what came before did work. It was painful, it did not scale well, but it was suffered through because collaboration has always been a key activity. Github did not "network" developers, it just upgraded them from coax to fiber.

I guess another way to say that would be that github has lowered the bar for collaboration. I am certain that has affected the developer community, but I really doubt that it’s been the sort of sea change the article implies.
posted by Tell Me No Lies at 7:54 PM on May 17, 2018 [3 favorites]


If JavaScript wins, I'd like to hear also who lost and where. It seems to me that the popularity of JavaScript is the popularity of front-end development and not much else. I find myself doing fairly low-level stuff, and while apparently you can run Arduino with JavaScript there is not much point because Arduino is easy and slow enough, compared to what you get when you actually know what you're doing.
posted by ikalliom at 11:03 PM on May 17, 2018


Thinking of it as the cooperative multitasking of 30 years ago isn't really helpful. There's a reason that so many recentish frameworks and programming languages have green threads/cooperative multitasking/coroutines/eventing/etc., and it's not because it's slow--when it's appropriate, it can be much, much faster. A green thread can have all the overhead of an if statement, vs. creating a new native thread.

Oh sure. My point was not so much that the non-preemptive options are actually in some sense objectively worse or better, but that there's a really strong industry-wide (and especially industry-commentary-wide) tendency to treat them as if they were, and that quite a large part of what decides which technologies get widespread use comes from marginally competent project managers eager to be seen to have the New Hotness on their CVs.

But the thing is, there is no New Hotness. Not really. There are just techniques that work well within certain restricted problem domains, and most of those techniques have already been around in one form or another since approximately forever. It's a lot of fun watching the kids rediscover them and give them new names, is all.

The sad fact remains that most working commercial software sucks. It's badly designed by people who lack insight, and implemented in a hurry by people who don't care about it, using cut-and-pasted Stack Overflow snippets glued together with inadequate testing and pure optimism.

Next to the sheer size of that vast and smoking garbage mountain, the pros and cons of any particular programming language fade into insignificance. Javascript is good because it's everywhere, and bad for the same reason every other language is bad, which is that people will insist on using it in ways that would be better served by using something else.

If you like Javascript, that will be because you've been using it for stuff it's good at. If you don't, you've probably been forced to use if for something it isn't. And the same goes for Haskell, and C, and C++ and C# and Perl and Rust and on and on and on.

Except, of course, Java. Java is just bad.
posted by flabdablet at 5:03 AM on May 18, 2018 [5 favorites]


I know you mean 'healthy' in terms of size, but I've never found the Haskell world (as I've intersected with it online) particularly welcoming, and I'm someone who found the "monoid in the category of endofunctors" paragraph in Categories for the Working Mathematician illuminating. (The phrase alone isn't. It's also totally disconnected from how functional programming people seem to talk about category theory.) I've sort of backed away from Haskell as a result, even though there's plenty I like about it.

That's interesting. I wonder if Haskell's reputation for difficulty and math adjacency might invite some bad social behavior.

(I'm kind of in love with Clojure at the moment. And Clojurescript, but I don't know if that's because I'm in love with Clojure or because it let me opt out of sorting out the Javascript toolchain. I was shocked that it more or less "just worked". I've wasted hours mucking about with Grunt figuring I should learn something about frontend development tools.)

It's real easy to fall in love with lisp.
posted by The Gaffer at 8:16 AM on May 18, 2018 [3 favorites]


That's interesting. I wonder if Haskell's reputation for difficulty and math adjacency might invite some bad social behavior.

My bounce off of Haskell back into scheme was that I never could find a clear or simple answer to the question of how do I apply this provably correct mathematical function that I've spent hours learning to build to a sequence of numbers from a file. I also think there's some utility in purposefully breaking your functions to see what comes out rather than just barfing with some error about the types not matching. Functional purity and immutability are great as default preferences but make certain tasks and algorithms harder than they need to be when taken as universals.
posted by GenderNullPointerException at 8:38 AM on May 18, 2018


So your username is runtime?
posted by The Gaffer at 8:55 AM on May 18, 2018 [1 favorite]


« Older MH370 is still missing, with no final answers   |   Bringing ancient manuscripts in the Vatican's... Newer »


This thread has been archived and is closed to new comments