Tesla employees say Gigafactory problems worse than known - <AUTHOR> https://www.cnbc.com/2018/01/25/tesla-employees-say-gigafactory-problems-worse-than-known.html <comment><USER2> I recently interviewed for Tesla's module department. Module engineering is essentially the gear between engineering and manufacturing. They're the heavy lifters. They're the front line grunts. They're the ones accountable for everything - LVM to HVM feasibility, process development, metrology, selection of suppliers, qualifying the manufacturing cell, process control and sustaining(operations, efficiency, continuous improvement, training etc.) and troubleshooting lines down situations.

The interviewer was very polite and told me this is probably the most demanding job at Tesla, especially at this time of the company's state when they're ramping up the production lines for Model 3.

I was intrigued and went to second round interview, and it eventually led to an offer. That is where things got interesting. Tesla needs to invest heavily in their Module engineers. The pay package was extremely disappointing and I am not willing to let go of the golden years of my life (late 20's) for this kind of a job unless it is heavily incentivized. I've had similar demanding job offers from oil companies, but at least they offset with a very compelling pay package (15% Alaska bonus, 4 weeks off, presumably amazing yearly bonus).

<comment><USER3> It boggles my European mind that 4 weeks of holidays is considered a lot...

<comment><USER4> It's not really considered a lot for many corporations in America. Not to mention government workers, who often get even more. All military personnel get 30 days (6 weeks), for example.

What's mind-boggling to me is that Europeans can't help but continue to make these smug comments, when your minimums are usually either 4 or 5 weeks, and the average isn't much more.

Yes, Americans work too much and don't get enough vacation. But for software developers in particular, the overall comp in America is WAY better than for Europe. I'll happily trade a week or two off (if I even have to) for double the salary.

<comment><USER5> There are very few companies that give four weeks paid vacation. Can't be more than 10%.

Two week is the status quo, and that's after you earn it. Silicon Valley is an anomaly.

<comment><USER6> 2 weeks + 10ish federal holidays is pretty standard for professional white collar office jobs. Works out to about 4 work weeks.

<comment><USER5> VS 4 weeks plus holidays in many European counties.

No matter how you cut it, we absolutely suck at time off. And even when companies offer it people don't take it because the culture discourages it.

He's right to be smug about it. We need to change the culture here.

<comment><USER4> Yes, and smugness from Europeans is the way to do that.

It's also unfair to consider things like vacation time, parental leave, and universal healthcare (the prime topics for smug) without also considering economic growth rates, employment levels, and overall comp, _particularly for white collar workers_.

The story in America vs the EU isn't one of their paradise vs our hellscape. It's one of inequality. Life for the poor or middle class in America sucks compared to Europe. But if you're lucky enough to be an employed white collar worker in America, you don't have it much worse, if at all, than the average white collar European. Open to data proving otherwise.

For what it's worth, I too want more vacation time, better parental leave, and universal healthcare in the US. But they come at a cost, and we shouldn't pretend otherwise.

<comment><USER7> I'm not smug, I think the workers in the US get a shitty deal. It's a major reason I wouldn't want to work there. (The same reason I wouldn't work in the games industry in the UK).

<comment><USER4> That's a common misconception. Many workers in the US get screwed. But definitely not all. Software devs in the US are almost unquestionably better off when you take total comp into account.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Tl;dr I hope they upgraded the the DB backing their battery manufacturing process.

I had a buddy who worked at Tesla. The first step of the battery manufacture process involves a robot taking a little cell out of the box, discharging it, charging it back up and testing to see if it shows the right voltage. Super easy quality control test. But all that needs to be written to a database. The database was hosted on a vm using a shared raid array of spinning disks. Their battery manufacturer process was literally gated by a slow ass disk drive. My buddy pointed this out. Asked that they just throw an SSD in there (we're working on it). Followed up, asked if he could just do it himself (no). Followed up a third time asking for the authority to fix the problem (no). Finally quit in disgust because they refused to solve a simple problem so how are they going to solve hard ones?

<comment><USER9> Was it limiting the testing in some way? In can't really imagine it was.

Changing working things in a critical phase of the core business without reason does not seem like a good idea.

I agree the setup seems bad and should be addressed, but if there are better things to do maybe do those first.

<comment><USER8> They had to slow down the robots so they didn't outpace the database. Slapping an SSD in a database increases write speed by 4X. They probably could have increased battery production by 15% for a total of $99. Slow database meant slow robot meant slow battery pack production meant slow car production. Replacing a working thing might be bad, but when your expert says your thing can be drastically improved with a trivial upgrade, you should do it. Especially if it's in the critical path of production. You can't know everything, but you can employ experts. But they can't help you if they're not empowered.

<comment><USER10> Was this a bottleneck to the end product? If at some point in the process there's a different bottleneck, I'd expect it to be reasonably construed as dangerous. That being said it sounds like an ownership problem. Red tape made from past fires (not the pink slip kind ) can easily become the real problem in a complex operation like this.

</comment></comment></comment></comment><comment><USER11> > It's looking more and more like the official reason for the layoffs - "…As > with any company, especially one of over 33,000 employees, performance > reviews also occasionally result in employee departures" \- doesn't hold > water.

Why not? If you can't find 2% dead wood at your company you're miraculously good at hiring or are not looking very hard. Stack ranking companies tend to use 5-10% as the bottom tier subject to "yank".

I'm not saying it is just performance reviews, because I have no more idea than whomever wrote the article what's really going on inside Tesla, but the idea that it couldn't make sense for a big employer like that to do a small round of firings doesn't hold water.

<comment><USER12> Stack ranking is stupid. Eventually you'll be firing good people. Idk why people think that Jack Welsh had good management practices or that GE is a company to aspire to.

If nothing else, GE has 300k employees. Your company probably doesn't.

<comment><USER4> "Idk why people think Jack Welsh had good management practices..."

 _Prior to Mr. Immelt GE was headed by Jack Welch. During his tenure at the top of GE the company created more wealth for its investors than any company ever in the recorded history of U.S. publicly traded companies. GE's value increased 40-fold (4000%) from 1981 to 2001. He expanded GE into new businesses, often far removed from its industrial manufacturing roots, as market shifts created new opportunities for growing revenues and profits. From what was mostly a diversified manufacturing company Mr. Welch led GE into real estate as those assets increased in value, then media as advertising revenues skyrocketed and finally financial services as deregulation opened the market for the greatest returns in banking history.

Jack Welch was the Steve Jobs of his era. Because he had the foresight to push GE into new markets, create new products and grow the company. Growth that was so substantial it kept GE constantly in the news, and investors thrilled._

That's why.

Source: [https://www.forbes.com/sites/adamhartung/2015/04/15/ge-a- tot...](https://www.forbes.com/sites/adamhartung/2015/04/15/ge-a-total- leadership-failure/#7a43845b5699)

<comment><USER13> Wasn't he disgraced for having a gold plated shower on his company jet?

<comment><USER4> No idea. Also, you may be using "disgraced" a little liberally here. Pretty sure Welsh is still held in extremely high regard in the business world.

<comment><USER13> Depends if you get caught the press and politicians can be brutal especially if the economy needs a whipping boy. See the presidents club furore in the UK some "well respected" business men are no longer held in such high regard.

<comment><USER4> Yes, but he clearly is held in high regard. So there may have been some dust up about that years ago, but no one really remembers or cares. I can't even find any reference to it, so you may be thinking of someone else.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> Anti union company finds workers need investing in.. Who knew?

</comment><comment><USER15> So layoffs in Fremont and Roseville are somehow causing Tesla employees at the Gigafactory to become less experienced?

[https://www.mercurynews.com/2017/10/13/4819750/](https://www.mercurynews.com/2017/10/13/4819750/)

Yeah... OK.

</comment><comment><USER16> Url changed from [http://media.thinknum.com/articles/teslas-production- plagued...](http://media.thinknum.com/articles/teslas-production-plagued-by- inexperienced-workers-after-they-laid-off-700/), which quotes heavily from this yet links not to it.

<comment><USER17> Hi, I'm the author of the piece in question, and, being a professional, of COURSE I linked to the CNBC article. Twice. When I introduce the CNBC material, in the first paragraph, and again when I introduced the (fully credited) blockquote. Just saying....

</comment></comment><comment><USER18> recent reddit post where an owner was on his second attempt to take delivery of a III [https://www.reddit.com/r/teslamotors/comments/7t0uul/inspect...](https://www.reddit.com/r/teslamotors/comments/7t0uul/inspect_for_major_panel_gapalignment_defects_at/)

the annoying part was the take it or leave it that they felt they received, apparently the first car was worse

<comment><USER19> Just take it to an independent third party repair shop.

<comment><USER20> That isn't possible for Teslas – Tesla does not offer manuals or replacement parts, and if a third-party is found to have modified the car, Tesla reserves the right to remotely disable it.

<comment><USER21> I thought that was illegal in the US? How exactly are they getting around the Magnuson-Moss Warranty Act?

<comment><USER15> It is illegal as far as I know, and I've never heard of Tesla remotely disabling a car unless it's been stolen.

The only thing I've read about is them not doing in-warranty repairs and/or recalls on salvage vehicles, but that's normal. They'll apparently recertify a salvage car for $3k-$6k though, if an owner really wants support.

</comment></comment></comment></comment></comment><comment><USER22> >Which leaves only one possible reason: the layoffs could only have been a Union-busting move,

Is that legal?

<comment><USER23> No. There are a number of open complaints about Tesla's union-busting efforts at the National Labor Relations Board.

But nothing's been proven yet and Tesla claims the complaints are "entirely without merit".

</comment></comment><comment><USER24> The author argues that they are not careful enough and not taking their time to fully inspect the battery packs, while saying that they should stop taking their time and ramp up the production already! Appears to me that she would blame Tesla either way.

</comment><comment><USER25> Elon Musk is spread out way too thin. He should never have bought SolarCity, and he needs to relinquish SpaceX entirely. He needs to be laser-focused on getting the Model3 out of the door because his whole company depends on it.

I think people are sensing a hell of a lot of weakness, and if Tesla starts running out of money, he could literally find himself and the company bankrupt, especially if banks stop lending money because it looks like a bad credit risk.

This feels like the type of company that could crumble down to single digits in stock value because of some catastrophic set of financial issues.

<comment><USER26> I'd rather Musk give up owning a car company than give up working on the most plausible near-term route for humans to enter low earth orbit that doesn't enrich the Putin cartel.</comment></comment>


Chrome username autofill extension - <AUTHOR> https://github.com/thepill/chrome-autofill-username/blob/master/README.md <comment><AUTHOR> a little chrome extension to autofill username inputs</comment>


Ask HN: Mozilla Firefox – Process Handling - <AUTHOR>

Believe firefox handles all user tabs as threads in a single process. please correct me if i'm wrong.
Wondering if it would switch to individual process from thread based approach.
Today one single tab hang renders FF not usable. Like keeping all eggs in one basket.
What do you guys think? <comment><USER2> Work is in progress; you can track it in [https://bugzilla.mozilla.org/show_bug.cgi?id=516752](https://bugzilla.mozilla.org/show_bug.cgi?id=516752)

<comment><AUTHOR> Glad to hear that. Thanks for your reply.</comment></comment>


Docker protects a programming paradigm that we should get rid of (2018) - <AUTHOR> http://www.smashcompany.com/technology/docker-protects-a-programming-paradigm-that-we-should-get-rid-of <comment><USER2> [https://www.google.com/search?q=ModuleNotFoundError%3A+No+mo...](https://www.google.com/search?q=ModuleNotFoundError%3A+No+module+named+%E2%80%98MySQLdb%E2%80%99)

In all seriousness he has half a point, but for the wrong reasons. Docker doesn't let you take your "old" languages and put them "in the cloud" over more superior approaches - it's a shipping container. That's it. It's a known quantity that lets you slot your 10,000,000 LOC Java monolith alongside your 25 line Python microservice and orchestrate them with the same tools.

That's the advantage. The side effect is, sure, you can take your old, shitty code and run it "in the cloud", and it's nothing "we should get rid of".

To put it another way: "Shipping containers protects a transportation method that we should get rid of". Sure, drones could fly every item individually to you from the factory, but while you're fiddling around with that Maersk is shipping 20% of the worlds GDP every year by dealing with what it knows best: how to move containers, not caring about what's in them.

<comment><USER3> There are many arguments I can think of for using docker but "standard" is a pretty poor one. Directories, bash scripts and package managers are also arguably "standard" and sufficient to install most software. We should care primarily about alleviating deployment pain - not about argumentum ad popularum.

"Shipping container standardisation" is not a metaphor for what docker is, it's _marketing_. Docker, of course wants to be a "standard" product. _Every_ product wants to be that.

In my experience, it's been more like a buggy kludge to deal with applications that have isolation issues with their dependencies and unnecessary overhead for applications that don't. All with a sprinkling of marketing hype.

</comment></comment><comment><USER4> So, someone who doesn't understands his tools blames the tools for the fact that somehow they need to keep using a language they don't like (and don't understand either, it seems).

Nothing of what he complains about is Docker's fault or even Python the language's fault.

Funnily enough, I have spend the better part of Friday trying to wrap my head around Go modules and getting a project to a state that I could run any go command in. Have I blamed Go, the language? Nope. The tooling? A little bit but mostly my own ignorance of how it works.

It would do the author good to do some soul searching and perhaps understand that not all problems are nails, where the best tool to deal with is a hammer.

<comment><USER5> I think the average Python practitioner does not know how to reliably build a Python environment. Like most languages, Python has footguns. Packages installed in a user's home directory are often visible in virtualenv or conda environment and defeat isolation. If your charsets are configured wrong, a single print() statement will crash your Python if Unicode characters are in play.

Python is being fixed at its foundations and tools like poetry will approach parity with Maven.

<comment><USER4> Python tooling is in a very sorry state in general. The language has drawbacks. What I wrote was not meant in defense of Python at all, but rather a criticism of what the author said about Docker and the fact that he expects it to fix his Python (or Ruby or Perl) woes.

He goes on to suggest that somehow these languages put the programmer closer to the OS than C, which completely ludicrous since most reference implementations of them are written in C - making the language effectively one layer above it.

I get the argument about concurrency but that's pretty much the only thing he has to offer there. Everything else is just someone who doesn't understand the tools blaming the tools themselves and wishing he was using something else.

The fact that he thinks "Docker is supposed to protect us" from dependency management issues is ludicrous.

</comment></comment></comment><comment><USER6> The author compares docker-based deploys to deploying straight on top of the OS. And looks at it from a "application programming" perspective.

I argue docker-based deploys should not be looked at from a "application programming" perspective, but from a "dev ops" perspective. It is docker vs puppet/ansible. Not docker vs akka.

To me docker is a big step fwd from provisioning OSes with puppet/ansible and deploying apps on top. I have a deployable unit that is accepted in many envs (k8s, aws ecs, roll-your-own), I keep more of the app-specfic code in the app's source code repo (instead of having some of it in puppet/ansible scripts), and we can use the same system locally (on our laptops) for development. And finally the configuration-by-env-vars convention creates a lot of clarity.

<comment><USER7> > Not docker vs akka.

I'm not familiar with akka, but I do see BEAM (the Erlang VM utilized by Elixir as well) as an alternative to docker swarm/kubernetes.

It requires stack homogeny of BEAM languages, but you can run distributed, concurrent, parallelized code with live debugging tools and "hot code reloading". I feel like the author's point is that docker and friends enable tools not meant for distributed/concurrent/parallel to be deployed in such a way. I could be mistaken and would be curious what you think of that argument.

I'm inclined to agree with the point in as much as docker can permit forcing a square peg into a round hole. On the other hand, being able to develop on *nix and deploy to weird editions of windows 10 had made me deeply appreciate docker.

<comment><USER6> > I feel like the author's point is that docker and friends enable tools not > meant for distributed/concurrent/parallel to be deployed in such a way. I > could be mistaken and would be curious what you think of that argument.

That's exactly the point I think the author fails on. Docker is not a tool to make your app distr/conc/parallel: and thus I point out that docker is merely a way to ship code. Not as a binary. Not with load of ansible/puppet scripts. But as a container (container spec + config as env vars).

<comment><USER7> I see what you're saying now, there's nothing about Docker or containerizing that promotes using the wrong tool for the job.

It just happens to be employed by other frameworks that make it easier to make that mistake.

</comment></comment></comment></comment><comment><USER8> > _consider two different companies. One spends the next 5 years committing to > those languages and eco-systems that have been built for the era. The other > spends the next 5 years using Docker so they can keep using script languages > from the 1990s. Now it is the year 2023, and a crisis happens at both > companies. Which of those two companies do you think will be more ready to > adapt to the crisis?_

Presumably the one that doesn't have to rewrite everything that they just wrote from scratch to avoid Docker.

<comment><USER9> > Presumably the one that doesn't have to rewrite everything that they just > wrote from scratch to avoid Docker.

I think that's too simplistic. Larry is right that a company who manages to survive 5 non-productive years rewriting everything in a "better" ecosystem will likely be in a better situation than the company trundling along with ever increasing technical debt.

The problem is that the conservative company without the major rewrite is more likely to make it through (at the least the first few of) those 5 years. So Larry's not wrong --- he just might be making some unwarranted assumptions.

<comment><USER10> > rewriting everything in a "better" ecosystem will likely be in a better > situation than the company trundling along with ever increasing technical > debt

So you believe that code with no-to-minimal history running successfully will be better than dated-but-proven code that has been running for over a decade?

<comment><USER9> There are good and bad ways to do such a rewrite. If the 5-years are spent completely isolated from the world, then no. But if the system has been used in live production for a couple years before the 5-years is up, then yes. I think "technical debt" is a really large hindrance, believe that even long lived systems are still full of hidden bugs, and would probably bet on the newcomer with a clean codebase if they can get far enough along to have a working system.

<comment><USER11> That really depends on quite a few other factors: how big is the team? What development methodology do they use? Does the leadership understand how to manage and direct a rewrite? Are there people that understand the full scale and scope of the system? Does the system interact with legacy components that can't be modified? Are there political factors in play? These are just a few of the questions that can change the outcome of any given rewrite.

You mentioned hidden bugs, but what about hidden "features" that may be a critical part of existing business processes for core parts of the company? Developers really like to believe they are at the center of the wheel due to the complex work they do, but a lot of the time they are not the ones that actually create the cash-flow.

I've been part of rewrites that have succeeded tremendously, but I've also been privy to utter failures that have cost millions, and led to entire teams getting sacked.

</comment></comment></comment></comment></comment><comment><USER12> His point about fat binaries is a good one.

After using languages with lots of dangling parts such as Java and Ruby, moving to Go was amazing on the deploy end.

With the dangling parts languages, you have a VM of some sort, and packages. All that stuff needs to be managed when you're building the app, _and_ when you deploy the app, _and_ when you maintain the app.

With a fat binary you only have to manage that once, and deployment becomes super simple. We actually put off using containers for quite a while because what's the point of putting a single binary into a container? There are reasons, but its much less compelling than if you have all of those dangling parts to manage.

<comment><USER13> Other than the JRE/JDK what other dangling parts does Java depend on? I mean installing the same JRE/JDK at both ends is hardly onerous.

<comment> half-kh-hacker If you don't shade libraries, I imagine managing a classpath can become quite difficult.

<comment><USER14> Does Go or other 'fat binary' languages have a better story for this? I know this is an issue for Java when dependency A wants X v1.0 and dependency B wants X v2.1 (incompatible), but not sure how using Go makes this any easier.

<comment><USER15> go modules allows v1.0 and v2.1 of a lib to coexist in a project because their import paths differ.

</comment></comment></comment></comment></comment><comment><USER16> I've been slowly developing the opinion that the emergence of Docker is in some ways a phenomenon of extreme JVM-envy. In between cracking jokes about "Write once, test everywhere" in Java the critics decided "yes actually all our languages suck at cross platform by the way so we are going to hack together a giant kluge so that we can just keep coding however we like and carry on". So while Java had deprecated environment variables because "Hey, you know one day someone might make a system without environment variables" they were re-inventing the JVM as the Linux kernel so that `/dev/stdin` will always exist and they can stop worrying that another OS will ever exist.

However I think this viewpoint misses some of the fundamental features of Docker that are nothing to do with platform independence and more about isolation, configuration management and orchestration. I would use docker and docker compose even if it could only run Java which is already cross platform. Because I love how it lets me map volumes, ports, orchestrate startup and shutdown with compose etc etc.

<comment><USER17> We're a 95% JVM shop and we've moved nearly all our apps to Docker now. For ease of devops, really.

</comment></comment><comment><USER18> Blaming docker for being able to package up an app so simply that even an app not suited for the cloud can be dockerized but not take advantage of the cloud is like saying you dislike Hydrogen because it's just too flammable. Be less flammable hydrogen!

<comment><USER19> It's like giving up water because hydrogen is flammable.

</comment></comment><comment><USER20> >>> ModuleNotFoundError: No module named 'MySQLdb'

On Py2 I think it's C compiled and that's always awkward - usually I forget to add python dev headers. Unless I use proper systems with "ports". start from the beginning or don't use py2 unless you really have a good reason.

On Py3 there is no mysqldb - they have not made the leap. so it sounds like the author got trapped in the 2to3 chasm. it happens to us all.

Problem is not docker- problem is not python. Problem is devops is hard and your personal eco system is only comfortable because you know where all the sharp bits are.

<comment><USER21> conda install mysql?

</comment></comment><comment><USER22> On a related note, some people seem to think anything that doesn't run in AWS Lambda or similar is out of date, legacy, not cloud native.

I think such absolute thinking is misguided and is low on fundamentals.

Same thing with people arguing over what is or is not a 'systems' programming language.

In the case of this article however, I think the author just dislikes python and docker.

</comment><comment><USER23> > Python programmers tend to spin up new processes, rather than using > something they consider ambiguous, such as threads.

Great generalization with no mention of asyncio?

> Myself and a friend just spent an hour trying to get a short Python script > running on an EC2 instance. We got stuck dealing with this error: > ModuleNotFoundError

Outdated dependencies, dealing with your distro's package manager, and specially understanding your package manager is vital, isn't it? But I guess it's easy to dismiss an ecosystem without fully understanding the problem.

> the dependency management in the Python community is so badly broken

You can choose to use pip as the package manager for system libraries.

python -m ensure pip # you won't use your distro's pip version pip install --user <your-package>

For apps, a virtualenv is sufficient?

I see no mention about C extensions, which is one pain point for packages. If the package doesn't have a pre compiled version[1], you might see a big red blob of text directly from the compiler when trying to link dependencies . This kinda sucks for a newbie but I guess a quick google search will tell you to do apt install python3-dev or something if you're using some debian based system like the author seems to be using.

[1] This pycon talk is a nice summary of the state of wheels and C extensions.

<comment><USER24> was there a link to the talk?

<comment><USER23> Yes! I forgot: "Elana Hashman - The Black Magic of Python Wheels" in [https://www.youtube.com/watch?v=02aAZ8u3wEQ](https://www.youtube.com/watch?v=02aAZ8u3wEQ).

The gist is that new binary wheels are being added, and it's a community effort.

</comment></comment></comment><comment><USER25> > What is Docker for? You can take your old Python and Ruby and Perl apps and > wrap them up in Docker, and thus those old apps can make the transition to > the modern world of cloud computing.

There's no reference to isolation with namespaces and cgroups.

> There are older, mature options, such as Java and C# and Erlang, and there > are many newer options, such as Go or Elixir or Clojure.

The JVM, BEAM, or Go process still needs to run on a machine and interact with an OS. They still need to be scheduled across thousands of machines that are constantly breaking. They still ought to be isolated from each-other when running on the same machine. There is nothing magical about these platforms that solves these problems.

<comment><USER26> _There is nothing magical about these platforms that solves these problems._

Sure, and you can solve those problems without docker or dockerfile hell.

<comment><USER25> Good point. The article didn't point out that Docker does have a valuable use case that as you say, can be solved in other ways.

</comment></comment></comment><comment><USER27> Docker format is a way of creating portable executable images, written in a wide variety of languages and based on a variety of operating systems, that run on a wide variety of servers.

There are more stripped-down ways to achieve that if you're willing to solve a less general problem. Something like gvisor [1] gets pretty far. In the limit, I'd guess the difference between an executable and a containerized app goes away?

[1] [https://gvisor.dev/docs/architecture_guide/](https://gvisor.dev/docs/architecture_guide/)

</comment><comment><USER28> I would have to disagree with the idea that Python is the main place where this is a problem. What about a system which needs to run multiple applications which require multiple JVM versions, for example? Or different versions of the .NET framework? My experience is that JVM developers use Docker just as much as any other ecosystem.

The idea that Kubernetes is somehow a symptom of bad dependency management seems to miss the point of Kubernetes - to allow multiple systems to be modeled as a pool of computing resources. One could image a Kubernetes that runs 'fat binaries' instead of containers and still be useful. In fact, that may be possible to implement within Kubernetes with a simple extension given how flexible it is.

> Developers who write Scala are in love with Akka, which appears to be very > good.

Nitpick: Akka is very far from universally loved in the Scala community. Most Scala devs I know would rather use Kafka for cross-system message/event processing, and something lightweight like Monix for parallelism and concurrency within a process (you can also simulate Actor-like behavior with Monix if you want)

EDIT: there's some kind of addendum at the end about base images where it looks like they are A) pulling straight from Dockerhub (a huge no-no from a security viewpoint) and B) not using tags right. Irrespective of how much you like or dislike a certain tool, not taking the time to learn the best way to use it is going to cost you more time in the end.

</comment><comment><USER29> Therr are three ways of deploying a program. Either you install it globally, you ship it in a folder which includes it's dependencies or you ship it inside an archive format (everything is in a single file).

Docker three things at once. It's a container image format, a way to build images that follow this format and a way to run those images as containers. Therefore docker images are just giant fat binaries.

What the author seems to miss is the fact that a lot of languages need not only an archive that contains all dependencies but also an environment to run those archives like a JVM or a python interpreter, maybe even both at once. And this is the part were docker comes in. You split your Dockerfile into two stages. First you run the build stage which includes all development tools needed to build your software and generate your language specific archive, then copy it over to the next stage which only installs the bare minimum to run the software.

There is one fatal flaw here. If fat binaries don't install their JVMs or python interpreters then docker containers don't install their container runtime. So you will again need to up one layer and use an automated tool to install docker or kubernetes.

Oh I forgot to mention the solution to the JVM+python problem in the same Docker container. Well it's pretty easy. In the build stage you just tell pip to install the dependencies into the libs folder of your application instead of the global folder then you just create a bash script that sets the PYTHONPATH to your libs folder and passes cli args to the python script. That way you don't need pip in the final stage of the dockerfile.

</comment><comment><USER30> I'm glad the author left the part about never having dependency issues with Java projects to the very end (to be fair, saying it is nothing like python issues might be true, I don't use python). I would have stopped reading if that had been at the beginning. My highest ranked stack overflow question (with 100k views) has to do with dependency management on Android. It's a problem everywhere.

I do think this article has some interesting points.

<comment><USER31> There are dependency problems in ALL languages. I think the point of the article is that with Java/Go/Rust/Node you can create a single file and deploy it on 100s of VMs without having to worry about dependencies during deployment. The same has been done for years with WARs and EARs.

But, he misses the main point of Docker (or LXS for that matter) which is to scale/downscale & maintain a massive amount of VMs.

I worked at the time where we had 16 or 64 servers (not VMs), running several instance of Weblogic/Jboss. Each deployment took hours and we didn't have any elasticity on the number of servers/instances (each server could run X instances of Jboss) to scale up/down. If we hit the max, management bought another server and that's it. Oh, and every deployment meant downtime, because we couldn't do the crazy stuff Docker allows.

</comment></comment><comment><USER32> The thing is, fat binaries don't really solve the problem; Java and Go have just as many problems with this as python does because you're still depending on the OS. Your java app might still depend on a service running on the OS, or a system level configuration (hosts files, etc), or a JNI interface to a C library.

To me, Docker is a tradeoff: you're trading disk space and a little bit of efficiency for removing a TON of variables. Given that I have zero interest in debugging servers, that's a great win for me. YMMV. But if you have to potentially deal with thousands of servers, it seems like an obvious choice (excluding otherwise using something like a VM).

The JVM may have promised "write once run anywhere", but that's never really been particularly true. You've only ever really gotten that with an actual VM, and those are much heavier than Docker is

<comment><USER26> _Given that I have zero interest in debugging servers_

You're going to have to debug _something_ , even with Docker. I still have nightmares about the Docker 12 rollout.

 _The JVM may have promised "write once run anywhere", but that's never really been particularly true. You've only ever really gotten that with an actual VM, and those are much heavier than Docker is _

Which is to say that you don't get "write once run anywhere" with Docker either. In x86 land you'll still have differences (some more serious than others) between Docker on Linux, Mac (that still runs under a Linux VM, with all the networking hell that entails, right?), and Windows.

</comment></comment><comment><USER33> Robust concurrency options for python exist that are not Docker-based (e.g. Celery). Even basic "fork" calls are cheap on UNIX (and wrapped with the multiprocessing package for cross-platform use). Package managers like Conda make multi-platform deployment with dependency binaries easier on Python.

Frankly Python is still catching up to many improvements that have happened in the 2000s. That said, if you want to avoid using Docker as a packaging kludge for Python, it's possible to do so in many cases.

</comment><comment><USER34> I think there's a few misconceptions here, but I also think I kind of agree with the general point.

First, yes, Docker is a hack to make a fat binary. But that's not the only reason people use it. People use it because it's easier than packaging _and_ running their app "the right way". Running 10 fat binaries all listening on the same TCP port and IP won't work. Even if your 10 binaries all co-exist on the filesystem just fine, you still need to run them in a way that won't conflict. You can do that without Docker, but Docker makes your life easier, so people use it.

Second, concurrency frameworks don't make your life easier, they make it harder. It's a language-specific abstraction that you have to design your app for. You _should_ be able to just call fork() and join(), or listen() and accept(), and have some OS-level, generic component handle the concurrency for your app. This is not a failing of the language, but a failing of the OS.

And if you're going to rag on the industry, target the lack of standards. "Integration" is the opposite of standardization. The fact that I have to re- write 10 layers of glue to make some shitty web app run on AWS versus Azure is frankly one of the stupidest things I've seen in my career, but it makes sense when you realize all this tech was written by small departments in companies who don't give a shit about standards. Why spend time on interoperability for a product that only _needs_ to work with one thing, right now?

You should be able to just call one function call in any app, and your runtime should communicate with a language-agnostic ABI for anything needed to route communications between a service broker and the code being executed, including changing the location the computation is happening on. And executing _any_ application should allow you to include some isolation guarantees, because _any_ application can have interoperability problems with other components running on the system. Containerisation is, I believe, the only thing besides Jails that has attempted to do this.

And if we're serious about microservices, why do specific clusters need to live behind a dozen levels of security groups, load balancers, VPCs, etc that all have to be custom crafted before we can even run an app in a specific region? That's a shit load of state surrounding a supposedly stateless service.

I think k8s is in some ways a response to all this, but it's still a poorly designed hack that enslaves itself to traditional OS models. What we _really need_ are distributed operating systems. But just like we will never retrofit our highways with electric tracks for self-driving electric cars, we will never begin to upgrade the OS to be more standard, automated, and distributed. Instead we'll just push more shit into the app layer. Browsers now implement their own TCP/IP stack, and nearly all modern apps support encryption without ever allowing the OS to handle it. We're just too damn lazy to tackle anything but short term goals.

<comment><USER35> > And if we're serious about microservices, why do specific clusters need to > live behind a dozen levels of security groups, load balancers, VPCs, etc > that all have to be custom crafted before we can even run an app

That's the difference between IaaS and PaaS. If you don't want to deal with custom infra, go with heroku or platform.sh rather than AWS.

<comment><USER35> I'm really curious about the downvotes. We've got PaaS options which get rid of all that extra management for you. The configuration of networking and the details of load balancing will always exist at some level. Which layer you choose to interact with is your completely your choice at this point. (Although the more details you want to control, the more you have to do yourself) Many PaaS solutions are great for microservices and give you that nice "from the repo to live production" workflow.

What do people actually disagree with here?

<comment><USER34> Oh, it's that many businesses (and all Enterprises) just can't often use PaaS. You need to deal with regulations, customers who want you to retain tight control of data, private links back to corporate networks, SSO, IAM, support and availability contracts, NDAs, code quality gates, security scanning, policy auditing, dedicated performance guarantees, microservice ecosystems, network access control for partners, overall cost. And as far as "lock-in" goes, you can't get much more locked-in. Enterprise won't even use hosted CI/CD [unless it's for an open source product/service]. You have to fit a very specific niche to be Enterprise-compatible.

<comment><USER35> I don't buy it. If you're an enterprise which needs a PaaS but policies prevent an external one, then you build an internal one. HP did it. Oracle did it. I'm sure others do it too. This still doesn't prevent millions of non- enterprise companies from using it.

If you don't want to create something from scratch you can even use ready solutions like Flynn.

<comment><USER34> Well first of all, I'm not the enterprise :) They are fiiiiiiiine with building from scratch. They love building rocket ships when they really just needed a wheelbarrow. It's kind of a problem.

My point is more like, a lot of the time we don't need a PaaS, we just need to do less "integrating", if cloud providers all implemented the equivalent of Terraform providers. But going further, that we shouldn't need to use K8s if the operating system came with similar functionality and exposed it as an ABI.

All these things would let you "build from scratch" distributed parallelized network services, with a lot less layers of technology, in a more standard way. Rather than building a spaceship just to run errands, we could be cruising around on city rental bikes, or golf carts, or something. This comparison might have gone off the rails.

</comment></comment></comment></comment></comment></comment><comment><USER36> Pinning the blame on python is misplaced. The real problem is that C dependency management is pure hell, and that makes building native modules for scripting languages (like, say, database drivers) horrible. Dockerfiles are great for providing the right environment for building all your sloppy C stuff.

</comment><comment><USER37> I haven't seen much docker used with python? I thought it was mostly a nodejs/java thing...

I am mostly a python dev though. I may have just ignored the docker option when presented with a python project, but used it for those other languages.

<comment><USER38> Wait until you need to deploy to a platform that doesn't have a precompiled version of a dependency uploaded to PIP. Docker shines in that regard.

<comment><USER37> I thought that's what wheels were solving?

</comment></comment></comment><comment><USER39> Author is trolling, not taking the bait. There are no useful arguments made in support of the title.

</comment><comment><USER40> Sigh. The author neglects to mention Zappa or Chalice, which kind of blows down the historyonic soapbox.

</comment><comment><USER41> Can someone post a TLDR?

<comment><USER42> The author dislikes both Python and Docker. But mostly Python.

For the reasons why, see the article (you can safely skip the first two paragraphs). The biggest gripes are concurrency and package management.

</comment></comment><comment><USER43> This is an exceptionally well written essay on technical debt and scope creep.

But most of all, I found the definition of "conservative" so apropos to politics (accidentally, surely) that I both laughed and cried.

<comment><USER44> I think you have the direction of that mixed up. The definition of conservative in this article _is_ the political definition of conservatism.</comment></comment>


EdgeML: Algorithms for edge devices - <AUTHOR> https://github.com/Microsoft/EdgeML <comment><USER2> Edge devices are what MS is calling IOT devices on cloud networks, I think:

[https://blogs.microsoft.com/iot/2017/05/10/microsoft- azure-i...](https://blogs.microsoft.com/iot/2017/05/10/microsoft-azure-iot- edge-extending-cloud-intelligence-to-edge-devices/)

<comment><USER3> I used to work at a company whose software had to interact with security cameras. In the security/surveillance industry, at least, the term 'edge devices' has long been used to describe IP cameras and other devices like motion sensors operating in the field, transmitting their data back to a central server.

Interestingly, 'edge analytics' has been a thing in that industry for a relatively long time, too. This is used to refer to cameras that do things like motion detection, person counting, and other analytics in the camera instead of having to post-process the video streams at a central location to extract that data.

So in this case at least, is looks like MS is just using terminology that was already widely used in IoT devices even before "Internet of Things" was even really a phrase that was used to describe these devices.

</comment></comment><comment><USER4> This is a neat project and having this framework could really address two things.

1\. If we bake all the intelligence on the device then it won't have to go outside to a network which could increase security.

2\. If the intelligence is on the device then the users could control their data better.

</comment><comment><USER5> I assumed Microsoft EdgeML was related to Microsoft Edge browser...it is not. It sounds like and "edge device" refers to an IoT device.

</comment><comment><USER6> What is an Edge device??

<comment><USER7> _" The trained models can be loaded onto edge devices such as IoT devices/sensors, and used to make fast and accurate predictions completely offline."_

Then, from: [https://www.microsoft.com/en-us/research/project/resource- ef...](https://www.microsoft.com/en-us/research/project/resource-efficient-ml- for-the-edge-and-endpoint-iot-devices/)

 _" Our objective is to develop a library of efficient machine learning algorithms that can run on severely resource-constrained edge and endpoint IoT devices ranging from the Arduino to the Raspberry Pi."_</comment></comment>


Yet another blockchain explanation after 2 years of fining - <AUTHOR> https://medium.com/@hllozercan/what-is-blockchain-fa79e8119ecc <comment><AUTHOR> Hi HN! This is my first technical blog experience and I would love to have a feedback. If you have any questions to add unexplained details(I'm sure there are a lot), I will try to answer as much as I can.</comment>


Clear Linux Project - <AUTHOR> https://clearlinux.org <comment><USER2> Just what we need a Linux distro who's main goal is apparently to promote Intel products. The language used to describe it makes this quite clear. "The goal of Clear Linux OS, is to showcase the best of Intel Architecture technology...". This is a blatent attempt to exclude ARM who is gaining Linux market share. Whatever innovation they might bring to the table, I will avoid it purely on the basis that its aim is to benefit Intel rather than the user. Dot org my ass.

<comment><USER3> The site is weak but you should check the LWN link given in this thread. They have done some cool stuff actually.

</comment></comment><comment><USER4> One issue where "pure" containers have an advantage over VMs is IO.

For network intensive workloads, there is a choice between the efficiency of SR-IOV and the control & manageability of a virtual NIC like virtio-net. In order to get efficiency, you need to use SR-IOV, which (the last time I checked) still made lots of admins nervous when running untrusted guests. Sure, the guest could be isolated from internal resources via a vlan, but it could still be launching malicious code onto the internet, and it may be difficult to track its traffic for billing purposes, especially if you want to differentiate between external & internal traffic. SR-IOV NICs also have limited number of queues and VFs, so it is hard to over-commit servers. So in order to maintain control of guests, you end up doubling the kernel overhead by using a virtual NIC (eg, virtio-net) in the VM and a physical NIC in the hypervisor. Now you have twice the overhead, twice the packet pushing, more memory copies, VM exits, etc.

The nice thing about containers is that there is no need to choose. You get the efficiency of running just a single kernel, along with all the accounting and firewalling rules to maintain control & be able to bill the guest.

<comment><USER5> SR-IOV should not really make you nervous, it uses the iommu. Billing might have some issues I guess.

There are higher performance virtual network setups eg see [http://www.virtualopensystems.com/en/solutions/guides/snabbs...](http://www.virtualopensystems.com/en/solutions/guides/snabbswitch- qemu/)

Container networking has overheads, the virtual network pairs and the natting is not costless at all, and most people with network intensive applications are allocating physical interfaces to containers anyway.

</comment></comment><comment><AUTHOR> LWN got an article about it... [https://lwn.net/Articles/644675/](https://lwn.net/Articles/644675/)

<comment><USER6> Public link: [http://lwn.net/SubscriberLink/644675/5be656c24083e53b/](http://lwn.net/SubscriberLink/644675/5be656c24083e53b/)

<comment><USER7> Is it bad to send an LWN Subscriber link to a large number of people? Will they get upset? They mention that they'll remove the feature if it gets abused.

<comment><USER8> From [https://lwn.net/op/FAQ.lwn#slinks](https://lwn.net/op/FAQ.lwn#slinks):

"Where is it appropriate to post a subscriber link? Almost anywhere. Private mail, messages to project mailing lists, and blog entries are all appropriate. As long as people do not use subscriber links as a way to defeat our attempts to gain subscribers, we are happy to see them shared."

</comment></comment></comment></comment><comment><USER9> How they purport to do packaging is interesting, but I'm not sure it will work well in the end. Having "bundles" that contain immutable sets of packages sounds good from a stability point of view, but unless they are entirely self contained, you'll undoubtedly run into a library that you need to updated for one bundle that then forces you to update another entire bundle. If each bundle is entirely self contained (allowing it to have it's own set of libraries), you're essentially recreating what's a static binary through package semantics. This comes with the usual downsides of static binaries.

I'm interested in seeing it tried though. The learning is in the doing.

<comment><USER4> Self contained packages are not a new idea. For example, PC-BSD has been doing this for years, via their PBI package format. See the description of PBI here: [http://www.pcbsd.org/en/package-management](http://www.pcbsd.org/en/package- management)

I think PBI does de-duplication at the package manager level by manipulating hard-links to common files, rather than installing multiple copies.

<comment><USER10> > I think PBI does de-duplication at the package manager level by manipulating > hard-links to common files, rather than installing multiple copies.

Which is, itself, a bad reinvention of Plan 9's Venti filesystem. Having one, or two, or a million files on disk containing the same data should take up as much space as having just one. "Hard links" are a policy-level way to express shared mutability; deduplication of backing storage, meanwhile, should be a mechanism-level implementation detail.

<comment><USER11> ZFS has support for block-level deduplication and it comes with heavy memory and performance requirements. File-level deduplication with hard links is lightweight and requires no special support (besides a filesystem which supports hard links, obviously).

</comment></comment></comment></comment><comment><USER12> I just tried it. it _is_ fast.

its a VM really, but packaged like a container. On my laptop, it starts about as fast as a Docker container, ie less than a second.

This is quite impressive.

<comment><USER13> I'm not so sure that running a container is directly analagous to using it in a VM.

<comment><USER12> While namespacing allows you to do various things, most container setups are vm-replacements, running either full OS or not, they're used for the same purpose in the end (ie resources separation)

<comment><USER14> > most container setups are vm-replacements, running either full OS or not, > they're used for the same purpose in the end (ie resources separation)

No they are not. A VM is a completely different system, while a container is a packaged application.

VM's provide an awful lot more than just resource separation... security and isolation being at the top of the list.

The problem we see here is an awful lot of people think a container is a drop- in replacement for a VM, when it is usually not.

<comment><USER15> > No they are not. A VM is a completely different system, while a container is > a packaged application.

I think you have a misunderstanding of terms here, possibly confused by all the fuzz around Docker. A container is nothing more then a virtualization technology on OS level[1]. What you are talking about is something like rkt, which is how to run an app inside a container[2]. From the point of your app there is no difference between a VM, OpenVZ or LXC.

[1] [https://en.wikipedia.org/wiki/Operating-system- level_virtual...](https://en.wikipedia.org/wiki/Operating-system- level_virtualization)

[2] [https://github.com/coreos/rkt/blob/master/Documentation/app-...](https://github.com/coreos/rkt/blob/master/Documentation/app- container.md)

<comment><USER14> > What you are talking about is something like rkt, which is how to run an app > inside a container

Rocket, and Docker, yes.

> I think you have a misunderstanding of terms here, possibly confused by all > the fuzz around Docker

I agree Docker has spread a lot of FUD, causing great confusion about what Docker can do, but also what containers are.

> A container is nothing more then a virtualization technology on OS level[

Not quite. A container was intended to be the first (for linux) truly portable application. You create an application, "containerize" it, then you can run that application on any system with minimal effort (Ubuntu app running on CentOS, etc).

Containers are not virtualizing anything, and that is the entire point. They remove the virtualization/emulation overhead of a hypervisor and instead run your application at native speed on the native system.

Docker has tried to make a do-all application which then provides process isolation and other things to add "Security", but at the end of the day, an app running in a container on your system can still negatively impact other containers and/or the host OS (if your container needs to read/write to /etc for example).

In a VM, everything is isolated because it's literally it's own OS running on (what it thinks is) it's own hardware. An app can destroy the VM, or the VM can be exploited, but nothing outside the VM can be effected.

Xen/KVM have zero comparison to things like Rocket, and Docker.

<comment><USER15> > Containers are not virtualizing anything, and that is the entire point.

What is it when a process sees a different process tree, different filesystem tree, different network then the host?

[http://man7.org/linux/man- pages/man7/namespaces.7.html](http://man7.org/linux/man- pages/man7/namespaces.7.html)

<comment><USER14> As the link you provided states, it's called Namespacing.

> A namespace wraps a global system resource in an abstraction thatmakes it > appear to the processes within the namespace that they havetheir own > isolated instance of the global resource. Changes to theglobal resource are > visible to other processes that are members ofthe namespace, but are > invisible to other processes. One use ofnamespaces is to implement > containers.

Virtualization via hypervisor does a lot more than just namespace isolation.[1]

> The basic idea behind a hypervisor based virtualization is to emulate the > underlying physical hardware and create virtual hardware(with your desired > resources like processor and memory). And on top of these newly created > virtual hardware an operating system is installed. So this type of > virtualization is basically operating system agnostic. In other words, you > can have a hypervisor running on a windows system create a virtual hardware > and can have Linux installed on that virtual hardware, and vice versa.

> So the main basic thing to understand about hypervisor based virtualization > is that, everything is done based on a hardware level. Which means if the > base operating system (the operating system on the physical server, which > has hypervisor running), has to modify anything in the guest operating > system(which is running on the virtual hardware created by the hypervisor), > it can only modify the hardware resources, and nothing else.

[1] [http://www.slashroot.in/difference-between-hypervisor- virtua...](http://www.slashroot.in/difference-between-hypervisor- virtualization-and-container-virtualization)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> After reading the overview and features, I'm left wondering:

* what tangible benefits would I get from using Clear Linux over my own heavily customized/handrolled linux server?

* how does the update system handle breakage/conflicts?

* are any of Intel's changes likely to make it into other existing distros or kernels?

<comment><USER17> This was linked elsewhere in the comments. I think it answers some of your questions:

[http://lwn.net/SubscriberLink/644675/5be656c24083e53b/](http://lwn.net/SubscriberLink/644675/5be656c24083e53b/)

</comment></comment><comment><USER18> I just tried on my desktop, woot it's super fast!

[ 0.000000] KERNEL supported cpus:

[ 0.000000] Intel GenuineIntel

[ 0.000000] e820: BIOS-provided physical RAM map:

...

[ 1.245851] calling fuse_init+0x0/0x1b6 [fuse] @ 1

[ 1.245853] fuse init (API version 7.23)

[ 1.246299] initcall fuse_init+0x0/0x1b6 [fuse] returned 0 after 431 usecs

<comment><USER19> Anyone know what they might be doing for the speed increase?

<comment><USER20> Seeing as it's Intel I might guess that they either have extra instructions in the instruction set they know about or other optimizations that they know to look for. Seeing as they only support 4th generation and E5 v3... it wouldn't surprise me.

</comment></comment></comment><comment><USER21> i wonder if it builds with icc? seems like a matter of pride they should get that working.

<comment><USER22> that was my first guess at "how'd they make it faster?" icc is sometimes a shockingly better (read: compiled code that is faster) compiler.

</comment></comment><comment><USER23> I dont quite understand what this is: Is it a linux distribution that can have a graphical interface like Gnome 3? My question is essentially: Is it more like Ubuntu or more like Docker?

<comment><USER24> More like CoreOS

</comment></comment><comment><USER25> Would very much like to see a comparison of Clear Containers and LXD. Would also like to know why Intel decided to do their own thing and not just help with the LXD project.

</comment><comment><USER26> Unless I am not getting something, are the developers expected to manually compile everything that isn't in a bundle?

And then recompile again whenever a bundle gets updated?

</comment><comment><USER27> Correct me if I'm wrong but shouldn't 'Cloud' have a lower case C if it's not a product?

</comment><comment><AUTHOR> I didn't find very mutch information about it.. yet. :( anyone played with it?

</comment><comment><USER28> Download link didn't work for me in firefox for some reason, had to paste the link:

[https://download.clearlinux.org/](https://download.clearlinux.org/)

</comment><comment><USER29> I am surprised they didn't go down the container route for OS updates like CoreOS. I think I like that approach.

<comment><USER30> This does use containers and in fact they have some interesting modifications that they have made to the rkt container runtime to use KVM isolation instead of just namespaces and cgroups. See a link in 4ad's comment for an LWN article.

Those modifications are exciting for me as one of the developers of rkt. We built rkt with this concept of "stages"[1] where the rkt stage1 here is being swapped out from the default which uses "Linux containers" and instead executing lkvm. In this case the Clear Containers team was able to swap out the stage1 with some fairly minimal code changes to rkt which are going upstream. Cool stuff!

[1] [https://github.com/coreos/rkt/blob/master/Documentation/deve...](https://github.com/coreos/rkt/blob/master/Documentation/devel/architecture.md)

</comment></comment><comment><USER31> Would be cool if it built with ICC, like the old Linux DNA project.</comment>


Open your terminal and type: telnet towel.blinkenlights.nl - <AUTHOR>

Open your terminal and type: telnet towel.blinkenlights.nl <comment><USER2> Try pasting telnet://towel.blinkenlights.nl into the location field of your browser.

</comment><comment><USER3> Just for a little backstory to the guys who created this.. they've also made:

A bender beer brewing kit

<http://www.asciimation.co.nz/bender/>

and the "jet powered beer cooler"

<http://asciimation.co.nz/beer/>

</comment><comment><USER4> This must require an unbelievable amount of patience.

</comment><comment><USER5> Kind of makes me want to play a MUD

</comment><comment><USER6> Nice.</comment>


Sick of Ruby, dynamic typing, side effects, and object-oriented programming - <AUTHOR> https://blog.abevoelker.com/sick-of-ruby-dynamic-typing-side-effects-object-oriented-programming/ <comment><USER3> Programming is hard. A few years back, in the 90's when most of the code in my field was still mostly structured, and bad at that, a lot of people were saying that OOP would sort it out. I was skeptical, not because I'm resistant to change, but because it was obvious to me that doing OOP right was (and is) very hard. Not that structured programming was easy.

Fast forward to today: programming is still hard, and actually it probably got a lot harder. OOP did not sort it out. Most of the code in my field is object- oriented, and bad at that. A lot of people are saying that FP will sort it out. I am skeptical, not because I'm resistant to change, but because it is obvious to me that doing FP right is (and will be) very hard. Not that object oriented programming is easy.

Am I alone in thinking that fast forward a few years, once there is enough rotten FP code written, we will be reading people ditching FP because it's the root of all evil?

The facts are that programming is hard. Working with legacy code is hard. Learning a paradigm well enough so the code you write in it is not total crap is very hard, and requires years of practical experience if you are proficient at another paradigm, let alone if you simply skimmed a paradigm and moved away because it was too hard...

It's great that people want to move on from single-platform, single-paradigm monocultures, with one caveat: breadth without depth is shallowness.

I'd like to read people treating languages and platforms as tools and not as cargo cults. You don't read carpenters writing they'll ditch hammers for screwdrivers because the old cupboard they are fixing uses nails. You read carpenters debating the pros and cons of using hammers versus screwdrivers. And you read better carpenters that debate how cupboards are designed, because it is ultimately more important than whether they are glued, nailed or screwed.

<comment><USER4> What I 'love' about object-oriented programming is that every other year there is a new pattern or paradigm that is shoved down our throats by opinion leaders and self-proclaimed OO-gurus. These architectural patterns all make sense on the surface but by the time people try to apply them in real life and realize that they are mostly a load of horse shit, the instigators have already moved on to the next "big thing". And this pattern is repeated ad infinitum.

<comment><USER5> The problem is that the pattern that are being discussed ( or a pattern in general, that's far from limited to OO ) are applied by a team of dedicated developer, combing the code meticulously, generally with near-limitless budget.

You read the story about how Linked In, Facebook, LMAX and you dream of applying that.

That won't work. Those companies decided to go with their current infrastructure after their previous one failed miserably and threatened their billion making core business.

Real life for most developer is a lot duller. Very often you will have barely enough to do what need to be done. Consistency, code gardening is difficult to justify a budget for until the house is on fire. No matter how good the pattern you use, the code will be shit if you don't have time to maintain it properly.

</comment></comment></comment><comment><USER6> The title "I'm sick of object-oriented programming" is misleading. The author is sick of their work with Ruby and the fact that it is OO is one amongst several complaints.

I use a mixture of OOP and FP day to day (mostly with the Java/Scala/Clojure family) and have to say that both have their place. In large projects I appreciate OO design patterns for clarity and flexibility (though maybe that is just because it is what I'm used to), and FP's mandate on immutability for the same.

Finally I have grown to whole heartedly share the author's dislike of dynamic typing. I find Scala, not its more "pure" FP cousins Clojure and Haskell, to provide the most productive balance of the above.

Anyone else like me: tried both and ended up walking the middle road?

<comment><USER7> I used to code a lot of Python earlier. After some time I started learning Haskell, Scala and Clojure. Finally I ended up sticking up with Haskell becomes of it's strong type system and ability to reason the code by just seeing the types. And now when sometimes I write code in a dynamic language, I must say that I write it more neatly.

</comment></comment><comment><USER8> Ok, I get it. Mature Ruby codebase sucks. Integer division changes are surprising. But what does it have to do with object-orientedness?

> break functionality into lots of small objects > use immutabile objects as > much as possible (e.g. using thin veneers over primitives or adamantium)

are the guidelines that I'm using in C#.

> separate business logic into collections of functions that act on said > objects (service objects) minimize mutation and side effects to as few > places as possible

How does separating out functions minimize mutation?

> thoroughly document expected type arguments for object instantiation and > method invocation with unit tests (mimickry of a static type system)

Yet another argument for static typing...

<comment><USER9> The point is that OOP was introduced so people could continue coding with globals (i.e. states), where the globals now lives inside different namespaced containers instead the global container.

The effect is still the same though, your code is just the same old Rube Goldberg machine.

</comment></comment><comment><USER10> The problems exposed by languages like Ruby are not necessarily problems with dynamic types. For example you can do reasoning about purity, side-effects and whatnot in languages of the LISP family as well. Clojure for example is much, much saner than Ruby in all the points listed by TFA - static typing is for example by definition anti-modularity and anti-adaptability and note that I prefer static typing over dynamic typing and Scala over Clojure. On the issue of static versus dynamic one has to view this as a different school of thought and to apply one versus the other depending on the needs of the project.

Uncontrolled side-effects are the real issue behind most of the accidental complexity that we are seeing. We all badly need to adopt more abstractions and techniques from functional programming.

Also, changing languages or idioms doesn't necessarily help with the exposed problems. We also need a change of mentality in how we are doing software development. Lets face it, when we need to do something right now, urgent, that should have been done yesterday - no matter the language, no matter the abstractions or idioms involved, we are bound to do stupid shit - <USER2> there's accidental complexity and then there's inherent complexity and nothing saves you from inherent complexity other than thinking really well about the problem at hand and splitting it into simpler, more manageable parts.

This is also why TDD is a failure and complete bullshit in how it is advertised. Tests don't save you from doing stupid shit. Tests don't tell you whether your architecture is any good, they only tell you if your architecture is testable. Tests don't prove the absence of bugs, they only prove their presence. Tests only tell if you reached a desired target, not what that target should be. And perhaps most importantly since this is touching the core of their purpose, when uncontrolled side-effects are happening in your system, tests are a poor safety net - anybody that had to deal with concurrency issues can attest to that.

Agile methodologies are also trying to paint a turd. Yes, we should deploy or publish as soon as we've got something to publish. We should pivot a lot. We should communicate more with the end-users or within the team. And so on and so forth. But it's an indisputable fact that some problems are hard enough that they can't be solved by puking code and tests in a matter of hours or days, or by adding more people to the team.

<comment><USER11> > This is also why TDD is a failure and complete bullshit in how it is > advertised. Tests don't save you from doing stupid shit.

Why do people think tests are for that? Tests are basically same as free climbers safety lines. They won't protect you from everything and sure they are tedious to place, but once they save your tush, you'll be glad they were there, and you weren't splattered across the floor.

I've seen lack of tests in practice and it's not pretty. Nope. Not pretty at all. Basically lots of entangled undocumented, untested systems that you can't refactor because your refactor just broke some code somewhere.

To demonstrate some of the bugs, if you accidentally type your username wrong, the whole server crashes and resets. It was not pretty.

<comment><USER12> "you can't refactor because your refactor just broke some code somewhere" \- picking a language that is not matched with first-class automated refactoring (ReSharper, IDEA) was their first mistake (rather than lack of unit testing).

<comment><USER13> Renaming stuff and pushing variables around is not refactoring. It's just some editing work.

<comment><USER14> You'd be surprised what transformation modern IDEs can do that IS refactoring, not just renaming and pushing variables around.

Plus, you're wrong: a lot of refactoring is also about renaming stuff and pushing variables around. You don't always have to rewrite everything in new hierarchies and patterns in order to do a refactor.

<comment><USER13> Renaming, pushing variables, changing their types, stuff like that. It's still editing work. Can any IDE split the class into two according to methods' responsibilities? Can it abstract a set of functions to a single generic function? Can it get rid of unnecessary boilerplate code scattered around in various classes? Can it change data structures used to store data?

Because refactoring is about making the code _simpler_ and _more flexible_. Rearranging that IDEs do is only a method (and not the only one) to achieve that.

</comment></comment></comment></comment></comment></comment><comment><USER15> I inherited a 6 y/o rails codebase and I worked on it for 6 months straight. I am usually against rewriting things, but this is like going into one of those abandoned houses and pulling off layer and layer of crap to find more termites, cockroaches etc. Every time I had it 'working', I found all kinds of weirdness, usually do to with forked GEMs to the old dev his personal github, which where not only old/ancient but had stuff bolted onto them so they could not be upgraded in any way.

So rewriting now... In F# (and C# where handy). I like Ruby but for projects like this I have seen it fall over too often; most Rails dedicated companies I know deliver great projects but they don't have to do long term support. I would like to see how that would work out as I see companies in the wild struggling to find devs _willing_ to support their codebases. This is not a gripe with Ruby/Rails per se, but (in my experience!) Python programmers who do large Django (or other frameworks, but I encounter mostly Django) projects are more disciplined so less goes haywire, there are too many people who can do JS, so you'll always find people willing to work on your crap. Ruby is in a niche but popular spot; hard to find coders, some coders are not so good and yet enormous projects are created in it.

</comment><comment><USER16> I get this periodically. I have to walk away and go and do something else for a bit before I go nuts. This is usually after debugging some patternitis rats nest that is completely over-engineered.

However occasionally amongst the muck, a beautiful and elegant thing pops out and makes it all OK. This event is getting rarer for me as our product evolves though.

</comment><comment><USER17> The older I get, and the more I watch and help programmers (including programming myself), the more I believe this is an OO/mutability problem.

We created OO, at least the C++ version, in part as a way to create boxes of code -- a reusable module system. But what happened was that we created a huge stinking pile of mutability and hidden dependencies. If I'm looking at a method in an object that takes one parameter, I literally have no freaking idea what the current state of the object is, what the current state of the parameter is or might be (and let's assume the parameter is itself an object or graph of objects). In fact, it's impossible for me to reason about what the hell I'm looking at. That's why we are forced to use the debugger so much.

Pure FP takes that all away. I have data going in, I do a transform, I have data going out. If my data is clean and my transforms are broken down enough to be understandable? It just works.

We keep trying to bolt on solutions like TDD to a fundamentally flawed model of development. Damn, I hate to say that, because I _love_ OOA/D/P. I'm not giving it up, but my current programming practices consist of using OCAML/F# and pure functions to begin with, then "Scaling up" to objects as systems get more mature. If I've got a big closure, I'm probably looking at an object. So far I've found that scaling up is not necessary. I get more mileage from composing my functions into command-line executables, a la unix, than I do sticking everything together. But that could change.

It's right to be discouraged. There's something deeply wrong here. A big change is coming to software development.

</comment><comment><USER18> I am simply not convinced that static typing resolves as many bugs as its proponents claim. The bugs I have are very rarely related with the type of a variable. They are incomplete/incorrect implementations of business rules. The type system doesn't solve that.

The other point of the article is that dynamic typing makes code rot. I am not convinced that static languages do any better. Code rot is not a problem of the typing system, it's a problem with the programmer writing the code, or the environment he's in. Let's see what happens when he inherits a 5-year-old Haskell codebase.

That said, I think the OP will do good in learning other languages. That always helps.

<comment><USER19> > The bugs I have are very rarely related with the type of a variable. They > are incomplete/incorrect implementations of business rules. The type system > doesn't solve that.

It doesn't until you encode the business rules in the type system. But in a well-designed language that's actually fairly easy.

> The other point of the article is that dynamic typing makes code rot. I am > not convinced that static languages do any better. Code rot is not a problem > of the typing system, it's a problem with the programmer writing the code, > or the environment he's in. Let's see what happens when he inherits a > 5-year-old Haskell codebase.

Having done both, it's far easier to port an old statically-typed codebase to newer versions of its dependencies than to do the same for an old dynamically- typed codebase. Compare a Wicket upgrade (seamlessly smooth, and the compiler will catch anything you've missed) with a Rails/Django upgrade (batten down the hatches, hope you've got high test coverage, and even then you'll likely have something break).

</comment></comment><comment><USER20> The problems I experienced with TDD in Rails applications (it's about the only way I'm using Ruby) didn't derive from object orientation or dynamic typing. They came from time and money constraints, especially in those one hour or one day rushes to get a new small functionality into the code base and deliver it into production. If a company has an internal development staff the technical debt can be repaid later on. If a company works with consultants paid by the hour, there might be never enough money to do it. An application with reasonable test coverage can quickly turn into an application with 100% broken tests and weeks of work to fix them all. But this isn't about Ruby or OO, it's about customers and the amount of money they want to spend no matter how good you are at explaining them what's happening to their software.

I have a Rails 3.2/Ruby 1.9.3 application that will be hard to port to Rails 4/Ruby 2.1 because of that. The point of the original post could be that writing that application in Haskell would require less work on tests so we could have less technical debt by now. Maybe. But when integration tests break (originally run with Selenium) because the UI changed so much and there are many new functionalities to test, I don't think the language can help. It's back to having enough budget.

</comment><comment><USER21> I think it's fair to say that 'everything is an object' was always a bad idea. I'm a little surprised that it took Ruby devs that long to realise that (Java devs still seem fine though).

My favourite example is the 'Utility' module that almost every project ends up with at some point. Why would that ever be an object? In C++ you'd open up a namespace and trow a bunch of free standing functions at it. Doesn't have to be more complicated than that. Classes are supposed to be one method of abstraction (among many others) that programming languages offer to us to structure our code.

The real problem with OOP aren't objects though. It's inheritance. Complex inheritance graphs are probably the best way to couple supposedly independent parts of your code as tightly as possible. And they're notoriously hard to wrap your head around. I guess a good example are component based scene graphs (again, in C++). Whenever you're implementing some sort of graph, chances are you start by writing a class called 'Node'. That's fantastic as long as you stop the chain there. Each individual object in your scene should be a subclass of Node that has any number of independent components (mesh component, audio component, AI component, what have you) attached to it. Favoring composition over inheritance is always a good idea as far as I'm concerned and I'm happy to see languages like Rust adopting it.

I don't want to get into the whole TDD thing right now. All I'm gonna say is that assuming your code didn't break anything because all tests passed is a risky business and testing JavaScript UIs might not be as useful as you think. Having said that, Cinder ([http://libcinder.org](http://libcinder.org)) had a bug in it's matrix multiplication code not so long ago that could have easily been detected with unit tests.

</comment><comment><USER22> He's inherited several rails codebases and has to maintain them.

Sounds like the 'other peoples code' problem to me.

Just like all non trivial abstractions are leaky (Joel) I guess all non- trivial applications are 'hairy'

<comment><USER9> No, I have seen tons of times when one developer on a single code base build a rats nest for themselves by just doing OOP.

Sure the objects or classes where probably not perfectly designed or the choices of the correct objects/classes to begin with, but that is the problem with OOP, you don't know if the main building blocks you are using are the correct ones.

<comment><USER23> So you are saying it's impossible to build a rat's nest with FP? It's problem with programmer, not with tool.

<comment><USER9> Uh? Where did I write that? Why are you making up what I wrote?

I guess your assumptions are in line with the OOP programming style... ;-)

You can make a rat's nest of any coding paradigm, however I would argue it is easier to do it with OOP.

</comment></comment></comment></comment><comment><USER24> I was sick of Object Oriented programming the first moment I had to deal with an API built with OO that replaced a previous API without it.

It was the WordPerfect 6 something language, replacing the WP5.1 macro language.

I had built a perfectly reasonable autocorrection engine, it handled typos, misplaced commas and periods, adding accents, and a few things more.

The Object Oriented macro language in WP6 removed any possibility to make my macros work, in exchange for adding silly graphic buttons.

Now I like C++ and D, but they are not 'pure OO'. Therefore I hate Java.

</comment><comment><USER25> Most of the points he makes are a byproduct of expecting too much from other people. I.E. gem authors, or misunderstanding why something exists I.E. the ruby standard library, which is a motley crew of modules meant to let people write hacky scripts a la perl. This is why I'm getting away from magic/cleverness as much as possible. Clever solutions usually rely on the dark corners of a language/ecosystem, which might break in the future.

</comment><comment><USER26> When Edsger Dijkstra pronounced _Program testing can be used to show the presence of bugs, but never to show their absence!_ had your Pa met your Ma?

</comment><comment><USER27> I suspect Rails the framework is as much to blame here as Ruby, OOP or dynamic typing.

The siren song of static typing is loud today. Robert Smallshire has given convincing -- and even evidence based -- arguments that it increases development time while catching only a very small percentage of bugs:

[http://vimeo.com/74354480](http://vimeo.com/74354480)

<comment><USER28> Possibly but.. Having had to dig into the Chef client code base way too often.. Large ruby code bases can be a special kind of hell.

</comment></comment><comment><USER29> Just use Scala, and you'll get to love object oriented combined with immutability and functional programming.

</comment><comment><USER30> I almost had to stop reading when I hit the quote from @HackerNewsOnion. Does the author realize that's a parody account?

<comment><USER31> Of course OP knows. Read it again with that in mind and it makes [more] sense.

</comment></comment><comment><USER32> I guess we all agree that one way to get around the burden of reasoning around mutable state is restricting the language.

I find that an equally reasonable way is to be able to add new language constructs to make this reasoning far more (humanly) tractable. You can do this with functions, and objects and so on, many a times, but without proper macros, you may lose far too much in terms of performance (in a dynamic language).

</comment><comment><USER33> I've never written tests for my projects. I hate writing tests because almost certainly, as I'm creating a new software, things change. I'm focused on the changing part all the time I hate being bogged down by having to write a script that tells me everything is fine.

On a large scale project, I understand the need.

<comment><USER34> I agree with this. You (I) waste as much time trying to work out if the test is wrong, or the code is wrong. Fiddle until the bar goes green. Doesn't help you focus on the main problem. Show it to the users, and the requirements instantly change anyway.....

In some cases automated tests are helpful, but not everywhere.

</comment></comment><comment><USER35> The original headline is this:

"Sick of Ruby, dynamic typing, side effects, and basically object-orientied programming"

He's sick of OOP in Ruby, not of OOP in general. Ruby's dynamic typing means you have one type, "the dynamic type". The compiler leaves you entirely on your own as static analysis is impossible. It means many more tests, assertions, and runtime error conditions. Most OOP techniques have evolved out of, and rely on strong static typing, Ruby isn't that kind of language.

OOP in Ruby is the inevitable result of many Ruby projects growing in scope and size. When you reach that point, a better way is to move part of the project out of Ruby and into a language that can handle that scope and size.

P.S.: Any communication with the outside world is a side effect (ex. network, file, database I/O), so sick of it or not, you better get used to it. Haskell masking side effects as monads through a language loophole isn't making things significantly better.

<comment><USER36> > P.S.: Any communication with the outside world is a side effect (ex. > network, file, database I/O), so sick of it or not, you better get used to > it. Haskell masking side effects as monads through a language loophole isn't > making things significantly better.

Eh what? Even as a Haskell non-user, this just doesn't make any sense.

a) Haskell doesn't "mask" side effects b) The fact that monads are involved is completely irrelevant c) It's not a language loophole

<comment><USER37> a) side effects are "masked" in Haskell in that a function that is generic over any type of monad _may or may not_ incur side effects at run-time, depending on which actual monad it is used with.

b) see above - because monads as a type class exist, a function may be written with a type signature that does not indicate in any way that it will be eventually used over IO.

c) the fact that the Haskell denotational semantics are entirely silent over what happens at run-time with the IO monad is definitely a loophole. From a birds view, a Haskell program is a giant expression that reduces to an object of type IO, and what happens with that object is entirely outside of the language semantics.

<comment><USER38> a-b) The objects of type IO are values, just as any other monad. It is true that polymorphic functions can be instantiated with type IO, just as they can be of any other type. How you think this supports the assertion that side- effects are "masked" is beyond me.

c) The language boundary of Haskell typically ends at the production of an IO value. You can easily give an operational semantics to many IO operations, and in fact there are papers that do this for simple IO operations such as putStr. It's not possible to give a full operational semantics for IO in _any_ language, not just Haskell. Of course you are going to model console I/O, references, exceptions, concurrency features (all of which have been done). But these aren't the only kinds of side effects. Does your model account for the network, and all its complexities? Does your model account for power failures? Does your model account for cosmic rays? Most models don't, but nobody calls them loopholes, nobody implies it's a big cover-up. Every model is going to have a boundary, and Haskell's seems good enough to me. It's no more undefined than, say, ML.

</comment></comment></comment></comment><comment><USER39> Sounds like you need to spend some time with go!

<comment><USER40> now he'll have two problems!

</comment></comment><comment><USER41> I'm surprised those shiny new languages still can't do what was considered normal in good old BASIC. And all programmers nowadays go "Meh! BASIC. Considered harmful! Will permanently damage your brain!!!"

Come on people, FreeBASIC has really great options for object-oriented programming and could use your skills.

<comment><USER42> Fun fact:

"Since the only computer language Richard [Feynman] was really familiar with was Basic, he made up a parallel version of Basic in which he wrote the program and then simulated it by hand to estimate how fast it would run on the Connection Machine."

[http://longnow.org/essays/richard-feynman-connection- machine...](http://longnow.org/essays/richard-feynman-connection-machine/)

<comment><USER41> That's a really cool blog post. Makes me wonder about a lot of stuff:

What were the projects and discoveries for which the connection machines were clearly essential?

Are there connection machines that are still in operation?

What happened to the old ones?

Does Danny Hillis now keep a cluster of GPUs running somewhere instead of his old hardware?

Would connection machines be more useful now than in the past?

Is it the right time to boot up thinking Machines 2.0 ?

<comment><USER43> Parrella boards and cray xmt both are probably the closest you get to connection machines today.</comment></comment></comment></comment>


Writing Code to Be Spoken (2019) - <AUTHOR> https://www.sacrideo.us/writing-code-to-be-spoken/ <comment><USER2> That was very much not what I was expecting - I was expecting another attempt at producing a more English-like language which could genuinely be read aloud.

I'm not familiar with APL, but I can imagine that the test process for "how well can this language be read aloud" would be to have someone read out a short program over the phone and measure how long it takes and how many bugs are introduced. I wonder how people would handle significant-whitespace languages over the phone, for example?

(Yes, I know hardly anyone ever does this)

</comment><comment><USER3> I feel as if I am missing something here, some previous reading that would make this clearer? I do not understand how the code snippet he provides is "lyrical". Any more stuff I could read on this sort of topic?

<comment><AUTHOR> His APL to GPU compiler is less than 1000 loc in it's entirety and the "comments" are the 400 page accompanying master's thesis.

There are a few HN discussions u/arcfide and several YouTube presentations at functional programming conferences. Neat stuff!

[https://news.ycombinator.com/item?id=13565743](https://news.ycombinator.com/item?id=13565743)

[https://www.sacrideo.us/smaller-code-better- code/](https://www.sacrideo.us/smaller-code-better-code/)

<comment><USER4> I don't think it's a strong selling point that you need a 400 page book to make sense of a 1000 line program. I find the style of the Dyalog dfns library much more pleasant to read and much easier to follow.

<comment><AUTHOR> When it is an entire compiler and teaches you APL and compiler techniques?

It is part thesis, part tutorial, and part textbook. Cool item. I honestly don't remember the page number, but it was definitely over 100.

<comment><USER4> It's definitely an impressive piece of software and I realize that his thesis is much more than just "comments" to the code.

My objection was to the implied claim that a 1000 line program is easy to understand and work with, easier than a much longer program. I don't think that's true if the 1000 line program is written in an incredibly terse style where a lot of contextual information has been deliberately eliminated.

For example, in this post Aaron comes up with a bit of APL that's a direct transliteration of " Description #5: Increment the n field of the parent for nodes whose parent is of type 2 and kind 3 for each node by 1."

My claim is that an experienced APL and compiler programmer could figure out what the APL is doing at the level of "description 5".

But I think he/she would struggle to recognize the problem statement at the top "Pass Overview: Count the Rank of Indexing Expressions" because a lot of contextual information has been lost in the transliteration to APL. That information could have been included in the code in the form of comments or by assigning a helpful name to this snippet.

Aaron didn't do that by design, and he didn't need to because he's been working on this for years. It's all in his head and now in his thesis. But if you're not Aaron you have to read the thesis to learn the missing contextual information.

Dyalog's dfns library is including the contextual information inline in the form of comments and local utility functions. I prefer that to having to cross-reference some other piece of documentation.

</comment></comment></comment></comment></comment><comment><USER5> This is why I love `for` loops, and why I hate functions that accept functions as arguments.

Sustainable code should be easy to read out loud.

<comment><AUTHOR> I for one, cannot stand writing for-loops when unnecessary.

</comment></comment><comment><USER6> Might have been more compelling if it had been illustrated using a more mainstream language.

For instance what does

        p⌿⍨

mean?

<comment><USER7> It says, unhelpfully,

"P first-axis reduce or replicate/compress (commuted)"

Because APL functions only have a left and a right argument, and evaluates right to left but does parens first, it often means wrapping things on the left into parens to get them evaluated first. Commute (⍨) tacked onto a function reverses it's arguments so you can put them the other way round and remove the parens e.g. 8-3 is 5 and 8-⍨3 is 3-8 is minus 5.

p⌿⍨... says (...)⌿p

Exactly what ⌿p does depends on what the rest is - it's either a foldr operation if given a function, or "copy the items in p this many times each" if given a value or an array of values that matches the shape of p.

Looking at the link, it's a replicate - that is, a filter. It filters p where the matching positions in t are =2, and t[p] is an array lookup (multiple indices at once) into another array.

I have no idea (yet?) how people say APL "reads left to right", it seems to "decipher a bit at a time jumping all about from easy sections to hard sections"

</comment></comment><comment><USER8> He is out of his mind</comment>