#T-SQL, 31 bytes

SELECT c FROM t ORDER BY i*7%54

If you don't care about an extra column in the output I can get it down to 29 bytes:

SELECT*FROM t ORDER BY i*7%54

So you can verify my output is "Superb", here is the deck it produces:

 J, 5H, 8S, KH, 3D, 8C, JD, AS, 6H, 9S, AC, 4D, 9C, QD, 
2S, 7H, 10S, 2C, 5D, 10C, KD, 3S, 8H, JS, 3C, 6D, JC, 
AH, 4S, 9H, QS, 4C, 7D, QC, 2H, 5S, 10H, KS, 5C, 8D, 
KC, 3H, 6S, JH, AD, 6C, 9D, J, 4H, 7S, QH, 2D, 7C, 10D

(Generated using the new SQL 2017 addition, STRING_AGG):

SELECT STRING_AGG(c,', ')WITHIN GROUP(ORDER BY i*7%54)FROM t 

The hard part for me was not the select code, it was populating the input table (which is allowed for SQL per our IO rules).

Because SQL is inherently unordered (it only guarantees a certain order if you include an explicit ORDER BY clause), I had to include that original order as a field i in the input table t. This also means I can use it to sort, using the same "relatively prime" factor/mod process everyone else is using. I found that i*7%54 worked just as well as i*17%54.

Here are the commands to set up and populate the input table t, based on my solution to this related question:

CREATE TABLE t (i INT IDENTITY(1,1), c VARCHAR(5))
--Insert 52 suited cards
INSERT t(c)
SELECT v.value+s.a as c
FROM STRING_SPLIT('A-2-3-4-5-6-7-8-9-10-J-Q-K','-')v,
 (VALUES('S',1),('D',2),('H',3),('C',4))s(a,b)
ORDER BY s.b
--Insert Jokers
INSERT t(c) SELECT 'J'
INSERT t(c) SELECT 'J'

T-SQL, 31 bytes

SELECT c FROM t ORDER BY i*7%54

If you don't care about an extra column in the output I can get it down to 29 bytes:

SELECT*FROM t ORDER BY i*7%54

So you can verify my output is "Superb", here is the deck it produces:

 J, 5H, 8S, KH, 3D, 8C, JD, AS, 6H, 9S, AC, 4D, 9C, QD, 
2S, 7H, 10S, 2C, 5D, 10C, KD, 3S, 8H, JS, 3C, 6D, JC, 
AH, 4S, 9H, QS, 4C, 7D, QC, 2H, 5S, 10H, KS, 5C, 8D, 
KC, 3H, 6S, JH, AD, 6C, 9D, J, 4H, 7S, QH, 2D, 7C, 10D

(Generated using the new SQL 2017 addition, STRING_AGG):

SELECT STRING_AGG(c,', ')WITHIN GROUP(ORDER BY i*7%54)FROM t 

The hard part for me was not the select code, it was populating the input table (which is allowed for SQL per our IO rules).

Because SQL is inherently unordered (it only guarantees a certain order if you include an explicit ORDER BY clause), I had to include that original order as a field i in the input table t. This also means I can use it to sort, using the same "relatively prime" factor/mod process everyone else is using. I found that i*7%54 worked just as well as i*17%54.

Here are the commands to set up and populate the input table t, based on my solution to this related question:

CREATE TABLE t (i INT IDENTITY(1,1), c VARCHAR(5))
--Insert 52 suited cards
INSERT t(c)
SELECT v.value+s.a as c
FROM STRING_SPLIT('A-2-3-4-5-6-7-8-9-10-J-Q-K','-')v,
 (VALUES('S',1),('D',2),('H',3),('C',4))s(a,b)
ORDER BY s.b
--Insert Jokers
INSERT t(c) SELECT 'J'
INSERT t(c) SELECT 'J'

#T-SQL, 31 bytes

SELECT c FROM t ORDER BY i*7%54

If you don't care about an extra column in the output I can get it down to 29 bytes:

SELECT*FROM t ORDER BY i*7%54

So you can verify my output is "Superb", here is the deck it produces:

 J, 5H, 8S, KH, 3D, 8C, JD, AS, 6H, 9S, AC, 4D, 9C, QD, 
2S, 7H, 10S, 2C, 5D, 10C, KD, 3S, 8H, JS, 3C, 6D, JC, 
AH, 4S, 9H, QS, 4C, 7D, QC, 2H, 5S, 10H, KS, 5C, 8D, 
KC, 3H, 6S, JH, AD, 6C, 9D, J, 4H, 7S, QH, 2D, 7C, 10D

(Generated using the new SQL 2017 addition, STRING_AGG):

SELECT STRING_AGG(c,', ')WITHIN GROUP(ORDER BY i*7%54)FROM t 

The hard part for me was not the select code, it was populating the input table (which is allowed for SQL per our IO rules).

Because SQL is inherently unordered (it only guarantees a certain order if you include an explicit ORDER BY clause), I had to include that original order as a field i in the input table t. This also means I can use it to sort, using the same "relatively prime" factor/mod process everyone else is using. I found that i*7%54 worked just as well as i*17%54.

Here are the commands to set up and populate the input table t:

CREATE TABLE t (i INT IDENTITY(1,1), c VARCHAR(5))
--Insert 52 suited cards
INSERT t(c)
SELECT v.value+s.a as c
FROM STRING_SPLIT('A-2-3-4-5-6-7-8-9-10-J-Q-K','-')v,
 (VALUES('S',1),('D',2),('H',3),('C',4))s(a,b)
ORDER BY s.b
--Insert Jokers
INSERT t(c) SELECT 'J'
INSERT t(c) SELECT 'J'

#T-SQL, 31 bytes

SELECT c FROM t ORDER BY i*7%54

If you don't care about an extra column in the output I can get it down to 29 bytes:

SELECT*FROM t ORDER BY i*7%54

So you can verify my output is "Superb", here is the deck it produces:

 J, 5H, 8S, KH, 3D, 8C, JD, AS, 6H, 9S, AC, 4D, 9C, QD, 
2S, 7H, 10S, 2C, 5D, 10C, KD, 3S, 8H, JS, 3C, 6D, JC, 
AH, 4S, 9H, QS, 4C, 7D, QC, 2H, 5S, 10H, KS, 5C, 8D, 
KC, 3H, 6S, JH, AD, 6C, 9D, J, 4H, 7S, QH, 2D, 7C, 10D

(Generated using the new SQL 2017 addition, STRING_AGG):

SELECT STRING_AGG(c,', ')WITHIN GROUP(ORDER BY i*7%54)FROM t 

The hard part for me was not the select code, it was populating the input table (which is allowed for SQL per our IO rules).

Because SQL is inherently unordered (it only guarantees a certain order if you include an explicit ORDER BY clause), I had to include that original order as a field i in the input table t. This also means I can use it to sort, using the same "relatively prime" factor/mod process everyone else is using. I found that i*7%54 worked just as well as i*17%54.

Here are the commands to set up and populate the input table t, based on my solution to this related question:

CREATE TABLE t (i INT IDENTITY(1,1), c VARCHAR(5))
--Insert 52 suited cards
INSERT t(c)
SELECT v.value+s.a as c
FROM STRING_SPLIT('A-2-3-4-5-6-7-8-9-10-J-Q-K','-')v,
 (VALUES('S',1),('D',2),('H',3),('C',4))s(a,b)
ORDER BY s.b
--Insert Jokers
INSERT t(c) SELECT 'J'
INSERT t(c) SELECT 'J'