The History of The Waite Group (in Mitch's own words) - <AUTHOR> http://www.mitchwaite.com/writing.htm

<comment><AUTHOR> This is extremely interesting. Mitch Waite lists the journey of his PC/Computing publishing powerhouse, from its humble beginings in 1972 to its demise in 2001.

He had one huge failure that whiped him out in the late 80s but he came back up.

The pages are hard to navigate, but click on the "Next Page" button on the bottom right of each page.

Mitch Waite's Waite Group was bigger than O'Reilly; he was HUGE. I found his ways of doing business strange and ill advised, but you will see he ran one of the earliest "lean" companies out there (averaging 2-4 employees most of his career, and 50 at the height of it!)

</comment><comment><USER2> Really loved this article. Only 3 points though? This is why I stopped looking at the "Top Rated" HN articles.

<comment><USER3> Agreed, it seems like most of the gems I'm finding are languishing 3 pages in on the new submissions with just a couple of points.</comment></comment>


Bitlove.org now features WebTorrent (BitTorrent over WebRTC) playback - <AUTHOR> https://bitlove.org/ <comment><AUTHOR> Click the Play triangle to the right of the green download buttons. Requires browsers with WebRTC support (Firefox or Chrome) and it's only enabled for MIME types that might stream into a <video> element.</comment>


Ways to Write the Worst Unique Value Proposition Ever - <AUTHOR> http://usabilityhour.com/?p=118

<comment><AUTHOR> I wrote this after doing landing page consultations for a month straight.

This is the stuff I saw from so many different startups.</comment>


European Investment Bank announces €25M funding for MariaDB - <AUTHOR> https://ec.europa.eu/commission/commissioners/2014-2019/katainen/announcements/investment-plan-europe-eur-25-million-support-mariadbs-development-new-software_en <comment><USER2> Good for mariadb and a good eye opener for any EU government system that is stuck on oracle.

Mariadb 10.3 is going to be a haven (or rehab) for oracle veterans.

[https://mariadb.com/kb/en/mariadb/what-is- mariadb-103/#compa...](https://mariadb.com/kb/en/mariadb/what-is- mariadb-103/#compatibility)

<comment><USER3> > stuck on oracle.

What is the problem with Oracle except the price?

edit: sorry, I mean the DB, not the company.

<comment><USER4> It's all about the price. The database is largely irrelevant.

I have been involved in a dozen or so Hadoop deployments now and almost all of them are there not because it will allow them to do amazing new things but because the licenses for Teradata or Oracle were too expensive. So they have a giant "data lake" aka "dumping ground" on HDFS and keep just the mission critical data in the EDW.

<comment><USER5> Out of curiosity, did all of those clients use CDH (Cloudera Hadoop)? They're pretty much becoming a hegemony in their own right like DataStax and Cassandra

<comment><USER6> We run both CDH and Cassandra at my employer. DataStax made a play, but they were Oracle level expensive, so we stuck with OSS.

CDH provides benefits in the early days, but at this point it feels more constraining. Their release cadence is slow, so we're stuck writing long term workarounds for bugs that we're fixed two years ago in the upstream project. The stuff that they are working on is half-baked and doesn't support what would seem to be trivial use cases.

I wouldn't be surprised if their ecosystem calcifies now that they are public.

<comment><USER7> We had a similar experience and walked away very early on. Now run >1k node clusters without outside consulting.

</comment></comment></comment></comment></comment></comment><comment><USER8> Slightly off-topic, what caught my attention was how the firm developing MariaDB is Finnish while one of the top leadership* who approved the agreement is Finnish too.

*: European Commission Vice-President Jyrki Katainen, responsible for Jobs, Growth, Investment and Competitiveness

<comment><USER9> That's exactly the kind of corruption we have in "the least corrupted country in the world" (maybe not this year, but pretty close). No money changes hands, but if you scratch my back, I'll scratch your back. It's all about who you know

<comment><USER8> I am not saying anything but this looks like good old "pork barrel politics" to me.

</comment></comment></comment><comment><USER10> I've seen multiple open source projects get such government funding. Does anyone know the process that they go through to get such grants?

<comment><USER11> For this program, look here: [http://www.eib.org/efsi/how-does-a-project-get- efsi-financin...](http://www.eib.org/efsi/how-does-a-project-get-efsi- financing/index.htm#) There's also a map of funded projects (most not software projects, as far as I can see): [http://www.eib.org/efsi/map/index.htm](http://www.eib.org/efsi/map/index.htm)

</comment></comment><comment><USER12> I'm wondering what will prevent that open source project from being sold (like MySQL was)? The prospect of having a stable open source database engine is nice, but then it gets sold to a big corporation (Oracle in case of MySQL), and gets killed off (presumable to push paying customers towards their own DB). The original developers leave the project, development and maintenance stalls, and whoever was using the DB freely, now has to transition to something else.

So now MariaDB gets this funding, they might just as well work on the product for couple of years, build up user and paying customer base, and then sell it off. If i were giving grants as a government entity, i would consider adding a condition to the deal that they can't sell the software and have to keep it open-source and free.

<comment><USER13> MySQL has done great since Oracle acquired Sun -- regular & high-quality releases, new features, tech debt reduction.

</comment></comment><comment><USER14> Would love to see this for Datomic.

<comment><USER15> The EIB invests in EU projects or in developing countries. Datomic/Cognitect seems to be based on the East Coast, so it doesn't seem like EIB investment material.

It does look like VC material, though :)

</comment></comment><comment><USER16> What are the terms of such a loan? Has anyone reading this bothered to look deeper?

</comment><comment><USER17> The actual press release:

[https://ec.europa.eu/commission/commissioners/2014-2019/kata...](https://ec.europa.eu/commission/commissioners/2014-2019/katainen/announcements/investment- plan-europe-eur-25-million-support-mariadbs-development-new-software_en)

<comment><USER18> Thanks, we updated the link from [http://europa.eu/rapid/press- release_MEX-17-1244_en.htm](http://europa.eu/rapid/press- release_MEX-17-1244_en.htm) a little while ago.</comment></comment>


Pathways to Cellular Supremacy in Biocomputing - <AUTHOR> https://www.nature.com/articles/s41467-019-13232-z <comment><USER2> As someone who spent 10 years at the forefront of synthetic biology (and has programmed for 30+ years) I always found the biocomputing baffling. I would be willing to bet against Cellular Supremacy over any time frame, except evolutionary or geologic timeframes.

<comment><USER3> Your brain consumes about 40 watts and you wrote that sentence.

<comment><USER2> why do you assume that writing that sentence was computationally hard?

<comment><USER4> the closest computational equivalent to writing that sentence we have today involves executing a model with 1.5 billion parameters. (and I couldn't find an estimate of the energy cost of that)

<comment><USER3> It's many orders of magnitude larger than 40 watts * 5 seconds. :)

I have a running bet with some friends that one of the following is true:

(1) The brain is somehow leveraging quantum computing to achieve polynomial or square root acceleration on combinatorial search and optimization problems.

(2) P=NP and there exist polynomial time classical algorithms for these problems.

(3) The naturalistic hypothesis fails and intelligence is somehow "supernatural" and does things that cannot be described or modeled within the confines of physical space-time.

I cannot think of any alternative that can possibly explain how the brain can do what it does on ~40 watts. Everything we have learned to date argues that intelligence and cognition involves a whole lot of massive combinatorial problems that can't possibly be performed classically on so little power.

<comment><USER5> The brain is not a von-neumann architecture.

We have different architectures that can perform computation million times more efficiently than general computers. Of course, they lose on other axes (like precision).

Whats 54398456905 * 23423645745? Your 40 W brain can't compute that in a minute, yet a 0.01 W calculator can in a millisecond.

<comment><USER3> We can build less accurate computers and analog computers. Neither of these even begin to approach what brains can do. A self-driving car's computer takes hundreds of watts to run, uses reduced precision and custom silicon wherever possible, and does not begin to approach the navigational ability of a mouse or bird whose brain consumes less than one watt of power.

The human brain didn't evolve to perform consciously explicit and exact calculations on huge numbers, but our navigational and positional awareness abilities do far more impressive things with far more data much faster than this. A monstrous amount of effective but subconscious number crunching is involved in being aware of where your body is in space using nothing more than vision and sensorimotor feedback, taking apart auditory input (including FFT- like transforms), etc.

I really think CS people suffer from Dunning-Kreuger when they hand wave around the impressiveness of biological systems. Study some actual biology and neuroscience. What biological systems do as a normal part of metabolism and cognition is as awesome and mind-blowing as the vast energies, times, and distances found in astronomy. Computers are specialized devices that perform impressive feats of specialized computation but they do not even approach what biological systems do in terms of total data throughput per unit energy, learning ability, or associative and versatile memory to name just a few.

Edit: computers seem so impressive to us because we built them specifically to do the things we didn't evolve to do very well, but I have little doubt that if there were some kind of evolutionary forcing function selecting us for conscious explicit number crunching ability we would not need computers and wouldn't have built them.

<comment><USER6> > A self-driving car's computer takes hundreds of watts to run, uses reduced > precision and custom silicon wherever possible, and does not begin to > approach the navigational ability of a mouse or bird whose brain consumes > less than one watt of power.

I would not trust the brain of a mouse or a bird to drive me in a car. Also the self-driving car computers which take hundreds of watts to run do not take advantage of custom silicon to the greatest possible extent, because the relevant algorithms are evolving rapidly. There is probably at least an order of magnitude or two of power efficiency that can be gained with current systems if the algorithms were truly baked into the chips.

<comment><USER3> I wasn't comparing performance at a specific task but performance at tasks of equal or greater difficulty.

Mouse and bird brains have evolved to operate mouse and bird bodies, not cars, and their learning ability isn't as powerful as a primate or a human so I doubt they could learn to drive a car as well as us or our specialized self- drive computers.

But... what they _do_ manage in terms of controlling mouse and bird bodies is _vastly_ more sophisticated and impressive than driving a car. A mouse runs around on four independently controlled legs and can tackle a vast array of terrains while dodging or chasing moving objects. Birds can navigate in 3d space while flying with articulated flapping wings with complex control surfaces operated by dozens of muscles.

Driving a car is ridiculously easy compared to anything like that. If mouse and bird brains had evolved to control cars I'd absolutely trust them to drive me around at least as much if not more than I trust a Tesla's autopilot. Driving is a simpler problem than operating a mouse body.

Don't get me wrong: our self-drive AIs are amazing engineering achievements. I'm just pointing out the impressive performance of tiny brains using fractions of a watt of power at much more difficult tasks.

The thing that blows my mind and makes me hypothesize quantum computing or even P=NP is the power requirements of those brains. It's "impossible." I'm not suggesting that we can't figure it out, just that we haven't yet and that it's probably going to take more or different approaches than we think it will take.

Immune systems were once considered so "impossible" that it led several researchers to abandon science in frustration, but we eventually got a good understanding of what was going on (and it's impressive!). Understanding immune systems had to wait for molecular genetics and modern evolutionary learning theory among other things. I suspect that really replicating brain- like performance will have to wait for something as far beyond our current state of the art as those were in the 1920s.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> It appears that "Supremacy" isn't going away ;)

Overall, a very enjoyable read. As long as we are speculating on the limits of bio-based computatbility, The same physical constraints governing inanimate systems would of course apply to biochemical reactive systems.

What biologic does buy you is _reproduction_. An proclivity to seed machines over a wide geographic or cosmic area that is self-propelling.

[https://en.wikipedia.org/wiki/Limits_of_computation](https://en.wikipedia.org/wiki/Limits_of_computation)

</comment><comment><USER8> This way to name things give me the impression that science is not any more about advancing knowledge but about to find the most grandiloquent way to speak about your work. All this "quantum supremacy" and now "cellular supremacy" seems really disturbing.

As they propose the term in this article, I hope that someone will found a better name. It's an interesting subject and it deserve a better name.</comment>


Gun Control on the Blockchain? - <AUTHOR> http://www.ingenesist.com/gun-control-on-the-blockchain/ <comment><USER3> I've long wondered if, in addition to opening up the NICS system to private individuals for private transactions, the blockchain could be used to demonstrate that a background check was performed without the hassles of dealing with an FFL or the negatives of storing 4473's. Could we eliminate 4473's altogether? Of course, if we're actually serious about background checks, we need to fix reporting into NICS system while we're at it, among other things.

As to the linked proposal, it doesn't strike me as very informed… I still fundamentally don't understand the infatuation with insurance (other than as a backdoor way to limit ownership). Insurance may cover acts of negligence, but doesn't it exclude suicide/suicide attempts and criminal acts, right? What events are being insured, and who is paying out?

</comment><comment><USER4> All in all, although this system may not be a drop-in replacement for "gun control," I think this is exactly the kind of discussion that makes sense to have in the 'hacker' community in light of the sudden insistence on the part of politicians to pretend that gun violence is a significant concern for the American public.

</comment><comment><USER5> A big problem that comes with all of these novel proposals is that for me, the average American gun owner, they're not better than the current system.

What incentive do I have to change from the status quo if the change won't result in a net benefit for me?

<comment><USER6> I think this idea is ridiculous. However, ...

Owning a gun does not reduce the odds that you or someone you care about being being killed by a gun. So, you benefit just as much from gun control as everyone else.

PS: One option is to simply jack up the cost of each bullet. At 100$ a pop that still useful for hunting or self defense so no constitutional issues, but your not going to see teens firing thousands of rounds. ;)

<comment><USER5> _Owning a gun does not reduce the odds that you or someone you care about being being killed by a gun._

Irrelevant.

 _So, you benefit just as much from gun control as everyone else._

Which is "Not at all".

 _PS: One option is to simply jack up the cost of each bullet. At 100$ a pop that still useful for hunting or self defense so no constitutional issues, but your not going to see teens firing thousands of rounds. ;)_

This would make me and a lot of people like me very rich.

<comment><USER6> Compare US vs UK violence statistics and the benefits are not trivial.

<comment><USER4> Surely you realize you can't just say this in a vacuum. This is a huge topic of debate. At the very least, you need to recognize the two basic challenges of this argument:

1) Violence is no less typical in the UK; as I understand it, you are more likely to be attacked with a knife in London than with a gun in any US city, and

2) In several crucial ways, the UK and the US are completely different - <USER2> least of these is that the US is the center of hegemonic influence in the world. For sociopolitical reasons, it may not be wise to allow this hegemon to be armed and unchecked, and this might not be so for other developed nations.

<comment><USER6> > Violence is no less typical in the UK

[https://en.wikipedia.org/wiki/List_of_countries_by_intention...](https://en.wikipedia.org/wiki/List_of_countries_by_intentional_homicide_rate)

      United States intentional homicide rate: 3.8
      United Kingdom intentional homicide rate: 1.0

So, UK has plenty of issues with crime and is worse in many areas, they just have vastly fewer deaths.

</comment></comment></comment></comment></comment></comment><comment><USER7> That solution seems to assume that the prospective gun buyer is honest when creating their profile, without any way to check against third-party information sources.

<comment><USER4> The proposal is that, in the event of a discharge causing injury, they can reveal their persona in order to prove that they were were qualified to own the weapon in question. If, on the other hand, it turns out that they provided misleading information for this purpose, they lose the protections of the 2nd amendment for the purposes of the incident.

<comment><USER5> This may work when dealing with the incompetent but not the malicious.</comment></comment></comment>


Choose design over architecture - <AUTHOR> https://18f.gsa.gov/2015/11/17/choose-design-over-architecture/ <comment><USER2> I'm not sure what to make of this piece. It draws you in with the curious challenge to "choose design over architecture" but uses terms loosely and merely gives broad claims like "Unfortunately, this kind of a grand plan usually leads to technical-debt that collapses towards complete immobility."

It then wanders to the topics of "SOLID," "Optimize for change, but don't optimize in advance," "Commit to refactoring," and finally concedes "There is still a place for architectural planning"

I think I made a mistake reading this piece; the complexity of the relationship between architecture and customer asks is much too complex to be answered with a few quotable phrases. Maybe I should have known this going in.

<comment><USER3> The article is indeed an odd mix. As for Architecture vs Design -- I think "Software Architect(ure)" is a bit of a misnomer -- in as much as architecture makes sense as a term, it is a property of a _System_. And like the original MVC was MVCU: Model-View-Controller- _User_ \-- a _system_ consists of more than just code.

I keep going back to the original REST thesis[1] -- and it's wonderful use of architectural constraints as a lens in which to say something general and useful about the nature of hypertext applications. And _other_ architectures, which people seem to ignore all the time -- REST is just one sub-set of constraints that emerges for a rather particular application type. I really think the chapter that details all the _other_ architectures is at least as interesting as the REST-part.

Notice how this article talks about "web servers" and "APIs" \-- as if they were general, universal, system level properties -- rather than some very specific instances of RPC -- shaped by the architecture of hypertext applications and REST.

[1] [http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_...](http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm)

<comment><USER4> Model-View-Controller-User? Really? That's awesome!

I would have expected there to be a mention of this on c2.com[1]. Any other places I might find it?

[1] [http://c2.com/cgi/wiki?ModelViewControllerHistory](http://c2.com/cgi/wiki?ModelViewControllerHistory)

<comment><USER3> [https://heim.ifi.uio.no/~trygver/themes/mvc/mvc- index.html](https://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html)

[Ed: note the illustration. On a cellphone, so a little painful to read through - I just remember Trygve mentioning it in a presentation I had the good fortune to attend a few years back]

[Ed2: Here's at least one reference to MVC-U, from one of the presentations on DCI (a successor to MVC of sorts):

[http://www.artima.com/articles/dci_vision.html](http://www.artima.com/articles/dci_vision.html)

"Most programmers think of MVC as a fancy composition of several instances of the Observer pattern. Most programming environments provide MVC base classes that can be extended to synchronize the state of the Model, the View, and the Controller. (Model, View and Controller are actually roles that can be played by the objects that the user provides—we'll talk more about roles later.) So it's just a housekeeping technique, right? To think of it that way is to take a nerd's perspective. We'll call that perspective "Model-View-Controller." More deeply, the framework exists to separate the representation of information from user interaction. In that capacity we'll call it "Model-View- Controller-User," capturing all four of the important actors at work—MVC-U for short."

As I recall, in the presentation, it was indicated that this was the an emphasis on what MVC originally was about, and that the User-bit originally was such a central part of the whole thing, that it was also part of the name -- but that the "U" got dropped at some point (ie: in the late 70s when they were writing up this stuff initially).]

</comment></comment></comment></comment><comment><USER5> "Architecture" is a funny word in software development. Funny because what they call "software design" is still considered "architecture" to some. And what they call "architecture" I prefer to call "topology".

But regardless of what you call it, I generally agree with the article that application topology should be loose and adapt to changing requirements. Use well known software patterns and principals when writing modules, etc. Refactor cruft swiftly as needed.

Maybe it's just me, but after a decade of building software systems it's all fairly obvious. Yet still important to teach and mentor to juniors.

<comment> m-i-l In a large organisation you'll typically have a number of different architecture roles, i.e. its always _something_ Architect. For example, there are Enterprise Architect, Line-of-Business Architect and Solution Architect roles for differing levels of vertical alignment within the business, and there are Information Architect, Data Architect, Infrastructure Architect, etc. roles for differing levels of horizontal alignment. Similarly within design you'll find a number of design roles, e.g. UX Design, UI Design, etc.

<comment><USER6> I've found that different organisations seem to have _completely_ different definitions of "Enterprise Architect" \- some use to to cover infrastructure and applications and others applications and business processes.

</comment></comment></comment><comment><USER7> I think part of the problem is that Software Architect is a bad term. An Architect makes a blueprint. That blueprint can be given to many different builders who can then all construct basically the same building.

If you tried to build equivalently detailed software blueprints, you end up just coding the whole thing. The problem is, the software is the blueprint.

Casey Muratori summed it up best in a handmade hero episode. He thinks that a better analogy for software architect is an urban planner. I think that if you approach your design phase more like urban planning, you'll accomplish most of what the article author is going for.

<comment><USER8> The title of Architect only makes sense in enterprise Java or .NET OOP software projects where the architect's work product is UML diagrams and dataflow diagrams, and the implementation of the classes is delegated to a large number of developers.

I think that whole paradigm is a bad idea, but I also think that if you've already decided you're going to use one of those languages and run your project that way, it does make sense to have a person responsible for the high-level system design.

<comment><USER6> "architect's work product is UML diagrams and dataflow diagrams"

IMHO this is one of the worst ever ideas in software development - largely as if you never actually get your hands dirty with real code and the whole messy business of getting it developed, deployed and actually _used_ you never actually see what _actually_ works and what doesn't.

</comment></comment></comment><comment><USER9> I understand what the author's point is but a good architect will use a light touch to help guide an effort toward solution. The sentiment is basically to avoid the temptation to over architect toward perfection in favor of building something based on an expression of business need. I generally agree with this sentiment, however in large organizations where outsourcing prevails, a deliberate architecture is a guard rail against bad practice and bad outcomes. In my experience, architecture is a needed practice that can help communicate the big picture and connect business goals to technology solutions.

</comment><comment><USER10> I don't get it .The "ugly " picture at the beginning is what you get in the end . No matter how many design steps you have.

<comment><USER11> Not if you have the right architecture.

</comment></comment><comment><USER12> Software Architecture is the complete system, including the hardware and protocols. The complete system of an airplane is a software architecture.

It is very scary how naive and misinformed this article is coming from a .gov site. Given the misuse of terms and purely ridiculous suggestions, I wouldn't even show this to grade schooler.

[http://disi.unal.edu.co/dacursci/sistemasycomputacion/docs/S...](http://disi.unal.edu.co/dacursci/sistemasycomputacion/docs/SWEBOK/Addison%20Wesley%20-%20Software%20Architecture%20In%20Practice%202nd%20Edition.pdf)

</comment><comment><USER13> The most disconcerting thing about this nonsense is that it is on a government funded website.

</comment><comment><USER14> Granted I'm an old timer, and not a commercial software developer right now, but to me, the article brings to mind what I learned about "top down" versus "bottom up" design.

</comment><comment><USER15> My concern with this (and my general pet peeve with the "user stories" in software engineering) is: how do we make sure the "user stories" are faithful to real-world usage of the software being built? tl;dr: how do we know the user stories are relevant?

The article defines user stories as "simple scenarios told from the point of view of a person using the software. There can be many types of users for an application". This is very, very problematic. How can I be sure that software developers are able to walk on the shoes of the user? That they even know who are the real users? Their needs, their context?

I have little to no faith in user stories, on software development. It takes a lot of UX knowledge and experience to be able to faithfully depict scenarios and personas, and even more so to have the maturity to do such things grounded on data and not on our preconceptions. I just can't assume software developers will have this kind of knowledge and experience and, as such, user stories will end up being a reflex of their preconceptions, not of the real-world usage of the software.

<comment><USER16> I've been in many projects where people would iterate numerous times over architecture while completely forgetting what real-world problem they are actually trying to solve. Architecture becoming art pour l'art.

I don't see the point of the article being that every software developer becomes a fully-fledged UX guy, but understands the context in which the system is going to be used and not get lost in the technical rabbit hole.

<comment><USER15> > I've been in many projects where people would iterate numerous times over > architecture while completely forgetting what real-world problem they are > actually trying to solve. Architecture becoming art pour l'art.

I completely agree. Unless constrained, software developers will entertain themselves with architecture stuff ad libitum. But this is one problem; the other - a full-blown, bigger one - is truly knowing the real-world problem.

> I don't see the point of the article being that every software developer > becomes a fully-fledged UX guy, but understands the context in which the > system is going to be used and not get lost in the technical rabbit hole.

The premise is a noble one, and correct IMO. But, as above, truly knowing the real-world problem is hell. We can't really hope to solve the technical rabbit hole _just_ by focusing in the real-world, or _simply_ assume that we know it.

Software developers won't understand the real-world context, most of the times. They aren't trained to do so. Most of the times, companies won't help: organization keeps software developers very far from customers. Hell, I'll say it: many software developers even lack the basic empathy skills to understand the user. Their model of the software is the implementation model, not the usage model. And many times they're too stubborn, and talk very cheap regarding users and usage: software developers say "this is what the user wants" as cheaply I say "the sky is blue". But the thing is that "what the user wants" is not that obvious; the only obvious thing is the mis/preconceptions we have.

</comment></comment></comment><comment><USER17> I think the author confused "Architecture" with "Big Desing Up Front" (BDUF), meaning the architecture is defined ahead of time in static (design...) documents that do not interact with the actual code.

This is somewhat excusable because that is pretty much how architecture works today. However, it shouldn't be, and Objective-Smalltalk[1] is an attempt to bring architecture into the fray of actual code, allowing it to participate in the feedback cycles of building real systems.

[1] [http://objective.st/About/](http://objective.st/About/)

</comment><comment><USER18> While this article is sadly vague, I will at least commend the GSA for commissioning some great architecture in the more traditional sense.

And ironically, their website kept crapping the bed as I try to find their page on it, so I'll just have to post a few examples from outside sources:

[https://en.wikipedia.org/wiki/San_Francisco_Federal_Building](https://en.wikipedia.org/wiki/San_Francisco_Federal_Building) [http://www.archdaily.com/416001/som-breaks-ground-on-los- ang...](http://www.archdaily.com/416001/som-breaks-ground-on-los-angeles- courthouse) [http://www.gsa.gov/portal/mediaId/190803/fileName/2014DA-- Aw...](http://www.gsa.gov/portal/mediaId/190803/fileName/2014DA--Awards_Book-- 508_compliant.action) (PDF)

</comment><comment><USER19> I have mixed feelings about this. An experienced programmer might know the best way to structure a application simply from past experience. In this situation, a blueprint ensures that everyone is on the same page and saves an enormous amount of time that would have been spent refactoring code.

</comment><comment><USER20> Choose semantics over wordplay.

</comment><comment><USER21> a pile of bricks is not a house.</comment>


Ask HN: Legal rights for US alien status developers - <AUTHOR>

For international web/software/app developers, how do they get legal rights for launching their websites/softwares/app in the US. For  instance if they are working with other co developers for a startup in the US, what are the legalities?<p>Thanks a lot! <comment><USER2> Well, the cool thing about the internet is that you don't need to launch at a certain location. If you've launched in location X, you've launched it in the US.

<comment><USER3> Except when it comes to taking money from US customers. There are far more options if you have a US presence, as well as greater customer confidence.

</comment></comment><comment><USER4> Consider starting a company in your home country, and launching under that.

It doesn't matter if you only cater to US customers, and it means that you won't be employed by any other US company whilst working in the US.

<comment><USER3> You can found the company elsewhere and launch it for US customers, but you've still got problems if you want to live and work in the US for long periods of time.

</comment></comment><comment><USER5> you are in for a world of hurt with USCIS, startup can't be your sponsor (too small).

your best bet is <http://www.cicdgo.com/> they will verify the company and be the official sponsor on your J-1 visa. The J-1 is issued to you in your country.

IIRC we paid 500-600$ for their services

<comment><USER3> Seriously, a J-1? I'm assuming you went with the "internship" J-1, which lasts only 6, maybe 12 months. And it's only plausible if you are currently a student.

Might be worth it for someone hoping to get funded or bust in under a year, but otherwise that seems problematic. Also, correct me if I'm wrong here, but once it's over, you can't turn around and get another J-1; you invariably have to spend some time out of country?

</comment></comment><comment><USER6> this post is strikingly similar to one a few days ago, but as a reversal with citizenship. The article talked about bit.ly being a website that was technically on the domain for the country of libya (.ly) meaning that the libyan government could possibly remove it like they had other sites in the recent past, I would feel confident that the same is possible for the US, if it caught enough attention of the proper people it could possibly get shut down. Otherwise i would imagine it rolls freely without much fuss.

</comment><comment><USER7> Launching is not a problem. Getting paid is.

As an H1B employee, you will have all kinds of restrictions on doing business in the US.

<comment><USER8> I agree. I also heard the owner of a small but decent ERP consulting company was working for a different company in L1 or H1B.</comment></comment>


Ask HN: Anyone need a PHP Dev? Side projects? I'm bored - <AUTHOR>

If anyone has an idea and needs a dev to help out let me know. I work full time as a PHP Team Lead and I'm just looking to do some stuff on my free time.
We can work something out: equity?
I wear all hats and can help with any aspect.

        - Laravel, CodeIgniter 	- Development (Front and back) 	- Sys admin & DB
 Let's chat.
firstname.lastname@example.com <comment><USER2> I have sent you an E-mail.

Please check it out and I will wait for your reply.

</comment><comment><USER3> damn, I just handed over one project -_-</comment>


After 12 years and endless fights with Google, HubPages finds a buyer - <AUTHOR> https://www.cnbc.com/2018/01/06/hubpages-sells-to-maven-giving-venture-investors-exit-after-12-years.html <comment><USER3> I used to be an avid HubPages fan. At its peak, it was mildly useful, kind of like instagram where you'd be able to discover new, useful projects/places/things and what not. During its time, AdSense was the craze, everybody wanted an account. Since AdSense was invite-only, application based, (don't know if it still is), the main criteria was to have a website/weblog with some useful content. A LOT of people, many even in my circle used HubPages to get their AdSense accounts approved. The process was simple - <USER2> a hub, write a couple of useful articles, submit it along with your AdSense application and BINGO. Approved (for most, not all).

Over time, slowly, HubPages started positioning themselves as a "get rich quick" scheme. This was especially suitable for them because they would also share your revenue from your AdSense account (60-40? I'm not sure). There were a LOT of affiliate products out there claiming to help you get rich quick with AdSense and HubPages. They allowed this nonsense to grow like a snowball. Now, I also made some money with their platform. Not too much, maybe about $100-200 in 2 months. I did try to scale my earnings, but realized the real guys who were getting rich were the ones who were teaching me (with courses, books) on how to get rich.

Around 2008-2009-ish if I'm not wrong, HubPages became the hub of Spam. And then Google hit everyone hard with their algorithmic changes. It hit everyone really hard. Even some of my quality hubs disappeared over night. Ever since then, I learnt two lessons:

1) Don't rely 100% on someone else's (free) platform to host your content. Use your own or pay for it.

2) If someone teaches you how to get rich, you can be 100% sure he/she's getting rich because of you.

I never looked back at HubPages since then. Today, I logged in and wiped out all information about me. Just had a look around and seems like not much has changed since I last left them.

</comment><comment><USER4> I have never ever found any single HubPage useful at all.

Yes, small publishers struggle in Google. And some of them produce very useful content that should be more visible. HubPages isnt one of them though.

<comment><USER5> I have found over the years that it isn't difficult to get useful content to surface on Google; the problem is that a lot of content isn't useful and is merely an SEO play.

<comment><USER6> > a lot of content isn't useful and is merely an SEO play

wikiHow.com is an example I always see ranked high in search results but the content is 99% garbage. Given high number of "how to" searches the world sees, I'm surprised Google keeps them so highly rated.

</comment></comment></comment><comment> dh-g Google wasn't fighting HubPages, just spammy SEO.

</comment><comment><USER7> From the article:

> "Paul and I are aligned because we both agree that mom-and-pop or small > publishers no longer have a sustainable business," Heckman said in an > interview. "It's over."

This is the biggest reason Google needs to be reined in by splitting it apart.

<comment><USER8> You seem to have an encoded assumption that smaller mom-and-pop businesses are desired by the market and are being crowded out. I don't think that's true, I think the average consumer doesn't especially care about the size of the corporation they're dealing with. In my experience (and yes, obviously there are the Patagonia exceptions to this general statement), people care about price, quality, convenience, and then ethics. In that order.

<comment><USER9> Probably true as far consumer attitude goes. But in the long run it's healthier to have many small players. I think the fact that Google, Facebook and Apple are so dominant is already killing a lot of innovation.

<comment><USER10> Why is it healthy to have many small players? Larger companies have the resources to put experts on hard problems. They also have the vested incentive (since they have more to lose if they fail) to handle things like security correctly---I trust Facebook and Google to use security and authentication best-practices much more than J. Random Startup, for example.

<comment><USER9> Because big companies set the hurdle really high for new technology to succeed. Either they buy the new company and kill the product or they can re- implement the feature.

To me mobile devices are an example of this. PalmOS or FirefoxOS could maybe have succeeded if Android and iOS weren't that overwhelming. Apple and Google can control whatever they want to be on their devices and what they don't like. Innovation is pretty much stopped.

<comment><USER10> As a former owner of several generations of Palm devices and a former Palm developer, I must regrettably suggest that it wasn't Apple or Google's control of their respective ecosystems that killed PalmOS. Palm hardware was unreliable and plagued with battery breakdown problems.</comment></comment></comment></comment></comment></comment>


Why we moved from Angular 2 to Vue.js and why we didn't choose React - <AUTHOR> https://medium.com/reverdev/why-we-moved-from-angular-2-to-vue-js-and-why-we-didnt-choose-react-ef807d9f4163 <comment><USER3> > With Typescript things that were really easy to do on Javascript like > defining a simple object were more complicated to do on Typescript.

TypeScript in no way prohibits you from defining a plain old untyped object. Just don't assign a type to it, and it behaves just as it would in plain JS. I wouldn't use Angular 2/4 either, because of its needless complexity and over engineering — but not because of TypeScript. If anything, TypeScript is a bonus.

> React mixes both JSX/HTML with JS code which I just don't like since I > strongly believe in separation of concerns and it looks ugly IMHO.

This is valid only if you think separation of concerns is the same as separation of technologies. I don't think so. It makes more sense to group code based on function.

In fact Vue.js allows single file components that mix HTML, CSS and JS in a way that would violate the author's definition of separation of concern. From Vue.js' documentation: "One important thing to note is that separation of concerns is not equal to separation of file types." [1]

> Coding speed was an area Vue.js won by far, not having to learn JSX was of > huge help.

It should take no more than 20 minutes to learn JSX.

1\. [https://vuejs.org/v2/guide/single-file- components.html#What-...](https://vuejs.org/v2/guide/single-file- components.html#What-About-Separation-of-Concerns)

<comment><USER4> > It should take no more than 20 minutes to learn JSX.

it should, but in practicality, for most front-end devs especially junior ones, it's not. Moving Angular 1 devs to Vue gets actual work going 3-4 times (anecdotal experience) quicker than with React. For most smaller shops/startups Vue is almost always a better idea - it's much easier finding devs (especially remote/<100k comp ones) with previous Angular 1 experience and the learning curve is alot nicer. React is overengineering for most web apps.

<comment><USER5> If you know only JS, JSX is _much_ easier to pick up than some proprietary templating language. How do I do an if, a loop, a map, ... any code at all? In JSX, the answer is squiggly-brackets and regular old JS code. In Angular's templating system and Vue's, you've got to relearn all of these and more.

<comment><USER6> > proprietary templating language

Isn't that exactly what JSX is?

<comment><USER7> No. JSX is a small domain-specific language for expressing a hierarchy of virtual DOM nodes. Angular is a template language in that it eschews JavaScript compatibility in favor of its own directives that try to emulate basic iteration and conditional expression evaluation.

<comment><USER8> I wish you could write non string based jsx in angular. Or at least make aot fast enough for the regular webpack watch / recompile workflow.

</comment></comment></comment></comment></comment></comment><comment><USER9> "We invested in a beta product and then shock horror - it changes before it's released. Let's blame the framework on that poor choice."

"We were unable to learn how to use TypeScript properly, so let's abandon gradual typing and suffer a net loss in productivity over the longer term."

<comment><USER10> > "We invested in a beta product and then shock horror - it changes before > it's released. Let's blame the framework on that poor choice."

Angular.2 has been in beta for years. And when it went out of beta it basically became something else. This is not a good thing. It's normal for teams to be excepting at least some level of stability in the library they are using. And now that Angular.X pretends to be using semver, it's going to be even worse.

The Angular team doesn't care about stability or lacked vision when they started 2, but a stable API is a valid expectation for a developer team.

But it's not surprising as frameworks with huge API surfaces like ExtJS have pulled the same trick for years, with the same results. Their downfall is more the consequence of API breaking than anything else.

<comment><USER9> If you rely on a beta product you should have no expectation of API stability.

It's very easy to blame vendors when it's your own poor decision making that got you in the mess to begin with.

<comment><USER10> > If you rely on a beta product you should have no expectation of API > stability.

If i rely on a beta product, i don't expect a complete rewrite of the API when a stable version is released. That's exactly what happened, several times with Angular. Now you can't have it both ways as a vendor. You can't expect people to try out your product and test it in a professional setting then change everything at the last moment either. Or you're saying developers shouldn't even checkout Angular until it is out of beta. If that's what you're saying then the vendor shouldn't expect broad adoption.

<comment><USER11> I don't know what he's saying, but I would say that you should not have your product depend on something that is subject to change. Thus, although the vendor can do wrong by changing their product API when it is in Beta, it's still ultimately your fault for relying on something that hasn't had a stable release.

Although I get what people are saying about Beta products, the truth is that different vendors use the term "Beta" with different levels of precision, and thus should not typically be trusted not to pull the rug out from under you in some way if they haven't firmly committed to stability.

</comment></comment></comment></comment></comment><comment><USER12> Maybe my viewpoint is too 'elitist' or something, but I have a hard time taking this seriously when one of the chief complaints of Typescript is that it is too "difficult"

It really makes me question the validity of the rest of the points.

<comment><USER13> Yeah was interested to hear what their points would be but couldn't get past when they started complaining about typescript.

</comment></comment><comment><USER14> > I didn't feel Typescript added substantial value and even worse, we noticed > that our coding speed was reduced. With Typescript things that were really > easy to do on Javascript like defining a simple object were more complicated > to do on Typescript. I highly recommend you to read the following articles > before you start using Typescript. It is not the right solution for > everyone.

If you read the linked article, it's using a graph of the number of GitHub issues labelled "bug" to justify that languages with strong static types don't reduce the number of bugs which isn't meaningful or convincing...

> The main thing we didn't like and we still don't like about Angular 2 is > Typescript. I know Angular 2 can be used with Javascript but again, the > decision to use Typescript was already taken and from what I understand, > using pure Javascript with Angular 2 is not the ideal way you should be > using Angular 2. In any case, getting rid of Typescript meant a full rewrite > of the project. ... > I still remember how easy to work with Angular 1 was, > it certainly had it's own problems, but it was nice to work with it compared > to other frameworks, something that Angular 2 lost somewhere on the way.

I recently moved from Angular 1 because it didn't work well with TypeScript. The rest of my project was in TypeScript and all the bugs were coming from the Angular 1 layer because there was no static checking there.

TypeScript is an enormous improvement over plain JavaScript in my opinion in terms of productivity (better refactoring, better autocomplete) and making your code more robust (no unexpected null/undefined variables, no more mixing up strings and arrays). Ignoring TypeScript for large projects is a big mistake.

Angular 2 felt too verbose and overly complex so I switched to Vue which has decent add ons to work with TypeScript. If you use JSX for Vue templates as well, you get type checking for your templates.

</comment><comment><USER15> > With Typescript things that were really easy to do on Javascript like > defining a simple object were more complicated to do on Typescript.

Sure defining a simple JS object has no overhead as opposed to _maybe_ the 15-30 seconds of overhead that creating the Typescript interface entails. But that few additional seconds of overhead gives you this for rest of the (weeks, months and years) of the systems lifetime:

      1. Instant IDE/editor code completion and error checking
      2. Compile time checked contracts when that object is passed to another function
      3. Compile time checks for misspelled or non-existent members of the object.
      4. Instant refactoring of member names across files with any number of editors and IDEs
      5. A chance to take a little higher level look at the design of your system.

After using Typescript for a couple of years now I've found that when I design my types well the overall design and flow of the system tends towards beauty. That is probably why the Haskell folks are always over on the sidelines smirking.

</comment><comment><USER16> Angular is a application framework, Vue is a view library. It's really frustrating to see these two compared, because they have different purposes and intentions.

Vue just renders components. There's no state management, built in routing, or any of the other things you get for free with Ember/Angular/etc.

By the time you slap all of that on top, you may have well just stuck with Angular. I noticed in React by the time you added the required add-ons (mobx or redux, polyfills, react router, styled components) it was extremely heavy. Furthermore, maintaining these addons, with their own release cycles and bugs is an additional burden on a team.

<comment><USER17> > Vue just renders components. There's no state management, built in routing, > or any of the other things you get for free with Ember/Angular/etc.

That's not really true anymore; there is now an official router[1] and state management library[2] for Vue. You don't _have_ to use them, but I think the comparison is still completely fair.

[1]: [https://github.com/vuejs/vue-router](https://github.com/vuejs/vue- router)

[2]: [https://github.com/vuejs/vuex](https://github.com/vuejs/vuex)

<comment><USER16> This is a great point, I did not know it was officially in the build. Thanks!

</comment></comment></comment><comment><USER18> 2 flaws with this article. 1) Using a Beta product and complaining on Angular2. You could have waited till the product is matured 2) Blaming for the developers inefficiency on Typescript. If your developers coding speed is reduced blame on your developers. Your title and article appears that something is wrong with Angular2 and moved to Vue.js. Before you post such articles make sure what your write makes sense

<comment><USER19> He cites two articles going into much more detail on the line of thinking regarding the tradeoff that is static typing. I realize this is one of those tab/spaces kinds of religious debates, but hopefully all sides can acknowledge that we are talking tradeoffs and not universal truths. Maybe one day we'll see loose typing as evil as "goto" statements, but the evidence isn't there yet. IMO.

<comment><USER20> Goto statements still have their fans, and on the other end of the spectrum you'll find people arguing that things like multiple return statements and exceptions are basically the same. It's hard to find absolute truths in computing. I bet there are a few people who'd like us to ditch that whole binary kerfuffle, too.

But yeah, they're trying to be productive in the short term, so it's probably not worth overanalyzing whether a distaste of static typing isn't emblematic of other issues. Getting things rolling has a higher priority...

<comment><USER21> > I bet there are a few people who'd like us to ditch that whole binary > kerfuffle, too.

[https://en.wikipedia.org/wiki/Setun](https://en.wikipedia.org/wiki/Setun)

Knuth has also hypothesized that we may one day start producing ternary computers again due to their efficiency and elegance.

</comment></comment></comment></comment><comment><USER22> everybody who feels so strongly about separation of code from templates - <USER2> you realize that down there it's still just bunch of string concat calls? it's literally what ERB templates in Ruby compile to, and similarly in literally every other template language.

rather than focusing on "omg html in my js" you should focus on "omg presentation code in my business logic code" because that's when you realize where the real boundary is.

it's one of the reasons i love clojurescript's hiccup so much - i'm still clearly writing idiomatic clojure code but now the boundary is not some arbitrary "this file is named .html and this .js", but actual namespaces/functions, where it's obvious from scope and signature what data my templates depend on.

<comment><USER23> I got a theory about that. Somewhere along the way our IDEs and code editors trained us that different languages always belong in different files. Eventually people saw this as an aesthetically tidy arrangement to strive for.

Mixing bits of different languages "inline" within the same file got a bad rap despite the fact it was often a sensible approach to organizing common logic together.

You write html inside js? or sql inside python? omg noob!

Ironically I think our tools have programmed us to think/operate in a specific fashion that was convenient for IDE .

<comment><USER24> My theory is that a lot of us have gone down this road, eventually found the thing getting unwieldy and difficult to maintain, and swearing never again.

</comment></comment></comment><comment><USER25> Angular 2 in beta made bold claims about being 'production ready' which reads 'almost done', it was frustrating just how long it then took to become what I would consider production ready.

I consider Angular 4 the first release to produce _just about_ acceptable sized app bundle. On the whole though it's a very ambitious project and I think it will be increasingly hard to ignore, we've currently no intention of changing framework.

<comment><USER26> I think this had to more to do with internal pressures at Google than the actual state of the code. They had been working on it for a _long_ time, and, I think were under some pressure to actually ship something. Angular v4 is what the first production version should have looked like.

Having just upgraded a large AngularJS v1 project to Angular v4, I'm actually very happy with where it's ended up. It feels like a very good combination of power and flexibility. There are still some complex bits, but it feels more like the complexity is necessary and sanely designed, rather than the craziness of what AngularJS's directive stuff evolved into.

<comment><USER27> Would you share some stats about the upgrade? How many LoCs was the codebase and how many man/hours it took?

<comment><USER10> s/upgrade/rewrite . I don't believe a second there is a reasonable way to upgrade 1.X from 4.X without rewriting all UI related code.

</comment></comment></comment></comment><comment><USER28> We moved from Angular 1.3 to Vue.js. Vue came at a right time and I especially liked its ease of use, similarity to Angular and footprint. The most important thing to me personally was the speed and the development feedback cycle.

<comment><USER29> I like Vue, but one thing that worries me is that 99% of commits are being made by a single person.

<comment><USER30> I like it, a mirror opposite of extreme "designed by committee" practices of big co. funded frameworks.

I feel purposefulness of Vue's design. There are no gigatons of features and behaviors which make you scratch your head and think "why it is there to begin with" like why Ang2 insists on using observer objects for HTTP responses, or why Ang1 had a such an extensive buildover around its component zoo to do just "new mySerice", or reasons for React's component rendering order peculiarities, or logic behind their choice of syntax.

Vue is very bare bones thing. It provides no reactive layer over complex object with non-primitive content. Lack of native support for maps or sets from ES6 is inconvenient a bit, but it is not hard to provide a function wrapper around any logic that uses them. I usually keep all business logic outside of Vue's instance and only wire though its inputs and outputs.

What I lack in all common frameworks is the ability to play smoothly with really complex DOM manipulations, like swapping prototypes of a DOM elements and mergings. Trying to do something like complex drag and drop logic usually means doing a lot of "do it within DOM element, or do it within framework's element" thinking

<comment><USER29> I'm not talking about the API design, I'm more worried what happens if Evan dies, or just loses interest in it. Bus factor of 1.

<comment> super-serial What happened to jQuery when John Resig focused on other things?

I'm actually hoping Vue.js builds everything needed for a Reactive minimalist framework and then development slows down similar to the speed of jQuery. I think people are sick of frameworks doing overhauls of their entire codebases every major version release.

</comment></comment></comment></comment></comment><comment><USER31> It's always a bit strange when someone chooses a framework based on how far they get in a few hours or days of testing. For medium sized or larger projects it's much more interesting how it will work long term with a large code base.

I'm not saying that Vue is no good or that it was not a good choice for the author, but the way he described their process makes me think that they optimized the wrong thing.

</comment><comment><USER32> I've been attempting to learn Angular2 and React, but haven't delved into Vue. Angular2 is just different, but it makes more sense to me than 1 if you take the time to learn the concepts. If you go into 2 thinking your 1 skills will translate, then I get why you'd be frustrated. But I found 1 to be very vague conceptually, so many different ways to do the same thing that you end up with many bad implementations. And compared to React, Angular2 is cake imo. There's so much more materials to draw from, and ui libraries to use, and you have to import so much in order to do the same things in React. That may allow for more flexibility, but it makes the learning curve that much more difficult. I'm still not a fan of Typescript, but it seems important to get familiar with ES6.

Also angular-cli and create-react-app are both excellent tools that take a lot of the guess work out of the process, at the very least they show you how to do things right way and keep up to date with what's important.

<comment><USER10> > Angular2 is cake imo.

Angular.X totally lacks of vision. For years it didn't know what it wanted to be, pilling up layers of layers of complexity with IoC containers (useless in a weakly and dynamically typed language such as javascript), Some custom HTML that even needs its own parser, Rx.JS (which is self sufficient if you use it, you literally do not need something on top of that). For what result? it's not faster, snappier in the client, lighter when it comes to the payload, not easier to learn or to test or to use. You don't need some ajax libs either, the fetch API already exists. Angular.X is trying to be the "JEE" of the front-end, except it miss the point of JEE which are a bunch of stable specs, which Angular isn't.

<comment><USER33> The vision is finally having a good UI kit. Components, templates, lazy loading, isomorphic/universal JS, precompilation, maintainability, code discoverability, ease of team development, testing, etc.

Angular CLI does the compilation, provides the boilerplate management (no need for IDE, if you don't want that), provides the language service (for static checking templates).

Google dogfoods it, they are on the latest rc always. Somehow they can manage the API changes/breaks. (And so far it wasn't much problem for us either.)

I don't know if rx is now a hard or optional dependency, but at least they haven't NIH-ed another Observable lib.

</comment></comment></comment><comment><USER34> Just wanted to come here and say thanks to the author for writing up your assessment of their tech stack and the pluses and minuses - it's brave to do so and it's obviously spurred discussion.

Thanks for sharing some of your learning and having the guts to put it out there, and congrats on shipping the results.

I have a couple of questions:

1) You had two people working on the project - how do you think it would scale out to 10? React's componentized / functional nature allows for that pretty easily which is a consideration for me.

2) Managing JavaScript in templates (html) with Angular 1.x was always weird because you couldn't necessarily tell if the execution was happening in the view or the controller. Does Vue make that any easier when it mixes templates and JS together? I also appreciate knowing that this file is where everything is contained for X element or function.

3) How are the test harnesses?

</comment><comment><USER35> The thing I find amusing about posts like these is that they come about once every 18 months. Just substitute the left framework for last years shiny and the right for the latest shiny. We developers are nothing if not consistent in our ability to chase the latest shiny. I do wish more developers would take the time to master languages instead of learning new frameworks though.

</comment><comment><USER36> I still say Mithril ([https://mithril.js.org/](https://mithril.js.org/)) is where it's at. I am at a company now that uses Angular 4.x and I'm not impressed with it. IMO, it's a way to make JS seem more like Spring/Java (especially with Typescript) rather than understand how JS works and use it as it is.

Not to mention the learning curve even for senior developers. Mithril took me maybe 30 minutes to understand. The entire source ([https://github.com/MithrilJS/mithril.js](https://github.com/MithrilJS/mithril.js)) is easily read in a few hours. They have multiple committers and an active gitter chat room for any problems. Plus you can use JSX if you like it that much. And it has a nice license.

More folks need to try it out.

<comment><USER14> Are you not at a disadvantage with it having a smaller community or is there enough content out there? I like to support new innovations but knowing I can easily find a prewritten component for Vue or Angular is a big selling point.

<comment><USER36> I never felt like I had any problems, to be honest. It was so quick and easy to write things, I never worried. There are a decent amount of plugins out there on github, though. Give it a shot!

</comment></comment></comment><comment><USER37> Vue seems to be less taxing on the mind. Compared to React, I feel Vue is more easy to build with. Just my 2 Cents

<comment><USER38> I agree. Having used both on small projects I was able to get started and finish quicker on Vue.

That being said, I use React more because of the larger community, (easier to find answers, and components) as well as more jobs for React vs Vue.

Also, Fiber introduces better animation performance, which i'll eventually use.

<comment><USER37> Things have become easier with create-react-app though.

</comment></comment></comment><comment> vladimir-y The article says to me that the team/company had no initial actual need to use TypeScript as seems author doesn't get a point of its purpose (of course code writing will be slower on the initial stage as it's not just about writing the code, but also about defining its structure which gives you the benefits with the growth of the project) and so a bad decision was initially made.

In my opinion Vue is ok for the one kind of projects, with smaller team, smaller project lifetime and Angular is ok for other types of projects. React is alien here, ie not really needed.

</comment><comment><USER39> No experience with Vue.js or React, but I used Angular 2 recently and I did not like it much. Too much magic, too much 'do our things our way or woe betide you'.

</comment><comment><USER40> The author made some really weak arguments.

In his comparison matrix, why was Reactivity a criteria? Why did Angular score a "Kind-of"? Reactivity is just another word for the framework's underlying change detection logic. Obviously all of these frameworks have that. The fact that he put the term "reactivity" up on a pedestal and rated angular down tells me the lack of understanding on the author's side

</comment><comment><USER40> Angular 2+ does require more up front investment. However once you get going, the framework's convention is pretty seamless and on can create rather structured, team friendly projects, and iterate functions quickly.

The Angular CLI tool is a must! Without it, the friction to get dive into the Angular 2+ world is significantly more.

</comment><comment><USER41> > At the time we were thinking about Vue.js vs React, we were also considering > rewriting our mobile app and React Native looked like a really good choice. > That was a big plus for React since Vue.js didn't have anything remotely > stable that resembles what React Native is trying to do, so the possibility > of reusing code between the web and app clients was a huge plus, but I > decided that I wasn't going to consider possibilities that might or might > not happen. After all, from my experience, with Node.js I reuse a really > insignificant amount of code between the browser and the server.

The main benefit of using React if you are considering using React Native is that you and your team won't need to learn another framework in order to build native mobile apps for iOS and Android - if they know React already, they'll be up to speed with React Native very quickly.

<comment><USER42> Alibaba's working on a Vue-based mobile alternative called Weex. It's still in its infancy, but it's worth checking out:

[https://weex.incubator.apache.org/](https://weex.incubator.apache.org/) [https://github.com/alibaba/weex](https://github.com/alibaba/weex)

</comment></comment><comment><USER43> Ember user here, looking for a breath of fresh air from the limitations of Emblem/Handlebars and the endless layers of complex objects.

I am enrolled in Udacity's React Nanodegree, but recently took a closer look at Vue. It seems to offer everything React does (VDOM, one-way data flow, centralized state management, support for JSX), but without the patent drama.

I previously took a nuanced approach to Facebook's unfair patent license, and will probably never need or want to sue them for patent infringement. But Vue is quite a viable alternative, so I see no reason to reward Facebook's unwillingness to play fair.

I plan to finish the Nanodegree, but will probably be skipping React and using Vue for my own real-world projects.

</comment><comment><USER44> While we are at it - any success stories with Weex? (a la Vue.js native)

<comment><USER28> A few months later: "Try Weact, a Weex alternative."

The speed at which these frameworks pop up is almost exhausting.

<comment><USER45> My approach for a JS framework or library is that the time I can hope it will be maintained for is at most the time that it has already been maintained. This way, depending on how long my project is supposed to be supported I can make a reasonable choice about what to use. I call it "JS half-life time".

<comment><USER46> There's a name for this in the literature: [https://en.wikipedia.org/wiki/Lindy_effect](https://en.wikipedia.org/wiki/Lindy_effect)

<comment><USER45> I didn't know about that, thanks for sharing.

</comment></comment></comment></comment></comment><comment><USER47> I just broke your Vue website.

[http://cl.ly/2I2r2S2v171T](http://cl.ly/2I2r2S2v171T)

</comment><comment><USER48> Clickbait. The author switched from Angular 2 beta 9 (not even a release candidate) because he was unable to migrate to Angular 2.0.0 since 'too many things broke to make the upgrade non trivial'. Yet somehow rewriting the entire app in Vue is easier?

<comment><USER49> You'd be surprised how simple it is to re-write an application in Vue. As someone who just finished doing so, I can say that development speed is like nothing I've ever experienced. The application I rebuilt initially took about 2 months to build with React. I rebuilt it with Vue in 2 weeks by myself. I am not venerating Vue, just simply responding to your concerns about rebuilding entire applications.

<comment><USER14> I did a rewrite from Angular 1 to Vue recently and it didn't take long at all plus it fixed a bunch of bugs that were problematic to fix in Angular. If you write your Angular 1 code in component style, moving them to Vue is pretty straightforward and a lot of the template conversions just involve changing keywords (e.g. ng-if -> v-if).

</comment></comment></comment><comment><USER50> I envy how some companies can migrate from one to another framework like that. Beside that, TypeScript is just fine once you get more time with it, you don't need to type everything. On the other side I find Angular more stable framework on the long run.

</comment><comment><USER51> Have been using angular 1 and I so wish that I had used vue instead. vue is easy and intuitive compared to angular bloat. May be will take less than half hour to understand basics coming from angular.

Can anybody share experience with nuxt.js ?

</comment><comment><USER24> People are already migrating from ng2? It just came out!

<comment><USER52> ng2 final was released in September 2016, but many were using it well before then, as in the article. (first beta was in January 2016 I believe)

<comment><USER24> I guess maybe it because I am not a frontend person but completely redoing a project in less than two years seems kind of crazy to me.

</comment></comment></comment><comment><USER53> I stopped reading at "The main thing we didn't like and we still don't like about Angular 2 is Typescript". Sorry.

</comment><comment><USER54> Wait, but TypeScript makes inheritance a joy. So, how you do it - unless you don'r really reuse the implementation?

</comment><comment><USER55> > JSX was also a problem since we could not reuse HTML code

Who has source code in native HTML lying around?

<comment><USER56> Even more, a simple find and replace for "class" to "className", and wrap it in a render function. There, now the HTML is being reused as JSX.

</comment></comment><comment><USER57> What I want to know is, why didn't you choose Aurelia? :)

</comment><comment><USER58> I wonder why nowadays anyone would choose React and give away _all_ patent rights to the E̶v̶i̶l̶ ̶c̶o̶r̶p̶o̶r̶a̶t̶i̶o̶n̶ Facebook (or not, in which case one would need to rewrite the app completely, since he cannot use React anymore). This alone should make choice way easier, if you decided to not use Angular anyway.</comment>


Why Google TV is fundamentally flawed - <AUTHOR> http://theexciter.com/articles/why-google-tv-is-fundamentally-flawed.html

<comment><USER2> "Imagine instead if the remote for a storage, OS and video-decoding "media box" was an iPad(-like) tablet on which you did all the interactions and the TV simply mirrored those when you where browsing, or presented the results of such interactions, like playing a show from a playlist you just created."

I think the author missed the part where they were controlling the TV using their Nexus Ones. Go watch the presentation again, they're already doing exactly that. You can't complain a product is flawed if it is already doing exactly what you want it to do!

Edit: Logitech already has iPhone and Android apps for their box: [http://www.engadget.com/2010/05/20/logitechs-google-tv- compa...](http://www.engadget.com/2010/05/20/logitechs-google-tv-companion- box-includes-smartphone-apps-we/)

<comment><USER3> The iPad would also be an excellent adjunct device. As the price of such devices fall, the interface possibilities will become readily available.

Also, just having an Apple/Front Row style remote with a menu driven interface enables a whole lot.

The big attraction is the data. iAd style advertisements on these boxes will be a treasure trove of consumer data.

</comment></comment><comment><USER4> Kind of a weak argument.

The people that are working on these devices aren't idiots and they realize that input is a problem.

Many cable operators are exploring the use of smart phones as remote (in fact the Google TV demo used and android phone as its data entry device).

Vizio TV's are putting keyboards in their remotes as well.

What most people designing apps for TV realizes is that apps that require heavy user input don't work well so they instead design apps that work around these restrictions. Its a challenge but not one that is insurmountable. No one is trying to turn your TV into a PC replacement they're just trying to extend its capabilities a bit.

<comment><USER3> Right. Look at what Apple does with the very simple 6 button remote. The trick is to come up with the right contexts and choices to cover the easy 80% use cases.

</comment></comment><comment><USER5> Google TV's developer page notes the importance of the user being able to navigate with only five buttons (up, down, left, right and enter) here <http://www.google.com/tv/developer/#navigation-is-critical>.

So this post seems a bit uninformed to me. I think google knows what they're doing.

</comment><comment><USER6> This article "debunks" Google TV for no other reason that it isn't the cool way dynamic web based TV should be as the author imagines it.

Title is sensational at best.

</comment><comment><USER7> I have been using my Android phones as my remote for my Windows 7 media center for quite some time. I don't see why this wouldn't be possible with Google TV...

</comment><comment><USER8> I'm skeptical also. Do people really want a search driven TV experience? TV is the opposite of the Internet in many ways. I think people want content pushed at them or presented in a buffet style interface. From the demo video Google TV looks to be _very_ focused on search instead. The other thing that made me skeptical was Google presenting the problem of a program being on multiple channels. My cruddy cable DVR was able to figure this out years ago. TIVO has always done a very good job at it. What's the problem there?

<comment><USER9> My problem with them is data entry, which google wants to let me take care of with my droid (and I'd love to). I have used search on a cable box exactly once because it was as much of a chore to enter the query and sort through the spectacularly awful search results as to scroll through all the channels trying to find what I wanted. And yet, every time I actually have something in mind I want to watch, I wish I could use an easy and decent search function. Then theres the possibility of hulu style "channels" which still give a buffet, but you get to stick to the sushi section of the buffet instead of having no discernible organization.

Lots of what google is trying to do has been done poorly and in half-measures before. A good implementation with all of them together has a ton of potential.

</comment></comment><comment><USER10> This guy clearly didnt watch the demo or read the developer docs.

And, I DO want a search based TV interface. I hate having to scroll through several screens to find the show that I want.

<comment><USER11> And the search interfaces that STBs do have are terrible, you can barely search by name, and can't search by actor or anything like that.

But being able to scroll through a list is much better than having to watch a scrolling list and having to _wait_ for the thing you want to scroll by.

<comment><USER10> I know on my STB, the list that the search returns is just the title of the show (for instance, 30 Rock). It gives me nothing more than the title, so I have to click around till I find the one that I want

</comment></comment></comment><comment><USER12> I agree with the post in that in the long history of the "TV-Internet convergence" starting with MS's WebTV in the 80s most people viewed the TV as a tool to browse the web. That's why they failed because, as most people know, the TV watching and Web browsing experiences are quite different.

Then, there's the problem of the input device. Ever enter a movie name for search using the TiVo remote, AFAIK the best currently available? It's a pain. Now, one thing Google TV gets absolutely right is that your phone will be your secondary interaction device for your TV.

The real interesting question here is: will applications on the Google TV set- top-box be able to access the tuner and EPG functions. TiVo has a nice SDK for their boxes for years now, the reason you never heard of it because they don't allow apps to access these features out of fear from content providers. If you can write Android apps running on the STB that can access the video stream, now that would be _super_ , but I don't expect to see this anytime soon.

<comment><USER4> "will applications on the Google TV set-top-box be able to access the tuner and EPG function"

Only of the TV and this would only work with "Over the air" tv. In the US most of us receive our TV and guide via our cable or satellite box and tune via that mechanism. Google TV and competing products have no easy way of accessing that data (the guide data and tuning).

There's some hacky ways of doing it but nothing really integrated.

<comment><USER7> I have a Hauppauge WinTV HVR-2250 and Windows 7, which I use with the cheapest basic cable package Comcast has -no STB, basically just analog and HD Clear QAM of the local channels. Upon installation, Windows scans your signal and asks your ZIP code and service provider, and that's it- the EPG is set up and works great. Hardly what I'd call 'hacky'. If Microsoft can maintain a database and have it work flawlessly, I don't see why Google couldn't...

<comment><USER12> Getting EPG data is not a big deal, but may be costly if you plan to sell services based off it, e.g. a single Tribune (EPG data monopoly in the US) EPG data access costs around $10K. However, if you are developing apps for non- commercial purposes, e.g. open source, you can get this data for $20/year at <http://www.schedulesdirect.org/>.

The real problem is to access the video stream. Currently this is viewed to be illegal (see the lawsuit in 2001 that pretty much sank ReplayTV, <http://www.eff.org/cases/newmark-v-turner>).

<comment><USER7> I'm guessing Microsoft has gotten a licensing deal with Tribune to get and share the EPG data for Windows Media Center. As far as the video stream, I wonder then how Microsoft/Hauppauge get away with it?

<comment><USER4> You're only getting access to the unencrypted channels. (and generally I believe only SD?)

The vast majority of Comcast's channels and content can't be accessed without a cable card or cable box.

<comment><USER7> Yes- I'm getting SD analog channels + HD Local Channels (which the FCC mandates they carry in the clear), although there _are_ CableCard PC tuners out there, and from what I've heard, CableCards _are_ available from Comcast (I just refuse to pay $50/mo, or whatever it is, to get the digital package). I also use my Xbox 360 as a Media Center Extender to watch stuff I've DVR'd in the bedroom. I don't see how this is really doing anything different than what ReplayTV was doing. Maybe it's just that there aren't enough people doing it to have drawn the ire of the media companies...

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Here's how I imagine Google TV when I turn it on for the first time:

"This program is not available in your geographical location"

</comment><comment><USER14> This looks like an article written to match a desired headline. The control device is hardly 'fundamental' to the concept of a web-enabled TV.</comment>


SVT-AV1: open-source AV1 encoder and decoder - <AUTHOR> https://netflixtechblog.com/svt-av1-an-open-source-av1-encoder-and-decoder-ad295d9b5ca2 <comment><USER2> No further mention of rav1e from Mozilla/Xiph/Vimeo, which seems like the more relevant benchmark comparison than libaom.

<comment><USER3> Why? rav1e doesn't yet achieve the same quality as libaom.

<comment><USER4> I definitely got better quality with rav1e than libaom (via ffmpeg), before I gave up on the latter altogether.

<comment><USER3> Here are some measured results. rav1e is worse than libaom and SVT-AV1:

[https://www.reddit.com/r/AV1/comments/f1h2u1/aom_vs_rav1e_vs...](https://www.reddit.com/r/AV1/comments/f1h2u1/aom_vs_rav1e_vs_svtav1_vs_x265_vs_vp9_vs_svtvp9/)

[https://forum.doom9.org/showthread.php?p=1893776#post1893776](https://forum.doom9.org/showthread.php?p=1893776#post1893776)

<comment><USER4> Perhaps things have improved for libaom since the last time I tried it but my issue wasn't overall quality so much as sections of videos that had way too many very much visible artifacts (to me it looked like there were likely bugs rather than a poor design).

<comment><USER3> YouTube is using libaom for its many, many AV1 encodes. Without knowing the version you used or the settings you used there isn't much that can be usefully talked about. What we can say is that libaom is good enough to be used on the world's biggest video website.

<comment><USER5> I agree with the OP's assessment - as recently as two weeks ago, Libaom was too slow to even do quality testing on real footage. And that's with forty modern Xeon cores.

The fact that YouTube uses it only proves the increasingly obvious business model they use in the space, namely the monopolization of the encoding ecosystem by literally throwing away money to steer people clear of rav1e.

<comment><USER3> The practical reality is that libaom is benchmarked against routinely. It is the benchmark.

See some benchmarks here:

[https://videocodectracker.dev/](https://videocodectracker.dev/)

[https://arewecompressedyet.com/](https://arewecompressedyet.com/)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> AV1 Encoding is ready for prime time. However hardware decoder is mostly absent, which blocks adoption in mobile apps. (Dav1d is great, but consumes too much power on mobile devices)

<comment><USER7> The encoding still isn't ready for user driven content sites. It's still too slow, even with the 16% savings shown with the new improvements this article talks about. For Netflix it's great as they have a significant amount of time before content goes live (weeks if not months), but for sites like youtube/vimeo/instagram/etc, it just isn't quite there yet. The turnaround time is simply too long.

That's just the UX bottleneck, but there's another elephant in the room: it's cost prohibitive. Encoding time is so slow that we're still measuring in frames per minute for most software encoders. If I want to move my whole video encoding pipeline to AV1 from h264, I need around 100x the horsepower to encode. That's 100x the server costs, and as someone who's looking heavily at using AV1 for the video site I'm working on now, it's simply cost prohibitive.

Don't get me wrong, the steps that Netflix are taking with SVT-AV1 are amazing. We're seeing a huge improvement from the 500x vs h264 it was showing last year, but it still needs a huge amount of effort before it's ready for prime time. I'm really hoping we see some early hardware encoding/decoding implementations for AV1 given the number of companies who are in support of it.

<comment><USER3> > _The encoding still isn 't ready for user driven content sites._

YouTube has lots of AV1 encodes. You've probably watched AV1 encoded content without realising it. Here are a few of examples. To verify that they're AV1 encoded, right-click on the video and select "Stats for Nerds". I'm playing them in Firefox 75 beta.

Halo trailer: [https://www.youtube.com/watch?v=Fmdb- KmlzD8](https://www.youtube.com/watch?v=Fmdb-KmlzD8)

Despacito music video: [https://www.youtube.com/watch?v=kJQP7kiw5Fk](https://www.youtube.com/watch?v=kJQP7kiw5Fk)

Porsche Taycan commercial: [https://www.youtube.com/watch?v=92sXWVxRr0g](https://www.youtube.com/watch?v=92sXWVxRr0g)

For some videos YouTube has AV1 encodes up to 480p, others are up to 1080p, and some are up to 4K.

<comment><USER8> Any reason why YouTube only uses it for low(er) resolutions?

<comment><USER3> The YouTube video library is huge so they're prioritizing encodes based on encode time (AV1 takes longer to encode), the ability to play it (more systems can play 480p AV1 than can play 4K AV1), and the number of views a video gets (if a video has a low view count then it doesn't much matter what it's encoded in).

</comment></comment></comment></comment></comment><comment><USER9> Why does Netflix publish articles on paywalled websites? Are they aware that users need to pay Medium to read their articles? I get this error: "You've reached the end of your free member preview for this month. Become a member now for $5/month to read this story and get unlimited access to all of the best stories on Medium."

<comment><USER10> >Why does Netflix publish articles on paywalled websites?

Maybe nobody there can figure out how to set up a web server? Maybe they get a kickback from Medium subscriptions? So many questions.

You can usually bypass the paywall with the archiver: [https://archive.ph/gv8T6](https://archive.ph/gv8T6)

<comment><USER11> > Maybe nobody there can figure out how to set up a web server?

Huh? It's their business for sake.

</comment></comment></comment><comment><USER12> Nice.

> For estimating encoding times, we used Intel(R) Xeon(R) Platinum 8170 CPU @ > 2.10GHz machine with 52 physical cores and 96 GB of RAM, with 60 jobs > running in parallel.

Would love to see some comparisons with amd, at some point.

Is there currently an easy way to run this on multiple machines? Back in the day, I'd probably try a single image cluster, like openmosix - but I'm not aware of anything similar for modern setups - neither self-host or "hardware on tap"?

<comment><USER3> > _Would love to see some comparisons with amd_

Here are some comparisons of various SVT-AV1 releases on Intel and AMD CPUs:

[https://openbenchmarking.org/showdown/pts/svt- av1](https://openbenchmarking.org/showdown/pts/svt-av1)

<comment><USER12> Thanks. Nice to see 60fps 1080p is within reach for certain profiles. Anyone know how big the difference is up to 4k for typical video? Is it more or less than 4x?

</comment></comment></comment><comment><USER13> >The results are presented for 1-pass mode with fixed frame-level QP offsets. A single-threaded compression mode is used.

Why is it 1-Pass? and if I may, use the word "again". Every time when it is compared to LibAOM, it is always one pass.

<comment><USER3> There's a 2 pass comparison in the article. The graph comes from their comparison site which uses 2 pass encoding for both SVT-AV1 and libaom:

[https://videocodectracker.dev/](https://videocodectracker.dev/)

</comment></comment><comment><USER14> Seeing the title I thought this was something developed by the Swedish public service broadcasting company SVT, which also has a pretty extensive online streaming service and so it wouldn't be too far fetched an idea that they might work on something like this. Finally – I thought – taxpayer money being out to good use.

Anyway, cool tech, well done! Hope it takes off and hardware encoders/decoders start to become common place as well.</comment>


Shell Has a Forth-Like Quality (2017) - <AUTHOR> http://www.oilshell.org/blog/2017/01/13.html <comment><USER2> (author here)

Oil has made a lot of progress in the last 3 years, with a few releases every month.

[http://www.oilshell.org/releases.html](http://www.oilshell.org/releases.html)

The goal of the project is to replace bash!

If you know shell and Python (or C++), I maintain a "help wanted" bug label:

[https://github.com/oilshell/oil/issues?q=is%3Aissue+is%3Aope...](https://github.com/oilshell/oil/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22)

It's almost there, except for speed, but it needs more testing from users. The "should-run-this" label has some ideas:

[https://github.com/oilshell/oil/issues?q=is%3Aissue+is%3Aope...](https://github.com/oilshell/oil/issues?q=is%3Aissue+is%3Aopen+label%3Ashould- run-this)

There a lot of project updates on [https://oilshell.zulipchat.com/](https://oilshell.zulipchat.com/) too (requires login)

<comment><USER3> Very curious - what kind of people use OSH and how many actually use Oil in OSH?

I am hesitant to spend the time ramping up on something like this because, as much as possible, I try to write my shell scripts so that they can run without any additional packages in an Alpine docker container.

Is this resistance that you have encountered before?

<comment><USER2> Right now it's mainly a few shell enthusiasts and early adopters, i.e. people who want a better shell and want to influence the design of the Oil language. [1]

I've definitely seen people who want to limit themselves to either bash or POSIX shell on purpose, and that's fine.

For simple shell scripts, I might lean that way too (at least until Oil is smaller/faster).

One major reason for Oil is to give you an upgrade path after you've used and enhanced such a shell script for years. Then you will likely bump up into shell's limitations, and the extra dependency will be worth it.

For example, all Linux distros are based on thousands of lines of shell scripts [2], and I think those scripts desperately need a new language. They're big and complex, and need a better language to be correct, robust, and fast.

Here's a comment I wrote that might explain the design goals of the project more:

[https://www.reddit.com/r/ProgrammingLanguages/comments/ddhmj...](https://www.reddit.com/r/ProgrammingLanguages/comments/ddhmj9/you_can_now_try_the_oil_language/f2htup3/)

[1] _Oil Language Design Notes #1_ [http://www.oilshell.org/blog/2019/08/22.html](http://www.oilshell.org/blog/2019/08/22.html)

[2] _Success with Aboriginal, Alpine, and Debian Linux_ [http://www.oilshell.org/blog/2018/01/15.html](http://www.oilshell.org/blog/2018/01/15.html)

<comment><USER3> Thank you, your response was very informative. It got me to dive a bit deeper into some of your essays and blog posts. I learned a lot particularly from these:

1\. [http://www.oilshell.org/blog/2016/11/06.html](http://www.oilshell.org/blog/2016/11/06.html)

2\. [https://github.com/oilshell/oil/wiki/Shell- WTFs](https://github.com/oilshell/oil/wiki/Shell-WTFs)

</comment></comment></comment></comment><comment><USER4> Discussed at the time: [https://news.ycombinator.com/item?id=13477842](https://news.ycombinator.com/item?id=13477842)

<comment><USER5> Thanks, that's some quality discussion. Really impressed with the depth and breadth of the commentary.

<comment><USER6> I really like oilshell and chubot for that. He has some really great posts on the shell language and parsing.

</comment></comment></comment><comment><USER7> When I see stuff like this I always wonder how people above about finding these capabilities. I don't use bash every day so I tend to forget a lot of "tricks". But then I get annoyed when I see people write about really neat stuff that can be done in bash but couldn't figure out myself.

<comment><USER2> (author here)

I agree a lot of this stuff hasn't been documented well in existing shell resources. I should write more about it, but I'm still busy working on the Oil shell implementation nearly 3 years later :) I should have written a post about xargs 2 years ago, which has nontrivial compositional patterns. Hopefully next year!

I still recommend _The Art of Unix Programming_ (mentioned in this post), which is more generally about Unix design, not about shell in particular.

I also got a lot of ideas by reading DJB's shell and C code, and his papers (e.g. _Ten Years of qmail Security_ ). I probably learned about DJB 10 years ago from Hacker News.

I would say there's a lot of "tribal knowledge" in people's heads, and online forums are where it gets disseminated. For me those forums were Usenet, the old JOS forum, and Hacker News and lobste.rs these days.

\----

Neil Stephenson has a good quote about this "oral history"

 _Unix, by contrast, is not so much a product as it is a painstakingly compiled oral history of the hacker subculture. It is our Gilgamesh epic._

[https://en.wikipedia.org/wiki/In_the_Beginning..._Was_the_Co...](https://en.wikipedia.org/wiki/In_the_Beginning..._Was_the_Command_Line)

[https://en.wikipedia.org/wiki/Epic_of_Gilgamesh](https://en.wikipedia.org/wiki/Epic_of_Gilgamesh)

The next post has the "point-free" pipline pattern which is both useful and hard to find out about!

        hist() { sort | uniq -c | sort -n -r; }

_Pipelines Support Vectorized, Point-Free, and Imperative Style_

[http://www.oilshell.org/blog/2017/01/15.html](http://www.oilshell.org/blog/2017/01/15.html)

</comment></comment><comment><USER8> I've done my share of shell tricks in the past and I love them, but I got very disappointed when I noticed that the performance sucks for anything more data intensive in the shell. At least in bash, which was the interpreter that I've used. I ended up porting my code to Python and gained at least 10x in performance.

But I prefer the shell code for tasks interfacing with system tools. I wonder if there is a shell interpreter around that is really fast.

<comment><USER2> If you have some realistic shell benchmarks, please file a bug and link the files:

[https://github.com/oilshell/oil](https://github.com/oilshell/oil)

Oil isn't fast at the moment, but I'm currently optimizing it (auto- translating some code to C++, and eventually hand-optimizing other parts.) I run benchmarks on every release, so speed is definitely a goal.

I haven't seen that many shell scripts that are "CPU bound" (as opposed to waiting for processes or I/O). (Although now I recall a shell-script-library bundler project that was.)

Of course, one big problem with shell is that you often have to spawn an external process like sed or awk to do string manipulation that's just a library call in Python. That could easily be a three order-of-magnitude difference -- e.g. milliseconds vs. microseconds.

<comment><USER9> I have a feeling the "bundler" lib you mentioned is mine - we discussed it a bit on lobste.rs a few years ago? Good to see you're still plugging away on oil!

<comment><USER2> Yes! I remember it was a good workload because it was doing a lot of string manipulation in pure shell.

I'm still interested in more feedback on Oil (e.g. does it still work on the latest version of shell-script-library? :) )

It's changed a lot, and the Oil language now exists! Latest post: _You Can Now Try the Oil Language_ \-- [http://www.oilshell.org/blog/2019/10/04.html](http://www.oilshell.org/blog/2019/10/04.html)

<comment><USER9> The testing setup for the lib is much improved, with actual unit tests and a built in capability for building/testing against a specific shell.

Next time I'm working on it I'll grab a release of oil and see how it fares!</comment></comment></comment></comment></comment>