Also interesting: You're allowed to use the same query parameter multiple times in one URL and the server is expected to merge it into an array. But I don't really know which implementations do this.
Yes, learned this when writing server side code it's very easy to extract query params dictionary style and then learn that to be pedantically correct, they should be handled list style.
i understand who the author of that article is, but i feel that's an overly hardline approach. f# and racket are perfectly fine and productive mostly functional languages.
... and pattern-matching. But yeh, patterns are a sign of a weakness in the language. And it's not infrequent that patterns really turn out to be anti-patterns.
> But yeh, patterns are a sign of a weakness in the language.
That line of reasoning never ceases to be amusing by how silly and self-defeating,particularly as those who make those claims try to pin ignorance on others while manifesting their own ignorance. They seem to be entirely oblivious to the fact that the main goal and usefulness of patterns is to communicate intent and provide semantics and use a common language to describe common problems. A function is a function but a strategy pattern isn't a state pattern. Those who miss this fundamental difference are totally oblivious to what design patterns actually are.
The point is that patterns shouldn't be patterns in books—they should be abstractions in libraries. You know what's better than having a shared vocabulary you expect everyone to know from a book? Having a shared vocabulary defined in the language and accessible not only to programmers but to the compiler and tooling as well.
> The point is that patterns shouldn't be patterns in books—they should be abstractions in libraries.
And how you go about developing those "libraries"?
By writing code using the programming language, isn't it?
Just because C++ and Java and Python and many other programming languages added support for iterators and generators it doesn't make them out to be less of a design pattern. Heck, supporting emcapsulation and composition and information hiding doesn't make a facade pattern, as well as its concept and the semantics of implementing one, magically disappear.
This fundamental fact regarding design patterns is what these self-important fools miss. While they are too busy grandstanding with their criticism, they are actually showing off their ignorance and demonstrating they don't even understand the basic problems solved by design patterns, which are orthogonal to programming languages and their features.
> A function is a function but a strategy pattern isn't a state pattern.
Funny you should mention that. What does "state pattern" communicate about the design, that "state machine" does not? Because state machine is a well-established term, applicable across paradigms.
And what can you communicate with "strategy pattern"? I mean, pick a design for solving a problem (any problem), and explain the design in writing using the words "strategy pattern". I bet I can rephrase it to be at least as simple, and use common-language terms that predate the "strategy pattern".
I've heard people try to take this stance before, that "design patterns are a way to communicate your designs", but to me, it doesn't hold water. How do you communicate your designs simpler, with them?
Right, a function isn't a pattern. But a pattern in the common usage is some functionality that needs to be communicated outside the core language. In languages that offer that functionaliry in the core, I would argue there no longer "patterns". I don't think many of the gof patterns are remarkable in a modern Language like clojure, because the options are obvious.
It should be clarified that the whole thing is about functional patterns in Clojure that are expressing same functionality as well known OO patterns in Java.
Adding "it's just..." in front of functional patterns doesn't make them non-patterns.
Patterns are named ideas on how to approach/solve similar problems.
They are not tied to OO programming, Java, they are not good or bad per-se; it's just a cookbook with recipes that have names.
Presumably the point is that most functional programmers wouldn't have bothered giving dedicated names to, say, “strategies” or “factories”, more or less the same way nobody would bother calling “(a + b) / 2” the “average pattern”.
> But a pattern in the common usage is some functionality that needs to be communicated outside the core language.
What a truism. Programming languages exist to implement functionalities outside of the core language. So what? Does this mean that software projects aren't designed, and parts of the design may not be shared and integrated in other projects? Those working on software projects still need to discuss design issues, and it's easier and more efficient to assign names to recurring patterns. Those who don't understand this issue and opt to manifest their ignorance by criticizing the existence of patterns are simply fools who try to feign competence by ridiculing the consequences of their own ignorance.
Names are useless unless they convey a precise meaning. And, if you can't write down that meaning in a formal system (such as a programming language or mathematics), then it can't be that precise after all.
> Names are useless unless they convey a precise meaning.
They do convey a precise meaning. You simply fail to understand it, and even make it your point to complain about something you systematically fail to understand where you stand on your dunning-kruger corner.
You are aware you're asking to "mathematically formalize" algorithm constructs, right? Either you know nothing about the subject or are trolling this thread in spite of being completely removed from the field.
Algorithms are mathematical objects, and they sure as hell can be formalized. Alas, software design “patterns” aren't algorithms. And, so long as they resist formalization, they are non-ideas.
Accusations of trolling are completely unwarranted.
No idea what you mean by “strong language”, but a high-level programming language is one in which patterns are expressible directly as libraries or frameworks.
I believe in the majority of cases SSE are a better technology than web sockets (e.g. WS do not seem to conform to HTTP/2.0, SSE offer transparent (browser-supported) reconnects, SSE event ids allow for replay, etc). The downside is no support in IE/Edge (you can vote at https://goo.gl/bd8V1K), no binary content (but again usually JSON is enough) and no fully bidirectional communication.
I am a bit puzzled about the scalability of listen/notify in Postgres and its use in the article. Each "listener" in the code requires a connection in the database so it's not a good design to have one listen "query" for each user. You will probably need a dedicated connection in a thread (or a limited number of connections) for the database listening functionality. You can possibly use some async PG driver but still on the database end I am not sure how efficient and scalable this solution will be.
I can assume that this is a good solution if you don't have (need) a high rate of "notify" statements and a high number of subscribers waiting on "listen". Any comments on these limits of PostgreSQL?
[1]: https://chartdb.io/ [2]: https://github.com/chartdb/chartdb