Write Junior Code - <AUTHOR> https://www.parsonsmatt.org/2019/12/26/write_junior_code.html <comment><USER3> This might be a little bit of a "hot-take", but if idiomatic code written by a competent senior engineer remains inscrutable and unmodifiable after around 2 weeks of training an engineer who is at the beginning of their professional career, then that language is probably a bad choice to use in production. If lenses, MTL, fancy concurrency are "the way" to do things in Haskell, and those require an extraordinary amount of time to learn, then Haskell may not be a good choice for production code from a sociological POV.

I haven't used Haskell professionally so I can't actually weigh in on the veracity of the prominence of difficult-to-learn code. I do know about using another "weird" language though: Common Lisp. We at Rigetti took a bet with Common Lisp and it passes the "senior-written idiomatic code can be junior- learned and modified" smoke test with flying colors. Every group of interns and every new grad that has become involved in the tens of thousands of lines of code has been able to contribute substantially in less than two weeks.

<comment><USER4> Or, just don't hire junior developers :).

This reminds me of what my boss from my second-ever job told me when he tasked me with starting a new project: "I know I promised you you'll get to choose your own tech stack, but you're going to write it in PHP; I know you'd like something better, perhaps Ruby, but when it comes to hiring developers to help you, I'll have to pay a Ruby developer $X, and I can get PHP developers for $X/2".

I guess it makes business sense for bottom-feeder development. In my case, it burned me out completely.

Anyway, I work in Common Lisp professionally these days too, and we don't shy away from using both simple and moderately-complex macros. There's nothing magic in them. Sure, tracing a problem with the expansion of someone else's macros can be a cognitively taxing work, but you're going to have to do this kind of work somewhere anyway - if not here, then when trying to figure out a convoluted call graph of 20 functions or methods that macro would have abstracted away for you (which was a common thing to do at my previous job, involving Enterprise Java).

<comment><USER5> "Junior" might as well be an IQ classification.. How many people change their IQ?

The reality is something nobody really talks about.. When a company doesn't want to hire a "junior" it doesn't mean they don't want to hire somebody without X amount of experience in a tech stack or without X amount of experience in the industry.. They don't want to hire people bellow a certain aptitude.

Many "juniors" will never be "senior". Even if they get the title and salary. We all know "seniors" in salary and title only.

Some people are inexperienced "seniors" year one.

<comment><USER4> Viewing it from this lens, it still doesn't make sense to sacrifice productivity of people "with aptitude" for the sake of expanding your hiring pool to include people "without aptitude". Instead of bringing down everything to the lowest common denominator, one can try to assign different types of work to people with different levels of aptitude (or care).

(Personally, I feel what makes "forever juniors" isn't aptitude, but lack of care. I don't see it as flaw of character - the factors like structural anti- intellectualism in the industry, lack of enthusiasm due to work being meaningless, and that not everyone is into programming beyond it being a 9-to-5 job all contribute to some people not learning. This suggests to me that expecting people to learn and making learning part of their jobs - <USER2> part, with paid time set aside for it - can overcome this problem.)

<comment><USER6> > anti-intellectualism in the industry

Could you expand upon this point?

<comment><USER4> A bit more here: [https://news.ycombinator.com/item?id=21909816](https://news.ycombinator.com/item?id=21909816).

But the gist of it is: the industry prefers to work with dumbest tools possible and throw cheapest bodies they can get at a problem, instead of expecting people to keep learning, improving themselves, and applying these improvements to their work. This article is an example of that - it advocates discarding advanced tools given to the programmer by Haskell, in favor of writing dumb code that's easily digestible for beginners. Most of the advice about avoiding "clever code" is a form of that too.

I find it a penny-wise, pound-foolish approach, because when you do this trade-off, you're losing in two places. First of all, you handicap your skilled team members. But secondly, the cost (in terms of time, money and incidental complexity) of a project grows _faster than linear_ with the number of people you get involved in it. It'll be O(n!) if you do it naively, O(n logn) if you arrange people into hierarchies, but the problems still grow faster than they're solved as you scale up.

The alternative approach I'm encouraging is to make responsible but full use of the power of the tools you have, and if this goes over the head of some new hire, then _teach them_ until they understand and can make use of that power too. Embrace and encourage learning as a part of this job (actual, expected, and paid-for part). Push the industry upwards, instead of dragging it down.

</comment></comment></comment></comment></comment></comment><comment><USER7> I think one should write the code that's most suitable for a specific scenario. Senior vs junior has nothing to do with this (at least not in a categorical way). I have met many who call themselves seniors who really just aren't as good as they think they are.

The best engineer I've worked with sometimes wrote simpler code and sometimes wrote highly sophisticated code. If there's someone on the team who can't understand a particular piece of code, he should just ask and learn. There's no reason to weigh someone down just to make an inexperienced, incompetent programmer or unwilling to learn something happy.

Good code isn't junior code. Good code isn't senior code. Good code is just what works best in a specific scenario. And it takes experience and details of a problem to decide what that is exactly. Dogmatic, rigid views just don't work well in this line of work.

<comment><USER8> Agreed, I'm not a huge fan of junior/senior. What we should be talking about is inexpert/expert, which doesn't always map 1:1 with how long you've been working, or practicing. Though obviously, the longer, the more likely you learned and became more knowledgeable. But some people spend 10 years doing the same thing over and over, and that's not broadening and deepening their skills the slightest.

So in my opinion, there is two type of unreadable code, there is the code that's just plain bad, convoluted, overly complicated, like a Rube Goldberg machine. That one is often written by inexpert programmers, sometimes they are juniors, and sometimes they're senior as well. And then there is code that you personally can't read, but which is great code, simple, coherent, to the point, etc. You just haven't learned the vocabulary and grammar to understand it.

</comment></comment><comment><USER9> To be clear, one of the reasons I decided to focus on Python in the early 2000's was this reason, that I wanted to work within a computing language that was as accessible as possible to the widest variety of programmers, thus helping to ensure that the code I write would be maintainable by others, the libraries I create would be in high demand, and whatever code I write for employers would be maintain a high degree of transparency to everyone else at that employer.

My general impression of functional languages with Haskell at the top, is that these languages are inherently not for "junior" programmers of any stripe. That is, if you are a programmer writing Haskell code that actually works and does something useful, by definition you are nothing like a "junior" programmer. A "junior" programmer would be doing it in PHP, C#, or Python. Just the kind of motivation one would need to learn Haskell and actually be functional at it would take you out of the realm of the vast majority of "junior" programmers.

This is based on my own experience of working alongside many other programmers, many of whom were probably not necessarily "junior" however they were the kind of programmers that went home at 5 pm. These people could get a lot done but only in a language that did not require intensive conceptual visualization. Even in Python, parts of code that I would write that would get too clever / recursive / FP-ish would be lost on everyone else and I'd be stuck having to save everyone from that little clump every time something had to change with it.

<comment><USER10> One would expect that a language like Haskell abstracts away the need for junior programmers. In the same way that digital computers abstract away the need for pencil-and-paper calculators.

<comment><USER11> I've never seen a scenario like this and even with the ideal case of current abstraction frameworks there is always tedious grunt work that juniors get to cut their teeth on - doing minor adjustments to fine-tune requirements, adding minor functionality, etc. Stuff where you don't want to waste time and focus of senior devs.

The only scenarios I saw where juniors were not needed is overly complex systems where the barrier to entry was so high you needed a huge amount of upfront knowledge to do anything. Those were not good projects to work on.

</comment></comment></comment><comment><USER4> I have the opposite view. Sure, don't go overboard with power _for your own sake_. If it ends up a convoluted mess, it's your fault and you should refactor - proper application of powerful language concepts result in clean interfaces hiding complexity that rarely, if ever, needs to be touched again.

From my personal experience, instead of writing dumbest possible code to make juniors productive from day one, just don't hire juniors. Or at least, not the absolute beginners. And if you do hire juniors, accept that they'll need more than few weeks to get up to speed.

Despite the perceived smartness, our industry has a weird anti-intellectualism deeply ingrained in it. Programming is a profession - you're supposed to get better over time. Learning is part of the job. And yet it seems to me that more and more people think that what they've learned prior to their first job is all they'll ever need to understand, and anything beyond it is "clever code" that needs to be expunged.

(Of course, keeping everything dumbed down makes sense if you're interested in penny-wise, pound-foolish optimization on the hiring side of the company, or otherwise like to have developers be replaceable cogs. But it's not in the best interest of the developer, and arguably it isn't in the product end- user's best interest either.)

<comment><USER3> One of the most enjoyable aspects of my career has been teaching and mentoring engineers with little experience. Everybody starts somewhere, and I would never want to suggest an organization I'm a part of ought to bar a healthy, tempered number of less experienced folk.

But, organizations aren't charities, right? I might like mentoring, but that doesn't mean it's the best choice for a company to make. Fortunately, there are a plethora of incredibly bright and talented individuals who really can move the needle in your business in a _short_ amount of time. You wouldn't see it from number-of-years worked, but you'll find out by investing your time and energy in them. With this attitude and managerial philosophy in mind, I find that you inevitably build stronger, more loyal, more flexible, and exceptionally competent teams this way.

<comment><USER4> Well, sure. My main point isn't that you shouldn't train hires (you can't really expect to not train new hires). It's that I don't think it's worth it to sacrifice your team's internal productivity for the sake of speeding up the onboarding process and/or making it cheaper - which is what IMO the article is essentially suggesting.

The article is about Haskell, but this advice - make code newbie-friendly, avoid "clever" code - keeps popping up again and again. The extent to what's considered "clever" varies between jobs, languages and programming communities.

As an example, when my old Java job was grudgingly upgrading from Java 7 to Java 8, my boss took me to the side, and said to me: "I knew you'll be happy about the transition, but if you could, perhaps consider refraining from using _lambda expressions_ ; I know you understand them, but some of your colleagues do not".

I didn't comply; instead, I've explained lambdas to people in my project. It took few minutes, they understood it almost immediately, and we continued using full feature set of Java 8 just fine. The practice eventually spread around, and the other day I saw a particular developer my boss was worried about, going around the office full of excitement, telling everyone about the cool things he's just learned about Java 8 (namely, lambdas and streams API). Soon thereafter, everyone was using these features, and they've lost their status as "clever code".

So, to put my point another way, perhaps instead of worrying about the code being friendly to experienced developers, one should take the time to teach the new employees - just like you are doing.

<comment><USER12> I fully agree with this. I haven't really seen code that is 1) actually useful but 2) so clever that you can't quickly explain why or how it works (or just let the person reading it figure it out or ask stackoverflow...). So I don't really even know what people mean by clever code.

<comment><USER13> In my experience, a big danger is when someone higher in the company hierarchy is a former developer who no longer writes code.

Such person will perceive the new language features or libraries as "too clever, and not really necessary", will voice their opinion loudly, and you can't make them learn and find out that it's actually simple and useful. (And, yes, lambdas in Java 8 were an example of that.)

<comment><USER14> Find good examples that you can defend well, and overwhelm them with practical and relevant examples.

</comment></comment></comment></comment></comment></comment><comment><USER15> Wish there was something similar to Elm, but designed with backend/networking/generality in mind, like Go. Take the Haskell core language without all the lang extensions, and accompany it with a solid stdlib. I want an FP ecosystem that's not rooted in research. Can have a more simplistic type system, etc. Basically a functional Go. Maybe an effect system, idk.

<comment><USER16> I keep telling myself that this is the year I'm going to really learn F#; it has a lot of the nice parts of Haskell, but is a little more on the pragmatic end, and has access to the whole .NET world.

The problem I run into frequently on my abortive attempts is that when things get harder, it's too easy to just drop back and smash something out in C#.

<comment><USER17> Once you get used to / take for granted the additional compiler features in F#, you will find yourself weaning yourself off C# code more and more. Resistance is futile!

2019 ends my year of F# focus. In 2020, I will take a look at Rust since it is C-but-not-nearly-impossible-to-correct-insecure.

Between Get Programming with F# and Domain Modelling Made Functional, I am a convert for F# and will continue using it into the future. Why?

Quick example: I'm currently hacking together a program for the RPG system used in Star Wars Fantasy Flight Games, so that the game master can input possible player actions during their turns and keep track of player stats, generate NPC encounters etc. and so forth.

Writing the back-end in F# (stored to SQLite) really helps me keep the game rule book (business logic) straight, with compiler-based warnings if I try to, say, stick XP into a function that expects in-game cash.

On the front end, I'm using plain old Windows Forms in C#. The UI is mostly for data crunching and keyboard-first usage (I'm keeping in mind my FoxPro days and gui.cs / TUI / keyboard-first functionality from that twitter thread a few weeks back), and is mostly for gluing UI controls to the back-end itself (maybe this will be a mobile app, website, etc. in the future depending on the GM's needs).

For this program, I wouldn't write any game logic in C#, now that I'm used to F#. C# lets me get away with too many mistakes compared to F#, for the same reasons JavaScript lets me get away with (even more) too many mistakes compared to C#.

</comment></comment></comment><comment><USER18> I don't know much about Haskell but I'd say in any language you shouldn't write code to show off your erudition. Doing that kind of thing in production code is hardly the mark of a truly senior engineer. If the code is the best way to solve the problem, though, why is it so inscrutable in this language?

</comment><comment><USER19> This is why I advocate for popular frameworks in commercial projects, even though I don't prefer writing in them myself. Sure, it's easy to find people who know {Language}, but everyone has their own idioms, and they will need to spend time learning yours.

A framework has the benefit of having existing documentation you didn't have to write, an existing community of people solving problems the framework may have, and most importantly a slew of idioms that are literally codified and documented.

Do things "The {Framework} Way" and when you onboard someone familiar in {Framework} you should only have to help them with the domain space knowledge and any novelties of your specific implementation. You still get to use advanced concepts, but hiring and onboarding is significantly simplified.

For personal projects, I never use frameworks, it's not nearly as fun as writing greenfields code. But in a commercial project, long term viability of the project should probably come before fun.

</comment><comment><USER20> "Why not write Go instead?" was the response from an audience member after a talk at Haskell eXchange 2019 that encouraged simple use of Haskell.

They had a good point — if a primary goal in your team is to make code accessible for juniors and maintainable for new hires without weeks or months of ramp-up, and you need to ban Haskell language features, extensions, and libraries to achieve that, perhaps there are better choices than Haskell?

And if the Haskell community needs a repeated rallying cry to "write simple Haskell", maybe it's a sign that a new Haskell standard should be created that defines what "simple" Haskell code means.

Juniors could then feel assured that learning the 2050 Haskell standard [or whatever] would be enough to help them get a job as a Haskell junior. And companies would have a target to move their codebases towards that's consistent across the industry.

</comment><comment><USER21> I think that it's important to hire people who are comfortable with the whole language that you are using.

I also think that "junior code" could mean the opposite of what the author means. Lots of smart juniors write code that abuses complex language features in noncanonical ways that confuse all of the people. Lots of senior devs stick to a known (and canonical to them) subset of features that proved themselves in battle for them.

<comment><USER22> > Lots of smart juniors write code that abuses complex language features in > noncanonical ways that confuse all of the people.

Do you really see people do this in Haskell? I'm "junioring" my way through a problem set now (advent of code) and that does not describe my solutions at all. It is definitely not pro-level Haskell. I use direct recursion with an accumulator when I know there's gotta be some recursion scheme that fits the bill, very simple types, very few advanced combinators and symbols, etc.

It definitely could be better, but it suffers from a lack of fanciness rather than an excess. I've peeked at some expert solutions posted online and they are neat and super impressive... but by and large they confuse the shit out of me.

I have a hard time picturing being overly ambitious as a common beginner flaw in this space.

<comment><USER21> Different folks take different paths. In any language, you will find folks who start out by kinda overshooting before they learn to tone it down.

It's not that all Juniors are this way. Maybe some get it right or maybe they even act too skidding. But I think of it as a Junior trait to sometimes overshoot on complexity.

</comment></comment></comment><comment><USER23> >Let us grow Haskell in industry by writing simpler code and making room for the less experienced.

>Let's not delete all of our fancy code - it serves a purpose! Let's make it a small part of our codebase, preferably hidden in libraries with nice simple interfaces.

Says something about the Haskell culture that this isn't already standard practice, regardless of the need to train junior programmers.

<comment><USER24> It says something about the Haskell _language_ \-- that it has near infinite power for abstraction and Don't Repeat Yourself-ism. Most Haskell code is fancy because if anything else had a large amount of mass, it could be abstracted to higher-level Haskell. Haskell programs have size approximately "log(size of program in another language) ^ k" because anything repetitive can get squeezed out.

</comment></comment><comment><USER25> Almost every other language has a problem that it's already so dumbed-down to the point employees get treated as disposable/replaceable. There's a reason obscure languages pay very _very_ well, but if you dumb them down, it's not hard to see what will happen to that advantage...

(I don't work in Haskell. Now I have mixed feelings about it.)

<comment><USER24> There are more $200K+/yr new-college-grad C++ and Java jobs at FAANG than all $200K+/yr Haskell jobs in the world.

</comment></comment><comment><USER26> > Employee writes a ton of really fancy Haskell, delivers fantastically and in > about 1000 lines of code. Everyone is very impressed. The project grows in > scope.

>

> Boss: It's time to hire another Haskeller. What are the job requirements?

The job requirements should be the same as the ones the original engineer was hired for. Then they can mentor the newbie. After all, they're not an expert if they've done this, they're still able to explain why they pulled in a shit ton of libraries to do their work.

Asking that person what the new requirements are is doomed to fail because they moved the goal posts. Give them a junior and let them learn.

<comment><USER27> That's the thing a lot of devs who hire don't get. You don't necessarily need someone who knows the language inside and out on day one.

What you need is someone smart and who can demonstrate that they can learn new languages quickly.

They understand the fundamentals of how to write software.

Language specific abstractions are just muscle memory.

<comment><USER24> No one learns Haskell quickly. "the fundamentals of how to write software" are very different in Haskell from other languages, even other functional or functional-ish languages.

</comment></comment></comment><comment><USER28> I have a page saved with a load of quotes, some of which are about this very subject. Here's a selection, from [http://quotes.cat-v.org/programming/](http://quotes.cat-v.org/programming/):

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan and P. J. Plauger in The Elements of Programming Style

</comment><comment><USER29> One should code in Haskell as if it were a small language like Scheme (or Standard ML, or early OCaml, or..). It's a wonderful language for that. The deep stuff isn't actually necessary.

<comment><USER30> True, but the problem is that any production ready library you come across uses some pretty advanced type magic that you have to learn to understand. At least to some extent.

Servant, the currently dominant API library/framework alone is already based on type level programming.

</comment></comment><comment><USER31> I'm kind of having this problem. I'm a senior engineer but junior Haskell programmer.

Can't find any jobs willing to hire me as a junior haskell programmer so I just stick with the popular languages.

</comment><comment><USER32> talking about haskell, i always get a laugh out of: [http://steve- yegge.blogspot.com/2010/12/haskell-researchers-...](http://steve- yegge.blogspot.com/2010/12/haskell-researchers-announce-discovery.html)

</comment><comment><USER33> I enjoy Haskell and I use it for some of my own projects, but I rarely use it professionally. I also use a simpler style of writing Haskell: I try to make as much of my code as possible be pure, with no IO or touching the real world. I try to isolate impure code as much as possible.

Using a subset of Haskell makes coding fun and productive, but when I have to read and use other people's code, it takes time to understand what they are doing.

I have made peace with using Haskell in a simple way, enjoy it, but frankly spend most of my time using Lisp languages like Hy, Common Lisp, and Racket. I have been using Lisp languages for 35 years and part time Haskell for about 7 years, so it is understandable why I have an easier time with Lisp.

</comment><comment><USER34> If code written by a "Senior" Engineer is unreadable/unworkable by someone with less experience - that is 100% on the writer. Don't enable ego-fueled programming, best to either do as the article suggests or bring in some actual more senior engineers who have already learned that code is read 10x more than written, and should be optimized thusly.

</comment><comment><USER35> Wow but he continues to recommend using Haskell at all...

</comment><comment><USER36> I'm having a similar experience with Golang, 90% of job postings are senior level, everybody wants 3+ years experience in the field, etc.

</comment><comment><USER37> Perfectly fine advice if you're solving a routine problem with well-understood solutions with no special reliability, productivity, or security requirements. Terrible advice if you're pushing the envelope. If you're using Haskell with half its functionality verboten, why use Haskell?

<comment><USER38> Which is, perhaps, why basically no one uses Haskell in production.

</comment></comment><comment><USER39> While you do it, find a business case for the language development. PL papers in the <Funny Title>:<Actual Description> format make a good read but a production language also needs more mundane input and work.

</comment><comment><USER40> Do Haskell programming jobs really pay better than, say, a Java programming job?

<comment><USER41> Maybe working on the one internal system Facebook has written in Haskell. [https://engineering.fb.com/security/fighting-spam-with- haske...](https://engineering.fb.com/security/fighting-spam-with-haskell/)

Otherwise, I don't think many jobs pay more than Java engineer at FAANG.

</comment></comment><comment><USER42> What I try to do in my projects is to allow complex code (if it serves a purpose), but only in libraries and try to make it as self-contained and well documented as possible. Application code should be simple.

<comment><USER43> I concur. We use Clojure, and the actual application logic is boring and simple. This is good because it is easy to navigate in code from any project (even from other teams).

Complexity is all at our common libraries. So most programmers don't even need to understand our abstractions, they just work. Of course, sometimes our abstractions are not enough so you need to get your hands dirty. However I would say it works well 99% of the time.

</comment></comment><comment><USER44> Or become senior and apply for that Haskell job in five years.

</comment><comment><USER45> The same goes for Scala in my opinion. A company using Scala should restrict themselves to a easily comprehensible subset of Scala.

</comment><comment><USER46> I feel like you could say some similar things about flutter.

</comment><comment><USER47> That's why as much as I love Haskell as a language and a way of doing things, I will not choose it to implement anything in my place of work.

</comment><comment><USER48> This post probably also applies to <insert name of programming language here>.

</comment><comment><USER49> Just for another data point, I'm a "senior" developer (been programming for 30 years) and I tend to look more at frameworks than languages. I really think that starting from first principles allows one to end up with an elegant solution, regardless of whatever errata is present in a language. A good framework is the elucidation of an idea with the edge cases covered so that you don't have to reinvent the wheel. It should give you the tools you need to integrate with your code and then get out of the way.

Specifically, take something like Laravel. It's based on Ruby on Rails, which borrows heavily from .NET. Personally I think that Ruby is a decent language that gets a few things right, despite some early compromises to get closer to the metal which caused some unwieldiness down the road. However, Ruby on Rails has a brutal learning curve unmatched by just about any other framework that I've learned. And the end result unfortunately succumbs to being too opinionated due to emphasizing convention over configuration too much IMHO. I think that's why it fell from favor, and personally I wouldn't recommend it for new development.

Whereas Laravel does a lot of what Rails does, despite using the "hackier" PHP language and less syntactic sugar or magic under the hood. The companion Laracasts are mostly exceptional. I would even go so far as to say that if you want to learn Ruby on Rails, learn Laravel first. That way you can build on context and be comfortable with Rails in a few weeks rather than the months it would take to learn it from scratch. You'll also notice the inconsistencies in Rails more and be able to work around them so your code is conceptually correct, rather than evangelize why their existence is needed or that they're the "one true way" to do something.

What I'm trying to say is that after using Ruby on Rails, I'm still not sure what problem it's trying to solve half the time. It seems to be structured in a way that solves issues encountered late in a project, but it's never really clear why one path was chosen over another. Like I solve a problem in my head, then have to translate it to the Ruby on Rails way. I don't get that as much with less-opinionated frameworks like Laravel. I think the best approach is to provide as much functionality as possible with sane defaults but not force the user into a paradigm.

Simplifying from Angular to Vue is another example of this. There are many others, but to play on this, it's one of the reasons why I'm uncomfortable with stuff like Kubernetes. Or even Unity for that matter. The more monolithic/enterprisy/opinionated something is, the more I'm skeptical of it.

This idea of working from first principles (the way a new user might) is a way to think about how to go about writing code that junior developers can use, even if the concepts involved are senior-level. I practice this technique but it easily gets lost in translation and I find myself explaining the easy vs simple dichotomy a lot. It's probably even cost me jobs to be honest. But that doesn't mean it's wrong.

</comment><comment><USER50> > _The project can't really grow anymore. Maybe the original employee left, > and now they have a legacy Haskell codebase that they can't deal with._

This is the litmus test for a good language, in my opinion. Not the way it makes you "feel" when writing it, but how easily it can add in new people to the project and get them running.

This is why — even with all of its shortcomings — I prefer Go to almost every language now.

</comment><comment><USER51> Not specific to Haskell but, I think code in general is becoming more complex than it needs to be without any added benefit other than adding an extra buzzword to the list of things you know.

In a non-functional programming language for instance, I firmly place lambdas in this category. I was working on a legacy Java 7 application the other day, and Netbeans was configured for using lang spec Java 8 (which I later switched over to 7). Every time I wrote an anonymous function, it could give me a yellow underlined hint saying I should convert this to a lambda. Why? Why should I do that? It doesn't make it more readable, it saves only a few characters of space (our target platform had more than enough disk space for this to be irrelevant), and it makes the code more difficult to skim. And it's an extra thing a junior may not know about that they get bogged down trying to understand. Given, it's a simple concept and isn't hard to understand. But this applies to all sorts of other silly syntactic sugar the internet has decided is cutting edge tech, that is making our code bases less readable.</comment>


Code versus Data - <AUTHOR> https://theartofmachinery.com/2016/06/21/code_vs_data.html <comment><USER2> Brilliant point of view. I too, am slowly coming to the realization that a mixed mode of paradigms is actually better and _simpler_ to attack composite problems. Attacking everything with code (OOP gravitates to that approach IMO) has its strengths but I see people over engineer there trying to solve problems where just a different way of thinking would produce a simpler, more robust and easier to maintain solution.</comment>


Americans fled the country to escape their giant student debt - <AUTHOR> https://www.cnbc.com/2018/10/26/he-moved-to-a-jungle-in-india-to-escape-his-student-debt--and-hes-not-alone-.html <comment><USER2> This is because of distortions in the student loan market. Risk is not being properly assessed and loans are being made when they should not be. Philosophy majors at non-top schools should not be given loans since it is unlikely they will be able to pay them back and the philosophy majors are hurting themselves in the process.

A fix to this distortion is unlikely since the end result would be the closure of hundreds of schools and thousands of faculty and staff being laid off as there would be significantly fewer students.

<comment><USER3> There's a lot of assumptions here about the value of degrees. It's not just liberal arts people who have trouble getting work, and no degree is a guaranteed ticket into work.

Education shouldn't be treated as a problem to which the solution is free markets. If anything the US could learn from other countries and "distort" its loan "market" more.

<comment><USER4> His example is talking in aggregate, not specific students. Sure, you might have an art history major find a job quicker than an engineering student, but who will end up getting more jobs, 100,000 art history majors or 100,000 engineering students?

The loan market in the US IS improperly distorted right now - it treats all loans as having the same repayment risk...which is absurd. What we need is a loan system that offers interest rates based on majors. Computer science major? 4% interest. Comparative women's studies major? 25% down and 12% interest.

"That will just make it MORE difficult for liberal arts majors to repay their loans!" — Yes, exactly. It's a market signal to re-evaluate their decision, or skip college entirely.

</comment></comment></comment><comment><USER5> >Philosophy

>Comparative literature

Then gets a job as a Medical Courier.

>Communications and History

Then gets a job as a pizza deliveryman and says "I lost faith in my country"

\---

I find it very hard to relate to such people. They get a college degree, but never learned critical thinking skills. Maybe the issue is colleges producing low quality students.

I have friends with similar degrees and they found soulless sales jobs.

It seems like a responsibility/thinking problem. These arent your best students, these are bottom barrel.

Who is to blame? Maybe our high school teachers for telling everyone to follow their dreams instead of learning.

<comment><USER6> High school counselors for mass-funneling students into university. Corporations for demanding college educations for unskilled labor. Creditors for lending to young-adults predominantly 18-20 years old. Universities for inflating social experience to the detriment of academic quality and increased tuition. Parents for the cultural peer pressure.

Ultimately, I tend to agree with you but I have a hard time criticizing the naive 18-20 year old rather than the multitudes of enablers who allowed this situation to arise. Is it really fair to blame the victim of an elaborate and complex system designed to extract the perfect amount of present and future value from them while leaving them with just enough (or in the extreme case, not enough) to survive?

"I've designed the perfect device. It can extract just enough usable meat from a cow while still keeping it alive." -Paraphrase of a quote that I can't attribute at this time.

 __EDIT __Actual quote thanks to leetcrew and andygcook: "I invented a device called Burger On The Go, it allows you to obtain 6 regular size hamburger, or 12 sliders, from a horse without killing it."

<comment><USER7> No matter how predatory or even fraudulent the lender, in U.S. culture the individual takes the blame in the name of "personal responsibility". After all, if we were to acknowledge that vendors influence consumer choice, uncomfortable ethical questions would arise.

<comment><USER8> Nobody disputes that people are influenced. But it still comes down the the fundamental right of self determination, which is a pretty core principle in Western Democratic society. It's my right to try to influence you to do something (within reason) and it's your right to do whatever you please.

</comment></comment></comment></comment><comment><USER9> This is actually really excellent reporting. The people and stories in this article are very real, and I bet there are thousands more people just like this and potentially millions who want to be like this.

I did the expat thing for 2 years. Sleeping on mountains, on couches, in airports, in cars, everything. It's a lot of fun and really cheap. You feel a lot of freedom.

But, it is still hard to get things going "legitmately" in any country, and by that I mean finding a job and getting a visa and, if desired, having an apartment or a family/spouse.

I came back to the USA and luckily found what seems to be a more permanent job than sales. I'm making $2,000 a month and splitting expenses with my gf.

Ultimately that math works better than being a nomad on $500 a month. But I'm wondering if someday I will give it another shot :)

</comment><comment><USER10> While immoral I am hardly one to speak, right after the Brexit vote when the Pound Sterling was unusually low against the US dollar (Oct 2016), I cashed everything in to pay off my loans at a stark discount (15% off). Is it wrong to benefit from your home country's misfortune? Is it wrong to leave your home country to avoid repayment?

I will say that while I consider the morals of things, the wealthy and ultra- wealthy seem to have no such compunction. They will happily move money off- short to avoid tax, re-work income to pay lower capital gains tax rates, or have an official residence in a lower tax location.

Somehow I think they will clamp down on this a lot more than they do the ultra-wealthy.

<comment><USER8> Why is this immoral in the least? At worst, it's lucky. At best, very shrewd. The UK held a referendum which impacted the value of the currency against another that ended up being beneficial to you. Literally nothing you did impacts any of this. In fact, by doing what you did, you helped support the pound (i.e. selling dollars to buy pounds). It's not even close to what's being described here.

<comment><USER10> > Why is this immoral in the least?

I'm personally financially benefiting from other's misfortune.

> In fact, by doing what you did, you helped support the pound (i.e. selling > dollars to buy pounds).

Good point, I hadn't considered.

<comment><USER11> >I'm personally financially benefiting from other's misfortune.

and why's that bad? honest question. you're not the cause of the misfortune. I see it as no different than a roulette game where you bet on red, someone else bets on black, and you end up winning.

</comment></comment></comment></comment><comment><USER12> Time for the weekly thread where CS majors call anyone who is not a CS major stupid and worthless.

<comment><USER8> Red herring. I am not a CS major and I think people taking out huge loans to major in communications are just as much a problem as bloated school staffs, federalized loan programs, etc.

It's not zero sum. People who bash CS majors for no reason are douchebags, as are people who irresponsibly borrow.

<comment><USER12> Communications majors work in HR, advertising, PR, etc. Most liberal arts majors are the same way- there are jobs, just no recruiters throwing themselves at you. CS is unusual in that there's a huge demand for recent grads, most other jobs have the experience/no experience paradox.

</comment></comment></comment><comment><USER13> My wife has $400,000 of medical student loan debt. We are on PSLF but are nervous about the program and question if her student loans will really be forgiven. If they are not forgiven at the end of our 10 years of qualifying payments we plan to leave the country. If you can find a job outside the U.S. and don't mind learning a new system I think leaving the U.S. is a great option. Will people do this over medical debt in the future? As the world becomes more integrated this option becomes easier. Especially since speaking only English is not as limiting as it used to be.

<comment><USER14> Silly me thinking I couldn't afford medical school, I wasn't shrewd enough to take out the loans anyway and then skip town.

<comment><USER15> It sounds like she took the loan because the government promised a particular repayment scheme. I don't get how you can be mad at the individual in this case, when the government is the one that renneged on its promise.

</comment></comment></comment><comment><USER16> It's interesting to me that the people highlighted in the article are creative enough to do things to avoid repaying their student loans but aren't creative enough to turn their education into a higher paying job. It strikes me as misdirected energy.

The heart of the article is the debt of student loans are getting so great that more people are taking drastic measures to avoid repayment. The article I wish I had read was how some people aren't entrepreneurial enough to turn their college education into cash. More people should learn how to negotiate their employment lives better. I renegotiated my salary immediately after graduating because (A) I knew the market values college grads higher and (B) I wanted to try to raise my pay just to see what happened. Why don't others see their degree as a bargaining chip to be played when negotiating? Why aren't some people willing to employ riskier plays?

"I couldn't believe I couldn't find a job in America." \-- Albright, from article

Creativity and entrepreneurial spirit is especially needed for people who get degrees that don't have obvious market potential. For example, some people say a history degree isn't worth much However; entrepreneurial individuals with history degrees have gone on to make a great living making educational content for online media. The job didn't exist so the individual created it. Sure, it's a risky proposition for the individual but they're already playing risky from a market potential standpoint. I feel like Albright from the article could have used this framing to his benefit; but instead, he fled his debts.

<comment><USER17> > More people should learn how to negotiate their employment lives better. I > renegotiated my salary immediately after graduating because (A) I knew the > market values college grads higher and (B) I wanted to try to raise my pay > just to see what happened. Why don't others see their degree as a bargaining > chip to be played when negotiating? Why aren't some people willing to employ > riskier plays?

You have no bargaining power if you have no differentiating skills or knowledge.

</comment></comment><comment><USER18> I wonder if these news stories intentionally pick weak examples of people to highlight. 20k and 30k debt, for communications and history degree, so now you have to flee the country? Okay.

<comment><USER19> The people who bought homes in 2000's that they couldn't afford were acting irrationally, too. It's easy to dismiss this and think "wow these people are dumb, serves them right..." (my first reaction), but then I think: wait, these are just a few examples they found who are willing to share their story. How many people are out there defaulting on their loans that we don't know about?

<comment><USER20> Why do you say they were acting irrationally? They were broke and they saw they could still live in a 1/2M house--sounds pretty rational to me, especially if you can just drop the debt via bankruptcy.

With colleges, there is a nasty effect that student loans are inflating tuition prices and punishing the financially responsible people who save money for tuition. It's almost more rational to make sure to have no savings and benefit from the free government money.

</comment></comment></comment><comment><USER21> In Malaysia, those who default on their student loan are barred from traveling overseas. Since it's taxpayer's money, people are not happy when you are free to travel overseas without settling your responsibility. At least that's the impression from asking around (I'm not local).

"Can't find a job" won't fly here, as you can literally get burger-flipping jobs easily—you can't walk to a mall without seeing dozens of "Admin/sales/waiter staff needed". Also, most uni graduates have a family (rent-free stay).

What makes US different? Student loans not from taxpayers money? Low-paying jobs impossible to get? Parents don't let their kids stay until they can afford their own place?

In Indonesia, the govt doesn't even have money to give loans to students.

<comment><USER22> It's the cost. Tertiary education in America is unrealistically expensive, so you're locked into higher payments for longer (typically life). Even if a lower paying job is enough to pay up, your entire life purpose becomes paying off a student loan. Without the college and loan you would have had a shitty job but $300 more, nothing else would be different.

In South Africa the banks finance students, so the government doesnt hand out loans there either. You can pay off a typical degree in less than a decade. That system is completely unlike what Americans experience.

</comment></comment><comment><USER8> > He then went back to school to pursue a master's degree in comparative > literature at the University of Colorado Boulder.

You graduate with a degree that has little market value and can't pay your load, so your solution is to accumulate more debt for another degree with little market value?

</comment><comment><USER23> There are many sources of this problem, but I suspect the three that get the least attention are:

\- parental pressure to attend college

\- guidance counselors and school administrators pushing for college

\- the wholesale destruction of vocational schools

As a result, the US K-12 education system produces a never-ending deluge of students who believe their only life option after high school is to get a four year degree. Or joining the military, but that's a different discussion.

Like the people in this story, many HS grads study subjects with little economic viability.

Why?

That's the story I'd like to see. What motivated the choice to waste four or more years and tens or hundreds of thousands of dollars on a credential that will never pay for itself?

</comment><comment><USER24> Two of the three have become teachers in other countries, and one wanted to be a professor here. So they have at least some desire to teach, some ability to teach, but would rather move to a new country than teach K-12 here. And somehow we have a teacher shortage.

From my experience, quite a few people getting the degrees being criticised in this thread want to become a professor in that field. Teaching is what they want to do, but they just saw how terrible being a high school teacher would be.

</comment><comment><USER25> This is ridiculous. I left school with $30k in debt and paid it down with my $35k job. What we don't hear enough about are the people who foolishly go to a bank for their loans, and then take out massive amounts, avoiding all work and scholarships, then get some degree that has little to know market value. Student debt is not the problem. Banks, universities and the students are the problem.

</comment><comment><USER19> Where's a good place to park money if you're worried about an imminent student loan collapse? Or, put another way, what's a good hedge?

<comment><USER26> Most student loan debt is owned by the government so it wouldn't collapse quite like how mortgages sank the housing market. If the pipeline for easy loans dries up a lot of colleges and their dependent industries (publishing, construction, education focused IT providers) will probably take a big haircut or close.

<comment><USER27> True, but there has been a large drive toward refinancing student loan debt, which moves that risk into the private sector. I would be curious to see what percentage of government financed loans have been converted to private debt.

<comment><USER26> Oh yeah I've seen a lot of ads for SoFi and Laurel--also weirdly extravagant SoFi 'member' events. It seems like SoFi alone is probably fairly large. They've been reporting billions of dollars in consumer and student loans converted in a Q1 2018.

Also they've been issuing asset backed securities linked to their loans.

</comment></comment></comment></comment><comment><USER28> I couldn't afford to go to college when I left HS. So I took my life savings and certified as a CNE back in the day. I found a job and was able to attend school part time. My employer ended up funding a lot of it. It took a while but it worked out. I had no school debt and actually made a really good living.

If you can't afford it, find another way....

</comment><comment><USER29> The federal government shouldn't be in the loan business. Those are my tax dollars being redirected for uses for which taxes should not be applied. I'm not an ATM.

</comment><comment><USER30> Other than that time I payed off one of my student loans with a lump sum check I've been perpetually in default and they never came after me (other than an occasional letter) or garnished my wages...actually, now that I think about it, I can't remember getting a letter in quite a while, years perhaps?

Admittedly, I did try to skip the country a couple times but it never stuck.

Now I just work as an "independent contractor" so have no wages to garnish, no retirement plan and will have to work until the day I keel over dead from who knows what (or get replaced by the robots).

And yet I blame nobody but myself...

</comment><comment><USER31> I personally like to see loans during the first couple years capped and community colleges more subsidized.

<comment><USER32> Or scrutinized. I don't think it's ethical for the government to give $100k to a music therapy student, as they'll never be able to pay it back with their future wage.

</comment></comment><comment><USER33> I honestly think the mess the US is getting into here is just another example of failure of capitalism just like the health care system.

Now everybody struggles to get education and health care right but few places in the west does it seem to go as wrong as in the US.

People also choose dumb stuff in more socialized educational systems but because the government regulates the school system they don't make tons of useless study places.

In fact we have seen this effect in Sweden as private enterprise started taking over more schooling. The number of popular but useless studies shot up. It is a classic case of market failure. It is one of those areas we're bureacrats actually do a better job than the market.

</comment><comment><USER34> This article should be titled "How some dishonest people made bad decisions and instead of fixing them ran away." They blame others for their choices, and take no responsibility. Nobody made them get those degrees, take out those loans, or any of it. I get that the cost of education is a problem, but using loans and then skipping town to avoid repayment isn't only dumb, it's dishonest.

<comment><USER35> And yet, in the corporate world there's no condemnation of businesses that avoid paying back their debts by declaring bankruptcy.

Legally, that's not an option for student loans, but _morally_ is there really any difference? Is there an ethical reason why student borrowers are less deserving of the bankruptcy option than other borrowers?

</comment></comment><comment><USER36> Preventing educational debt from discharge in bankruptcy is one of congress's greatest crimes. The fact that they exempted their own children from the law is just the icing on the cake.

<comment><USER11> >they exempted their own children from the law

source?

<comment><USER37> It's not true. The original source of the claim appears to be a misrepresentation on Fox News years ago of Congress' student loan repayment plan for staffers.

[https://www.factcheck.org/2011/01/congress-not-exempt- from-s...](https://www.factcheck.org/2011/01/congress-not-exempt-from-student- loans/)</comment></comment></comment>


200 terabyte proof demonstrates the potential of brute force math - <AUTHOR> https://motherboard.vice.com/en_us/article/padnvm/200-terabyte-proof-demonstrates-the-potential-of-brute-force-math <comment><USER2> Sure, "proof mining" is feasible, but the goal of proving a theorem is only rarely finding _any_ proof, it is rather finding a proof that _makes sense_ , is "elegant", and in the best case scenario a proof that actually forms a sensible new theoretical framework in which the theorem becomes almost trivial to prove.

<comment><USER3> If something can be proven by any method, that means that it is _true_. An elegant proof is often more illuminating, but it isn't precluded by a direct method.

If the proven theorem is useful, isn't it better to be able to make use of it earlier, rather than wait for the elegant proof?

An example: If the AdS/CFT conjecture is demonstrably proven, it will elevate it from "useful computational technique" to "law of mathematics, probably how nature does it, too". I'll take any proof, as early as I can get it, in order to guide our experimental work.

<comment><USER4> But people often write papers anyway assuming X and Y and Z are true just to see what happens because of it, it's not like you really need it to be true to at least publish things.

And for your example that touches on applications of math, it approaches _scientific_ research from the wrong perspective. If some math follows reality, (agrees with experiment and even better makes predictions that turn out to be right), there is has to be some backing to it, even if the rigor isn't fully there. Physics often runs with ideas before Math has caught up (see QM in the early days, HEP in general, etc).

So, if we back off from applications who, quite frankly, only care about whether X is true in only a few, really important number of conjectures I can think of--big questions like P=NP for example--then math itself I imagine is, well, a study for its own sake. So, what above exhaustive proofs of your run- of-the-mill conjecture? Who would want to read a paper from a math person that merely iterates through a 200TB cache of data?

People forget that science is a social phenomenon as much as it is systematic process.

<comment><USER5> I don't want a math paper detailing 200TB of data. I want a paper telling me the generation of the digital input, the method that was used to actually prove it if it's novel. I want the authors to show how they verified the result and if it's important how they verified the automatic verification. The paper will end with "Oh and by the way, we used this conjecture because it was difficult, it's true. You can verify it yourself."

I want this all so I can do this myself, so I can prove a run-of-the-mill conjecture and not waste my time with it. I want this because proving is difficult and there is more to SAT than mathematical proofs, it is used in the industry. I want this because I trust a verified proof that the airplane won't crash more than a human proof.

The availability of computer proofs does not devalue the study of mathematics.

</comment></comment></comment></comment><comment><USER6> The article: [https://cacm.acm.org/magazines/2017/8/219606-the-science- of-...](https://cacm.acm.org/magazines/2017/8/219606-the-science-of-brute- force/fulltext)

Note that most people believe that co-NP /= NP, which implies that an unsatisfiability proof via SAT solving in general won't be efficiently verifiable.

<comment><USER7> Could this be used to prove co-NP = NP, though?

<comment><USER6> probably not

</comment></comment></comment><comment><USER8> I hesitated before clicking on that link as for a second I thought it would start downloading that 200 TB proof.

</comment><comment><USER9> Abstract:

\</comment><comment></comment><comment></comment><comment></comment><comment>-

Recent progress in automated reasoning and supercomputing gives rise to a new era of brute force. The game changer is "SAT," a disruptive, brute-reasoning technology in industry and science. We illustrate its strength and potential via the proof of the Boolean Pythagorean Triples Problem, a long-standing open problem in Ramsey Theory. This 200TB proof has been constructed completely automatically—paradoxically, in an ingenious way. We welcome these bold new proofs emerging on the horizon, beyond human understanding— both mathematics and industry need them.

<comment><USER10> > This 200TB proof

How do you verify a 200TB proof?

<comment><USER11> Not only do you need to verify the code, you also need to generate the proof multiple times since there is a significant possibility of hardware error with that large of a dataset.

<comment><USER12> ..and then rewrite it again via a clean room approach and run that one and see if they tally.

Preferably on different hardware.

<comment><USER13> The Pi (and other mathematical constant) computation records don't go that far. They verify random results towards the end with a different algorithm.

</comment></comment></comment></comment></comment><comment><USER14> Has there ever been a brute force proof that discovered the existence of a solution previously thought impossible? Something like a new tiling or proof by contradiction that found a positive example?

<comment><USER15> If I do not remember incorrectly, the proof of the Four Colour Theorem is essentially a brute-force one: a method of generating every possible graph that represents adjacency of tiling polygons on a 2D surface, and a subsequent colouring scheme for each and every one of them that never uses more than the desired four colours.

<comment><USER16> Everyone already strongly suspected that the FCT was true. Nobody was surprised by the result, it just took a computer to prove it.

<comment><USER15> You clearly are not a mathematician (nor am I). There's a _huge_ , unimaginably broad chasm cognitive chasm between "suspected", "conjectured", and "proved".

<comment><USER17> There is, according to quite a few, also a huge etc. chasm between 'proved' and 'proved by a computer'. Especially if it's a proof through exhaustive enumeration.

<comment><USER15> I disagree wholeheartedly. Proof by enumeration of finite cases is the most iron clad and idiot proof form of proof one can possibly aspire to. Proof by enumeration is fine and dandy. Some might cast a pall of disreputability upon a proof by enumeration by computer, but really it is no different — the computer and its program are merely a formal system somewhat more complicated and thus harder to inspect than mathematicians are used to, but this does not pose any real conceptual disconnect.

</comment></comment></comment></comment></comment></comment><comment><USER18> Does anyone know what the proof actually proves, and how the reduction was formulated?

<comment><USER19> Theorem — The set {1, . . . , 7824} can be partitioned into two parts, such that no part contains a Pythagorean triple, while this is impossible for {1, . . . , 7825}.

[https://arxiv.org/pdf/1605.00723.pdf](https://arxiv.org/pdf/1605.00723.pdf)

<comment><USER20> Yeah, when I saw "200 terabytes" I thought it was going to be about the Erdős discrepancy problem, since that's been making the rounds in the popular press, but turns out that only required 13 gigabytes for the 2010 proof.

I'm glad that Terry seems to have found a different proof. I attended a discussion of it during last week's Mathematical Congress of the Americas here in Mtl, and I think they were saying that Terry's proof seems correct.

</comment></comment></comment><comment><USER21> Mandatory insight-vs-bruteforce-in-science essay:

Peter Norvig, 2011: _On Chomsky and the Two Cultures of Statistical Learning_

[http://norvig.com/chomsky.html](http://norvig.com/chomsky.html)

</comment><comment><USER22> It's disappointing that the authors use the term "brute force" to describe modern SAT solving, in an article intended for people who may not be familiar with the algorithms used.

That term implies that the speed of the computer that was used to find the solution is the determining factor.

It is not. Modern SAT solvers use very elegant search algorithms that have enabled the solution of SAT-encoded problems that could never have been solved if only "brute force" was used.

</comment><comment><USER23> > You could take a basic algebra problem as an example: 2x + 100 = 500. To > solve this with brute force, we simply check every possible value of x until > one works. We know, however, that it is far more efficient to rearrange the > given equation using algebraic rules and in just two computations we get an > answer.

I gave some thoughts about this lately, and it occurred to me that it's a problem that is similar to how computers play chess. I'd like to know if I'm right.

The equation 2x + 100 = 500 is an algebraic identity and with algebraic rules there is a finite number of ways to transform it. For instance, x + x + 100 = 500, 3x - x = 400, x + 200 = 600 - x, and so on. Each of these new equations can once again be transformed in a finite number of ways. So basically the initial equation is the root node of a tree that represents all the ways the equation can be transformed.

So it's a similar problem than for chess, or many other board games, where you start from a position and you must explore a tree of possibilities to find the leaves (checkmates, for instance). For an equation the leaves are nodes of the form x = numeric value.

Does that mean success in solving board games can have applications in computational math?

<comment><USER24> Sorry, this is just a trivial observation, but if you're going to accept

x + x + 100 = 500

and

3x - x = 400

you can probably list any variety along the lines of

(n)x - (n - 2)x + y = 400 + y

so clearly that isn't a finite transformation space.

Now, these transformations might look trivial, but this problem is too. So there's an interesting question of bounding your algebraic transformations to a subset of all possible transformations that still make all possible solutions available, which ultimately doesn't answer yours.

<comment><USER23> True, it is not finite. Still, considering the algorithm will not attempt to search the tree exhaustively anyway, maybe the fact that the tree is infinite does not make much difference.

PS. On second thought the number of rules is finite, so the number of possibilities _has to_ be finite, at least if you apply the rules one at a time. It's the iteration of the rules that makes the tree infinite.

<comment><USER25> Nope, a single rule still has an infinite number of possibilities. As an example, multiplying both sides of the equation with an arbitrary constant produces a new valid equation, and there's an infinite number of constants to multiply with. (Bonus point: You get to choose what kind of infinity - countable or uncountable)

The reason a move tree[1] in a chess game has a finite number of nodes is not due to the finite number of possible transforms, but due to the fact that the number of possible _board states_ is finite.

[1] graph, really.

<comment><USER26> Infinite structures do not preclude finite analysis.

The theory of real closed fields is complete and decidable, for example.

<comment><USER25> Yes. Also, not germane to the topic discussed.

</comment></comment></comment></comment></comment></comment><comment><USER27> There's an error in the article.

        ((true AND false) OR true) AND NOT (true OR false)

is false, not true as asserted in the article.

<comment><USER28> Maybe he corrected it afterwards but he clearly says it's not.

</comment></comment><comment><USER29> A proof being valid does not mean the theory is useful or valid. If SAT was used, it means it is internally consistent in first order logic assuming the solver did not have a bug in it. (I bet the program was also verified.)

You can simplify these proofs by extracting subproofs and replacing them from database by substitution. It is like compression but makes more sense.

</comment><comment><USER30> From a technical standpoint, this is a terribly written article.

First, giving an example of solving an algebraic equation using brute force is misleading, because you can't enumerate all values of a real number.

Second, the risks of secrutity regarding brute force computing having nothing to do with SAT.

Also, their description of SAT is inaccurate. It's not new, and it was actually one of the first formal problems studied in computer science. Also, the original, linked paper notes that it is not brute-force computing that is itself the breakthrough, but the addition of heuristics in SAT solvers that make brute-forcing feasible.

<comment><USER31> This article is about SMT-solvers, which are used in formal verification, which can be about security. SMT solvers are kind of newish: [https://excape.cis.upenn.edu/documents/ClarkBarrettSlides.pd...](https://excape.cis.upenn.edu/documents/ClarkBarrettSlides.pdf)

<comment><USER30> The article and the linked paper ([https://cacm.acm.org/magazines/2017/8/219606-the-science- of-...](https://cacm.acm.org/magazines/2017/8/219606-the-science-of-brute- force/fulltext)) are about SAT solvers. The paper mentions SMTs briefly in passing. There may be a disconnect in whether SMTs are referred to as SAT solvers or their own distinct entity, though

Apologies for being nasty

</comment></comment></comment><comment><USER32> I suspect the average mathematician won't consider that "elegant".

<comment><USER33> Sure, but so what?

<comment><USER2> It is unlikely that such proof can be considered a contribution to mathematics. Finding "elegant" proofs (and not just "facts"), building conceptual frameworks in the process, is the heart of mathematics as a human activity.

<comment><USER34> Can't these proofs be useful in the context of "given that X is true we can say that"? In that case it doesn't matter how X was proven, it just provides a tool for future mathematics.

<comment><USER2> Ultimately, in mathematics it is important to _understand why_ something is true; simply knowing that someone (or something) "says so" is never good enough.

<comment><USER35> True, you don't understand why this is true. But you can understand that other things are true because this is true.

</comment></comment></comment></comment></comment></comment><comment><USER36> What did it prove?

<comment><USER19> Theorem — The set {1, . . . , 7824} can be partitioned into two parts, such that no part contains a Pythagorean triple, while this is impossible for {1, . . . , 7825}.

<comment><USER36> Wow, interesting. Is the 200 terabyte proof necessary for that -- could it be refactored into something smaller?

</comment></comment></comment><comment><USER37> This one is "from The Book" \- P.E.

</comment><comment><USER38> I can't wait for the day when a proof is 'discovered' that no one can comprehend.

<comment><USER39> A 200TB proof is already incomprehensible to humans.

The average reading speed is 200wpm. The average human lifespan is 79 years, or about 41.5 million minutes. If you did nothing but read at 200wpm for your entire life, you might read 8.30 billion words. A word is 5.1 letters, on average, and in ASCII, a letter is one byte. Multiply that all together to get an estimated human reading speed of 42.4 GB/lifetime.

It would take 4728 entire human lifetimes to read this proof once.

This is vastly underestimating the actual number, due to silly things like "eating", "sleeping", "learning to read", etc.

<comment><USER40> > _A 200TB proof is already incomprehensible to humans._

Not really, since what matters is the compressibility of the proof, not its size.

We might not be able to read all individual clauses, but it's enough that we know how the clauses are constructed.

</comment></comment></comment><comment><USER41> I really wish I'd known there would be an illustration of a naked woman in an advertisement on the right before I opened this at work.

<comment><USER42> Did not see it, shouldn't you use an adblocker at work for obvious reasons?

</comment></comment><comment><USER43> Assuming progress continues long enough: as proofs (and theorems) become more complex, the computational difficulty of verification, combined with the inherent physical impossibility of obtaining absolute certainty in the correctness of a computation will transform future mathematics into an empirical science, where mathematical hypotheses will be tested by computer, and results will be considered true only probabilistically.

<comment><USER44> That wouldn't be a proof though. The article is about exhausting the problem space rather than a probabilistic approach.

<comment><USER45> pervycreeper is making the point that all computers are, for practical purposes, probabilistic, since you can never know if a given result is because of a machine failure. In the normal sense of a math proof, one can not "exhaust the problem space" using a computer. Using a computer remains an empirical approach, since there is always the chance that the computer is malfunctioning.

<comment><USER9> The low probability of machine failure, combined with error correction means that by 4 layers of error correction, the chances of a failure (4 successive failures) are essentially nihil.

<comment><USER44> And furthermore, you could run it on different machines and have humans verify the results. In any case I'd trust the machines more than a human mind when it comes to consistency, and we already trust human minds with proofs.</comment></comment></comment></comment></comment>


AMD's Mobile Revival: Redefining the Notebook Business with the Ryzen 9 4900HS - <AUTHOR> https://www.anandtech.com/show/15708/amds-mobile-revival-redefining-the-notebook-business-with-the-ryzen-9-4900hs-a-review <comment><USER2> [https://www.anandtech.com/show/15708/amds-mobile-revival- red...](https://www.anandtech.com/show/15708/amds-mobile-revival-redefining- the-notebook-business-with-the-ryzen-9-4900hs-a-review/4)

The battery life alone just seems so appealing! Coupled with the CPU grunt, this is an ideal machine for someone like me that plays CPU-intensive games, and spends the rest of his time compiling code and running lots of programs. I wouldn't mind a dedicated Ethernet port, so I am eagerly awaiting reviews of the beefier Zephyrus G15.</comment>


Let's Clarify Some Misunderstandings Around Sign in with Apple - <AUTHOR> https://aaronparecki.com/2019/06/04/23/sign-in-with-apple-mi... <comment><USER2> In relation to the FAQ question "Will the affect you if you don't have an iOS device?"

I think the answer is might, probably should, and likely will. Enough apps are cross-platform or share backend code that developers "forced" to include "Sign in with Apple" on iOS may just include it across all their apps/sites. (Especially because they will want iOS users to be able to access their information from desktop browsers.)

It might be a rising tide that lifts all boats in that sense. Especially if Apple keeps their part of the bargain, it might even make sense for non-Apple device users to sign up for an Apple Account/iCloud just to use "Sign in with Apple".

I think that's an interesting question not enough people are thinking about yet.

<comment><USER3> This is what I'm hoping, that the Apple sign in and the user privacy features it provides will raise the bar for consumers, and eventually every consumer IDP will be expected to offer these protections and control.</comment></comment>