3 ms·

Hmm. Well. Most Python templating systems use HTML with some Python code intermixed, in one form or another. So you're basically writing HTML and adding Python

Hmm. Well. Most Python templating systems use HTML with some Python code intermixed, in one form or another. So you're basically writing HTML and adding Python for conditionals, loops, special function calls, etc. With this Weby library, however, you write Python code that generates HTML. I'm not saying that's bad, but it's a completely different approach. Also -- and this isn't a criticism of Weby -- I can't help but notice the lack of Python's syntactic flexibility here. Don't get me wrong, I love Python (still), but this is definitely not an area where it shines. In languages like Ruby or Scheme (etc), similar code would have much less fluff. In Python, OTOH, such a thing wasn't even possible until fairly recently, when the 'with' statement was added.

ljlolel 16y ago
Python does have limited syntactic flexibility. This makes it bad for making completely new languages. You are correct. My philosophy recently has been that you do not want to create a new language. Haskell makes it easy to make a custom DSL. Unfortunately, that means a preponderance of new languages and mini-languages that you need to learn to get your work done. More importantly, these mini-languages invariably are missing features that you are used to in your powerful language: imports, decorators, debuggers, etc. Django templates did not even have variable assignments for years. My recent philosophy is Pythonic: don't make DSLs but make domain-specific libraries. I have gone through many iterations to get this as minimal as possible while still being explicit and resisting putting in any magic. The results are still surprisingly readable after a little practice.
- mkramlich 16y ago
  I have exactly the same stance on DSLs as you. Well said.
- jerf 16y ago
  I'm coming around to the view that a DSL is a thing where you have actually created a new syntax. If there is no parser, there is no DSL in sight. Few Haskell libraries actually provide DSLs, though I can name some that do, usually very small ones, often ones where if you still desire to write the raw Haskell you can. It's just that APIs take effort to learn and use, and Haskell can use some patterns that many other languages can't, just as Ruby can use some patterns many other languages can't. I actually think seeing DSLs where there aren't actually any is somewhat dangerous, because people's brains stop being able to abstract correctly. I have a perl "DSL" at my workplace that I wrote that I have been desperately trying to convince people is not actually a DSL, because it makes people think about it wrong. It is a way of decorating functions in such a way that I can reach the metadata and do other helpful while they can get on with their lives, and it looks like this: special_sub subname => permission_check { $_[0]->had('some_permission') }, xml_rpc(name => "Category.subname"), does { blah blah blah }; and there are various other sundry things it can do easily that would make less sense out of context. This does things like expose this function to the local XMLRPC handler, and the xml_rpc function takes in the XML-RPC-specific metadata for this case. "xml_rpc", "permission_check" (which actually has a shorter name in real life), and even "does" are actually functions that return values which do the real magic, but I have the problem where people don't understand; my $common_permission = permission_check { $_->[0]->has('perm') }; special_sub sub1 => $common_permission, does {...}; special_sub sub2 => $common_permission, does {...}; special_sub sub3 => $common_permission, does {...}; People see the DSL magic and suddenly its like everything they knew about the base language just goes flying out the window.
kls 16y ago
So you're basically writing HTML and adding Python for conditionals, loops, special function calls, etc. With the maturing of the JS toolkits, I really don't know why people do this anymore. It is so much easier to write static HTML and overlay JS widgets for the dynamic parts. Then for search engines and older browsers drop a headless browser in front of it the website, so that no JS is required if the client cannot support it. To me the web templating frameworks represent a legacy mindset to developing web applications.

ljlolel 16y ago

Python does have limited syntactic flexibility. This makes it bad for making completely new languages. You are correct. My philosophy recently has been that you do not want to create a new language. Haskell makes it easy to make a custom DSL. Unfortunately, that means a preponderance of new languages and mini-languages that you need to learn to get your work done. More importantly, these mini-languages invariably are missing features that you are used to in your powerful language: imports, decorators, debuggers, etc. Django templates did not even have variable assignments for years. My recent philosophy is Pythonic: don't make DSLs but make domain-specific libraries. I have gone through many iterations to get this as minimal as possible while still being explicit and resisting putting in any magic. The results are still surprisingly readable after a little practice.

mkramlich 16y ago
I have exactly the same stance on DSLs as you. Well said.
jerf 16y ago
I'm coming around to the view that a DSL is a thing where you have actually created a new syntax. If there is no parser, there is no DSL in sight. Few Haskell libraries actually provide DSLs, though I can name some that do, usually very small ones, often ones where if you still desire to write the raw Haskell you can. It's just that APIs take effort to learn and use, and Haskell can use some patterns that many other languages can't, just as Ruby can use some patterns many other languages can't. I actually think seeing DSLs where there aren't actually any is somewhat dangerous, because people's brains stop being able to abstract correctly. I have a perl "DSL" at my workplace that I wrote that I have been desperately trying to convince people is not actually a DSL, because it makes people think about it wrong. It is a way of decorating functions in such a way that I can reach the metadata and do other helpful while they can get on with their lives, and it looks like this: special_sub subname => permission_check { $_[0]->had('some_permission') }, xml_rpc(name => "Category.subname"), does { blah blah blah }; and there are various other sundry things it can do easily that would make less sense out of context. This does things like expose this function to the local XMLRPC handler, and the xml_rpc function takes in the XML-RPC-specific metadata for this case. "xml_rpc", "permission_check" (which actually has a shorter name in real life), and even "does" are actually functions that return values which do the real magic, but I have the problem where people don't understand; my $common_permission = permission_check { $_->[0]->has('perm') }; special_sub sub1 => $common_permission, does {...}; special_sub sub2 => $common_permission, does {...}; special_sub sub3 => $common_permission, does {...}; People see the DSL magic and suddenly its like everything they knew about the base language just goes flying out the window.

kls 16y ago

So you're basically writing HTML and adding Python for conditionals, loops, special function calls, etc. With the maturing of the JS toolkits, I really don't know why people do this anymore. It is so much easier to write static HTML and overlay JS widgets for the dynamic parts. Then for search engines and older browsers drop a headless browser in front of it the website, so that no JS is required if the client cannot support it. To me the web templating frameworks represent a legacy mindset to developing web applications.