Self-healing electric ink refuses to die when cut - <AUTHOR> https://techcrunch.com/2016/11/02/self-healing-electric-ink-refuses-to-die-when-cut/ <comment> xkcd-sucks Cool, now we can actually light stuff on fire by overloading the conductive ink</comment>


German automakers who once laughed off Elon Musk are now starting to worry - <AUTHOR> http://www.latimes.com/business/autos/la-fi-hy-0419-tesla-germany-20160419-story.html <comment><USER2> To crib the top Reddit comment on this article for free internet points:

"Yeah, they laughed Elon Musk off so much that Daimler acquired nearly 10 percent of Tesla in the early days.

But at least they found an 88 year old (!) former executive of Daimler that dismissed Tesla."

"[https://www.reddit.com/r/technology/comments/4fmrrl/german_a...](https://www.reddit.com/r/technology/comments/4fmrrl/german_automakers_who_once_laughed_off_elon_musk/)?

<comment><USER3> I don't know that that means much. When the American big three saw Japanese carmakers overtaking them in terms of quality, delivering products people wanted etc., many entered into these ventures and bought sizable stakes, etc., but maybe except for Ford, I don't think they extracted much out of those partnerships.

<comment><USER4> I think GM would have gone straight out of business if they hadn't had their joint venture with Toyota (NUMMI). You can say they didn't learn as much as they could have, but I don't think you can say they got much out of it. You could say that GM owes its existence to Toyota.

<comment><USER3> I think there was untapped potential and undelivered potential. And the things they learned propagated way too slowly. That's my take.

</comment></comment></comment></comment><comment><USER5> As Elon would suggest, let's take this down to first principles. In some ways, Germany, with its focus on carbon emissions and clean power is a great market for EVs. There is a big obstacle, however. Air resistance at highway speeds is proportional to the square of the velocity. Kinetic energy is also proportional to the square of the velocity. What this means, is that there is a bigger physics barrier to making an acceptable Li-ion battery EV to run long distances on the Autobahn. Battery tech is going to reach "awesome" levels for the US a lot sooner than it will reach "awesome" levels for Autobahn-stormers.

(In fact, you could probably work out the approximate timing of this occurring using graphs of industry-wide improvements in Li-ion batteries and extrapolating when it will reach 4x today's capacity/weight and capacity/cost as a back of the envelope calc.)

<comment><USER6> Germany is also slightly smaller than Montana and nearly 10x as dense as the US, greatly reducing the relevant distances people regularly need to drive.

<comment><USER7> This is not actually that true. Germany is 7x as dense as the US, but Germany is only 5.9x as dense as the contiguous US.

About a third of the contiguous US has almost no people relative to the rest except for a few population centers (Intermountain West and Great Plains). There are several states with population densities higher than Germany, and quite a few within a factor of three, and naturally those will tend to have more people than the others.

So I'm not sure the median surrounding population density for an individual in the US would be that much different from Germany -- I'd think cultural factors, including public transportation availability, would have at least as much an effect on average distances driven.

</comment></comment></comment><comment><USER8> Good! I really hope that the car industry will finally start to take electric vehicles seriously, not only in Germany but everywhere around the world. It was a good strategy and justified to make money with an existing and mature technology (combustion engines) but it seems that the time for electric vehicles finally draws near. I really hope that the pressure from Tesla forces the other car makers to finally produce an electric car of practical value, so far most of their prototypes had only PR value.

I think what Tesla achieved in this market cannot be praised enough: Not only do they build electric vehicles that are actually usable, they also managed to create a brand with a perceived quality that is on par with that of the biggest premium car markers in the world.

<comment><USER9> > _I really hope that the car industry will finally start to take electric > vehicles seriously_

Every auto maker on the planet is heavily investing in EV technology. I'd say we're well beyond "starting".

</comment></comment><comment><USER10> It is exactly this why the world needs Elon Musks: To break out of the cycle of endless iteration of the same old technology. While conventionally fuelled motors have come a long way and today the cleanliness of fully electric vehicles might be a bit dubious given how electricity is largely produced and the bad battery technology employed, a large enough push in the right direction will fix that too.

Apparently the old minds of VW et al. are too slow to adapt. Let's see whether this situation becomes a giant slow-motion crash of German automakers (and therefore the German economy) or whether they can pull through with their promise to "not be the first, but the best" on the market.

<comment><USER11> Meh, the auto industry has been making real attempts at EV every decade for the last century or so. Last generation is what gave us the Prius. Tesla might have helped push us into pure EV a generation earlier but it was going to happen in our life times anyway.

</comment></comment><comment><USER12> When I see the factory videos of the production of the BMW i3, or that interview with the Monroe guy whose company took apart and analysed the i3... It seems to me BMW is well ahead of Tesla in many ways.

<comment><USER13> For BMW and others, they should have the advantage. They already have R&D, factories, distribution, and the workers in place. Tesla is having to build up everything from scratch including a battery factory.

<comment><USER4> The battery factory is owned and operated by Panasonic. Tesla itself operates out of the former Toyota/NUMMI factory in Fremont and has re-hired a substantial number of skilled autoworkers in the area.

<comment><USER14> yes, parent comment is typical carguy fanboyism translated into 21st century context. my favorite carbrand is special and unique, because of X reasons!

a new company producing cars isn't doing much "from scratch", other than design, and the basic concepts there are also pretty well established. as far as i can tell tesla is producing the same basic product as everyone else except all the tech people are into it because of elon musk, where they probably hated or didn't pay attention to cars before.

<comment><USER15> I'm a car guy, the type that loves manual transmissions, etc. My 'brand' is Toyota/BMW. I scoffed at electric cars as being even worse than an automatic, all that changed when I stepped into a Tesla.

I agree that Tesla's are an economic substitute for Toyotas but when you step into a Model S as a car guy you know it's different.

There's only two reasons I didn't buy it 1) I love road trips and there's one supercharger station in my province, and more importantly 2) I couldn't afford it. Tesla's are like BMWs you know they aren't that reliable, are really expensive, but there's nothing like driving one. Like BMW, it's a smiles per gallon car you buy it because when you step on it, it goes, not because it gets great gas milage.

<comment><USER14> so it's too expensive, and isn't practical, yet you pine and lust for one. it's also really really fast, and looks super duper cool and it's somehow better than the others. does any of this sound familiar?

in other words, same basic product as any high end fast car. this is coming from someone who has a high end fast car, is a car guy, has a 'brand', and has ridden in all the high end fast cars.

they're all basically the same.

musk is a car guy and lives in LA (bel air), car capital of the known universe. he's a genius for recognizing this market angle.

<comment><USER16> Isn't that exactly the point that Tesla made electric cars desirable (not practical)? Not sure that can be easily dismissed. They took a class of car that usually seen as weak and put into the same class as Porsche. That is no small feat IMHO.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> The winner in the German category of beer have been American breweries typically for many years now.

Much like the auto sector, it seems that German industry is able to compete on quality and efficiency, but not on innovation.

<comment><USER18> > The winner in the German category of beer have been American breweries > typically for many years now.

The beer itself is still the old recipes, brewed under the Reinheitsgebot.

Big Brew simply made a shitload of money by selling unsuspecting Americans stuff that a German wouldn't even want to smell, much less drink, and then bought up German breweries to teach them proper brewing.

<comment><USER19> I hear that prohibition was a huge factor in the decline in quality in American beer in the early 20th century. The hoards of Germany immigrants in the 19th century established breweries (including Coors and Millers) that produced good-quality beer.

During prohibition, the breweries went out of business and the brewers found other occupations. After prohibition, the new breweries that popped up produced beer of much lower quality. They found that the American public was just happy to have beer, and was way less picky about the quality of that beer. You'd think that after only 15 years of no beer, the former quality would be re-established, but I guess there wasn't a market for it anymore.

Same thing happened in California with the wine industry. It took decades after Prohibition before good quality wine returned. Those re-established wineries were producing some pretty terrible wines in their early years.

</comment></comment></comment><comment><USER20> what is the drive feel of a Tesla compared to a nice German car? Most cars feel really bad to drive compared to a nice BMW/Audi, and I've always assumed that the Teslas may have decent tech but still probably don't drive as well as cars made by people with much more experience than the Tesla guys. Is this accurate?

<comment><USER21> I test drove a Model S with the base wheels and suspension on damp roads. It was fine. A little soft and a little understeery, exactly what you'd expect for a large, non-performance car. The AWD was unobtrusive.

I have previously owned an M3 and driven a few other German sedans, mostly BMW. They are much more confidence inspiring. But I still reserved a Tesla Model 3.

</comment></comment><comment><USER22> This is the new form of advertising I suppose.

</comment><comment><USER23> All the German automakers are spending heavily on electric vehicle research and most of them are still making a profit.

The article made lots of assumptions about what the Germans are upto without actually finding out. Great journalism.</comment>


FreeCAD Arch development news - <AUTHOR> http://yorik.uncreated.net/guestblog.php?2017=361 <comment><USER2> I keep trying FreeCAD every 3-6 months, but it's so full of little bugs and crashes it's not really usable in my mind. I'm using the version from Debian unstable.

The UI is unstable (very easy to crash just by fiddling around), and the geometric kernel has a ton of little issues that you have to work around. At every new project I have the liberty of giving it a try without many constraints (no import/export required, minimal assemblies of elementary geometry). I really wonder how can you actually go through the relatively complex projects I've seen as a tutorial, really. I would always give up after a dozen crashes.

I've used SolveSpace in at least 4 projects, and I absolutely love it. The UI is different than FreeCAD, but in a very positive way (after learning the basics, I genuinely prefer SolveSpace's a dozen times!). It's a bit sad that SolveSpace's kernel is definitely inferior in terms of capability to FreeCAD (notably: no offsets and no chamfers!), but what is supported _is_ stable. I cannot say the same in FreeCAD, where chamfers would sometimes cause degenerate geometry or downright crash. The only minor complaint in SolveSpace is that currently it's not always obvious to see the construction tree, as it's represented linearly.

I bought a copy of VariCAD that I use on linux. But while it's certainly a capable CAD, I really don't like the UI, and the parametric modeling is clunky at best.

I don't think there's much more available in terms of parametric modeling on linux if we exclude prohibitive stuff like NX. I'd like to be proved wrong here.

I still think the best modeler I've ever used is still Rhino, a joy to work with. But while it supported parametric surfaces, it didn't really allow parametric modeling when I last used it.

<comment><USER3> I've used Solvespace a lot and agree, it's very intuitive and stable. Unfortunately it lacks a lot of the more in-depth features and also its constraints engine gets confused very easily, plus it doesn't do great with curved surfaces. I ended up moving away from it after getting frustrated that certain tasks were oddly difficult and complex, e.g. fillets/chamfer or changing the color of an object.

Nowadays I mostly use OnShape. It's similar to Solvespace in terms of workflow, but more comparable to a "real" CAD package feature-wise. It's also free for hobby use as long as you are willing to share your designs. The major disadvantage (to me at least) is that it isn't OSS, but by virtue of being in- browser it at least runs on Linux.

Edit: I'd also still recommend Solvespace, especially if you just want to do some basic drawings or learn parametric CAD.

<comment><USER4> Is Solvespace history based parametric CAD?

FreeCAD's architecture that combines history based modeling with inferior kernel (Open CASCADE) is about the worst choice from a reliability standpoint.

The best kernel, Parasolid, only started to get good when mainstream Unigraphics went history based parametric in 1992. The reason is that all of sudden Parasolid has to be able to correctly rebuild every model ever made in Unigraphics, SolidEdge and SOLIDWORKS - including bug-for-bug compatibility. That's an _extremely_ hostile evolutionary environment, and to survive Parasolid had to get extremely good.

OpenCASCADE in contrast only has to replay FreeCAD models, and there are modulo zero of those, and actually zero paying customers.

SpaceClaim has things the right way round to built a reliable CAD system: direct modeling X still v good b-rep kernel (ACIS).

Free/open source doesn't have a good curved surface kernel.

To build one is difficult. Every time you add a new surface or curve type, then case analysis for the intersection algorithms goes up with the square, so the key is to limit severely the number of surface types. One though I had was to just use Dupin cyclides (which covers the quadrics) and approximate everything else with cyclide sheets. There are some architectural CAD papers on these.

Disclaimer: Parasolid dev 1989-1995.

Edit: maybe that's what Solvespace does - limit to just NURB surfaces? Way to go! The Dupin cyclide approach would have to approximate NURBS with cyclide sheets, but the intersection algorithms could be easier to implement because they are implicit quartic surfaces.

<comment><USER3> I'm not sure, I think Solvespace is history based, but I don't know enough about CAD geometry engines to give an in-depth answer. Most of my experience with CG comes from the simulation modeling aspect (think more GEANT instead of CAD).

I'm pretty sure Solvespace is using their own geometry engine implementation and not something like OpenCASCADE or CGAL (as in OpenSCAD). As you note, it really struggles with curved surfaces. Just drawing a cylinder and doing some booleans on it will cause problems. And it can have a fit with constraints too, e.g. the symmetry constraint almost always leads to an unsolvable sketch for me. Onshape and Solidworks (which I dislike) perform noticeably better.

But, Solvespace really in most cases gets the UI and workflow right. It's highly intuitive except for a few things (as I said, a couple things like changing colors for a solid are really irritating). I think it's in most cases a better choice to learn for hobbyists than something like OpenSCAD, which is the maker darling.

OnShape to me feels like what I want Solvespace to grow into. The workflow is actually very similar, but as you say the geometry engine is vastly superior. And it's obviously the money thing. CAD is very much a "long tail" process, where it's not hard to make 90% of the features that are needed, but where everybody needs lots of stuff from that last 10%. This has always been an area where open source has had trouble.

<comment><USER5> What do you dislike about SolidWorks?

<comment><USER3> It's overly complex for what I do, which is mostly hobby stuff with some occasional custom designs for my work use (academic research lab, mostly custom mounts and brackets for obscure equipment). Also the onerous licensing and price. Admittedly it's been a while since I used it, so maybe the UI is more friendly nowadays but I never really found it to be particularly intuitive.

But the biggest reason is I'm a Linux guy and I want something I can run without rebooting into Windows or a VM. I'm usually extremely wary of complex applications running in a browser, but I have to say OnShape works great and performs well. And being in browser means it runs on Linux no problem, which is a major benefit to me.

</comment></comment></comment></comment></comment></comment><comment><USER6> Has anyone tried this recently? I did a few years ago and it wasn't really usable.

The only good open source CAD program I've found is SolveSpace ([http://solvespace.com/](http://solvespace.com/)). It's a bit of a weird program but actually works well.

<comment><USER7> Yes, I use it often. It works pretty well although it's really not perfect.

It's the only program I know that's able to directly import files from OpenSCAD.

I like to do a rapid sketch on OpenSCAD and then add fillet or chamfer in FreeCAD.

It also does good extruding of svg drawings.

I have tried other software, from Rhino (>$1000) to Onshape (free) but none match the simplicity of this workflow: openscad or svg to freecad, then export to .step

<comment><USER8> If you don't really care too much about parametric modelling, blender can import svg, extrude and bevel it quite well.

It also has a nifty 3D printing addon that is useful for cleaning up a mesh. I've started using blender almost exclusively for my 3D prints because by the time I spin up my Windows VM and pull a SolidWorks license I would have my mostly simple models done in blender.

<comment><USER7> But I love parametric modelling. I like thinking about elementary shapes (cubes, spheres, cylinders) and inputing them very precisely by setting mm and angles, etc. (really)

I have not really tried blender yet; is there a simple tutorial that you would recommend?

<comment><USER8> You can be pretty precise in blender - you can manipulate geometry to real world units easily. However unlike parametric CAD the geometry is mostly faces, edges and verts.

There are a lot of great resources online. BlenderGuru is probably the most popular.

This is one I came across here on HN that I like

[https://learntemail.sam.today/blog/blender-for- hackers-3d-mo...](https://learntemail.sam.today/blog/blender-for- hackers-3d-modeling-is-just-like-using-vim/)

</comment></comment></comment></comment></comment><comment><AUTHOR> My hat is off to LulzBot creators Aleph Objects for sponsoring FreeCAD development in addition to the two full time Blender devs.

Maybe someone knows, if there are even more FOSS 3D projects they are funding?

<comment><USER9> They also have sponsored Slic3r. ([http://slic3r.org/donations](http://slic3r.org/donations))

</comment></comment><comment><USER10> I think this project would gain much more traction if it was simple to integrate it within jupyter notebooks. Currently, it is possible, but FreeCAD window pops out outside of browser, or if it is inside the browser the scene is static (no interaction, selecting, zooming etc.) Anybody here knows solution to this?

<comment><USER11> This was a Google Summer of Code project that didn't get an applicant/accepted this year: [https://www.freecadweb.org/wiki/IPython_notebook_integration](https://www.freecadweb.org/wiki/IPython_notebook_integration)

</comment></comment><comment><USER4> I think this a smart pivot for FreeCAD: from MCAD to Arch.

The weak point in the kernel (Open CASCADE) is curved surfaces (and associated nightmare case analysis for blends/fillets/chamfers).. They just aren't that important in Arch. For example, SketchUp doesn't have them at all.

So now we have in free (as in freedom) software:

Arch CAD: FreeCAD - history based parametric architectural CAD - with no curved surfaces.

MCAD: Solvespace - direct modeling with streamlined NURBS only kernel.

<comment><USER12> Don't think this can be considered a pivot, just a couple of people putting extra effort into the Arch side of things. CAM (Path module) and a revamp of Part Design are (with groundwork for Assembly) are also happening in 0.17</comment></comment>


New AWS Deep Learning AMIs for Machine Learning Practitioners - <AUTHOR> https://aws.amazon.com/blogs/ai/new-aws-deep-learning-amis-for-machine-learning-practitioners/?sc_channel=sm&sc_campaign=launch_&sc_publisher=TWITTER&sc_country=Global&sc_geo=GLOBAL&sc_outcome=awareness&trk=_TWITTER&sc_content=MXNet_a331e93a_DL_AMI_Conda_Based_AMI&sc_category=MXNet&linkId=44774947 <comment><USER2> They're probably similar software-wise...but the Nvidia GPU Cloud is a docker container registry, so you can pull the docker image and use nvidia-docker to run it. Containers are easier to move around across cloud providers (AWS, Azure, Nimbix, etc...), or even to your local machine, so you don't need to manually configure (and sometimes compile from scratch) a whole slew of complex software packages. The Nvidia GPU cloud is maintained by NVIDIA themselves, so you know they have the configuration just right for optimal performance on their GPU hardware, wherever you choose to use it.

<comment><USER3> I never played around with nvidia-docker. Is there much, if any additional overheard to the gpu compute by running through it vs. natively with an AMI?

<comment><USER2> nvidia-docker is just docker that configures the docker to see the physical gpu device, and also mounts the run-time drivers that match the hardware driver that is installed on the host. It makes life way easier if you need portability across different Linux hosts for GPU-driven software. The Nvidia container images also have some of the "proprietary" free software packages like cuDNN which accelerate some popular deep learning packages with optimized CUDA implementations.

If you run on a bare-metal platform, like your laptop booting linux or a bare- metal cloud, there's a very small amount of overhead for using nvidia-docker, mainly just the same overhead as running a regular docker container (a container is just chroot + Linux kernel cgroups + cgroup kernel namespaces).

If you're in an AMI on AWS, it's a virtual machine _anyway_ , so there's virtualization overhead which is quite a bit higher than container overhead, but there's other baggage as well such as shared tenancy/noisy neighbors, and possibly oversubscription of hardware to the virtualized environment.

If you're in a docker container in an AMI, there's the slight container overhead plus the virtualization overhead and baggage and benefits that come with it. Virtualization overhead is probably an order of magnitude higher than container overhead. Natively with an AMI is not so native (though Amazon is trying to improve that with their C5).

<comment><USER4> >If you're in an AMI on AWS, it's a virtual machine anyway, so there's virtualization overhead which is quite a bit higher than container overhead, but there's other baggage as well such as shared tenancy/noisy neighbors, and possibly oversubscription of hardware to the virtualized environment.

Can you post or cite something related to virtualization overhead being "probably an order of magnitude higher than container overhead"

Your other points are very fair.

Any mention on costs for the docker versus Ami?

</comment></comment></comment></comment><comment><USER5> How do these AMIs stack up against the recently announced NVIDIA GPU Cloud images ([https://www.nvidia.com/en-us/gpu-cloud/](https://www.nvidia.com/en- us/gpu-cloud/))?

<comment><USER6> I did not see Keras [1] on the Nvidia machines, though to be fair, I did not search exhaustively. Keras is just too convenient for rapid prototyping to go without.

[1] [https://keras.io/](https://keras.io/)

</comment></comment><comment><USER7> If you want to use the p3 instances with Tesla V100's, you'll need to use CUDA9 instead of CUDA8, and unfortunately none of Amazon's AMI's have the latest PyTorch that support CUDA9. The easiest way to use them is get one of the Conda Deep Learning AMI's and then follow the latest PyTorch install instructions, which seems to work pretty seamlessly.</comment>


Five Years of Google Closure - <AUTHOR> http://derekslager.com/blog/posts/2015/06/five-years-of-google-closure.ashx <comment><USER2> I worked with Closure for a couple of years. It's great, but it has none of the characteristics that tend to make a library popular. It does almost nothing sexy. It's hard to set it up. Feature-for-feature comparisons to more accessible libraries (jQuery+plugins) are unconvincing. It's also verbose and kinda ugly, which folks tend to get hung up on. The various libraries are also very thorough, well-tested, etc., and the build system is amazing -- but that's not stuff that sells.

<comment><USER3> > Feature-for-feature comparisons to more accessible libraries > (jQuery+plugins) are unconvincing.

The attractive part of Closure was that it had extremely robust, unit-tested counterparts to jQuery's plugins and the reliability of it was never in question. For a while, their URL parser was superior to anything in the jQuery ecosystem. By contrast, jQuery plugins have many different authors with widely variant degrees of quality.

Part of the verbosity is due to its type system, but it was one of the few client-side tools I used where my code had a high chance of running well once I satisfied the compiler. I notice React's Flow and TypeScript are realizing the benefits of better type checking which Closure has had for ages.

</comment></comment><comment><USER4> The closure compiler itself is amazing, I feel like if that and the whole compile/build process had been the only focus of the google closure tools project it would have been a much larger success than it was/is.

I read through parts of the source and used bits and pieces of ideas at various points, even built toy apps with the toolchain, but for me, when using the libraries I always felt like I was programming in java, which might be endearing to some, but I didn't find it such an enjoyable experience and just went on my way after a while using only the compiler. IMHO javascript is all about its functional nature its where all the elegance, simplicity, and modularity comes from, I found it kind of placed on a backburner in the closure libs, but could just be me...

</comment><comment><USER5> Truly an vastly underated piece of software. In using ClojureScript, I thankfully don't have to understand it very well in order to get the benefits of using it.

</comment><comment><USER6> Reasons I don't care for Closure (currently using it in a production project):

1) Depends on both Java and Python. Ugh 2) It's big, and has to be setup anywhere you are doing builds (i.e. continuous deployment) 3) Hard to setup, understand, compose tasks (none of that is impossible to figure out, just harder than many of the alternatives)

The article made a minor mistake about Angular - Google is using Angular in over 1,400 internal and production apps (I know, the article just mentioned production, but the number should signify how all-in on Angular Google really is). Oh, and fun side point - they are using the master branch version of Angular (1.x) - the Angular team needs to run not only all of their Angular tests, but also all of the tests for all of the projects that use Angular to ensure they didn't cause any regressions.

Overall, Closure is that library you really want to love, but it just rubs you the wrong way over and over again until you decide it isn't for you. (in my experience)

</comment><comment><USER7> My team used this library extensively for years. I thought the best part was the dependency resolution through goog.require and goog.provide, but by far the worst part was the type annotations!! They made me think about my types, which was great, but having to write them is just old-school. Every code review was littered with type annotation corrections. The tooling, starting with the Python scripts was painful, though plovr did make it better.

Then there's Advance Compilation, a potentially great feature, but if you don't enable it from day one, you'll have a hell of a time ever enabling it later, especially under pressure to deliver.

Once other teams started using TypeScript, we had to hack the plovr server to make it serve up map and ts files.

Our whole project failed, so we got to start over with TypeScript.

My advice: don't use it! If you want type safety and dependency management for large teams, use TypeScript.

</comment><comment><USER8> I'm just starting a greenfield application development, and I tried and failed to bend my mind around Google Closure Compiler so that I could incorporate it into my build. Instead, I am using UglifyJS2 for my minification. UglifyJS is very good, but the function inlining that Closure Compiler can perform is what I am really after. (Closure Compiler is a real optimizing compiler!) I'd use lodash everywhere without guilt!

For my builds, I am using Webpack, (but the same goes for Browserify), Closure Compiler was not designed to play nice with other bundlers - it wants to be its own complete ecosystem that is focused on Google internal needs/wants.

I want to write my code as CommonJS modules, and I want plugins that can attach at different stages of my build system. For example, I want to be able to traceur --> lint --> closure compile --> karma test w/ coverage report --> bundle+source maps. Plugins and Loaders in Webpack can be scripted to do this kind of build and that's what makes large-scale JavaScript development possible. Closure Compiler currently has some half-baked CommonJS support. Even so, it does not seem possible to plug it into a bundler build system, given what command line options it has available.

If there was magically a closure-compiler-webpack-plugin package tomorrow that I could install into Webpack, I would be first in line to build with Closure Compiler and with Advanced Optimizations always turned on.

Closure Compiler might be 5 years old, but make no mistake, it is unique and awesome compiler tech! I just wish it was a priority for Google to see it widely used in contemporary JS development outside of Google and apart from the Closure library.

If I have caught the interest of any Googlers reading this, I'd also ask that Closure Compiler support JSDoc3 annotations. Not that I am bitterly opposed Closure Compiler JSDoc annotations, I'd just like to see standardization on the JSDoc3 set of annotations which I think are pretty expressive and understandable and grokked by many other tools out there.

</comment><comment><USER9> We use Google Closure at Lucid Software for Lucidchart and Lucidpress. It has been a great tool for us, especially for sharing code across a huge javascript codebase. Compile time type checking and dead code removal have also been great.

It is unfortunate that it isn't used more widely.

It's nice that you can see some of Google's open source projects built using closure

</comment><comment><USER10> The Closure Library definitely has its bright spots, and it was my library of choice for many years. For all its warts, I particularly like the design of goog.ui. goog.editor is a wonderful part of the library too. I still run ##closure-tools on Freenode[1] but nowadays we might get a question or two a month, at most, which is definitely a sign of the times ... there was brief uptick in activity when ClojureScript first became popular.

When developing software for evergreen browsers, or not needing to target old IE in general, the cross-browser reliability and performance the library provides is less important. I was lucky to get to pick a prominent Closure Library developer's brain about this last year, and he expressed a similar opinion. I agree with the author of this post in that ClojureScript has breathed new life into the Closure Tools, and gave a presentation last year that touched on this with some code examples showing the brevity CLJS allows[2], but it seems that Closure Library's ship has mostly sailed.

[1] [http://oinksoft.com/closure-tools/irc/](http://oinksoft.com/closure- tools/irc/)

[2] [http://oinksoft.com/closure-tools/sgdg- jul14/](http://oinksoft.com/closure-tools/sgdg-jul14/)

</comment><comment><USER11> Somehow I had never heard of Google Closure. This reminds me a lot of Apple's WebObjects. When I used it, in the late 1990s and early 2000s, it was by far the best web platform out there... and I think in a lot of ways it still is. (If it had remained Objective-C based and gone open sourced I would still be using it today.)

I think there is a bit of a problem in "engineer culture" where there is a tendency to fixate on a particular technology even when it's not the most appropriate for particular use cases. There are certainly use cases where MongoDB and Node.js are the best choices, but those cases are much narrower (particularly in the case of Mongo) then I think the community recognizes and they start being adopted as general purpose tools appropriate for all use cases.

I'd like to see a broader level of coverage and a change in our culture so we embrace more choices.

While WebObjects is powering iTunes and the AppStore still today... and Apple's even gone further and built javascript based platforms (Sproutcore was largely an Apple product) they no longer are putting the effort in they did with webobjects.

For isntance, with web objects you had interface builder- that allowed you to build web pages/sites much the way you build iOS apps using it now, and it was just as powerful, resulting in rapid development without the WYSIWYG issues of other tools. The lack of adoption by the community, though, means Apple only does this work in house for its in house users now. It just wasn't popular enough to support the work on Xcode and IB that was required.

</comment><comment><USER12> Would love to see Google Closure compiler features combined with Webpack features. I want to easily:

\- write ES2015 \- compile with dead code elimination, static type checking etc, but super fast like webpack \- include npm modules easily \- include assets using something as simple as webpack's loader

</comment><comment><USER13> Am I the only one who is seriously annoyed by the naming of this library?

I mean if I work at Google and create a C library, should I name it 'Google Pointer'? or a C++ library called 'Google Inheritance'? maybe a Haskell library called 'Google Monad'.

Aaaargh!

<comment><USER14> And imagine the outrage that would result if you had the audacity to commandeer the technical term "chrome" by naming your web browser "Google Chrome". :)

<comment><USER15> I thought Chrome was the OS.....

Using the same name for two distinct products does not end well. I think we would have all learned from the .NET naming at Microsoft, where suddenly everything was .Net (Office .net etc etc etc)

</comment></comment></comment><comment><USER16> Tangentially, in case someone else is curious, Google's Inbox doesn't use closure, it uses gwt and j2obc [1]. Probably due to the ability to use java code on android, IOS and the web.

[1] [http://gmailblog.blogspot.ru/2014/11/going-under-hood-of- inb...](http://gmailblog.blogspot.ru/2014/11/going-under-hood-of-inbox.html)

<comment><USER17> Inbox does use Closure. That blog post just talks about the data model using GWT to cross compile to many platforms. There's Closure in there and some other frameworks too.

Think of Closure like the JDK, it's robust and expansive, but not very opinionated and sometimes ugly. So you put frameworks on top that are sugary.

</comment></comment><comment><USER18> The most complete example of a project using Closure library I can find is the end-to-end project[1].

[1] [https://github.com/google/end-to- end/tree/master/src/javascr...](https://github.com/google/end-to- end/tree/master/src/javascript/crypto/e2e)

</comment><comment><USER15> I thought this was about taking 5 years to recover from working at Google and getting "closure".

Must be me misreading the title as some American expression.

The article was quite different!

</comment><comment><USER19> > If the measure of success for a JavaScript framework is popularity, Google > Closure has failed miserably. It's old, unsexy, and has missed its turn on > the hype train. Google spends no effort on PR for the library, and seems > content with it quietly powering the majority of its flagship applications. > And given that, the lack of hype has mattered very little to us, as it's > been a very good solution to our problems over the past five years.

>

> That's not to say that adoption doesn't matter. The absence of a rich > community around Google Closure has been disappointing. Only a single book > on Google Closure has been published, and the surrounding tools have been > slow to evolve. Contrast this with Angular, which has achieved off-the- > charts hype and has developed a massive community despite minimal usage in > production Google applications. Many books and countless blog posts have > been authored explaining various patterns and concepts, making it much > easier to get started.

And that is the cost of operating in a secretive, closed fashion as Google does.

<comment><USER20> Sometimes that's exactly what you want, though. If you're deriving a competitive advantage from a tool, it's often to your advantage for as few people to know about it as possible. That's why Google kept it secret and internal-only for the first 5 years of its existence, and only open-sourced it once the hype train had moved on to other technologies.

<comment><USER21> But in those 5 years industry passed it by and now Google is crippled by legacy technology. Compare to Guava Java, which also powers Google, is open source, and is still best in class today after many years

<comment><USER20> Well, the same thing happened to many of the more open, hype-laden technologies. JQuery and Angular are both also obsolete, and the new hotness is React, with Google trying to get in on the action again with Polymer but so far uptake seems limited. I also wouldn't say "crippled" \- I worked with Closure on both Google Search and Google Plus, and while I certainly wouldn't use it for a startup, it's _much_ better than all of JQuery/Angular/React for a 50+ person team.

Guava is in a much different position. As a fundamental class library, it's much more deeply embedded in your code than a front-end framework, and so switching costs are much higher. You could also argue that Java as a whole is "crippling legacy technology", with newer apps being written in Go, Node.js, Ruby, Python, and hopefully soon Rust.

<comment><USER22> Can you give some more information on why Closure is better than React for large teams and why Closure wouldn't be good for a startup?

<comment><USER20> Closure is much more tightly typed and namespaced, it has a larger library of pre-built components, it bans (via compiler warnings) practices that are hard to maintain, and it errs toward verboseness. All of these improve the readability of code at the expense of its writability. In a large established organization, you read code much more than you write it. In a startup, you write it much more frequently than you read it.

<comment><USER23> The react world has flow that does the same type checking, for the bundling webpack is now superior, and warning is handled by eslint, and with babel for ES6, and PostCSS for css next I don't think there is a lot of reasons to use the closure tools apart for the components.

<comment><USER24> > flow that does the same type checking, for the bundling webpack is now > superior, and warning is handled by eslint, and with babel for ES6, and > PostCSS for css next > I don't think there is a lot of reasons to use the > closure tools apart for the components.

The fact that your list is that long is a good reason. Using best-of-class libraries is brilliant (and I'd like to all the time), but using good-enough libraries that are well tested with each other and unlikely with new releases to change behaviour in ways that will create edge-cases or interop problems: that is pragmatic.

Plus the reduction in developer-rabbit-holes when every developer tries to include its own favourite (Webpack! Browserify!), the consistent documentation, and the ease of setup.

Not to say you're wrong, but I feel people overlook the benefit brought by well-developed monolithic frameworks.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> Clicked on this article hoping for closure on Google issues that lasted for 5 wholes years.

Thought to myself "Now that is something I can related to. Having issues with Google for years on end and wanting closure. Maybe I can get some closure too by reading this article."

Was severely disappointed. Google, the type of closure you provide is not the type I need.</comment>


Ask HN: How can you tell if a company prioritizes maintainability over delivery? - <AUTHOR> Specifically with respect to software development.
The title should probably read "_faster_ delivery".
I am currently in the gaping maw of chaos at my second development job of my career, and I see so many opportunities to clean things up and improve readability. Maybe I am just a naive Jr. Dev, but I prefer things to be as simple as possible – even if it means more lines of code, or comments explaining the business logic (ie what it _should_ do) instead of relying on external Jira tickets.
How do you go about bringing this up in the interview process? <comment><USER2> Sometimes you just have to look at the hardware product. A company which solders in batteries, for example, is probably not big on maintainability. Likewise, it it takes a special tool to gain access, it's likely not been designed by maintainability motivated engineers. For software it's a little harder. I think having fewer options, fewer knobs, and a simpler intuitive structure is an indicator of a bias towards maintainability. Also, not having source is a definite barrier to maintainability.

BTW, I find it hard to believe that "_faster_delivery" and maintainability are in opposition. Most of us would agree that maintainable systems have fewer bugs at every stage. And experience has taught us that bugs, particularly subtle bugs, take a long time to find and correct.

</comment><comment><USER3> Listen to middle management / product managers and how they talk about goals, task priority, and solutions to customer problems

</comment><comment><USER4> aka "Technical debt"

Get use to it, it exists in most companies. You could ask if technical debt (backlog) is actively being worked on is there a plan/vision to chip away at it etc.</comment>


Ask HN: anyone here founded a company in the US while on F1 student visa? - <AUTHOR>

We are a group of international students on F1 visa in the US, we've built some android apps that are getting popular. So we'd like to set the legal things straight and found a company (primarily for not messing up our personal finances with app/ads income, and not violating our F1 visa terms)
We are wondering if anyone on HN ever successfully founded a company while on an F1 visa in the US, without any legal troubles (financial, tax, immigration etc.) later on?
We know it's best to ask some lawyers about questions related to this issue, and we are contacting some lawyers too. But it is always good to know if there are any real life examples from the HN community :) <comment><USER2> I know people who have done this and different people have a different appetite for risk. But what you are thinking of doing is illegal from the USCIS perspective.

On an F-1 Visa you can only work for upto 20 hours only on University related jobs (library etc). Not on your start-up.

An option would be that you can apply for an OPT, get am American/resident co- founder, set up the company and then work on your OPT.

The USCIS considers something as 'work' even if you do not get paid for it as long as the company would have hired and would have paid somebody else to do it. So one way to get around this is to have an American/resident co-founder who can be doing all the 'work' and you can share profits in the concern.

Hire lawyers. Most people find that it is not worth messing up stuff with USCIS.

<comment><AUTHOR> Thanks for your advice. We've heard similar stories before (about how to find an US resident as a co-founder to do all the "work"). Working on our OPT may not be an option for now though, as we are not near to graduation...

But what if we don't found a company at all, just receiving app/ads income from our app to your personal accounts? any F1 students got problems with that before?

<comment><USER2> The question is not if people got in problem for that, the question is, is it illegal. And no, as far as I know, it is not legal. Still I know people who do it and it really depends on if you want to stay in the country and try to become a resident etc. If you do, it could be too risky.

How about starting a company back in your home-country?

<comment><AUTHOR> Ya, starting up a company in our home-country is another option we are thinking, but we are targeting the US market, not sure how complicated the international business thing could get...

</comment></comment></comment></comment><comment><USER3> Here is someone that did this, figured it might be helpful for you.

[http://www.k9ventures.com/2009/09/my-story-and-support- for-t...](http://www.k9ventures.com/2009/09/my-story-and-support-for-the- founders-visa/)

<comment><AUTHOR> Thanks!

<comment><USER4> test

</comment></comment></comment><comment><USER5> In a related note:

Has anyone founded a company in the EU while on a student visa from the US (or elsewhere)?

I'm currently studying in Lithuania and am hoping to come back to Europe post- graduation, but I realize the difficulty in that (for more then 90 days) without a work visa. Founding a company would solve that, and there's more then enough things for me to work on, I just have no experience in European company founding and requirements. Has anyone done this?

</comment><comment><USER6> It's legal, as long as you fill out the adequate paperwork. It might be as simple as filling out a W-8 instead of a W-9 (for taxes).

</comment><comment><USER7> A friend of mine has, although he had some American co-founders. Will try to get some more info.

<comment><AUTHOR> Thanks! Ya, our problem is we are all F1 students, from what we learnt, none of us can officially "work" for the company... please do share more about your friend's experience (his role in the company, was he only a "consultant" of the company?). Really appreciate it!

</comment></comment><comment><USER8> need a silent business partner / visa sponsor? (i already have an llc and make iphone apps, and am looking for an android dev team) - i have gmail and my name is jkatzer on there. (take that spam bots)</comment>


The abolition of work - <AUTHOR> http://deoxy.org/endwork.htm <comment><USER2> Voted up for being accurate about the evils of work. Pity the author has absolutely no clue what to do about it, and so little knowledge of economics as to not even be aware of his own ignorance.

It's all about incentive structures, professional specialization, and comparative advantage. If you want to replace work, you have to find something better. The author shows no sign of understanding why they are important.

If you could come up with a better incentive structure that gives people a reason to try, while still exploiting professional specialization and comparative advantage, _without_ creating bosses and managers to regiment life, you could systematize it and start companies that used it which would outcompete existing companies.

<comment><USER3> Comparative advantage is the biggie. Everyone wants to be the astronaut.

</comment></comment><comment><USER4> I could not disagree more with the article. Work is not evil. Oppression is evil, sometimes the way people treat each other in the context of work is evil. But work itself, especially hard work, is good for the soul.

It's not the drudgery or labor that's so satisfying. It's the sense of working on something necessary. No one would drive rail spikes or write in machine code for fun--at least, not on the scale necessary to actually achieve something. But once upon a time, the tasks were necessary, and those who undertook them rightly took joy in what they were achieving. That's work. Doing something necessary and useful is satisfying, even if it isn't fun.

Automate all you want; I'm all for it. It's one of the ways we make ourselves rich. I'd never argue that writing in machine code or taking out the garbage are inherently good for the soul, and eliminating the need for such things is good. But while they remain necessary, they are a source of satisfaction. There will always be tasks like that, because there will always be great things we can achieve that aren't possible without a lot of work.

I'm constantly pursuing projects, some for pay and some for play. But the funny thing about projects for play: most of them I never finish. The ones that do become great have a lot of the characteristics of work: I can see a need for them, I expect a big payoff for completion, others ask me to get them done, there's some sort of time constraint, I approach in a disciplined way and power through the dull bits. Of course, the inverse is also true: those projects I do for pay which turn out great have a lot of aspects of play: I make them interesting, I learn things, I experiment and inject humor, I have time to make them beautiful, to do things right. Great achievement lies in the intersection of work and play, I think.

I certainly wouldn't advocate unemployment, as this fellow does. I spent a year or so unemployed, once--and with no real financial pressure to get a job. It was absolute misery. My creative and passionate impulses slowly dried up. I always say, "I'll learn this new language when I have time," but in fact I learn things exactly when I _don't_ have time, but need them to get something done. When I had all the time in the world, I didn't pursue all those projects I was so interested in. After a few half-hearted starts, I shriveled into a TV-watching video-gaming internet-reading ball of goo.

I plan to never pursue that lifestyle. I may retire early from financially necessary work--in fact, I plan to. But I don't plan to ever actually stop working. That was hell!

</comment><comment><USER5> I used to have my freshmen composition classes read Bob Black. Was always interesting, but often hard for some students to see the difference between work, the stuff that gets done, and work, the social construct. I think it's good for everyone to think about the ways in which the latter is alienating (in the Marxist sense) and exploitive, even (maybe esp.) if you're not an anarchist.

</comment><comment><USER6> Standard counter-argument: someone's still got to take away the trash.

<comment><USER3> Now imagine trash bins that trundle themselves, Roomba style, to the loading lift of a DARPA-challenge AI-drone garbage truck.

The problem nowadays is not really eliminating dull work. We're pretty close to the tech level even where we haven't already reached it. The problem is figuring out an economic system that still feeds, houses and entertains people despite near 100% structural unemployment.

<comment><USER7> In such a post-scarcity Asimovian future, limited socialism (perhaps 1-5% of GDP) would be a viable option. Socialism misallocates resources. But if you have nearly unlimited resources, why worry about misallocating a small fraction of them?

<comment><USER8> "But if you have nearly unlimited resources, why worry about misallocating a small fraction of them?"

Because there is no society so rich that it can't misallocate even worse. Yes, I include full post-Singularity societies in that statement.

I think rather than saying "socialism can work then" or even "X can work then" for X in (socialism, anarchy, capitalism, etc.), it is rather worth saying that in that case, the foundation will have changed so radically that it is, correspondingly, time to completely reconsider society's economics from scratch.

The laws of economics will still be in play, and for a _very_ long time there will still be the challenge of deciding _which_ projects we wish to engage in, large and small ("which star do we colonize?"). That is not the problem that goes away. The problem that goes away is the lack of resources for basic happiness for some entity, a world we still live in.

 _Edit_ : Actually, for proof I point to modern society. We are _already_ , not to put too fine a point on it, "fucking rich". We have massively more resources than we did even twenty years ago. Yet many of us feel poorer today, because an awful lot of that excess is getting tied up in various things that I will put under the umbrella of "economically unproductive". For instance, in the context of recent state government funding troubles, many people have observed that almost across the board state governments are spending radically more than they did in 2003, yet it hardly seems like they're performing that many more _services_ than they did in 2003. A lot of that is because we are being terribly economically inefficient.

Health care has some of the same problems. We have radically more resources than we used to, but thanks to some systematic failures in the system (pick your choice of excessive centralization or insufficient centralization, for this point I don't care), we are spending way more than we need to. This is proved by people's ability to fly to, say, Argentina, and get virtually identical surgeries (even in a clean and safe environment) for one-tenth the price, give or take a bit. (The exact ratio doesn't matter, what matters is that it is _large_.)

We should be either getting massively more from our government, or paying massively less, than we did ten years ago, but we aren't. Health care expenditures may still be going up (it is a potential economic sinkhole just by its nature), but it still should be costing less _per procedure_ than it did ten years ago, but it doesn't. (On average. There are exceptions where medicine has advanced so far that it is cheaper for some procedures.)

Unfortunately, it's just not possible to "wealth" your way out of needing to put at least _some_ thought into economic efficiency.

(Also, I _personally_ do not feel poorer and believe that we are still better off than twenty years ago. I am merely observing that A: I appear to be in a minority there, at least among people motivated to post in online discussions and B: we should be even _better_ off than we actually are.)

<comment><USER7> The point I made was somewhat more limited than what I think you are arguing against. Obviously, wealth needs to be properly allocated or it is useless. However, my argument was merely that the solution to one particular problem ("how to care for people replaced by robots") would be cheap in the particular future envisioned.

Consider how this might work in modern terms. If you can't survive in the modern economy, you are provided with food and a bed to sleep in. We actually have such a system (homeless shelters + soup kitchens) and the cost of providing it is a negligible fraction of our GDP.

The problem comes when you try to add too much to this basic package, or when corruption eats up big chunks of wealth. I don't disagree with any of that.

And you are probably right about jealousy: people will feel poor when they get free health care but immortality pills are only for the rich. But that's a separate issue.

</comment></comment></comment></comment></comment><comment><USER9> I'm worried about the full scale psychological break down that's likely to come from not requiring anything from anybody. pg mentions 'Manhattan house wives' somewhere in his writing. It's that psychological affliction writ large. Some people can auto-impose the structure necessary to not sink into an orgy of escapism, but I'm guessing it's less than 3%.

Imagine the popular culture in a world where it's trivial for people to endlessly indulge their most idiosyncratic whims and vices - where hard knocks no longer cull delusional and generally ineffective behaviors.

</comment><comment><USER10> This reminds me of another manifesto arguing to expand our ideas of what's possible, 'The Hedonistic Imperative', that takes a mostly pharmacological approach:

<http://www.hedweb.com/>

For that matter, this piece has strong similarities to the Unabomber manifesto, aka "Industrial Society and its Future".

[http://en.wikisource.org/wiki/Industrial_Society_and_Its_Fut...](http://en.wikisource.org/wiki/Industrial_Society_and_Its_Future)

All such romantic manifestos are interesting in how they make you think, but the devil is in the details. Humans compete for power, for status, for reproduction; if you somehow remove economic competition you might get something worse, corrupt and oppressive and murderous in another direction.

And the hunter-gatherer past was a bit nastier than this piece lets on. Some alternate views:

[http://www.troynovant.com/Franson/Keeley/War-Before- Civiliza...](http://www.troynovant.com/Franson/Keeley/War-Before- Civilization.html)

<http://www.edge.org/3rd_culture/pinker07/pinker07_index.html>

Pinker summarizes the knowledge of prehistoric combat death rates: "If the wars of the twentieth century had killed the same proportion of the population that die in the wars of a typical tribal society, there would have been two billion deaths, not 100 million."

<comment><USER11> There is a long-standing anarchist critique of industrial society, and both the Unabomber and Bob Black are part of that tradition. The Unabomber just never got the memo that "we tried bombing our way into anarchy back in the nineteenth century and it didn't work out so well".

</comment></comment><comment><USER12> Marshall Brain's 'Robotic Nation' explores what would happen in a highly automated society (e.g. robots would take over all sectors)

<http://marshallbrain.com/robotic-nation.htm>

</comment><comment><USER13> From the text: _As Smith observed: "The understandings of the greater part of men are necessarily formed by their ordinary employments. The man whose life is spent in performing a few simple operations . . . has no occasion to exert his understanding . . . He generally becomes as stupid and ignorant as it is possible for a human creature to become." Here, in a few blunt words, is my critique of work._

Then what would the outcome be if man don't have to work at all? Better for some, but worse for many others is my guess.

</comment><comment><USER14> I always liked "Theses on Groucho Marxism" better: [http://www.collectivereinventions.org/Archives/pages/theses_...](http://www.collectivereinventions.org/Archives/pages/theses_on_groucho_marxism.htm)

</comment><comment><USER15> <http://www.whywork.org/>

</comment><comment><USER16> I posted a similar idea a couple years back:

[http://www.jonathanbrun.com/2006/07/guns-germs-and- happiness...](http://www.jonathanbrun.com/2006/07/guns-germs-and- happiness.html)

</comment><comment><USER17> I believe work is the source of happiness. Happiness comes to you when you see the fruits of your work.

I remember feeling really happy after finishing up a program that I had been working on for a long time. Just seeing it work so perfectly gave me an incredible sense of satisfaction. It was far better from the satisfaction/pleasure I got from doing things like watching TV/movies, going on dates, eating at nice restaurants, etc.

Developing the program was definitely not play either. It involved things (like fixing bugs, coming up with algorithms) for which I had to expend a considerable amount of intellectual energy. It was work, but it was work worth working on.

</comment><comment><USER18> it's easy to not be stuck to a job; just don't get into debts and marriage. then you can always pick and choose your schedule.</comment>


Show HN: Verify JSON using minimal schema - <AUTHOR> https://github.com/yusufnb/verify-json <comment><USER2> Very neat. I had a similar need recently which led to a similar solution[^1]. Notably, I used a syntax nearly identical to yours, albeit without the very handy pluggable validators yours has. Nice job.

What led you to choose "!" as the "optional" modifier? My intuition would have guessed that character to have the opposite meaning.

[1]: project: [https://github.com/tylerchr/jstn/](https://github.com/tylerchr/jstn/) — playground: [https://tylerchr.github.io/jstn/](https://tylerchr.github.io/jstn/)

<comment><USER3> A long time ago, before MyPy, I did a python schema checker for JSON. It grew into argument checking too: [https://pypi.org/project/obiwan/](https://pypi.org/project/obiwan/)

Simple stuff like:

       Person = { "name": str, "age": int }

The basic idea was to use a file full of obiwan types to document the rest api. The schema was both human-readable and valid python. The api could then trivially check the schema. Once the schema is checked, of course, its safe to go walk the json knowing that things aren't going to crash on you etc.

It worked great. Still works great. I still prefer the syntax to that of MyPy.

No real adoption, of course :) But fun to remember what could have been :)

</comment></comment><comment><USER4> Maybe I'm in the minority but I don't want light-weight at the expense of compatible/standard. It's being recognized that validation is more important than we'd expected - the recent ACM guidelines for moderation on Postel's Law really resonated with my experiences with RESTful/JSON micro-services ([https://queue.acm.org/detail.cfm?id=1999945](https://queue.acm.org/detail.cfm?id=1999945)). But if we're going to the effort of validating, let's do it in a language/framework agnostic way ... jsonschema.org is mentioned in other comments but I'm a fan of the OpenAPI initiative ([https://www.openapis.org/](https://www.openapis.org/)). Then we can all share the validation rules!

<comment><AUTHOR> I understand. In my experience, the usability of those standards is pretty bad. Which in effect leads to projects not using anything at all.

One of the benefit of JSON over XML is that it is concise and fast to work with. The standard should reflect that part as well.

With this lib, as a developer to verify a JSON for a simple REST request is as simple as - `verify(json, "{a,b,c}")`

<comment><USER4> > leads to projects not using anything at all

We're counting that against products when we're analyzing what services to adopt/purchase. You doing nothing at all ... or something non-standard results in everyone else having to attempt to do it for you with the resulting inconsistencies. I'm not sure why you think OpenAPI is tailored for XML ... Here's the specification for the sample application (petstore) with service and model definitions in YAML - [https://github.com/OAI/OpenAPI- Specification/blob/master/exa...](https://github.com/OAI/OpenAPI- Specification/blob/master/examples/v3.0/petstore.yaml).

<comment><AUTHOR> I think we are talking about different things here. I love OpenAPI and wouldn't do a project without it. verify-json is a lightweight way to validate JSON schema and does not intend to change/improve anything about OpenAPI.

This is more for client-server JSON schema validations, comes handy when different teams are writing client and server side code. Especially in startups where iterations are rapid.

<comment><USER4> A long time ago in a galaxy far, far away, Corba implemented ICDs as "contracts" between parties. It seems like a client and server developed by different teams is still a good use-case for "something" that specifies the contract. In the 2000's, we wrote mil-spec style ICD documents that we attempted to enforce when writing code that had to interact (via a message bus). The benefit of a language/framework agnostic way of performing with something executed in code is a great step forward from just having an ICD document. Note that early Corba, XML-RPC and SOAP/XML could perform this function but people did horrible things to the data (using an indexed array of strings as parameters) that broke both typing and the ability to do type- specific validation.

From the way you've phrased your comment, I'm going to assume that the different teams are within the same start-up ... having a versioned, executable is even better when iterations are rapid if there are breaking changes. I've been in enough start-ups to know that things are skipped over to get a product out the door. I also know that the marketing and sales guys will say "we're already using a RESTful/JSON API for our back-end, let's open our API to third-parties to accelerate adoption of our SaaS". Ouch! (but I've been there)

I will admit that "back-filling" an OpenAPI specification for an existing service can be pretty daunting ... it's quite a bit easier if you start with the first MVP and iterate the ICD with each iteration of the client and server. Admittedly, we (software developers) still have issues versioning services. It's not so bad for incremental changes but breaking changes to a service where you have to support both older and newer clients is painful.

</comment></comment></comment></comment></comment><comment><USER5> This has already been said in the nested comments, but why not "?" for optional? Coming from Typescript, Swift, etc "!" feels more like an assertion of non-nullity (is that a word?). It's also easy to read as "not <key>".

<comment><AUTHOR> Hmmm, true. ? might be better. Let me think it through. I will update the package to support that.

<comment><AUTHOR> you can track this issue for that change - [https://github.com/yusufnb/verify- json/issues/2](https://github.com/yusufnb/verify-json/issues/2)

</comment></comment></comment><comment><USER6> Exclamation mark for optional is just weird. Question mark would be a lot more intuitive, unless there's an origin story here I'm not aware of.

<comment><USER7> Not sure of the exact motivation, but Swift uses exclamation mark to unwrap optionals.

<comment><USER6> In Swift optional types are marked by a question mark (exactly as I suggested). Unwrapping an optional makes it non-optional, so the exclamation point has the opposite meaning.

</comment></comment></comment><comment><USER8> It's crazy the amount of work that is spent to essentially implement static typing into dynamically / duck typed languages.

Projects like this, mypy and others makes the whole thing _bizarre_ to say the least.

<comment><USER9> What statically typed language lets me define a type as "number between -180 and +180", or "string which contains only alphanumeric chars"?

I think that would be a great feature but from what I see static typing fails here, too.

<comment><USER10> > What statically typed language lets me define a type as "number between -180 > and +180", or "string which contains only alphanumeric chars"?

Pretty much all of them. Any simple predicate like this can be encoded with witness types.

Here's an example in Java, which is hardly the paragon of static typing (i.e. it's no Haskell/Idris/Agda/Rust/Typescript):

        class AlphaNumericString {
            private final String str;

            // use a fallible factory with a `private` constructor if you're
            // morally opposed to exceptions
            public AlphaNumericString(String str) throws AlphaNumericException {
                if (!str.matches("^[a-zA-Z0-9]*$")) {
                    throw new AlphaNumericException();
                }

                this.str = str;
            }

            private static class AlphaNumericException extends Exception {
            }
        }

Now code can freely use `AlphaNumericString` and be guaranteed that it has been validated.

You may object and say that newtype wrapping is cumbersome but:

1\. That's an argument about sugar and ergonomics, not about the semantics that the static type system enforces

2\. Some languages make it easier to generate forwarding methods to the underlying type (a la [https://kotlinlang.org/docs/reference/delegation.html](https://kotlinlang.org/docs/reference/delegation.html))

3\. The `AlphaNumericString` is describing a smaller set of values than `String`. In general, you should be strongly considering the methods you allow and make sure that all paths continue to enforce the semantics you intend.

</comment></comment></comment><comment><USER11> Why are schemas strings?

It would seem much more natural to make them JSON structures since they're almost that anyway.

<comment><USER12> then you might as well use jsonschema.

<comment><USER13> Indeed, there seems to be no reason to use this instead of JSON Schema.

</comment></comment></comment><comment><USER14> JSON schema and ajv are my go to tools for this: [https://github.com/epoberezkin/ajv](https://github.com/epoberezkin/ajv)

</comment><comment><USER15> I built something similar for my latest webapp to validate json-requests in python, the syntax is like this:

        {
            "content": Required(str),
            "username": Required(str, validate=username_is_ok, transform=lambda x: x.lower(),
                       fail_message="Username isn't valid"),
            "message": Optional(str),
            "some_list": Required({
                "name": Required(str),
                "date": Required(str)
            }, is_list=True)
        }

Then I can provide this in a hook to the request method.

<comment><USER16> can you tell me a bit more about this? i wanted something like this for a small api i have but ended up using marshmallow to validate jsons against defined schemas which i think is a bit overkill.

<comment><USER17> If you haven't seen, these alternatives might also be helpful:

       * https://github.com/keleshev/schema
       * https://github.com/alecthomas/voluptuous
       * https://github.com/Pylons/colander

<comment><USER16> thanks, i will take a look!

</comment></comment></comment></comment><comment><USER18> This is OK for simple structures, but in a deeply nested structures and larger APIs you'd probably also need some equivalent of json-schema $refs and ability to reuse blocks in your api schema.

</comment><comment><USER19> You shouldn't validate json. You should parse it, e.g. transform it into your desired data structure if it comes in in a valid shape.

[https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t- va...](https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/)

I really like Elms way of Json decoding for this.

<comment><USER20> I read the post. It seems to be mainly applicable to statically-typed languages. Apparently, the core problem with validation is "shotgun parsing":

> Shotgun parsing is a programming antipattern whereby parsing and input- > validating code is mixed with and spread across processing code—throwing a > cloud of checks at the input [...]

> The problem is that validation-based approaches make it extremely difficult > or impossible to determine if everything was actually validated up front > [...]

Err, what? So validating against a well-defined schema won't necessarily cause this. But okay, again, I can buy the benefits for statically typed languages. There's more though:

> Don't be afraid to parse data in multiple passes. Avoiding shotgun parsing > just means you shouldn't act on the input data before it's fully parsed > [...]

> Use abstract datatypes to make validators "look like" parsers. Sometimes, > making an illegal state truly unrepresentable is just plain impractical > given the tools Haskell provides, such as ensuring an integer is in a > particular range.

I've experienced this in Java/Jackson (which btw, proves this is not exactly new, sexy, or rare in the statically typed world).

What is the suggestion for a dynamic language? In e.g. Javascript, classes will only get you so far, and seems needlessly heavyweight if you aren't going to get other benefits of type-safety. I really don't see how this is helpful, even after putting in the time to investigate this.

<comment><USER19> In JS, my preferred way of handling json is heavily inspired by the elm json decoding way.

I want my decoders to essentially do 2 things:

1\. Transform received data into a data structure that is best suited for my app. This might involve converting lists to objects, objects to sets, parse dates etc.

2\. Only succeed on valid data

This way, my application never has to deal with bad data. Also, I get to design the data structures I use, not the APIs I use. By only validating and not transforming, you are pushing more advanced validation further away from where the data was received (since you'll need to transform the data at some point anyway).

As for libraries, I want composable parsers. For TS I'd probably use: [https://github.com/paperhive/fefe/](https://github.com/paperhive/fefe/)

</comment></comment></comment><comment><USER21> Karate[1] has its own dsl for describing both json and xml. The output is short, but not very readable. For people new to the project it's rather cryptic. It is easy to maintain though once your team becomes fluent in Karate.

[1] [https://github.com/intuit/karate](https://github.com/intuit/karate)

</comment><comment><USER22> You can also use fefe ([https://github.com/paperhive/fefe/](https://github.com/paperhive/fefe/)) to validate _any_ data with its pure functional and minimalist approach. Bonus: it's 100% type-safe automatically if you use Typescript.

</comment><comment><USER23> i saw this and was thinking "hrm...this is the sorts thing i use lodash for...if i even need it".

and now i see lodash is a dependency.

<comment><USER24> It also exposes itself as a Lodash mixin, which I have never used nor seen, so that's something learned.

</comment></comment><comment><USER25> Enter [https://cuelang.org](https://cuelang.org)

</comment><comment><USER26> Wow this is very clean!

<comment><USER27> I do not think so. If you check the example schema, it is very hard to understand it. What does ':lat' mean? is it a string or a number? What does '!b' mean, can it only be false?

<comment><USER26> If you read the whole example:

lat = custom validator

b = shorthand for boolean (as is s for string)

! = optional

So for me reading the whole example its very easy to understand and digest.

<comment><USER27> Yes, reading the docs explains what these keywords mean. But by just looking at the schema it is impossible to understand what that is. And if you check the definition of clean code which is something like "intuitive understandable" then it comes clear that this is not clean.

<comment><USER26> Ah I see where you're coming from. Good point.

</comment></comment></comment></comment></comment><comment><USER28> There has been a schema specification for json already. it's called conveniently `json-schema` [https://json-schema.org/](https://json- schema.org/)

<comment><USER27> I think the author knew this but wanted a more minimal type of validation.

<comment><USER29> Json schema does scale down pretty well (indeed as the link above shows the simplest possible Json schema is just "{}") - it also has pretty good tool support (e.g. VS Code) - there is a Json schema for Json schemas which helps a lot.

The main advantage of the approach in the article appears to be that its easy to extend validation with code - which is a nice touch. Pretty much any complex Json validation I have written has to combine both schema based validation _and_ code based checks - usually done completely separately.

<comment><USER27> Json-schema itself scales down pretty well. But the libraries for validating it do not. Even if your schema is only {}, the build size increment because of pulling in a jsonschema validator is enormous because of all these supported features.

<comment><USER29> Fair enough I guess - don't think I've ever had a need to do client side JSON validation against a 'schema' so I've never had that concern.</comment></comment></comment></comment></comment>


Ask HN: Some less known books that are absolute favorites of yours - <AUTHOR> What are some less known books that are absolute favorites of yours?
Bonus points if:
1. You've read them as an adult
2. You've re-read them
3. You've enjoyed _the process_ of reading them — perhaps they are beautifully written or perhaps they made you laugh
4. They've impacted your life in a positive way
Both non-fiction and fiction books are welcome!
If you feel like it, please consider including a 1-2 sentence description or quote.
Thank you! <comment><USER2> "The green child" by Herbert Read anarchist utopianism from 1935. Very trippy ending

"Terra Nostra" by Carlos Fuentes translated by Margaret Peden. Huge 1976 magic realist novel with very bizarre subplots

"Zazie dans le metro" by Raymond Queneau 1959 ... it's a joy. Cross dressing swearmastery

"Fuzz against junk and the hero maker" Akbar Del Piombo Olympia press 1968/9 repurposed Victorian art subversive cartoon book.

"The exploits of englebrecht" Maurice Richardson 1950 surrealist literature at it's finest.

"A Scots Quair" Lewis Crassic Gribbon 1922-34 socialist feminist realist scotrish novel of great emotional burden

</comment><comment><USER2> The niccolo series by Dorothy Dunnett. (populist, best sellers but perhaps dated and less known by more recent readers) Meticulously researched bodice ripper romance adventure set in the rennaisance against a backdrop of trade in dye, fabric and knowledge. Dunnett was a first class medieval scholar and after a core of fictional characters were established almost everyone she writes about exists in the literature of the time. Plus, bodice ripping!

</comment><comment><USER3> The Sparrow by Mary Doria Russell. Deals with big themes in an accessible science fiction world.</comment>


Ask HN: What's the best place to hire remote freelance developers? - <AUTHOR> <comment><USER2> "What is your favorite place to find work" [https://news.ycombinator.com/item?id=15646550](https://news.ycombinator.com/item?id=15646550) from last week has a couple of good leads.

<comment><AUTHOR> Cool, thanks!

</comment></comment><comment><USER3> [https://www.moonlightwork.com/](https://www.moonlightwork.com/)

<comment><AUTHOR> thanks!</comment></comment>