Excel can't save to paths over 218 characters - <AUTHOR> http://support.microsoft.com/kb/213983 <comment><USER2> C:\not\sure\about\the\rest\of\you\but\i\needed\to\see\how\long\that\is\to\fully\understand\the\implications\of\this\seemingly\arbitrary\limitation\\-\to\give\this\some\context\this\path\is\two\hundred\and\18\characters\

<comment><USER3> And even with tab completion that path shows why only a masochist with OCD thinks paths that long or deep are needed.

People who name their folders "Documents and images from the conference in August with CEO" deserve what they get.

Although 260 characters does seem like the Excel team think more like me than the rest of (more reasonable) MS.

<comment><USER4> > only a masochist with OCD thinks paths that long or deep are needed

I'm surprised you can't imagine working on a path that deep. Path arrangements are frequently thrust upon you in work environments and if you have a lot of work (or a lot of people sharing the same folder hierarchy), you may need a deep path structure to keep it organized. Attacking people as "masochists" because their paths are difficult to type seems unfair.

As for your example though, Windows usually shortens path components longer than 8 characters as the path gets longer (so "Program Files" becomes "PROGRA~1") so long single components aren't as problematic as many shorter components.

<comment><USER5> I am pretty sure it's more for historical reasons than a solution from MS for long filenames on win32. It's due to the application writing to the file- system, not the OS.

Earlier DOS FS (and others) were sometimes limited to 8 characters + 3 for extension and Windows just used to shorten filenames when writing to those FS. But to these days it still causes some problems for legacy software and you might see some PROGRA~1 hanging around but it's not from the OS, it's from the application (or its old out-date API for FS access) doing the shortening to fit the long filename it was given into an 8 characters word it thinks the FS can handle.

Windows's file explorer or file picker doesn't shorten path or filenames when downloading long filename from the web for instance (via Firefox or IE).

</comment></comment></comment></comment><comment><USER6> When i first hard coded MAX_PATH in my program i though the length was reasonable. Now i think 1024 would be better as a really large file name does happen sometimes.

Apple has a limit of 1024 apparently( correct me if I'm wrong )

Solution by microsoft: [http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long- path...](http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net- part-1-of-3-kim-hamilton.aspx)

<comment><USER4> Setting an arbitrary limit is now and will always be the wrong thing to do in API design. MAX_PATH is one of the most persistent reminders of this problem.

Neither 260 chars on Windows nor 1024 chars on the Mac is an actual limit of the filesystem. Both Windows NTFS/FAT32 and Mac HFS+ can actually support thousands of nested folders.

But the "MAX_PATH" concept persists and a large number of programs will fail mysteriously when the limit is reached. Even though the filesystem supports vastly more, we are stuck with operating systems that _encourage_ programmers to needlessly limit things. And there's never been a serious push to improve the situation. Long paths aren't a serious alternative since they're not supported by many common Windows APIs (plus, users get confused when \\\?\ appears in front of everything). It's completely insane.

<comment><USER7> The \\\?\ thing is a weird hack. There are other side-effects of \\\?\, for example the system will stop removing trailing spaces and dots from path elements. So you could have a filename that fits well within the limit of MAX_PATH but is inaccessible without \\\?\ - just end it with a dot or a space.

It's not even always MAX_PATH directly that decides when you need \\\?\\. IIRC for a directory you must fit within MAX_PATH minus the length of a slash and an 8.3 filename.

There are other limits, for example by the time a create gets to the NT APIs the path must fit in a UNICODE_STRING structure which has a maximum length of 0xffff/sizeof(WCHAR). Once I was curious about probing the limits and I created an absolute path that was longer than this limit. I did it with something like this cmd script:

        mkdir a
        :top
        ren a a.tmp
        mkdir a
        move a.tmp a\
        goto :top

Sure enough I was able to create a dir that would stump just about anyone's recursive-directory-delete code. To delete it on my own filesystem I wrote a similar rename-loop to unravel it. If you ever want to play a prank on a Windows programmer who recursively enters directories, show them this.

</comment></comment></comment><comment><USER8> Let me rant on something here. I work in finance, Excel is my everyday. We do a lot of manual monkey work (copy pasting stuff around a lot), when we "automate", we use the adamant (can't find a better word) VBA.

Now, you see how not helpful is this error message? Ok, try that when you are writing a macro in VBA. You literally start regretting the day you were born.

Nothing beats Python stack traces...

<comment><USER9> From that article, something I haven't seen before:

      To verify the error message that you receive in Excel 2007,
      press Ctrl+Shift+I. The following number is displayed in
      the lower-right corner of this error message dialog box:
      100202

It's no stack trace, but should be helpful in searching for proper error codes vs generic text.

<comment><USER8> Except I am on Excel 2003. The company is slowly moving to 201x although (can't remember the version, the email subject was "digital toolbox" and thus I directly deleted it).

<comment><USER10> So do you work with a 2003 version of Python?

<comment><USER11> Python 2.3 still had stack traces.

</comment></comment></comment></comment></comment><comment><USER12> And TFS can't handle path lengths longer than 260 characters.

I don't want to hear the BS about MAX_PATH. These are really annoying customer-facing flaws that scream "amateur hour".

<comment><USER13> Yup. All due to a choice someone made when deciding how to wrap the win32 file system APIs for dot-net.

Also, if you think that's bad, how about this. The TFS build system schedules builds on agent machines using a time format of UTC time of day. Seems fine except for that it is utterly broken in the context of daylight saving time. If you schedule builds that you want to run at a particular local time of day, which almost everyone does as it's an exceedingly common use case, then the actual time of day that build runs will be determined by whether or not the build definition was last saved during the current DST period. For example, if you have a bunch of build definitions and daylight savings time had just ended then builds could run either on time or an hour early.

</comment></comment><comment><USER14> It's also problematic for enterprises trying to roll out sharepoint. Site addresses tend to be pretty verbose so I can't see that playing particularly nicely given this limitation.

Extra points also for the super helpful error messages it throws.

</comment><comment><USER15> Ah.. the old 218 characters in your path problem! Because of course!

<comment><USER16> It's MAX_PATH in Windows (== 260. There's a 32K Unicode-equivalent limit[1]). In Linux it's PATH_MAX, which is (very likely) 4096. That's a bigger number than 260, sure; but it's still a discrete one; instead of, say, ∞.

\---

[1] 'To specify an extended-length path, use the "\\\?\" prefix. For example, "\\\?\D:\very long path".' [http://msdn.microsoft.com/en- us/library/windows/desktop/aa36...](http://msdn.microsoft.com/en- us/library/windows/desktop/aa365247\(v=vs.85\).aspx)

<comment><USER17> For reference, the GNU Hurd kernel was designed to avoid fixed limits like PATH_MAX. As a result, they have reaped endless compatibility issues with software that assumes there will be some specific fixed limit: [https://www.gnu.org/software/hurd/community/gsoc/project_ide...](https://www.gnu.org/software/hurd/community/gsoc/project_ideas/maxpath.html)

<comment><USER18> And another proof that GNU Hurd is superior to every existing OS.

</comment></comment></comment></comment><comment><USER19> The msdn article [1] is a great reference on the strangeness of the Windows path naming conventions.

[1] [http://msdn.microsoft.com/en- us/library/windows/desktop/aa36...](http://msdn.microsoft.com/en- us/library/windows/desktop/aa365247\(v=vs.85\).aspx)

</comment><comment><USER20> This gets even worse when mixed in with emails, I recently bumped heads with the naming limitations as the naming of invoices exceeded the limits and rendered the excel file useless (it "existed", it would just error if you tried opening it).

File name limitation in 75 characters, so now my system renames the file when sending them by email to just the invoiced clients name, and retains the properly formatted one in the folder structure (It's a very detailed one following a "<course code>-<course name> <course date from and to> <student name> \- <billable company>.xsl" pattern as it revolves around certifications and needs to follow certain regulations, and obviously exceeds 75 characters with ease)

</comment><comment><USER21> This limitation is obviously put in place to make it easier for the NSA to index your documents

</comment><comment><USER22> Can't load them either, I guess. When I tried to open an Excel file directly from Sparrow I would get a "path longer than xxx" message. Saving it to ~/Downloads and then opening it worked just fine.

</comment><comment><USER23> No surprise here. Long path names have always been a pain on Windows, from not being able to open files to not being able to restore previous versions, backups, etc.

Hitting these limits is _very_ common on file servers.

</comment><comment><USER24> From their page, I offer a suggestion: Things to Try: Increase the maximum path length.

Jeez.

</comment><comment><USER25> It also can't open two documents with the same filename in different directories, which comes up a lot more often in my experience...

</comment><comment><USER26> does this apply to 2013? it is a rank amateur quality of mistake... and has been for quite a long time before 2007, since we lost the constraints on paths in early windows/dos land with Windows 95 I think...

</comment><comment><USER27> Neither can winrar, or was that fixed?

</comment><comment><USER28> Excel _2007_.

<comment><AUTHOR> Not just 2007 from what I can see and given the last update was before Excel 2013 was released, it could be affected too. Do you use 2013?

\--From the article-- Article ID: 213983 - Last Review: September 18, 2011 - Revision: 6.0 APPLIES TO Microsoft Office Excel 2007 Microsoft Excel 2002 Standard Edition Microsoft Excel 2000 Standard Edition Microsoft Excel 2010</comment></comment>


The secret to man's intelligence? POTATOES enabled larger brains - <AUTHOR> http://www.dailymail.co.uk/sciencetech/article-3189454/The-secret-man-s-intelligence-POTATOES-Humans-evolved-large-brains-ancestors-ate-starchy-carbohydrates.html

<comment><USER2> Wow, this is sloppy journalism. Ar drallison points out, potatoes (any subspecies) were unknown to the Old World altogether. The article makes _multiple_ references specific to potatoes ("It has been argued that an increase in meat consumption could have triggered the increase in size, but now scientists believe that we may have another food to thank: the humble potato.", and "They say starches would have been readily available to ancestral human populations in the form of potatoes", which is _categorically false_

The article implies that dietary glucose is necessary for survival, let alone optimal brain development. Neither is true, as anybody who has eaten a ketogenic diet (like me) can affirm. Although some organs need glucose (the brain is _not_ one of them!), the body can make all it needs from protein.

Agriculture only goes back 15,000 years or so, which is a blip in evolutionary terms. There is no indication of timeframe of the amylase adaptations,

The study is here: [http://www.jstor.org/stable/10.1086/682587](http://www.jstor.org/stable/10.1086/682587)

The abstract makes some similar claims about the _need_ for dietary carbohydrate, citing a 27-year-old paper, which is simply incorrect.

</comment><comment><USER3> The starchy carbohydrates were probably not potatoes which are a new world plant and domesticated fairly recently. [https://en.wikipedia.org/wiki/Potato](https://en.wikipedia.org/wiki/Potato).

The article states: "Dr Karen Hardy and her team at the Autonomous University of Barcelona say that there are five crucial reasons why a starch-rich diet was critical in human development." That suggests that the key is "a starch rich diet" rather than potatoes that enabled larger brains. It would be interesting to know where the starches came from, given that potatoes are not an option.

</comment><comment><AUTHOR> Full subtitle: "POTATOES: Humans evolved large brains because our ancestors ate starchy carbohydrates"

Our saliva suggests improved carbohydrate digestion: "...humans possess six salivary amylase genes, while other primates just have two, increasing the ability to digest starch. ...after cooking became widespread and the salivary amylase genes multiplied, this increased the availability of dietary glucose to the brain and foetus which, in turn, allowed the acceleration in brain size which occurred from around 800,000 years ago onwards."</comment>


Cloud computing customer bill of rights. - <AUTHOR> http://blog.jamesurquhart.com/2008/08/update-cloud-computing-bill-of-rights.html

<comment><USER2> "Bill of rights"?

I'd suggest _"You live by the cloud, you die by the cloud"_ , and everything else falls to contract law. Have your lawyer read your agreement carefully.

</comment><comment><USER3> I like some of the emphasis on physical location of the data store. I'd like to store my data in the country with the strongest privacy laws, please.

<comment><USER4> What's wrong with making known physical location a service that you buy, rather than a right? A right is really just a service that you can't not buy.

<comment><USER5> As a cloud service provider, it paints you stupid. At least for potential European customers. We can't store personal information about clients outside EU. Storing that kind of data in the cloud, without knowing where it... roams is a liability. Not helping your clients avoid liability makes for very bad business practice, hence you're stupid (CSP (Cloud Service Provider)).</comment></comment></comment>


AppstoreSpy a new mobile market intelligence tool - <AUTHOR> https://appstorespy.com/ <comment><AUTHOR> Hi. I'm the founder of AppstoreSpy a new mobile market intelligence tool. If you are mobile developer, marketer or product manager you must have installed our free AppstoreSpy Chrome extension for Play Store [https://appstorespy.com/playstore](https://appstorespy.com/playstore)</comment>


Robot Goes Rogue at Shenzhen Fair, Injures Bystander - <AUTHOR> http://www.sixthtone.com/news/robot-goes-rogue-shenzhen-fair-injures-bystander <comment><USER2> Headline inaccurate:

It didn't go rogue; it was teleoperated, and the person controlling it pressed the wrong button on the remote ("forward" instead of "reverse").</comment>


Amazon EC2 EU-West Outage - <AUTHOR>

I'm seeing this as a loss of network connectivity with external hosts. I have trouble connecting to external hosts and I have trouble ssh'ing into hosts running on EC2. Strangely, existing ssh sessions seem unaffected by the connectivity problem. Seems to be a problem with new connections. <comment><USER2> This was noted in AWS' status page for Europe:

> 7:26 AM PST We are investigating Internet provider connectivity issues in > the EU-WEST-1 Region. > 7:46 AM PST Between 6:41 AM and 7:25 AM PST we > experienced impaired Internet connectivity affecting some instances in the > EU-WEST-1 Region. The issue has been resolved and the service is operating > normally.

Should be resolved by now though. If it isn't, you probably should contact support. They're very good at responding to that.</comment>


Ask HN: What happens when a solely-responsible engineer quits a startup? - <AUTHOR> For example, at a company that has "an" iOS developer or "an" Android developer, as opposed to a team - a pretty common arrangement in startups, I think. This person would be entirely responsible for a component of the company's product. They might be the only person at the company that even knows the language they're working in, if the backend/web engineers are using Python, Ruby, or JavaScript for their server code - doubly so for an iOS developer, since Swift knowledge isn't anywhere near as common as Java knowledge.<p>How does the replacement process work? The team would be interviewing someone without any knowledge of the language and frameworks that candidate would be working in, and dropping them into a codebase that no one can explain to them, even if the documentation coverage is great. <comment><USER2> > What happens when a solely-responsible engineer quits a startup?

\- The management will try its best to keep the person. Raises, counter- offers, benefits will be put on the table.

\- The management will try its best to delay the leave until a replacement is found.

\- A sudden increase of communication and praise from the management.

> How does the replacement process work?

It depends on the contract. Some companies can use the notice period as defense. Some can hold you for as long as 6 months, using that period to keep you as well as find and train your replacement. Some companies won't let you leave unless a replacement has been found and trained to a sufficient level. This goes as far as making you find the replacement instead of the management.

\---

Normally, there wouldn't be a "solely-responsible engineer". If the startup was managed correctly, there will be at least one other person who knows what the other person is working on. That way, even if the weakest link falls off, the entire company doesn't suddenly tip over. Startup people have fancy names for these things. A team that knows a bit of what everyone else is working on is called a "cross-functional team". A developer that's part of that team is a "full-stack developer". It's just a fancy way of saying a developer in this team has more work to patch up management and HR issues like say, losing someone suddenly.

</comment><comment><USER3> Honestly, early on in a startup it is rare to have such specialization. That usually happens later. Usually early on you have 1-2-3 jack of all trades that can and are willing to do whatever so the chances loosing one causes that kind of disruption is rare. Although it is not unheard of, and if so, there are ways to manage. As others already said, you first counter with reasonable offers but only as a means to replace the person, as let's be totally honest, a founder shouldn't consider this a long term resolution as the employee already showed they want to leave so expect they will want to leave in the relatively near future too.

Outside of this, funded startups many times turn to advisors and investors to help them find a qualified candidate. And when not possible they may use a recruiter to find a person. For all the shit recruiters take, they have a place in the market, otherwise they wouldn't be there.

</comment><comment><USER4> Some companies hire a consultant to do part of an interview. E.g. "Do a phone interview. Tell us if this person is good at <database or programming language". It's a good investment compared to hiring the wrong person for a job. As for dropping somebody into a codebase nobody else in the company knows: that's sadly business as usual. Ideally there is a hand-over period of course.

</comment><comment><USER5> IMHO, it's not that common (or wise) to split roles like that, fwiw.</comment>


GitHub should let users know about problems and downtimes - <AUTHOR> When Github has problem they should show a banner or another sign in the main website about it. I'm a paying customer who hugely depends on their service. I shouldn't investigate if GitHub has a problem. I know that they have a status page, but it's not enough at all. When a problem occurs, the first thing that I do is to check if I did something wrong, Sometimes it more than few minutes. You can multiple this with dozens developers in my company (and most of them don't even know about this page). <comment><USER2> As you alluded to, there is a status page ([https://www.githubstatus.com/](https://www.githubstatus.com/)) and there is probably a simple reason that they don't rely on their main site to show critical status.

Hosting the status of the current service using the current service is not traditionally a winning combination.</comment>


Apple honors eight developers with annual Apple Design Awards - <AUTHOR> https://www.apple.com/newsroom/2020/06/apple-honors-eight-developers-with-annual-apple-design-awards/ <comment><USER2> So the companies are honored, not developers personally. Phew, I already feared I have to look at ugly nerds. Dodged a bullet there Apple, would be a bad fit on a fully stylized site.

</comment><comment><USER3> No Mac apps.

<comment><USER4> At least some of the games (the ones on Apple Arcade) are also available on Mac.</comment></comment>


Are ur contacts banned on Twitter? - <AUTHOR> https://whosban.org/ <comment><AUTHOR> good one. That's a graphical alternative to [https://shadowban.eu/](https://shadowban.eu/)

</comment><comment><USER2> Unlikely anyone will have Twitter contacts in Ur. Given it was abandoned c.500BC.</comment>


The IRL Social Graph - <AUTHOR> http://thegongshow.tumblr.com/post/1003191434/the-irl-social-graph

<comment><USER2> Agree that [1] social graph value is both proportional to proximity to IRL and massive, [2] current products/offerings are actually pretty far away from IRL and [3] that Google doesn't seem to be their culturally [4] that Facebook is probably not going to get there and that fundamentally the [5] data is fragmented across various platforms (your points re BlackBerry and Foursquare).

The Fridge is a YC company from the most recent batch (the YC demo day is today and tomorrow) that is taking a shot at this from essentially the standpoint Paul Adams outlined. It's got to be very, very tough to build something like this directly from a cold start, though. Especially in 2010 versus 2006.

If the incumbents can't do it, and it's hard to break into, perhaps the problem is at least temporarily intractable. In that case, it leaves the door open to something like Hunch's interest graph, where common clusters of interests (rather than IRL relationships) drive the connections.

[I also posted this comment to the blog post]</comment>


Vulnerabilities in OpenBSD's Hypervisor - <AUTHOR> https://marc.info/?l=openbsd-tech&m=158176939604512&w=2 <comment><AUTHOR> The major issue has just been fixed:

* [https://marc.info/?l=openbsd-cvs&m=158180761313544&w=2](https://marc.info/?l=openbsd-cvs&m=158180761313544&w=2)

Taking the opportunity, I'd like to point out that Max wrote NVMM and KASLR, both first appearing with NetBSD 9.0 released earlier today, to put some context into the rest of the comments about ASLR in OpenBSD:

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

* [https://wiki.NetBSD.org/security/kaslr/](https://wiki.NetBSD.org/security/kaslr/)

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

<comment><AUTHOR> Looks like it hasn't actually been fixed, after all:

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

</comment></comment><comment><USER2> A followup [https://marc.info/?l=openbsd- tech&m=158177725606272&w=2](https://marc.info/?l=openbsd- tech&m=158177725606272&w=2) suggests that "the bug is at least 28.5 years old."

<comment><AUTHOR> That's funny, because it's an AMD64-specific hypervisor that's first been released with OpenBSD 5.9 (released March 2016 — 4 years ago).

</comment></comment><comment><USER3> > this is not just a write-where, this is a full guest-to-host write-what- > where

Ouch.</comment>


Google churning out chromium nightly builds. Autoupdater here - <AUTHOR> http://www.howtotuts.com/2008/09/05/how-to-download-the-latest-nightly-build-of-chrome/

<comment><USER2> The snapshots seem to be closer to hourly: [http://build.chromium.org/buildbot/snapshots/chromium-rel- xp...](http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/)</comment>


Object-Oriented Design Heuristics (2017) [slides] - <AUTHOR> https://www.slideshare.net/kim.mens/objectoriented-design-heuristics <comment><USER4> The book the slides are based on is by far the best book on OOD/P I've ever read. Learned a lot from it. OO is such a hard subject that most of the people end up writing procedural code with classes (looking at you java).

<comment><USER5> The book you're talking about is it the one mentioned (i quickly looked at the slides): Object Oriented Design Heuristics?

<comment><USER4> Yes, Object-oriented design heuristics by Arthur J. Riel

[https://www.goodreads.com/book/show/179206.Object_Oriented_D...](https://www.goodreads.com/book/show/179206.Object_Oriented_Design_Heuristics)

</comment></comment></comment><comment><USER6> I try to follow a few rules when writing OO code.

1\. Make classes do one thing that is basically summarized in the class name. (This also takes care of 'separation of concerns')

2\. Be careful to not over-abstract. That results in many tiny classes, aka ravioli code. Nobody, not even you, will remember what all those little bastards do. 3\. If a class is bigger than a page (or two) of code, it's probably too long.

4\. Design patterns are for inspiration, not the law. Solve problems, don't prove how smart you are.

5\. Make your classes as simple as possible. You will thank yourself later.

6\. If you have to write a comment that explains how some confusing thing works; that code block is a good refactoring candidate.

7\. Refactor, refactor, refactor. Refactoring is rewriting code for clarity. The more you do this, the more your code will become clear to the reader. I find refactoring often reduces my LOC drastically.

8\. If you just learned a technique/pattern and that technique/pattern is suddenly popping up everywhere in your code; make sure you aren't just using it because it's fun. Say you just learned what a singleton pattern is, now your code is littered with singletons. That's a good sign that you are forcing yourself to use your new found toy and reconsider.

9\. Long method names. Don't be afraid to have long method names. Yes, it looks ugly, yes it takes time but you will thank yourself later and often a long method name will compensate for the lack of documentation on that method.

10\. Your program should basically be a bag of loosely related, self-contained components. Think of them like parts of an engine, they each do one thing very well and they each have an interface to the rest of the engine. Also, they can individually be swapped out for another component (as long as they bolt up to the engine appropriately).

Understanding OOP is definitely a paradigm shift in thinking and it is also loaded with many a foot gun (especially when you are new).

<comment><USER7> My rule for writing OO code is to not write OO code.

Procedural code is:

\- simpler to analyze, audit and (formally verify)

\- simpler to multithread

\- maps to what a program does: a series of transformations applied to an input

\- maps to low-level construct in the CPU, i.e. call/ret

\- doesn't force you to use heap memory and suffer cache misses due to rampant pointer indirection.

Note: I intentionally avoid saying functional programming.

There is a balance between having no state (Haskell) and allowing mutation because mutation is useful (C, OCaml).

<comment><USER8> It is true that some parts of your project can benefit from centralised approach (and that sometimes you really need to count every tick) but this fashion of blaming OOP is really weird and should stop.

It is still the best way to architecture big systems. I'm not talking about classes, I'm talking about decentralised, decoupled, small systems, communicating with each other using messages.

<comment><USER9> > this fashion of blaming OOP is really weird and should stop

Right. There are many places where OO fits well.

As you mentioned in the medium/large on the services/systems level. But it is also a good paradigm to model pretty much any real, outside thing. A database, a file-system abstraction (loading configs etc.), an external web-service, a peripheral device (keyboard, mouse), a GUI context (the whole thing, not the parts) and so on.

In these cases we want the properties of OOP: local retention, message passing, abstraction through public interfaces and state-machine-like behavior.

The issue arises when we model data with OO: A Person is not an object in your system. It is an associated data-structure. Treat it as such. A User interacts with an interface (CLI, config files, GUI...) treat those as objects. The data about the User is just data about the User.

I don't have an authoritative opinion to offer here. I'm just a dude who writes programs. This is merely the model that works for me.

<comment><USER7> > In these cases we want the properties of OOP: local retention, message > passing, abstraction through public interfaces and state-machine-like > behavior.

That's not OOP but Actors or event loops.

<comment><USER9> Depends on who you are asking.

[https://userpage.fu- berlin.de/~ram/pub/pub_jf47ht81Ht/doc_ka...](https://userpage.fu- berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en)

[https://www.infoq.com/interviews/johnson-armstrong- oop/](https://www.infoq.com/interviews/johnson-armstrong-oop/)

</comment></comment></comment></comment></comment></comment><comment><AUTHOR> (submitter)

The material in the slides is based on the book Object-Oriented Design Heuristics[0] by Arthur Riel.

[1] has a list of the heuristics. It may be incomplete.

[0] [https://www.goodreads.com/book/show/179206.Object_Oriented_D...](https://www.goodreads.com/book/show/179206.Object_Oriented_Design_Heuristics)

[1] [http://www.vincehuston.org/ood/oo_design_heuristics.html](http://www.vincehuston.org/ood/oo_design_heuristics.html)

</comment><comment><USER10> After a previous discussion here it seems people confuse classes with modules. At the risk of repeating myself.

Class based inheritance - <USER2>

Traits, roles, mixins - You are still thinking in terms of inheritance so its Meh.

Combining Data and Code - Slow.

Closures, Functors - Cool ... classes with single methods are as "single responsibility" you can get.

Interface Inheritance - Go / protocols from clojure - <USER3>

Interfaces without inheritance - Modules - Best ... the way software is meant to be written. This is the reason why APIs, libraries are so reusable. Modules are like contracts for the function call interface. Because of this you also get the ability to load plugins as opposed to the whole dependency injection.</comment>


FBI pushes private sector to cut ties with Kaspersky - <AUTHOR> https://www.cyberscoop.com/fbi-kaspersky-private-sector-briefings-yarovaya-laws/ <comment><USER2> I wonder how that is something the FBI should be doing. I always thought the US had it's somewhat-secret-security agencies divided between foreign and local, spying and acting, and public and government tasks. (which is why they have so many of them?)

If this was a problem for the country, wouldn't it be DHS's job? And if there was an issue to be looked in to, it's FBI's job. And if there is something about spying to figure out if someone is doing something, there is the CIA and the NSA depending on where they need to look?

On top of that: wouldn't this be something that should simply be looked at internally at agencies and if there is an actual problem, resolve it for the country by issuing a law or directive or bill or whatever name they put to rules the US-based companies have to follow?

<comment><USER3> Securing domestic computer networks and products from foreign attack surely fits within the FBI's jurisdiction. Obviously there's some overlap with the NSA in this mission (but not DHS -- they have very little in the way of computer crime experts), but this doesn't seem weird to me.

Basically: US law enforcement is telling US companies that Kaspersky products are likely compromised by Russian intelligence. Surely foreign law enforcement is issuing similar warnings about Symantec and McAfee products being compromised by the NSA.

<comment><USER4> NSA is DoD systems, DHS is other governmental systems and some critical private sector systems, FBI is counterintelligence investigations. They all overlap and help each other.

<comment><USER5> NSA is under Intelligence Community[0]. I think Defense Intelligence Agency is DOD's intelligence branch.[1] But my own wiki link is saying both NSA and DIA don't have parent agencies so idk..

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

[0][http://www.dia.mil/](http://www.dia.mil/)

[1][https://en.wikipedia.org/wiki/United_States_Intelligence_Com...](https://en.wikipedia.org/wiki/United_States_Intelligence_Community)

<comment><USER6> Both the NSA and the DIA are under the DoD. Both are intelligence agencies and are part of the IC. All of the IC members fall under the Director of National Intelligence (DNI). The NSA and DIA differ in their missions. The NSA is primarily focused on Signal Intelligence (SIGINT) whereas the DIA is focused on Human Intelligence (HUMINT), mostly pertaining to foreign militaries.

<comment><USER7> Those are euphemisms for spying and traitors.

<comment><USER8> more like "professional terminology"

</comment></comment></comment></comment><comment><USER9> This is essentially the same reasoning why other governments and their constituents shouldn't trust American tech companies. That's pretty well established thanks to some notable leaks.

<comment><USER10> Nowhere near to Kaspersky level though.

<comment><USER11> Indeed, significantly worse.

No actual technical mechanism has come out suggesting how Kaspersky is spying, only that it could. We've seen technical mechanisms which impact US firm's hardware such as Cisco and how they're embedding that malware into specific target's endpoints (postal intercepts). We've also seen firmware updates go out to US company's industrial hardware which MIGHT have needed the companies help to produce.

I'm yet to see anyone publish an article talking in technical terms about what Kaspersky is meant to be doing. All people keep repeating is that one of the top executives has Russian military experience. But technical facts are more key here than anecdotes or fear mongering. I'd stop using them tomorrow if someone can show me why, but even the FBI/DHS/NSA hasn't produced a paper on it or done a presentation at Blackhat.

Let's talk actual facts here. Software or even hardware isn't magic, if you can show that Kaspersky is evil show it already.

</comment></comment></comment><comment><USER12> The true reason why the FBI wants to get rid of Kaspersky: since American agencies do not have access to data of Kaspersky but do have access to all data of American antivirus vendors, they want everybody to switch to American vendors.

<comment><USER13> Define data? Eugene Kaspersky volunteered their source code. It's true that won't be an on-going effort and that back-doors are hard to detect through the millions of lines of code, but it's one hell of a sign of confidence.

Edit: Not dismissing the Russian scenario, but this is McCarthyism 2.0 as far as I'm concerned.

</comment></comment><comment><USER14> Highly skeptical that this isn't new red scare BS. Eugene gets to be the subject of so many dumb conspiracy theories.

A recent rebuttal by himself: [https://eugene.kaspersky.com/2015/03/20/a-practical-guide- to...](https://eugene.kaspersky.com/2015/03/20/a-practical-guide-to-making-up- a-sensation/)

Edit: and a more recent one: [https://eugene.kaspersky.com/2017/05/12/they- asked-me-everyt...](https://eugene.kaspersky.com/2017/05/12/they-asked-me- everything/)

Edit 2: _" FBI officials point to multiple specific accusations of wrongdoing by Kaspersky, such as a well-known instance of allegedly faking malware."_

Ok, if they are bringing that incident up, this really does mean they have nothing and are grasping at straws. This is referring to a time when Kaspersky trolled competitors who were stealing their signatures, and they made some fake detections. It's the antivirus equivalent of "Trap Streets" used by mapmakers. It doesn't create any kind of back door or weakness.

</comment><comment><USER15> The whole av industry is shady business - never know for sure whether some stuff is planted on purpose or is a result of a hack. (I used kaspersky stuff 20+ years ago - just don't have much respect for this industry in the first place. Also using kaspersky av in us gov settings or any critical business ops is just plain clueless)

</comment><comment><USER16> Interesting to look at these links, all 5+ years old:

1\. _Russia's Top Cyber Sleuth Foils US Spies, Helps Kremlin Pals_

2\. _What Wired Is Not Telling You – a Response to Noah Shachtman's Article in Wired Magazine_

3\. HN Discussion on 2

_____________________________

[1]: [http://www.wired.com/dangerroom/2012/07/ff_kaspersky/all/](http://www.wired.com/dangerroom/2012/07/ff_kaspersky/all/)

[2]: [https://eugene.kaspersky.com/2012/07/25/what-wired-is-not- te...](https://eugene.kaspersky.com/2012/07/25/what-wired-is-not-telling-you- a-response-to-noah-shachtmans-article-in-wired-magazine/)

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

<comment><USER17> man that is one deep hole I've fallen into :D very good reads

NOW I know win7 also phone backs home T_T

<comment><USER18> Yeah, and you can't turn it off.

[https://twitter.com/m8urnett/status/866353982217699328](https://twitter.com/m8urnett/status/866353982217699328)

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

</comment></comment></comment><comment><USER19> If USA is fussing over an antivirus program, Russia should be absolutely panicking about Windows, Office and other critical software from the USA.

<comment><USER20> Well, if they stopped using it altogether, it wouldn't remain critical to them for very long. It would probably be good for free software, too!

</comment></comment><comment><USER21> In the Lansing area all the municipalities using Kaspersky are being advised by the feds to drop it as quickly as possible. It was front page news a few days back.

[http://www.lansingstatejournal.com/story/news/local/watchdog...](http://www.lansingstatejournal.com/story/news/local/watchdog/2017/08/14/lansing- eaton-county-use-russian-software-feds-call-unsafe/552160001/)

</comment><comment><USER22> Presumably, the AV suite would send "telemetry" and related "data" to their servers for analysis...

"Microsoft Wins Appeal on Overseas Data Searches" [https://www.nytimes.com/2016/07/15/technology/microsoft- wins...](https://www.nytimes.com/2016/07/15/technology/microsoft-wins-appeal- on-overseas-data-searches.html)

[edit][https://www.mcafee.com/us/resources/solution-briefs/sb- quart...](https://www.mcafee.com/us/resources/solution-briefs/sb-quarterly- threats-aug-2015-1.pdf)

</comment><comment><USER23> How many are other security enterprises are out there who are as independent from US intelligence agencies?

<comment><USER24> Maybe nobody. But at least US intelligence agencies are operating in a jurisdiction where the rule of law is strongly enforced.

<comment><USER25> > Maybe nobody. But at least US intelligence agencies are operating in a > jurisdiction where the rule of law is strongly enforced.

Except when it's not.

</comment></comment></comment><comment><USER26> It looks like FBI is making great advertisement of Karpersky for security conscious people that has more than 2 neurons.

<comment><USER26> Kaspersky is the only company that discloses NSA and CIA's evil malware. They are the good guys here.

<comment><USER27> That is not true. Other AV vendors, such as FireEye and Symantec, repeatedly write about TTPs of all state actors they encounter.

<comment><USER26> So Karpersky is just more competent to find the ones from the USA Gov.

<comment><USER27> That is not the case.

It is actually quite difficult to intentionally ignore nation state malware from certain regions, because attributing the origin is not something a private entity can accurately do with confidence.

</comment></comment></comment></comment></comment><comment><USER28> Don't use stuff that's pwned by other intelligence agencies, use stuff that's pwned by us.

</comment><comment><USER29> From this reference in the article...

[http://www.reuters.com/article/us-kaspersky-rivals- idUSKCN0Q...](http://www.reuters.com/article/us-kaspersky-rivals- idUSKCN0QJ1CR20150814)

"Microsoft's antimalware research director, Dennis Batchelder, told Reuters in April that he recalled a time in March 2013 when many customers called to complain that a printer code had been deemed dangerous by its antivirus program and placed in "quarantine."

"Over the next few months, Batchelder's team found hundreds, and eventually thousands, of good files that had been altered to look bad."

"Batchelder told his staff not to try to identify the culprit"

This last part seems incredibly suspicious.. perhaps it was Microsoft trying to discredit Kaspersky

</comment><comment><USER30> Aside from all the innuendos and made-up proof, the one true statement you can make here is that Kaspersky is not, nor ever will be, providing backdoor services for the FBI.

</comment><comment><USER29> What happens if you use both Russian Anti Virus Software and an American Anti Virus Software?

Would this catch everything?

<comment><USER31> They'd probably catch each other.

</comment></comment><comment><USER32> I was surprised to hear an ad for Kaspersky on NPR this morning. I know there's a disproportionate number of ads for Barracuda and other security services, but I was curious about an entity in the news running ads. The hosts didn't mention any connections to current events.

</comment><comment><USER33> Seems to me like all the Chinese-made equipment everyone (including FBI) is using is a much more credible threat. This looks like they're just piggybacking on a witch hunt.

Disclosure: I am Russian-American, but always voted against Putin. Not that it mattered, of course.

</comment><comment><USER34> Is Jetbrains also a risk?

What if they build something bad into the Kotlin language?

<comment><USER35> You mean like easily allowing null pointer exceptions again?

</comment></comment><comment><USER36> Kaspersky can go fuck itself

</comment><comment><USER37> super surprised this thread isn't filled full of hate for our fed Intel teams. The IC works incredibly hard to keep us safe. Maybe this Presi and his hate for the IC is changing minds about our IC.</comment>


Girl visiting dad at Apple Campus showing iPhone X @ 2m:10s - <AUTHOR> https://www.youtube.com/watch?v=O1EpT41QAOw <comment><USER2> @ 3m [https://youtu.be/O1EpT41QAOw?t=3m](https://youtu.be/O1EpT41QAOw?t=3m)

in fairness, this is probably just some guerrilla marketing by Apple.

</comment><comment><USER3> YouTube says it's been removed.

</comment><comment><USER4> Mirror?</comment>


Reasons to Learn Redux as a JavaScript Developer - <AUTHOR> https://www.robinwieruch.de/redux-javascript <comment><USER2> I'm a Redux maintainer. I agree with the points Robin made, and want to toss out a few additional bits of info.

There's been a lot of chatter on social media over the last couple years suggesting Redux is dying or no longer needed. While it's true that there's a number of other options available, and that there's not as much _need_ to use Redux right away as there used to be, there's still plenty of good reasons to use Redux. In addition, Redux continues to be very widely used, and I've seen quite a few major apps choose to use it over the last year. I talked about these aspects in my Reactathon 2019 talk on "The State of Redux" [0] and my post "Redux - Not Dead Yet!" [1].

We recently released a new official package called Redux Toolkit [2], which includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once. It's now our recommended approach for writing Redux logic. It's also written in TypeScript, and the API is designed to provide a great experience in TS apps.

We're currently working on an ongoing major rewrite of the Redux core docs [3], which has several goals: updating content to better match today's target dev audience (removing references to "Flux", etc), simplifying explanations, encouraging easier patterns, and adding additional content and guidance on real-world usage.

As part of that, we've added a new "Style Guide" page [4], which has our recommended patterns and practices for writing good Redux code. We're specifically emphasizing and recommending patterns that simplify the amount of code you have to write, like using Immer for immutable updates, using the "ducks" structure for files and logic, treating actions as "events" rather than "setters", and so on.

Earlier this year, we also released new versions of React-Redux. v7.0 was a complete rewrite of the internals to improve performance, and v7.1 added a new React hooks API [5] as an alternative to the classic `connect()` API.

If you're interested in some of the behind-the-scenes details on how these libraries have evolved, see my posts "The History and Implementation of React- Redux" [5] and "Redux Toolkit 1.0" [6].

If anyone's got any questions, ask away!

[0] [https://blog.isquaredsoftware.com/2019/03/presentation- state...](https://blog.isquaredsoftware.com/2019/03/presentation-state-of- redux/)

[1] [https://blog.isquaredsoftware.com/2018/03/redux-not-dead- yet...](https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/)

[2] [https://redux-toolkit.js.org](https://redux-toolkit.js.org)

[3] [https://github.com/reduxjs/redux/issues/3592](https://github.com/reduxjs/redux/issues/3592)

[4] [https://redux.js.org/style-guide/style-guide](https://redux.js.org/style- guide/style-guide)

[5] [https://blog.isquaredsoftware.com/2018/11/react-redux- histor...](https://blog.isquaredsoftware.com/2018/11/react-redux-history- implementation/)

[6] [https://blog.isquaredsoftware.com/2019/10/redux-starter- kit-...](https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-1.0/)

<comment><USER3> This is disappointing. Partially for bikeshed reasons, but also for practical ones. Redux thunk is an anti pattern as far as I'm concerned but you're including it by default? Why? Just because it's the first (bad) decision people make when trying to handle async code doesn't mean it's the one that should be canonized.

The createAction function is unnecessarily verbose and the createReducer function obscures more than it abstracts.

<comment><USER2> I find your concerns very confusing.

In order:

Thunks are the most widely used middleware by a large margin [0], and we have frequently received complaints that there is no async middleware included in the Redux store by default. Thunks were in fact part of the store during the original development phase [1], but were made separate once the middleware API was defined [2]. Thunks are effectively the minimum viable way to write async logic that has access to interacting with the Redux store, so we include that in RTK out of the box to make that possible.

Sagas, observables, and other similar middleware are far too heavyweight and complex for us to endorse as the default async approach. I also strongly disagree that thunks are an "anti-pattern", and find them to be a highly useful tool (and especially so now that `async/await` syntax makes it even easier to write more complicated async logic in a readable form) [3].

You are always welcome to add another middleware or disable thunks as part of the store setup process instead if you want.

I don't see how this:

        const addTodo = createAction("todos/add")

is more verbose than this:

        const addTodo = (text) => {
            return {
                type: "todos/add",
                payload: text
            }
        }

We've had a version of `createReducer` shown in the "Reducing Boilerplate" docs page [4] for years, and there are literally hundreds of similar "lookup table"-type utilities out there. Including this in RTK is a no-brainer. It's even more valuable, because ours uses Immer inside to let you write "mutative" immutable update logic instead of having to nest spread operators. I don't see how this is "obscuring" anything.

Finally, our recommendation is that most of the time you shouldn't even be calling `createAction` and `createReducer` yourself. Instead, you should be using the `createSlice` function [5], which automatically generates action creators and action types for you, and calls the other two functions internally.

[0] Slide 38 in [https://blog.isquaredsoftware.com/2017/09/presentation- might...](https://blog.isquaredsoftware.com/2017/09/presentation-might-need- redux-ecosystem/)

[1] [https://github.com/reduxjs/redux/issues/1](https://github.com/reduxjs/redux/issues/1)

[2] [https://github.com/reduxjs/redux/pull/63#issuecomment-110575...](https://github.com/reduxjs/redux/pull/63#issuecomment-110575809)

[3] [https://blog.isquaredsoftware.com/2017/01/idiomatic-redux- th...](https://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on- thunks-sagas-abstraction-and-reusability/)

[4] [https://redux.js.org/recipes/reducing- boilerplate#generating...](https://redux.js.org/recipes/reducing- boilerplate#generating-reducers)

[5] [https://redux-toolkit.js.org/api/createSlice](https://redux- toolkit.js.org/api/createSlice)

<comment><USER4> Thunk is not a proper solution to the problem - it's a totally open escape hatch! You lose ALL the nice guarantees and behavior of redux when "action" no longer means "immutable, serializable event" and starts meaning "completely arbitrary function call with unbounded async effects."

There's no functional difference between using redux-thunk and just calling a "global" `dispatch` in random callbacks; both are equally unmaintainable in the face of interacting effects.

EDIT: Having a bunch of complex async logic all modifying your store in overlapping ways without careful coordination is like having concurrent operations on your database without any transactions or locking.

<comment><USER2> Actions are _still_ always an "immutable serializable event". The async logic is going to live _somewhere_, either in your components, or outside of them. Thunks are a way to move that logic outside of your components. The end result of the async logic is still dispatching plain object actions.

</comment></comment></comment></comment></comment><comment><USER5> Redux was such a mental overhead for me when I started out with it. The amount of boilerplate code that I had to write for the project I worked on was very frustrating. What helped me truly understand the concept was Elm.

These days I ask junior devs to learn Elm for a few days. We still use Redux, I will not choose it for new projects.

<comment><USER6> I see the Redux devs defending their tool in every comment thread around Redux and I have to say to them: it's not your fault and there's not a lot you can do to fix it by yourselves. The problem is every tutorial and training and boot camp and video I've ever seen around Redux treats Redux like heavyweight boilerplate and teaches you that you need five files with Redux where you only needed one with plain React and every function you add needs to touch all five of those files, including a file that only exists to write the name of the function you've added.

What I hear from the Redux devs does not in any way line up with what I heard from Brad Traversy or Stephen Grider, who have taught tens (hundreds?) of thousands of people on Udemy that the simplest React projects _must_ be used with Redux and Redux turns beautiful React code into dotcom-era Enterprise Java.

<comment><USER2> Yeah, unfortunately once something gets a large community, it takes on a life of its own.

Part of the issue is that the Redux docs _do_ show many of these patterns (`const ADD_TODO = "ADD_TODO"`, separate files and folders for constants / actions / reducers, etc). Dan has said several times that he didn't expect folks to literally mimic everything that was shown in the docs, but tbh that's what people do. He's also said he wishes he'd emphasized teaching it in some different ways.

We're doing everything we can to try to teach better practices and patterns now, but that can't magically change the gazillions of existing tutorials and codebases that are out there.

<comment><USER7> > didn't expect folks to literally mimic everything that was shown in the docs

Isn't that the point of documentation? To give you a reasonable, suggested way of incorporating a library into an existing project? This is almost saying, "the docs were wrong and everyone learned the wrong thing". I don't think you can blame package users for that. People reference documentation to know what to do, and also what to avoid, when using a new library.

<comment><USER2> Yeah, I know. I'm not blaming Dan here, specifically, just repeating what he's said several times himself.

That's why we're doing the docs rewrite. The target audiences have changed since 2015 (new devs learning Redux in a bootcamp vs folks coming from other Flux libraries), we've got a better understanding of how Redux should be used, and we want to set folks on a better path from the beginning.

</comment></comment></comment></comment></comment><comment><USER8> The issue with Redux is that a dispatch() and hence a state update causes a _synchronous_ (hence blocking) update of the view.

Andrew Clark better explains the difference in this tweet: [https://twitter.com/acdlite/status/1195453776217296896](https://twitter.com/acdlite/status/1195453776217296896)

> Redux architecture depends on the ability to block the main thread until > rendering is complete. Once you make rendering non-blocking, your store is > no longer synchronized with the UI. Leading to data races and > inconsistencies.

Many view layers are moving towards non-blocking rendering as they need to account for things such as different priorities based on what the user needs: for instance a user typing needs larger priority than a banner showing.

Once it is non-blocking it's hard to keep a store and several UIs elements in sync. For instance your store might say isLoading:true but the UI might not show that since it's rendering/working another higher-priority element on the screen. And then you might have another view that depends on the isLoading:true which causes another thing to appear on the screen before the other element is shown... all this leads to inconsistencies and race conditions.

Essentially the problem is that we have lots of code that does (especially in thunks):

      store.dispatch(FOO)
      const state = store.getState()
      // here we expect state to contain changes done by FOO
      // but with non-blocking UI this is no longer the case

<comment><USER2> Andrew's not wrong, but I'm also not entirely convinced it's as big of a concern as he's describing.

For context, Andrew is a co-creator of Redux, and is a current React core team member. He's spent the last couple years working deeply on the "React Fiber" rewrite that became 16.0, and the "Suspense" and "Concurrent Mode" features that are now available in alpha.

He's definitely right that Redux's synchronous update model is somewhat limited compared to how React's "Concurrent Mode" needs to be able to dynamically re-order state updates based on priorities. But, it remains to be seen how much of an actual problem this is in practice. Andrew's been heads- down in this feature for a long time, and so it's natural that he's seeing everything through that kind of a lens.

We've got an open issue to discuss and analyze how React-Redux might be able to work better with CM and Suspense:

[https://github.com/reduxjs/react- redux/issues/1351](https://github.com/reduxjs/react-redux/issues/1351)

</comment></comment><comment><USER9> Redux is tremendously verbose though. Message passing isn't attractive when the state space is big.

<comment><USER2> That's specifically why we've created our new official Redux Toolkit package - to simplify the incidental complexity that is not actually part of Redux itself. Try it for yourself :

[https://redux-toolkit.js.org](https://redux-toolkit.js.org)

</comment></comment><comment><USER10> MobX does not get enough love and has been around for a while

[https://mobx.js.org/README.html](https://mobx.js.org/README.html)

<comment><USER11> MobX doesn't get enough hate either. Inexperienced devs will put everything in the global state and end up with a soup. And, as opposed to Redux, it is _magic_ - I would have trouble rewriting it from the docs, would you be able to do it? Note that it also changes the way React render method works. All in all - no thank you.

<comment><USER10> Sloppy developers are sloppy in redux as well.

Vuex has a nice pattern with plugins and modules.

Mobx stands on its own outside of react. I understand many people don't consider redux outside of react and don't talk about one without the other. As other comments mentions the mobx state tree is more a drop in replacement for redux. I am unfamiliar with the render method changes you reference- do you have more info or a link?

<comment><USER11> > Sloppy developers are sloppy in redux as well.

Agreed. But the mess they make in MobX is in my experience much more difficult to clean up.

What I meant with render method changes is that mobx tracks access to state during a call to render (which means that anything that might influence rendering, _must_ be accessed inside render). It seems like it's not a big deal, but it can lead to surprising bugs if one is not careful. Redux otoh uses props to pass data to render, which is much more explicit and allows regular react dev tools to be used.

I might have some details wrong - I met MobX a year ago with two legacy apps and it was a hell to maintain. Still is actually, I'm just not that involved in these projects anymore. It's magic, and not in a good way. For new projects we use Redux Toolkit, which strikes a nice balance between verbosity and being explicit.

</comment></comment></comment></comment><comment><USER12> Redux is a mixed bag but I'd say it's one of the most elegant ways to handle state.

Biggest problem and reason why people (me included at the beginning) don't like Redux, you should know when you need it and you should use some abstraction layer (eg RTK). One cause could be the docs: while the maintainer try their best to educate a lot (also in this thread paired with interesting link building strategies), there is not quick and easy way to get into Redux. If you start with RTK's docs, you don't understand everything. Then, you need to read the Redux docs, then again back and forth. And this just takes too long to grok an actual simple API.

One easy indicator for Redux or not: does your app need kind of an undo feature, then you should dive into Redux and I'll promise you. there is no other way to do this in such a sane, maintainable way.

<comment><USER2> As mentioned elsewhere in the thread, we're working on a major rewrite of the Redux core docs. If you've got any specific suggestions on how we can improve them, please let me know.

When you say "no quick and easy way to get started", are you referring to code or docs?

In terms of explanations, RTK is currently documented as a separate layer on top of Redux, because that's really what it is. So yes, we do assume that folks have learned what Redux is and how to use it already, and RTK is then a faster and better way to write Redux logic instead of doing everything "by hand".

As part of the core docs rewrite, we do intend to completely redo the tutorial sequence, and we'll be introducing RTK somewhere in the tutorials and encouraging its use.

<comment><USER12> I meant the docs. It's like decades ago like when you wanted to learn Rails. Then somebody said stop! First learn Ruby... This is not how people learn. There's too much time between learning and trying, so there's no proper and face-paced feedback loop. Let's try to get into somebody's head who's ok in react and slowly wants to get into state management but having no clue of nothing:

His mind:

\- Ok, where should I start?

\- Which is the best? Mobx, redux, just ContextProvider or local state??

 _The poor guys falls into the rabbit hole and reads Reddit, HN, Github issues for hours, still not sure what to do; 2 hours later_

\- Ok, let's try redux, for whatever reason, the maintainers seem to be quite active

 _The poor guy tries to decide if he should go just with redux /react-redux or rtk; former because it is good to understand the foundation, latter good because just to avoid boilerplate and that's what this acemark is promoting everywhere. The guy is still overwhelmed and don't forget doing decision is hard; it's one of the biggest struggles for humans_

\- Ok, I guess I need to start with redux because it's the foundation.

 _He sees all the theory, new terms, the boilerplate and there 's no fast- paced feedback loop; he just think heck and checks out mobx, 4 hours later_

\- Man mobx is even more weird, totally unstructured and while mobx's maintainer seems to be a nice guy, my gut feeling is: stay away

\- Let's check out npmtrends, oh great, npmtrends shows that people also don't like mobx, cool, it has much less traction, decision made, nice

\- So, let's try redux again, maybe this time I start with RTK

 _We know what happens, RTK has better feedback loops but w /o the basic knowledge of redux he will struggle, 6 hours later after jumping back and forth the both docs_

\- Lets stop here, tomorrow is another day.

 _He is out of flow, motivation is down, the next day he doesn 't continue because the whole experience didn't feel good, he writes a post on HN that redux sucks steel and maybe looks the next week again on it_

The situation is a bit like with kubernetes; until you have proper feedback loops with k8s you need days, with new k8s distros this got better but the biggest bummer are the k8s docs, too much, too verbose, so many new terms, no feedback loops at all and every k8s examples has minimum 100kb yamls.

What would be great and I know that writing good docs is much harder than actual code:

One and only piece which the reader should read first, which teaches him redux foundation, react-redux boilerplate and rtk within max 2 hours. After that he should have a working example AND should have understood it. No links to other resources, no nothing.

This main piece should be linked everywhere in the Github readmes of all redux relates projects in bold and h1 READ OUR MAIN PIECE FIRST, on all the doc pages and in all forum posts. I mean look at your post's footer in this thread: so many links, why? You need one entry point. RTK could be the entry point, it just needs a bit more flesh on redux and should be declared as the entry point of redux. There's one disadvantage though: with RTK as entry you'd kill the ecosystem around redux but IDK if you did this anyway by declaring RTK the standard way. And you would have a lot of redundant docs with redux/react-redux. Or maybe we need to merge all because maintaining redundant docs is just too much for an OSS project.

Whatever, all not easy but there must be a way because redux is the most underrated thing in the frontend world, it's def the best state management and RTK is a nice and long deserved abstraction.

<comment><USER2> Thanks for the feedback. I've pasted it into our "Docs Rewrite: Overview" issue for reference [0].

Responding a bit further:

There's not much we can do about folks going back and forth between Redux and various non-Redux-y things. That's outside of our scope and ability to help with.

Teaching-wise, there's several reasons why the docs are structured the way they are right now:

\- Redux itself is an independent library that is not tied to React in any way (and is used with other frameworks / UI layers as well). Our docs do mostly assume that you're using React, but the tutorials start out trying to show how you'd use Redux without any UI layer, to teach the basic concepts.

\- React-Redux has been a separate library from Redux itself since it hit 1.0. While we do teach the basics of how to use React-Redux in the Redux core docs, it has its own separate repo and separate docs site. Similarly, RTK was designed as an addon layer around the Redux core, so it also has a separate repo and separate docs site, and its docs assume that you understand the basics of Redux already.

\- That said, yes, the vast majority of Redux usage _is_ with React, and we are encouraging folks to use RTK as the default way to write Redux logic. So, it's very reasonable to have a docs page that shows how to jump right into using both of them as fast as possible. This is something I've already said I want to add to the docs, as a "Quick Start" page [1].

In terms of teaching flow and learning, there's various ways to approach explaining things. Dan Abramov wrote the original Redux docs content and structure, and his teaching style is very much "bottom-up, from first principles". You can see that style in pages like the current "Middleware" tutorial page [2], and his Redux videos on Egghead [3]. That approach works great for some people, but other folks just want to be shown _how_ to do something first, and learn the "why" later. It's hard to serve both groups at the same time.

One issue with teaching RTK first is that while Redux requires / expects that you use immutability correctly, RTK's use of Immer does hide the fact that immutable updates are happening in the background. It would be easy for someone who learns Redux via RTK to assume that writing mutating logic _is_ the right way to write reducers, not realize that it only works right due to the "magic" inside RTK's APIs, and then go write reducers in another project without RTK that are completely buggy as a result. I haven't yet entirely figured out how to handle that aspect, other than plastering warning notes all over the docs. That's one reason why I would prefer that folks understand the core principles first and how to do things by hand, and then switch to RTK to write the same code in simpler form.

As I said earlier, there's good reasons why we have separate libraries and separate docs sites. I can hypothetically imagine pulling things together into a combined docs site, similar to how NgRx does it [4]. But, I'm not sure how technically feasible it would be. It might require restructuring everything into a mono-repo, and I don't think I want to have to figure out how to migrate everything at this point.

All that said, yes, part of the goals for this Redux core docs rewrite is to provide a much more obvious learning path.

Finally, no, I don't think RTK is "killing the ecosystem around Redux", as the ecosystem is much broader than what RTK includes. RTK does obsolete a lot of similar libraries, but there's many other pieces out there for other use cases.

[0] [https://github.com/reduxjs/redux/issues/3592#issuecomment-57...](https://github.com/reduxjs/redux/issues/3592#issuecomment-570072854)

[1] [https://github.com/reduxjs/redux/issues/3594](https://github.com/reduxjs/redux/issues/3594)

[2] [https://redux.js.org/advanced/middleware](https://redux.js.org/advanced/middleware)

[3] [https://egghead.io/series/getting-started-with- redux](https://egghead.io/series/getting-started-with-redux)

[4] [https://ngrx.io/docs](https://ngrx.io/docs)

<comment><USER12> Thanks for your reply. Man, so much legacy, now I get it better. The Quick Start sounds like a good next step and some low hanging fruit!

ps and to understand your _That 's outside of our scope and ability to help with._ better: Are you not also maintainer of redux and react-redux?

<comment><USER2> Yes, I'm a Redux maintainer. My point is that I can't do anything to prevent folks from asking "what state management approach should I use?", looking at NPM trends, reading other tutorials that espouse differing approaches, or jumping back and forth between the React, MobX, and Redux docs sites. All we can do is try to provide as much helpful info in our own docs, and even that assumes that folks even _read_ the Redux docs. I see a lot of people asking "I want to learn $TOOL, what's the best course on Udemy?", and not even looking at the actual docs for $TOOL at all. Doesn't matter how good the docs are if people don't read them :(

</comment></comment></comment></comment></comment></comment><comment><USER13> Here's the library I wrote to replace redux for myself: [https://github.com/gunn/pure-store](https://github.com/gunn/pure-store)

It's the simplest API I could think of, has excellent type support, and handles immutability for you.

<comment><USER14> Thank you for pure-store, I'm surprised it hasn't attracted more attention!

The API is perfectly small and straight-forward, it's close to the ideal I imagine.

For a few years I've been using a similarly tiny library I wrote to reduce Redux's verbosity, but I may migrate to pure-store as it's even smaller and gets to the essence of state management.

Seeing the popularity of React hooks and Redux+friends, I know I'm in the minority of people who lament the direction they're going. I'm secretly hoping for a "destructuring" of the React ecosystem into more generic concepts/libraries/modules that work with or without React, carrying on the lessons learned but implemented as simple and independent as possible.

To me, pure-store (and immer for sure) is one of those libraries that point the way to a better future.

</comment></comment><comment><USER15> This horse has already been beaten into a bloody pulp, but Redux is so unnecessarily verbose. All due respect to the team behind it, but the DX of Redux is just horrible. I can only imagine how many developers simply gave up and became farmers because of Redux.

After being subjected to the "action types" modules full of redundantly named constants, having to touch five files for a small feature, I simply use Rematch now. Its API is like cake compared to Redux, while it still satisfies the same underlying pattern for consistency/testability.

"I'm going to tell my kids that Rematch was Redux"

<comment><USER2> As I've pointed to a number of times throughout this thread, we created our new official Redux Toolkit package specifically to address those concerns:

[https://redux-toolkit.js.org](https://redux-toolkit.js.org)

In addition, our new Style Guide docs page recommends patterns that avoid those issues as well, such as using the "ducks" file structure:

[https://redux.js.org/style-guide/style-guide](https://redux.js.org/style- guide/style-guide)

</comment></comment><comment><USER16> Anecdotally, Redux was absolutely awful to work with. Want a project chockful of middleware to make it passably usable? Use Redux. With all due respect to the Redux team, I simply don't think Redux scales in large applications. The "defaults" are insanely unproductive and encourage developers to cram tons of state in some global pile of state-soup just to claw back conveniences they lost. Monadic transformers and pure state transitions - great ideas in principle, carried way too far here in an ecosystem where the rest of the language and libraries rely on and use mutable state. Not to mention the lost performance, bloat for code that would be considerably shorter, and more disadvantages.

No thanks Redux, no thanks :/

<comment><USER17> I was under the impression redux is basically a message bus plus some sugar. Is that wrong?

<comment><USER18> No you're right. I find the comments deriding Redux as some bloated beast to be amusing...it's just a thing that lets you read and update a plain javascript object that different parts of your app can access.

People making things more complicated than they are is really a disease in the dev community.

<comment><USER16> > it's just a thing that lets you read and update a plain javascript object > that different parts of your app can access

Doesn't require a library, let alone an ecosystem of libraries.

<comment><USER19> Why implement this functionality from scratch when a tried and tested implementation exists.

<comment><USER20> To eliminate a dependency.

<comment><USER21> So implementing everything from scratch has more benefits than a well maintained and documented dependency?

<comment><USER20> If it's simple, yeah. A redux-type store does not have to be complicated. there are certainly performance optimizations to using redux versus rolling your own, but that would only happen in very large applications.

<comment><USER21> I agree that you can roll your own store. You'll miss lot of free functionality and the dev tools, but maybe it's not stuff you need.

I also agree that introducing a dependency at every opportunity comes with serious drawbacks.

Every situation is unique of course. In my case: At work, I value code that is more standardised so that I get less bugs, documentation / best patterns and crucially easier on-boarding process. For a personal project, I would definitely consider rolling out my own implementation, even just for the learning it comes with.

<comment><USER20> Yes, I agree. There are trade-offs to be considered. Those are definitely benefits to using Redux, for sure.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> Something I've wondered about the "immutable updates" pattern discussed in the article: do JavaScript engines optimize it somehow? On its face, it seems like it would turn a constant-time "favorite post X" operation into a linear-time "create a copy of the array of all the posts, replacing post X with a copy of post X where 'favorited' is true" operation.

Or do developers just assume that their UI code won't ever need to scale to large numbers of items? (Is this why JIRA's web UI is so slow when you have a couple thousand open tickets?)

<comment><USER23> Most functional languages have immutable persistent data structures that _don 't_ require a linear copy and are fairly efficient.

For example in clojure, sequences are implemented as 32-ary tries so insert/delete/update to any particular index will only cost around sizeOfNode * numParents=32 * log_32(n). This comes with a cost that indexing is now log_32(n) but it's usually a fair price to pay.

In javascript, immutable.js implement these same ideas (as least according to these talks where they talk about index tries and hash array mapped tries: [https://youtu.be/I7IdS-PbEgI?t=456](https://youtu.be/I7IdS-PbEgI?t=456))

If you want native support, javascript engines are actually free to swap out their implementation of arrays! I know they already do depending on whether they think your array is sparse("holey") or not: [https://github.com/v8/v8/blob/8.1.81/src/builtins/builtins-a...](https://github.com/v8/v8/blob/8.1.81/src/builtins/builtins- array.cc#L887). I also vaguely recall someone saying that unshift (push to front) is automatically optimized by switching to a deque/circular buffer but I might be remembering wrong. Anyway, they _can_ make these optimizations in a distant future but I don't think do today.

<comment><USER24> > _Most functional languages have immutable persistent data structures that > don 't require a linear copy and are fairly efficient._

This is true, but unfortunately those libraries/languages don't make use of that tree structure for "partial memoization" of derived data. They very well _could_ , but they don't -- even when you use Immutable.js in a Redux app, and you use Reselect, your selectors will take linear time when you mutate one element in an object/array instead of taking constant- or log-time.

<comment><USER23> Yea that's a good point. This matters when your derived data takes linear time to recompute. There are still techniques to make this work (but not automatically afaik). For example it's easy to make them efficient again if your computation is just an associative fold or reversible fold: [https://sci- hub.tw/https://link.springer.com/chapter/10.1007...](https://sci- hub.tw/https://link.springer.com/chapter/10.1007/978-3-642-39038-8_29)

<comment><USER24> That article talks about map and filter and fold, but I think there are also (trickier) ways to make joins and sorts work as well.

I think it could be a great technique for a lot of things -- compilers and database views, in addition to front-end state.

</comment></comment></comment></comment></comment><comment><USER18> Redux is not that hard to learn so why not?

Why spend more time debating whether to learn something than just learn it?

<comment><USER25> It's hard enough. I haven't needed it in developing/contributing to my own frameworks and there's an infinite amount of things to look into. Right from the Redux docs ([https://redux.js.org/faq/general/#when-should-i-use- redux](https://redux.js.org/faq/general/#when-should-i-use-redux)) - the link [https://gedd.ski/post/what-not-to-learn/](https://gedd.ski/post/what-not-to- learn/)

<comment><USER18> Dunno. Perhaps there's more functionality than the core but all it is is a plain JavaScript object that you "update" that you can access from different parts of your app.

It really isn't that complicated.

</comment></comment></comment><comment><USER26> My brain I guess works in a different way. I could never truly understand/appreciate value of the Redux for state management (well except that it is better then nothing).

For this type of things I've always used one or the other implementation of State Machine pattern. Seems way more clear to me.

It is not just about JavaScript. State management is a part of many applications and State Machine is a nice paradigm to work with. At least for my taste.

<comment><USER2> The key values of Redux are separating state update logic from the rest of the app, emphasizing writing as much logic as possible as pure functions that are easy to test, and enabling developers to better understand when, where, why, and how their state is changing over time.

Note that it's entirely possible to write your reducer logic as state machines, and in fact we explicitly encourage that :

[https://redux.js.org/style-guide/style-guide#treat- reducers-...](https://redux.js.org/style-guide/style-guide#treat-reducers-as- state-machines)

<comment><USER26> In my opinion State Machine is sufficient on it's own. To me reducers seem superfluous and in fact distracting from actually managing state. But as already said it is my own opinion coming from my own experience. We do not need to convince each other

</comment></comment></comment><comment><USER27> I honestly have no clue about Redux. I know a bit about react and used Mobx but I'm not a huge fan. When it comes to state managers and especially bigger frameworks with best practice patterns I get reminded a lot about PureMVC. This was the framework in the late 2000th that claimed to solve everything because it's so simple and slim. But with a bigger application the whole boilerplate setup exploded. And don't get me started with PureMVC pipes etc. Reading the comments here sounds like Redux has kind of the same issues.

</comment><comment><USER28> What about the built-in Context api ?

<comment><USER29> Absolutely. For most projects it is more than enough. If you have a basic CRUD app with token authentication you can get away with using that. There has been better form support thanks to new libraries coming out recently so I don't see reason to learn redux is, as was pointed out by other commenters, very verbose and requires a lot of boilerplate code to get started.

The context API is baked in, no external lib required. If you can afford to update your react codebase to the latest version without major breaking changes I would totally migrate to the context API.

</comment></comment><comment><USER30> Redux = functional zealotry</comment>


Dropbox clone that uses FTP (open-source): Beta feedback appreciated - <AUTHOR>

https://code.google.com/p/iqbox-ftp/
Hi everyone- The Windows IQBox download is now available. I'm announcing it here first, so I can get feedback before the official beta release. (Link: https://code.google.com/p/iqbox-ftp/)
Features: -Uses FTPS standard (or FTP): 100% standards-based. -Realtime: Monitors local file changes without scanning. (When checking FTP it needs to scan, but future versions will use a changelog file.) -Lightweight app: No Java. Made in Python, like Dropbox. -Merge folders: Initial sync will merge local & server. -Automatically scans FTP server (optional): New files are downloaded automatically. -Sync multiple FTP sites to different folders. -Mac and Linux release date is now Mar 30/2014 but alphas will be available mid-Jan.
I know that the Internet is littered with failed open-source Dropbox clones, or DIY solutions that are complex. That's why I did this. The difference is, we are laser-focused on (1) simplicity and (2) sync reliability.
The Plan: Make an FTPS-based client that lets you sync and share as easy as Dropbox. No special backend or non-standard protocols. Depending on demand, we'll add local encryption. This is a long-term project. This is the beginning. For now, we just sync and link-sharing will be added later.
Positive and constructive feedback would be great. Bugs can be submitted on the Google Code page: https://code.google.com/p/iqbox-ftp/issues/list Direct Windows Download: http://goo.gl/QlIrv5 <comment><USER2> FTP has to die!

<comment><AUTHOR> It's the only standard for file transfer we have, and it can be secure. Why does it have to die? (NOTE: WebDav has even more issues but that's the only other standard.)

<comment><USER3> > It's the only standard for file transfer we have

No, its not.

> Why does it have to die?

Because its problematic in a whole lot of ways, and FTPS doesn't help much for most of them. [1] identifies a lot of them (in the context of implementing a MacFUSE filesystem, but the issues apply to most applications.)

> (NOTE: WebDav has even more issues but that's the only other standard.)

You keep using that word "only"; I do not think it means what you think it means.

WebDAV certainly has issues, though its probably less bad, on balance, than FTP/FTPS, but the more commonly used alternative for FTP/FTPS isn't WebDAV but SFTP (the SSH File Transfer Protocol, _not_ the Simple File Transfer Protocol.)

[1] [http://blog.expandrive.com/2009/02/02/ftp-considered- harmful...](http://blog.expandrive.com/2009/02/02/ftp-considered-harmful/)

<comment><USER4> SFTP is the correct answer.

WebDAV is terrible. Run, don't walk, away from it. Nobody at apache has any responsibility for it, the mod_dav author is totally MIA ... it's just a mess. Further, every single DAV implementation[1] is _both_ broken _and_ completely unique.

[1] Like DAV in Finder, or DAV in MS Word or in MS explorer, or in IE ... they are all completely different ... and also all of them are horribly broken.

<comment><AUTHOR> I think all this makes it clear that it is a software issue and not a protocol issue. That is my point here. People hate FTP (or SFTP/FTP-SSL/WebDav) because the software is implemented poorly. (NOTE: I know SFTP and FTP-SSL are different protocols.)

<comment><USER3> FTP/FTPS has serious, protocol level issues (including things that are underspecified enough that its poor as a protocol for apps on top of, and things that are just bad decisions.)

WebDAV arguably has fewer essential protocol level issues (aside from being overly large and baroque) -- that is, it has fewer problems that are _necessarily included_ in a correct implementation -- but lots of implementation issues (which, arguably, stem largely from the spec being overly large and baroque.)

OTOH, even to the extent that the problems (e.g., with WebDAV) are issues with the existing software and not the protocol, the main benefit of building a specialized app to a standard protocol is interoperability with other tools using the protocol -- if the existing implementations are incomplete and buggy in mutually incompatible ways, that negates the benefit of writing to the standard.

<comment><AUTHOR> The only reason FTP is insecure is because system admins still allow unencrypted FTP connections. POP3 and HTTP is also insecure- it's up to the system admin to block insecure connections.

With most FTP server software I know (such as ServU or FileZilla Server) once you force SSL connections, the server will disconnect users on the USER command (before sending the password) if they are connected insecurely. So only if your system administrator _wants_ to allow insecure connections, will you be allowed to transmit the password insecurely.

Why do people still connect using the old insecure FTP standard? _It 's the software._

I personally think FileZilla should connect using SSL Explicit by default. IQBox defaults to SSL, and prompts the user for a fallback. So again I think it's a software issue, not a protocol issue.</comment></comment></comment></comment></comment></comment></comment>


Mockingbirds and Simple Recursive Combinators in Ruby - <AUTHOR> http://github.com/raganwald/homoiconic/blob/master/2011/11/mockingbirds.md#readme <comment><USER2> There's an interesting graphical notation for the lambda calculus here:

[http://www.cs.virginia.edu/~evans/cs655/readings/mockingbird...](http://www.cs.virginia.edu/~evans/cs655/readings/mockingbird.html)

</comment><comment><USER3> I'd like an easy peasy explanation of what a combinator is.

<comment><USER4> I just finished reading To Mock a Mockingbird (though I don't recall a formal definition) so I'll take a stab and leave it to others to correct me.

Combinators are the basic building block of combinatorial logic. Simply, they are functions that permute, group, repeat and/or eliminate their arguments.

E.g., The T (thrush using the bird naming convention) combinator takes two args and swaps their order: Txy = yx.

The B (bluebird) combinator groups it's 2nd and 3rd args (overriding the default left-associativity): Bxyz = x(yz).

The M (mockingbird) combinator takes a single arg and repeats it: Mx = xx.

The K (kestrel) combinator takes two args and eliminates the second: Kxy = x.

There are two schools of 'lambda calculus' that use a set of base combinators to build arbitrarily complex ones. The first school uses B, M, T and I which is the identity function: Ix = x. The other school combines B, M and T into a single combinator that permutes, groups and repeats with one application. It's called S (starling): Sxyz = xz(yz). This latter school uses S together with K.

Whether using B/M/T/I or S/K/I, you can build up pretty much any other combinator:

      B = S(KS)K.
      E.g.,
      S(KS)Kxyz, applying the leftmost S =
      (KS)x(Kx)yz, dropping the parens (which are still implied when not present due to the left-associativity) =
      KSx(Kx)yz, applying the leftmost K =
      S(Kx)yz, applying the S =
      (Kx)z(yz) =
      Kxz(yz) =
      x(yz) = Bxyz.

      T = ((S(K(S((SK)K))))K)
      M = ((S((SK)K))((SK)K))
      I = SKK. E.g., SKKx = KK(Kx) = K(x) = x = Ix.
      V**xyzwv = xyvzw.
      V** is spelled: (S(K((S(K((S((S(K((S(KS))K)))S))(KK))))((S(K(S(K((S((S(K((S(KS))K)))S))(KK))))))((S(K((S((S(K((S(KS))K)))S))(KK))))(S(K((S((S(K((S(KS))K)))S))(KK)))))))))

The up-shot of all of this is that _any_ computer program complete with arithmetic functions, boolean/propositional logic, list processing, etc. (i.e., Turing complete) can be expressed as a sequence of these base combinators. There are other practical (less theoretical) applications in programming. E.g., Using the T/thrush combinator to improve readability: [http://debasishg.blogspot.com/2009/09/thrush-combinator- in-s...](http://debasishg.blogspot.com/2009/09/thrush-combinator-in- scala.html) .

The Y combinator, for which this site is named, encapsulates recursion (i.e., a fixed-point combinator). It's spelled: S(K(SII))(S(S(KS)K)(K(SII))).

<comment><USER3> "The up-shot of all of this is that any computer program complete with arithmetic functions, boolean/propositional logic, list processing, etc. (i.e., Turing complete) can be expressed as a sequence of these base combinators. "

Now, that is interesting. It mirrors some thoughts I've been having lately but unable to express fully. Tell me more.

<comment><USER5> Try reading the book that steamer25 mentioned (To Mock a Mockingbird by Raymond Smullyan). It's very approachable and well written.

<comment><USER4> Yeah, the answer is a bit beyond the scope of a HN comment but it kind of boils down to clever representations for the values zero, n+1, true and false, etc. Effectively, any real number is represented as 0+1+1+1+1+1+... E.g., You can compare two numbers (less than, greater than, equal to, etc.) by decrementing them simultaneously and seeing which arrives at zero first (which requires recursion, an isZero function and boolean values for the result), etc. It's very similar to deriving Lisp as in The Little Lisper or The Little Schemer.

The execution of such a program on an actual "Turing machine" probably wouldn't be as performant as on our modern complex-instruction-set processors. Then again, I think the intent is to think of it as executing at the same speed at which a mathematical equation is true. I.e., You could go out and count 999 things or just accept that nine nine nine is a concise symbol representing the same procedure. The SKI representation isn't as terse but it's still just a symbol.

You can also read more at [http://en.wikipedia.org/wiki/Lambda_calculus#Encoding_dataty...](http://en.wikipedia.org/wiki/Lambda_calculus#Encoding_datatypes) ...though it doesn't seem as gentle (read hand-holdingly verbose) as To Mock a Mockingbird.

</comment></comment></comment></comment></comment><comment><USER6> What do you mean by this, _One little problem: How are we going to pass our function to itself?_ ?

You just pass the function as a parameter to call, like this:

      sum_of_nested_list.call(sum_of_nested_list, [1,[2,3]])

Right? What am I missing?

<comment><AUTHOR> Again, that depends on binding the function to the name. If that binding changes (as in the example given where some logging is added), things break. Also, being able to do with completely anonymously allows you to use a recursive lambda anywhere you can use a lambda or a block, something that is not currently possible without making a combinator.

There's a practical example of using the Y-COmbinator to make auto-vivifying hash tables in one of the links.

<comment><USER6> Got it, thanks. I was confused because I took that sentence to mean that it wasn't possible to pass the function to itself.</comment></comment></comment>


Chocolate by the Numbers (2004) - <AUTHOR> http://www.washingtonpost.com/wp-dyn/articles/A24276-2004Jun8.html <comment><USER2> Also American chocolate apparently tastes like vomit:

[https://www.reddit.com/r/explainlikeimfive/comments/3nhoiw/e...](https://www.reddit.com/r/explainlikeimfive/comments/3nhoiw/eli5_why_does_american_chocolate_taste_so_bad_in/)

When I first tried a Hershey bar I had wondered if it was stale or gone bad somehow. Eventually I realized it is supposed to taste like that. Now I don't mind it really, especially for smores, those really won't work the same with European style chocolate.

<comment><USER3> I personally prefer Lindt chocolate bars in my smores, not sure how European style chocalates don't work.

Never really liked Hershey.

Cadbury dairy Milk is what I liked growing up, and still do, works great for smores 2nd best to Lindt (I love the orange chocolate).

</comment></comment><comment><USER4> Scrolling is broken on this site! Upon starting to scroll it reloads the page!?! (iPad)

</comment><comment><USER5> A wonderful article on a topic of utmost importance. Please post more on the subject.</comment>


Ask HN: What are your thoughts on launching a SaaS that is 100% open source? - <AUTHOR> For discussion, the main service would be a multi-tenant service with an option for a single-tenant on-premise installation. Given that you had a proper licensing system in place for on-premise installations of your software, do you believe a business model like this could be sustainable?
Questions:
- Would you expect a lot of individual users to use your software without a license?
- Would you expect businesses to use your software with a license?
- Would open sourcing your software have a positive or negative impact on marketing/customer reach?
- Do you know of any open companies that serve as good examples, aside from GitLab?
Interested in hearing different opinions on the subject.
Edit: I'd like to clarify that by open source, I mean that all source code that the company runs on would be available for review, contribution, issue reporting, etc. — not that it would abide by an 100% free open source software license. <comment><USER2> SaaS that is open source makes sense when you provide something that would be difficult or troublesome to achieve with running the thing on-premise. Good network connection with high uptime is one such thing. Keeping the software updated, populated with plugins, or a management panel for spinning up many separate instances could be another.

<comment><AUTHOR> That's my thinking as well. Take GitLab for example: you can self-host private repos using the community edition of GitLab for free, or have them host it for $35/mo. Loads of users choose the latter because it's less maintenance and easier to get started with. Larger companies on the other hand will pay for the enterprise edition so that they can self-host it.

</comment></comment><comment><AUTHOR> Benefits of open sourcing: better code review, contributions, increased community engagement (possibly more employment/customer connections), improved security. I'm about 90% convinced that open sourcing a business I'm launching soon would have a positive impact on its success. It's just about getting past the initial fear of doing it.</comment>