On 16 May 2016, at 01:00, Hans Hagen
wrote: On 5/15/2016 11:55 PM, Hans Åberg wrote:
On 15 May 2016, at 23:18, Hans Hagen
wrote: but eventually typesetting will become a niche and end up in the arts but i will probably not live long enough to see that happen
From the point of computer language design, TeX is not very good. One of the pitfalls of macro programming is that it gives the impression of lambda calculus efficiency without having it so one ends up spending a lot of time figuring out trivialities, which is why eventually was added, I gather.
it's not that bad .. the tex language has a certain charm that one needs to get accustomed to (as does metapost) ... and, combined with lua it's even more fun
Ideally, there should have been only one language with lambda capacity, and better syntax, though it is a problem figuring out what it might be.
just look at how many programming languages are there and will be there (no surprise with billions of people and taste)
you see the same with markup languages: people want simple, then need more and so simple becomes more and when not well thought about beforehand simple then becomes ugly and it all starts anew
Indeed computer tend to have natural life cycles, after they have matured, further development becomes difficult.
interesting tex was flexible enough to survive many decades
Other survivors are C, C++, Scheme. With TeX, change may start as with Lua, only some better syntax for text input. I experimented a bit with giving Guile a C++ API, and then then there is a problem with that that C++ is statically typed whereas Guile is dynamic. For example, Guile does not distinguish statically between different types of numbers: integers, rationals, etc, so the proper way from the point of C++ is to only have open number type. But static typing is important in optimization. And giving implement traditional function syntax on top of Guile does not work well, because (f, x_1, …, x_k) does not correspond semantically exactly to f(x_1, …, x_n). And there is a problem with the Scheme strict evaluation. So such issues lead towards to the design of a new language, rather than relying on an already existing.
On 5/16/2016 10:27 AM, Hans Åberg wrote:
On 16 May 2016, at 01:00, Hans Hagen
wrote: On 5/15/2016 11:55 PM, Hans Åberg wrote:
On 15 May 2016, at 23:18, Hans Hagen
wrote: but eventually typesetting will become a niche and end up in the arts but i will probably not live long enough to see that happen
From the point of computer language design, TeX is not very good. One of the pitfalls of macro programming is that it gives the impression of lambda calculus efficiency without having it so one ends up spending a lot of time figuring out trivialities, which is why eventually was added, I gather.
it's not that bad .. the tex language has a certain charm that one needs to get accustomed to (as does metapost) ... and, combined with lua it's even more fun
Ideally, there should have been only one language with lambda capacity, and better syntax, though it is a problem figuring out what it might be.
just look at how many programming languages are there and will be there (no surprise with billions of people and taste)
you see the same with markup languages: people want simple, then need more and so simple becomes more and when not well thought about beforehand simple then becomes ugly and it all starts anew
Indeed computer tend to have natural life cycles, after they have matured, further development becomes difficult.
interesting tex was flexible enough to survive many decades
Other survivors are C, C++, Scheme. With TeX, change may start as with Lua, only some better syntax for text input.
that always depend on the content; for complex docs tex or xml is ok (and best)
I experimented a bit with giving Guile a C++ API, and then then there is a problem with that that C++ is statically typed whereas Guile is dynamic. For example, Guile does not distinguish statically between different types of numbers: integers, rationals, etc, so the proper way from the point of C++ is to only have open number type. But static typing is important in optimization.
And giving implement traditional function syntax on top of Guile does not work well, because (f, x_1, …, x_k) does not correspond semantically exactly to f(x_1, …, x_n). And there is a problem with the Scheme strict evaluation.
So such issues lead towards to the design of a new language, rather than relying on an already existing.
and then the not foreseen limitations in that language and ugly extensions spoil it ... (btw, the nice thing about lua is that it's so stable) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 16 May 2016, at 10:48, Hans Hagen
wrote:
interesting tex was flexible enough to survive many decades
Other survivors are C, C++, Scheme. With TeX, change may start as with Lua, only some better syntax for text input.
that always depend on the content; for complex docs tex or xml is ok (and best)
The TeX syntax is too loose to do input that is close to the input. For example, in math, if properly parsed, the "{…}” can often be replaced by the normal “(…)”, and the the engine can decide to remove them when unnecessary, as in say e^(x+y).
So such issues lead towards to the design of a new language, rather than relying on an already existing.
and then the not foreseen limitations in that language and ugly extensions spoil it ... (btw, the nice thing about lua is that it's so stable)
One might focus on different parts communicating via the semantics of the underlying engine. Then with extensions, it is not necessary to know the syntax of other additions when writing the code. This is roughly how pure math works, and also the point extensible computer languages to get stuck on. And this is alos how Lua was added ro TeX.
On 5/16/2016 10:59 AM, Hans Åberg wrote:
On 16 May 2016, at 10:48, Hans Hagen
wrote: interesting tex was flexible enough to survive many decades
Other survivors are C, C++, Scheme. With TeX, change may start as with Lua, only some better syntax for text input.
that always depend on the content; for complex docs tex or xml is ok (and best)
The TeX syntax is too loose to do input that is close to the input. For example, in math, if properly parsed, the "{…}” can often be replaced by the normal “(…)”, and the the engine can decide to remove them when unnecessary, as in say e^(x+y).
asciimath tries to do that (is supported in context) but it has to be used very structured in order to not run into its weird aspects
So such issues lead towards to the design of a new language, rather than relying on an already existing.
and then the not foreseen limitations in that language and ugly extensions spoil it ... (btw, the nice thing about lua is that it's so stable)
One might focus on different parts communicating via the semantics of the underlying engine. Then with extensions, it is not necessary to know the syntax of other additions when writing the code. This is roughly how pure math works, and also the point extensible computer languages to get stuck on. And this is alos how Lua was added ro TeX.
-- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 16 May 2016, at 11:10, Hans Hagen
wrote: On 5/16/2016 10:59 AM, Hans Åberg wrote:
The TeX syntax is too loose to do input that is close to the input. For example, in math, if properly parsed, the "{…}” can often be replaced by the normal “(…)”, and the the engine can decide to remove them when unnecessary, as in say e^(x+y).
asciimath tries to do that (is supported in context) but it has to be used very structured in order to not run into its weird aspects
I worked on a theorem proof assistant, which then checks that the math is correct, but it then turned out complicated to write TeX code.
participants (2)
-
Hans Hagen
-
Hans Åberg