Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #15684 > unrolled thread
| Started by | "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> |
|---|---|
| First post | 2012-09-15 22:28 +0100 |
| Last post | 2012-10-15 18:00 -0400 |
| Articles | 20 on this page of 143 — 26 participants |
Back to article view | Back to comp.lang.forth
Olympic Spririt for Forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-09-15 22:28 +0100
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-09-18 02:08 -0700
Re: Olympic Spririt for Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-18 11:58 +0000
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-09-18 05:55 -0700
Re: Olympic Spririt for Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-19 12:50 +0000
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-10-06 01:40 -0700
Re: Olympic Spririt for Forth "A. K." <akk@nospam.org> - 2012-10-06 11:18 +0200
Re: Olympic Spririt for Forth Spam@ControlQ.com - 2012-09-18 11:13 -0400
Re: Olympic Spririt for Forth Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-09-19 15:56 -0700
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-09-29 00:56 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-09-30 12:31 -0400
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-09-30 11:53 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-09-30 17:38 -0400
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-10-02 04:16 -0700
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-02 10:52 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-02 20:20 +0200
Re: Olympic Spririt for Forth Spam@ControlQ.com - 2012-10-02 15:58 -0400
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-02 13:31 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-03 02:59 +0200
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-02 19:08 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-03 15:50 +0200
Re: Olympic Spririt for Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-03 14:04 +0000
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-03 10:29 -0700
Re: Olympic Spririt for Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-04 16:07 +0000
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-03 20:27 +0200
Re: Olympic Spririt for Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-04 16:11 +0000
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-04 20:12 +0200
Re: Olympic Spririt for Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-05 13:08 +0000
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-05 17:48 +0200
Re: Olympic Spririt for Forth Pablo Hugo Reda <pabloreda@gmail.com> - 2012-10-03 07:39 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-03 20:24 +0200
Re: Olympic Spririt for Forth Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-03 18:13 -0700
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-03 12:05 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-03 22:20 +0200
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-04 12:41 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-04 22:40 +0200
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-04 18:11 -0700
Re: Olympic Spririt for Forth "Elizabeth D. Rather" <erather@forth.com> - 2012-10-04 15:26 -1000
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-04 18:54 -0700
Re: Olympic Spririt for Forth "A. K." <akk@nospam.org> - 2012-10-05 08:19 +0200
Re: Olympic Spririt for Forth "Elizabeth D. Rather" <erather@forth.com> - 2012-10-04 22:18 -1000
Re: Olympic Spririt for Forth Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-10-05 08:20 +0100
Re: Olympic Spririt for Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-05 11:08 +0000
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-07 08:32 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-07 21:39 +0200
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-07 21:03 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-08 19:09 +0200
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-08 21:57 -0700
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-10-09 01:10 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-09 14:12 -0400
Re: Olympic Spririt for Forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-10-10 09:29 +0100
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-10 21:13 -0400
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-10-10 02:02 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-10 21:23 -0400
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-10 18:24 -0700
Re: Olympic Spririt for Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-11 17:21 +0000
Re: Olympic Spririt for Forth Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-11 12:33 -0700
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-10-11 13:42 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-11 18:59 -0400
Re: Olympic Spririt for Forth "Elizabeth D. Rather" <erather@forth.com> - 2012-10-11 13:49 -1000
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-12 03:27 +0200
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-12 19:18 -0700
Re: Olympic Spririt for Forth Elizabeth D Rather <erather@forth.com> - 2012-10-12 18:53 -1000
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-12 22:55 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-13 22:07 +0200
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-13 00:56 -0400
Re: Olympic Spririt for Forth Doug Hoffman <glidedog@gmail.com> - 2012-10-13 18:41 -0400
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-13 16:05 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-14 02:57 +0200
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-14 00:26 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-14 19:28 +0200
Re: Olympic Spririt for Forth kenney@cix.compulink.co.uk - 2012-10-15 04:21 -0500
Re: Olympic Spririt for Forth Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-14 03:17 -0700
Re: Olympic Spririt for Forth Alex McDonald <blog@rivadpm.com> - 2012-10-14 15:43 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-14 21:18 -0400
Re: Olympic Spririt for Forth kenney@cix.compulink.co.uk - 2012-10-15 04:21 -0500
Re: Olympic Spririt for Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-15 10:03 +0000
Re: Olympic Spririt for Forth visualforth@rocketmail.com - 2012-10-15 04:04 -0700
Re: Olympic Spririt for Forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-10-15 21:34 +0100
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-15 17:51 -0400
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-10-16 01:09 -0700
Re: Olympic Spririt for Forth visualforth@rocketmail.com - 2012-10-16 02:15 -0700
Re: Olympic Spririt for Forth visualforth@rocketmail.com - 2012-10-16 02:30 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-16 15:18 -0400
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-14 21:05 -0400
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-14 18:19 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-15 17:58 -0400
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-15 15:21 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-15 18:51 -0400
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-15 17:20 -0700
Re: Olympic Spririt for Forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-10-12 22:41 +0100
Re: Olympic Spririt for Forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-10-12 22:24 +0100
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-10-09 01:20 -0700
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-09 08:56 -0700
Re: Olympic Spririt for Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-09 11:14 -0500
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-09 22:47 +0200
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-09 18:31 -0700
Re: Olympic Spririt for Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-09 22:55 -0500
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-10-09 01:04 -0700
Re: Olympic Spririt for Forth Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-09 17:30 +0200
Re: Olympic Spririt for Forth "Elizabeth D. Rather" <erather@forth.com> - 2012-10-04 11:31 -1000
Re: Olympic Spririt for Forth kenney@cix.compulink.co.uk - 2012-10-03 16:53 -0500
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-03 16:50 -0700
Re: Olympic Spririt for Forth Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-03 18:06 -0700
Re: Olympic Spririt for Forth kenney@cix.compulink.co.uk - 2012-10-03 16:53 -0500
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-10-03 00:38 -0700
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-03 02:06 -0700
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-10-03 03:38 -0700
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-03 13:40 -0700
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-10-04 01:00 -0700
Re: Olympic Spririt for Forth "Elizabeth D. Rather" <erather@forth.com> - 2012-10-03 22:32 -1000
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-10-04 04:49 -0700
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-10-04 01:35 -0700
Re: Olympic Spririt for Forth Howerd <howerdo@yahoo.co.uk> - 2012-10-06 06:17 -0700
Re: Olympic Spririt for Forth arc <arc.deletethis@vorsicht-bissig.de> - 2012-10-07 23:45 +1300
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-10-10 09:34 -0700
Re: Olympic Spririt for Forth Mark Wills <forthfreak@gmail.com> - 2012-10-10 12:16 -0700
Re: Olympic Spririt for Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-10 20:04 -0500
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-04 11:41 -0700
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-10-05 12:29 -0700
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-06 19:26 -0700
Re: Olympic Spririt for Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-05 19:09 +0000
Re: Olympic Spririt for Forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-10-02 22:03 +0100
Re: Olympic Spririt for Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2012-10-06 08:30 -0700
Re: Olympic Spririt for Forth ilya74.tarasov@gmail.com - 2012-09-29 07:09 -0700
Re: Olympic Spririt for Forth visualforth@rocketmail.com - 2012-10-09 14:30 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-09 18:27 -0400
Re: Olympic Spririt for Forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-10-10 09:46 +0100
Re: Olympic Spririt for Forth visualforth@rocketmail.com - 2012-10-10 03:52 -0700
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-10 06:01 -0700
Re: Olympic Spririt for Forth visualforth@rocketmail.com - 2012-10-10 07:42 -0700
Re: Olympic Spririt for Forth theoriginalsnial@gmail.com - 2012-10-10 09:10 -0700
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-10 10:34 -0700
Re: Olympic Spririt for Forth visualforth@rocketmail.com - 2012-10-11 17:17 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-13 01:03 -0400
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-10 21:59 -0400
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-10 20:57 -0700
Re: Olympic Spririt for Forth visualforth@rocketmail.com - 2012-10-11 02:05 -0700
Re: Olympic Spririt for Forth Matthias Koch <koch@pci.uni-hannover.de> - 2012-10-15 11:20 +0200
Re: Olympic Spririt for Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-15 11:53 +0000
Re: Olympic Spririt for Forth Paul Rubin <no.email@nospam.invalid> - 2012-10-15 08:52 -0700
Re: Olympic Spririt for Forth visualforth@rocketmail.com - 2012-10-15 11:53 -0700
Re: Olympic Spririt for Forth rickman <gnuarm@gmail.com> - 2012-10-15 18:00 -0400
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-10-03 15:50 +0200 |
| Message-ID | <1599725.MmvXeDaymt@sunwukong.fritz.box> |
| In reply to | #15873 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> What about writing high level 3d-turtle graphics code? Forth is not >> about writing "dup swap + over !", it is about creating domain >> specific programming languages. > > I don't think they want turtle graphics (it's hard for me to > understand how 3D turtle graphics would mean). Then read it up. If you google for "3d turtle graphics", my papers on the subject show up as item 2 and 3 (German/English) on Google. > They want rendered, shaded robots > walking around on the screen, that they can replicate, vaporize, etc. Yes, that's the next layer up. It's quite easy to use the 3D turtle to create animated objects; one of the examples I've written is an animated swap dragon. To create a game for children this thing certainly needs more polishing, no argument about that. > Anyway, Forth is supposedly an amplifier, helpful to the most skillful > programmers but obstructive to the rest. The idea of Code Hero is > that it teaches everyone to code. It aims to be an equalizer rather > than an amplifier. That's a different philosophy than Forth. I don't know what's wrong with you guys, you and Rod... Am I really babbling gibberish? I said the essence of Forth is to create domain specific languages. A teaching aid such as this game is a domain specific language. You don't program the game in "low level Forth", you program it in a domain specific language written in Forth that makes the task easy to do. Anyways, a friend of mine teaches Forth to young students, most of them with learning difficulties. He succeedes. I don't think Forth is an amplifier in the sense that it leaves bad programmers behind. It is an amplifier in the sense that it makes people more productive, the vast difference between good and bad programmers show up in every language, not just Forth. It leaves people behind who are unwilling to learn, because Forth is too different to them, and they already had a traumatic experience of learning a difficult programming language. This is all not the case with children. They haven't learned another language before, and they are accepting everything, no matter how weird you think it is. >>> Then you'd have to re-implement Unity3D and so on. >> And what's the reason why this can't be done in Forth? > > You'd have to ask the Forth programmers who aren't doing it. I only know one single Forth programmer who writes 3D games in Forth: Gerald Wodni. And he was rather new to Forth when he started writing his game. It can be done, it is not even difficult when a novice can do it. Again, I think I wrote gibberisch, because you didn't understand a word of my rhetorical question. *Of course* you have to reimplement something like Unity3D or a framework with similar intent if you want to make 3D games in Forth. It has been done, it can be done. > Other languages burn more machine resources to conserve programmer > effort. Most programmers consider this a usually-good trade. Forth > wins in the situations where it's not a good trade. We had some sort of this discussion with type systems. We here don't think that a statically checked type system is a good trade-off. > Take a look at some rubyquiz.com problems sometime, and ask how you > would do them if you were being paid per delivered solution. Of > course they can all be solved in Forth, but for the most part they can > be solved much more productively in other languages. (I did a few of > them as Haskell exercises). I've seen such puzzles, they usually are done in a way to specify the problems so that the built-in features of the language (like regexps) make them easy to solve. You can have regexps with Forth (Gforth comes with a regexp package), but you usually don't solve problems in Forth with regexps all over the place. However, looking at one of these puzzles shows that this isn't always the case, like http://rubyquiz.com/quiz69.html There, one author uses PostScript to draw the solution (he actually draws the spiral, not the rectangles): 0.8 0.4 0 setrgbcolor newpath 0.0 0.0 moveto 5.0 0.0 5.0 180 90 arcn 5.0 0.0 5.0 90 0 arcn 0.0 0.0 10.0 0 -90 arcn 0.0 5.0 15.0 -90 -180 arcn 10.0 5.0 25.0 -180 -270 arcn 10.0 -10.0 40.0 -270 -360 arcn -15.0 -10.0 65.0 -360 -450 arcn -15.0 30.0 105.0 -450 -540 arcn 50.0 30.0 170.0 -540 -630 arcn 50.0 -75.0 275.0 -630 -720 arcn -120.0 -75.0 445.0 -720 -810 arcn stroke This is a remarkable similar approach I would use to solve this problem in Forth (I would probably use a much more regular output and rotate the coordinate system by 90 degree each step to achieve this). And his solution is touted as particularly interesting, even for the Ruby guys there who don't know nothing about PostScript. >>> (Tamarin Trace) >> The JIT is written in Forth; the rest is written in C++. > > What do you mean by "the JIT is written in Forth"? Is this difficult to understand? The code that transforms tokenized JavaScript into machine code is written in Forth. >> That's probably because the JIT couldn't be written in C++, therefore >> they resorted to Forth, not the other way round. > > If Forth was the language they "resorted to" rather than their first > choice, that fits the general picture of Forth's virtue as being able > to go to places where other languages can't, rather than it being able > to deliver comfort and style in the places where other languages can. It's the comfort of "being at home". Many people *only* know one single programming language, and don't feel at home with any other, and also don't want to learn any other, because it was already too hard to learn that single language. You rarely see Forth in academia. You will get your C/C++/Java class there (depending on your age, now it's Java), and that's it. Some academic circles will teach you Scheme or Haskell, but very few will teach you Forth; Forth is typically considdered as a "non-language" by these academic types, because it has nothing of interest to them - no syntax, no type system. It is just not complicated enough to study. >> There usually is a high pressure to use "popular" languages both in >> open source and commercial projects, and the rest of the browser is >> written in C++. > > But they are aiming to rewrite the browser in a language (Rust) that > currently has even fewer users than Forth. They see Rust as having > enough technical advantages over C++ that it's worth the change. They > don't see Forth that way, it's pretty safe to say. Rust visually resembles C and Ruby, two very popular languages. They feel at home. It's not that they have to relearn a lot. Rust has one huge advantage over C++, and one that is very important considering the main problem in Firefox is memory leaks: It has a garbage collector. Yes, I agree that a garbage collector is probably the one single most important feature any language or toolkit must have when you write a browser in it. My approach would be to write a garbage collector as part of the inevitable OOP system you also need for writing a browser. Writing good Forth programs is not about "swap dup + over !", as I already wrote. It's about writing the tools to make the actual programming of the system easy, and about redefining the problem so that writing the tools become easy. So you better use Forth for something like net2o, where you can redefine how the syntax of the page looks like, and you don't have to use HTML5. I think HTML is broken by design, as witnessed by the many "simple" markup languages people have invented since, which are more easy to write by humans and more easy to process by computers. Something roughly equivalent to JavaScript in terms of what you can achieve with it (probably much more) would be a natural outcome of that development. Probably with a "nice C-like syntax" to not alienate people who only feel at home when they smell curly brackets and semicolons. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-10-03 14:04 +0000 |
| Message-ID | <2012Oct3.160448@mips.complang.tuwien.ac.at> |
| In reply to | #15878 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>I think HTML is broken by
>design, as witnessed by the many "simple" markup languages people have
>invented since, which are more easy to write by humans and more easy to
>process by computers.
Which markup languages do you mean? I have used some web fora in
recent times that use BBCode, which is just HTML 2.0 (plus tables from
IIRC 3.2) with square instead of angle brackets. The idea here is
apparently that they want the user to be able to do some layout
markup, but they want a restricted what the users can do (not sure why
you need square brackets for that, though).
The main problem with HTML is that there are so many of them.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-03 10:29 -0700 |
| Message-ID | <7xr4pfbh1u.fsf@ruckus.brouhaha.com> |
| In reply to | #15879 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > with square instead of angle brackets. The idea here is > apparently that they want the user to be able to do some layout > markup, but they want a restricted what the users can do (not sure why > you need square brackets for that, though). Sanitizing HTML is very difficult. If they use angle brackets they have to be ultra-careful that the user can't sneak something malicious through the sanitizer. It's easier to just convert all < characters to < and do markup in a syntax that starts from zero and adds safe capabilities, rather than starting with something dangerous and trying to subtract from it. The syntax looks like HTML for the comfort of users already familiar with HTML.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-10-04 16:07 +0000 |
| Message-ID | <2012Oct4.180722@mips.complang.tuwien.ac.at> |
| In reply to | #15884 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> with square instead of angle brackets. The idea here is
>> apparently that they want the user to be able to do some layout
>> markup, but they want a restricted what the users can do (not sure why
>> you need square brackets for that, though).
>
>Sanitizing HTML is very difficult. If they use angle brackets they have
>to be ultra-careful that the user can't sneak something malicious
>through the sanitizer. It's easier to just convert all < characters to
>< and do markup in a syntax that starts from zero and adds safe
>capabilities, rather than starting with something dangerous and trying
>to subtract from it.
Yes, that's the right approach, but it does not require square
brackets. I would write a parser that understands the desired HTML
subset and outputs it verbatim, and everything that the parser does
not grok is processed in the same way as BBcode does it (i.e.,
"<"->"<"). This approach works equally well if I use angle
brackets or square brackets for my tags.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-10-03 20:27 +0200 |
| Message-ID | <1475980.P88riHPMI0@sunwukong.fritz.box> |
| In reply to | #15879 |
Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>I think HTML is broken by >>design, as witnessed by the many "simple" markup languages people have >>invented since, which are more easy to write by humans and more easy >>to process by computers. > > Which markup languages do you mean? All those attempts at Wikis, the YAML stuff and similar; there are tons of them. Too many, as well. > The main problem with HTML is that there are so many of them. The main problem with HTML is that it is both unsuitable for humans to write it nor for computers to parse it (the half-defective one the humans are able to produce). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-10-04 16:11 +0000 |
| Message-ID | <2012Oct4.181107@mips.complang.tuwien.ac.at> |
| In reply to | #15889 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>I think HTML is broken by
>>>design, as witnessed by the many "simple" markup languages people have
>>>invented since, which are more easy to write by humans and more easy
>>>to process by computers.
>>
>> Which markup languages do you mean?
>
>All those attempts at Wikis, the YAML stuff and similar; there are tons
>of them. Too many, as well.
I think that we probably would not have them if HTML had not become
way more complicated than HTML 2.0.
>> The main problem with HTML is that there are so many of them.
>
>The main problem with HTML is that it is both unsuitable for humans to
>write it nor for computers to parse it (the half-defective one the
>humans are able to produce).
Humans are able to produce fine HTML if they use tools that show
mistakes (unlike the popular browsers); and they are not able to
produce correct markup code in any notation if they are not given such
tools.
I also find HTML 2.0 pretty suitable to write, and computers have no
problems parsing it. Sure, it's a bit verbose (compared to, say,
LateX), but it's not too bad. A good-enough solution, at least in
these respects. But apparently it was not good enough for "web
designers"; it does not support design, just content.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-10-04 20:12 +0200 |
| Message-ID | <3254228.sXJsA62rQx@sunwukong.fritz.box> |
| In reply to | #15918 |
Anton Ertl wrote:
> I think that we probably would not have them if HTML had not become
> way more complicated than HTML 2.0.
People are notoriously bad at abstractions. They want WYSIWYG.
Therefore, these alternative markup languages provide features that a
bulleted list looks like
* item a
* item b
and an enumerated list is
1. first item
2. second item
and the syntax for headline is
headline
========
or
headline level 2
----------------
This sort of type-writer markup seems to be pretty easy to grasp.
I suggest if we had HTML2 and a WYSIWYG editor formular in every
browser, people wouldn't have seen a need for these more visually
pleasant markups. And it's still typewriter, it's still not at all 3rd
millennium technology.
>>> The main problem with HTML is that there are so many of them.
>>
>>The main problem with HTML is that it is both unsuitable for humans to
>>write it nor for computers to parse it (the half-defective one the
>>humans are able to produce).
>
> Humans are able to produce fine HTML if they use tools that show
> mistakes (unlike the popular browsers); and they are not able to
> produce correct markup code in any notation if they are not given such
> tools.
Yes, showing where you made a mistake is a good idea. But people are
much better at these visual markups, they do produce correct code much
more likely, because correct code is visually pleseant there. Incorrect
code isn't. That *does* matter.
> I also find HTML 2.0 pretty suitable to write, and computers have no
> problems parsing it. Sure, it's a bit verbose (compared to, say,
> LateX), but it's not too bad. A good-enough solution, at least in
> these respects. But apparently it was not good enough for "web
> designers"; it does not support design, just content.
Yes, and instead of supporting design (e.g. via CSS), they first
introduced a whole bunch of flashy additions to HTML.
The lession I learned from both LaTeX and HTML is:
* the content is in a free-form markup, i.e. you need to be flexible how
to parse your markup (one single markup notation won't do it)
* the flashy design must be done in a turing complete language,
separated from the content; the flashy designers want animations, they
want to control every pixel. Give them what they want, and make sure
that the content is separated from their design. You want to allow the
user to override the designers choice (what we now have as user-CSS).
I.e. you want to have
content <-> markup parser <-> internal, editable representation of the
content -> flashy display language using OpenGL+GLSL, video rendering,
etc. ("game engine") <- fonts, images, videos, and other resources which
can have a fixed, unflexible render pipeline, or a semi-flexible like
for vector graphics
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-10-05 13:08 +0000 |
| Message-ID | <2012Oct5.150822@mips.complang.tuwien.ac.at> |
| In reply to | #15921 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> I think that we probably would not have them if HTML had not become
>> way more complicated than HTML 2.0.
>
>People are notoriously bad at abstractions. They want WYSIWYG.
>Therefore, these alternative markup languages provide features that a
>bulleted list looks like
>
>* item a
>* item b
>
>and an enumerated list is
>
>1. first item
>2. second item
>
>and the syntax for headline is
>
>headline
>========
>
>or
>
>headline level 2
>----------------
>
>This sort of type-writer markup seems to be pretty easy to grasp.
I don't find this easier than LaTeX or HTML, and in the end you need
some more "abstract" markup after all, e.g., for links. The wide use
of the HTML-like BBcode also supports my view.
>Yes, showing where you made a mistake is a good idea. But people are
>much better at these visual markups, they do produce correct code much
>more likely, because correct code is visually pleseant there. Incorrect
>code isn't. That *does* matter.
My experience is that at some point visual pleasantness breaks down
and becomes hard to maintain. E.g., links, or comments. So now you
have a language that appears easy at first, and breaks down later.
>The lession I learned from both LaTeX and HTML is:
>
>* the content is in a free-form markup, i.e. you need to be flexible how
>to parse your markup (one single markup notation won't do it)
Your example above is everything but free-form.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-10-05 17:48 +0200 |
| Message-ID | <1755458.WhOceTjENW@sunwukong.fritz.box> |
| In reply to | #15947 |
Anton Ertl wrote: >>This sort of type-writer markup seems to be pretty easy to grasp. > > I don't find this easier than LaTeX or HTML, and in the end you need > some more "abstract" markup after all, e.g., for links. The wide use > of the HTML-like BBcode also supports my view. IMHO the motivation for BBcode is to make it easy to transform into HTML. The motivations for the other, more visual codes which are also widely used (like the Wikipedia syntax) is to make it easier. "more abstract" markup uses more difficult constructs, of course. Though I consider [url|name] as less cumbersome than <a href="url">name</a>. The only problem there is with the [url|name] notation is that some systems actually have a [name|url] syntax ;-). > My experience is that at some point visual pleasantness breaks down > and becomes hard to maintain. E.g., links, or comments. So now you > have a language that appears easy at first, and breaks down later. So your suggestion is to make everything hard to maintain, not just the difficult parts? If I would add comments to such a language, I would use skip-to-eol comments, and use one of the common EOL comments like %, # or //, which people are familiar with. >>The lession I learned from both LaTeX and HTML is: >> >>* the content is in a free-form markup, i.e. you need to be flexible >>how to parse your markup (one single markup notation won't do it) > > Your example above is everything but free-form. What I want to say is that the content is *not* in a form mandated by the browser (which would be fixed-form, fixed to whatever form the browser accepts), but one mandated by the content-provider (or that framework). Having the browser provide a fixed parsing program is so obviously wrong when you look at the current web: Almost everybody who has user-generated content uses something else than HTML, even when it is relatively close like BBCode. So you say "this is BBcode" and the browser fetches a BBcode parser and uses that to read your content. Or you say "This is a particular Wiki markup", and the browser uses that parser. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Pablo Hugo Reda <pabloreda@gmail.com> |
|---|---|
| Date | 2012-10-03 07:39 -0700 |
| Message-ID | <fc624748-955a-4aff-8426-462d31007e00@googlegroups.com> |
| In reply to | #15878 |
> > Yes, I agree that a garbage collector is probably the one single most > > important feature any language or toolkit must have when you write a > > browser in it. My approach would be to write a garbage collector as > > part of the inevitable OOP system you also need for writing a browser. > > if you need a garbage collector, sure you have a garbage generator. IMHO forth not need GC or OOP.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-10-03 20:24 +0200 |
| Message-ID | <4909461.0Es98soyja@sunwukong.fritz.box> |
| In reply to | #15880 |
Pablo Hugo Reda wrote: > if you need a garbage collector, sure you have a garbage generator. Of course you have, it's the web pages out there you load into your web browser. They quickly become garbage when you move on to the next page. > IMHO forth not need GC or OOP. For some problems, they are the natural solution. I don't think you got me: This is an *extension* to Forth within the application domain. It's not part of the core of Forth. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-10-03 18:13 -0700 |
| Message-ID | <40e38280-8401-472d-bbff-6d26d24fe938@ph9g2000pbb.googlegroups.com> |
| In reply to | #15880 |
On Oct 3, 7:39 am, Pablo Hugo Reda <pablor...@gmail.com> wrote: > > Yes, I agree that a garbage collector is probably the one single most > > > important feature any language or toolkit must have when you write a > > > browser in it. My approach would be to write a garbage collector as > > > part of the inevitable OOP system you also need for writing a browser. > > if you need a garbage collector, sure you have a garbage generator. > > IMHO forth not need GC or OOP. I totally agree --- GC and OOP are not for Forth. If you need GC or OOP for your program, then Forth is the wrong language to be using. There are much more appropriate languages. Straight Forth will only be for micro-controller development (it will include HostForth that runs on a desktop-computer, but the only program ever written in HostForth will be the TargForth cross- compiler). Straight Forth won't be a general-purpose language. I will recommend Racket as a "sister language" for writing desktop-computer software programs that are related to micro-controller programming (typically utility programs for working with data that comes from or goes into the micro-controller). Using Forth on a desktop-computer makes about as much sense as using Scheme on a 16-bit micro-controller --- none!
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-03 12:05 -0700 |
| Message-ID | <7xmx03bclp.fsf@ruckus.brouhaha.com> |
| In reply to | #15878 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > Then read it up. If you google for "3d turtle graphics", my papers on > the subject show up as item 2 and 3 (German/English) on Google. I get somewhat different search results but it did find your dragon graphics article, which is nice. Thanks. > I said the essence of Forth is to create domain specific languages... > You don't program the game in "low level Forth", you program it in a > domain specific language written in Forth that makes the task easy to do. Well, I have to reserve judgment about how feasible this is until I actually something like it. The dragon graphics article seemed to show the low level Forth that I'm used to. In order to compare to Javascript (or Python, Scheme, etc). the DSL would need: - Some kind of OOP system (ok, this one has been done in Forth many times) - Good runtime type checking (static checking not needed). For example, passing the wrong number of args to a function should signal an error. I think that doesn't fit so well into Forth's exposed-stack style. - Garbage collection (Anton did this but I don't know if it's widely used) - Convenient syntax for writing nested data structures Lisp and JS do all of the above pretty well. It seems to me that if you do it as a Forth DSL, it's not so Forth-like any more. > This is all not the case with children. They haven't learned another > language before, and they are accepting everything, no matter how weird > you think it is. I've heard similar things about Haskell, that it has a "steep unlearning curve". > *Of course* you have to reimplement something like Unity3D or a > framework with similar intent if you want to make 3D games in Forth. It > has been done, it can be done. Well, I'd want to see an example so I can compare its sophistication to something like Unity3D. >> Other languages burn more machine resources to conserve programmer >> effort. Most programmers consider this a usually-good trade. > We had some sort of this discussion with type systems. We here don't > think that a statically checked type system is a good trade-off. Type systems are a rather different trade-off and I can understand preferring dynamic types. I still use Python all the time myself. Forth though has no machine-checked types at all, so you have to be very careful to avoid type errors, or else spend a lot of time tediously debugging. >> Take a look at some rubyquiz.com problems sometime > I've seen such puzzles, they usually are done in a way to specify the > problems so that the built-in features of the language (like regexps) Some of the rubyquiz problems are Ruby-specific but as you saw, others are not particularly language-specific. A lot of them require some reasonable features for handling strings, but that's what a lot of non-embedded programming is like these days, so it can't be considered a special feature. There are many things to dislike about C++ but it does make handling strings easier than in C. > http://rubyquiz.com/quiz69.html > There, one author uses PostScript to draw the solution.. > This is a remarkable similar approach I would use to solve this problem > in Forth Yes that particular solution would be pretty workable in Forth. >> What do you mean by "the JIT is written in Forth"? > Is this difficult to understand? The code that transforms tokenized > JavaScript into machine code is written in Forth. Well, other meanings are possible, and my impression had been that Forth was basically the intermediate language that got compiled, rather than the implementation language of the compiler. I will have to take a closer look. Of course it's possible to write a JIT compiler in C++ or even in C. LuaJIT is exactly that. > It's the comfort of "being at home". Many people *only* know one single > programming language, and don't feel at home with any other, Oh, I'd say if they were implementing Javascript in C++ then they must know both of those languages pretty well. I'm really a bit puzzled about why they would have written the JIT translator in Forth and will have to check it out, it sounds interesting. > You rarely see Forth in academia. You will get your C/C++/Java class > there (depending on your age, now it's Java), Java was a 1990's thing and I hope it's gone from academic curricula. MIT switched from Scheme to Python, which is a good choice for introductory programming. CMU uses ML, but it's aimed at CS students who already have some programming knowledge. > Rust visually resembles C and Ruby, two very popular languages... > Rust has one huge advantage over C++,...: It has a garbage collector. It's not just the curly braces and GC since Java has both of those. Rust is really a more advanced language than Java or C++. > Writing good Forth programs is not about "swap dup + over !"... So you > better use Forth for something like net2o, where you can redefine how > the syntax of the page looks like, I've looked at net2o a little and it's interesting, but again it looks like the low level Forth that I'm used to. > I think HTML is broken by design, as witnessed by the many "simple" > markup languages people have You could google "naggum xml" but make sure there are no kids present ;-). > Something roughly equivalent to JavaScript in terms of what you can > achieve with it (probably much more) would be a natural outcome of that > development. Probably with a "nice C-like syntax" to not alienate > people who only feel at home when they smell curly brackets and > semicolons. Why not use Javascript directly in this case? I don't see what Forth contributes to the picture.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-10-03 22:20 +0200 |
| Message-ID | <1797229.DCWuoRaQ3N@sunwukong.fritz.box> |
| In reply to | #15890 |
Paul Rubin wrote: > Well, I have to reserve judgment about how feasible this is until I > actually something like it. The dragon graphics article seemed to > show the low level Forth that I'm used to. You can always mix in the low level Forth in any DSL. > In order to compare to > Javascript (or Python, Scheme, etc). the DSL would need: > > - Some kind of OOP system (ok, this one has been done in Forth many > times) The 3D turtle is actually a class, and the functions are methods... > - Good runtime type checking (static checking not needed). For > example, > passing the wrong number of args to a function should signal an > error. I think that doesn't fit so well into Forth's exposed-stack > style. I did some significant effort to have all the frequently used words of the 3D turtle take only one or two arguments. If you program with typically 5-10 arguments per function, the automatic check is much more vital. Don't do that. > - Garbage collection (Anton did this but I don't know if it's widely > used) No, it's not widely used. Such a DSL would probably combine the OOP and the GC, so that all objects are managed, and you still can program "native unmanaged" code underneath. > - Convenient syntax for writing nested data structures Maybe, but I don't see why you would need them. You want animated objects; these are *nested programs*, not *nested data structures*. Lisp has the "program is data" meme. Forth has the opposite meme: "data is program". In a typical Lisp program, you would have your robot described something like this: (body (left arm) (right arm) (left leg) (right leg)) In Forth, you write a program which draws the robot, you don't write an interpreter for complex nested robot data structures. The program is nested. > Lisp and JS do all of the above pretty well. It seems to me that if > you do it as a Forth DSL, it's not so Forth-like any more. Forth DSLs don't have to be Forth-like. >> This is all not the case with children. They haven't learned another >> language before, and they are accepting everything, no matter how >> weird you think it is. > > I've heard similar things about Haskell, that it has a "steep > unlearning curve". Indeed. >> *Of course* you have to reimplement something like Unity3D or a >> framework with similar intent if you want to make 3D games in Forth. >> It has been done, it can be done. > > Well, I'd want to see an example so I can compare its sophistication > to something like Unity3D. You know that we don't do the "breakfast machine" in Forth. We try to write to the point, not to all possible future extensions. We can extend our systems as we go. The homepage of Glforth (Gerald Wodni's game engine) is here: http://www.complang.tuwien.ac.at/anton/lvas/stack-abgaben/07w/glforth/ > Type systems are a rather different trade-off and I can understand > preferring dynamic types. I still use Python all the time myself. > Forth though has no machine-checked types at all, so you have to be > very careful to avoid type errors, or else spend a lot of time > tediously debugging. No, you just write your program piecemeal, and debug a few additional word at a time. Furthermore, we don't really have that many types in Forth, so the most likely confusion is between integers and floats. > Some of the rubyquiz problems are Ruby-specific but as you saw, others > are not particularly language-specific. A lot of them require some > reasonable features for handling strings, but that's what a lot of > non-embedded programming is like these days, so it can't be considered > a special feature. I probably would use string.fs from Gforth; it's not really difficult to add reasonable string handling to Forth. > There are many things to dislike about C++ but it > does make handling strings easier than in C. C is the horror in string handling ;-). > Well, other meanings are possible, and my impression had been that > Forth was basically the intermediate language that got compiled, > rather than the implementation language of the compiler. IIRC, it's sort-of both. > I will have to take a > closer look. Of course it's possible to write a JIT compiler in C++ > or even in C. LuaJIT is exactly that. Maybe it's just a skill issue. When you look for people who know how to compile code quickly at run-time, you will find more Forth programmers than C programmers. >> It's the comfort of "being at home". Many people *only* know one >> single programming language, and don't feel at home with any other, > > Oh, I'd say if they were implementing Javascript in C++ then they must > know both of those languages pretty well. I'm really a bit puzzled > about why they would have written the JIT translator in Forth and > will have to check it out, it sounds interesting. As I said, it's probably a skill issue. Just look for people who have experience in incrementally and quickly compiling code at run-time, and you end up finding Forth implementers. >> You rarely see Forth in academia. You will get your C/C++/Java class >> there (depending on your age, now it's Java), > > Java was a 1990's thing and I hope it's gone from academic curricula. TU Munich is still using Java for the introduction course. They say "or similar", so probably you can get through with Python or so... >> Rust visually resembles C and Ruby, two very popular languages... >> Rust has one huge advantage over C++,...: It has a garbage collector. > > It's not just the curly braces and GC since Java has both of those. > Rust is really a more advanced language than Java or C++. Somewhat, yes. But it's still an ahead-of-time compiled language. I don't consider ahead-of-time compiled languages (as only option) as "advanced". Less retarded, maybe, is the right word. >> Writing good Forth programs is not about "swap dup + over !"... So >> you better use Forth for something like net2o, where you can redefine >> how the syntax of the page looks like, > > I've looked at net2o a little and it's interesting, but again it looks > like the low level Forth that I'm used to. net2o still has only the network layer implemented. Nothing of the higher level stuff I'm thinking about has become code yet. >> I think HTML is broken by design, as witnessed by the many "simple" >> markup languages people have > > You could google "naggum xml" but make sure there are no kids present > ;-). Hehe. Some words are pretty strong ;-). I think the evolution of TeX has a remarkable teaching: Text markups evolve to turing complete languages. TeX did. As did HTML, with the addition of JavaScript and DOMs to the mess. Both became messy, because both didn't anticipate what would happen. There were several attempts to get TeX reimplemented in a real programming language that is also available to escape to during the typesetting process itself; LuaTeX is by far the most successful of these attempts (it actually is a very usable TeX engine). I'm usually not trying to reinvent wheels which are actually good. So maybe I will just use Lua as the high level scripting language for net2o. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-04 12:41 -0700 |
| Message-ID | <7x4nmauisn.fsf@ruckus.brouhaha.com> |
| In reply to | #15892 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > In Forth, you write a program which draws the robot, you don't write an > interpreter for complex nested robot data structures. The program is > nested. So what do you do if you want to describe a few different robots in the program? Write separate programs for each? >> compare its sophistication to something like Unity3D. > You know that we don't do the "breakfast machine" in Forth. We try to > write to the point, not to all possible future extensions. We can > extend our systems as we go. But all the features in Unity3D are there because somebody wanted them. And if you're making a toolkit for other people to use, I think you really do have to anticipate their requirements. > The homepage of Glforth (Gerald Wodni's game engine) is here: > http://www.complang.tuwien.ac.at/anton/lvas/stack-abgaben/07w/glforth/ This looks nice. >> Forth though has no machine-checked types at all... spend a lot of time >> tediously debugging. > No, you just write your program piecemeal, and debug a few additional > word at a time. But then you end up modifying the code and that usually introduces errors, so you're back to debugging. > Furthermore, we don't really have that many types in > Forth, so the most likely confusion is between integers and floats. Don't forget addresses and xt's, which are easy to get confused with data. And I don't think Forth's lack of strings, arrays, associative tables, closures, etc. help its attractiveness to programmers used to such newfangled conveniences. > I probably would use string.fs from Gforth; it's not really difficult to > add reasonable string handling to Forth. I'd think reasonable string handling absolutely has to use garbage collection (or at least, C++-style finalization on exit from a scope) to clean up the intermediate results of complex string manipulation. If strings.fs does that then it's interesting. > As I said, it's probably a skill issue. Just look for people who have > experience in incrementally and quickly compiling code at run-time, and > you end up finding Forth implementers. Oh come on, there just aren't that many Forth programmers. Lisp systems have done on-the-fly compilation since the dawn of time, Java probably uses the best-known JIT, etc. >> Rust is really a more advanced language than Java or C++. > Somewhat, yes. But it's still an ahead-of-time compiled language. I > don't consider ahead-of-time compiled languages (as only option) as > "advanced". Less retarded, maybe, is the right word. Meh, once you've got a fast build system (maybe not possible for certain styles of C++ but quite reasonable for other languages), ahead-of-time is fine. > I'm usually not trying to reinvent wheels which are actually good. So > maybe I will just use Lua as the high level scripting language for > net2o. Probably a reasonable choice. Lua has some traction, has a very nice embeddable implementation, and is lightweight and efficient. I'm not that crazy about the Lua language itself but I think alternatives (mostly Lisp-based, like Guile) will probably stay unpopular.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-10-04 22:40 +0200 |
| Message-ID | <2028826.7QaYsnLk6j@sunwukong.fritz.box> |
| In reply to | #15924 |
Paul Rubin wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> In Forth, you write a program which draws the robot, you don't write
>> an
>> interpreter for complex nested robot data structures. The program is
>> nested.
>
> So what do you do if you want to describe a few different robots in
> the program? Write separate programs for each?
Why not? What would you do when you describe robots in a data
structure? Write a separate data structure for each? Of course. You
can factor complex data structures, and you can factor complex programs.
If you think there is a substantial difference between a program and a
sufficiently complex data structure, you just don't get it.
You can have a robot with
4 red arms
green cylinder body
4 black wheels
Is this a data structure or a program? I don't know, I don't care. To
draw the robot, you have to interpret the data structure or to execute
the program.
> But all the features in Unity3D are there because somebody wanted
> them. And if you're making a toolkit for other people to use, I think
> you really do have to anticipate their requirements.
Hm, again, Forth philosophy is slightly different.
a) you don't anticipate future needs (you only take current needs into
account) and
b) you don't bury your tools
This b) is actually done to anticipate future needs *the right way*. If
I make a toolkit, and make sure you can't access *my* tools, I have to
anticipate what you will need, and implement all of that. If I give you
my toolkit-building tools, you can implement your stuff, even though I
didn't anticipate it. I wrote something which allows to easily draw
robots and let them move through a maze, and you use the tools to draw
robots to instead draw plants and flowers, and let the user manage his
or her garden.
>> No, you just write your program piecemeal, and debug a few additional
>> word at a time.
>
> But then you end up modifying the code and that usually introduces
> errors, so you're back to debugging.
I try to make these modifications one little piece at a time, and then
test it, as well. If I don't, if I do a big lump of changes, chances
are high that it doesn't work, and that getting out of that mess takes
more time than unrolling all the changes, and doing them one little step
at a time.
git bisect even automates this sort of debugging - when you have an
automated test for it. It's clearly not unique to Forth. Having
automated tests for the features that already work is a good idea.
I think someone like you, with a good grasp for formal methods, should
look at John Hayes ttester (in Gforth under test/ttester.fs; the
examples in the test directory are of more value than the source code
itself). You complained that Forth doesn't check stack effects. Well,
just add a check yourself:
require test/ttester.fs
: bounds ( addr len -- last first ) over + swap ;
t{ 3 5 bounds -> 8 3 }t
For words with no side-effect, you can simply leave these tests in the
code. When you introduce an error, you see it when you compile next
time.
>> Furthermore, we don't really have that many types in
>> Forth, so the most likely confusion is between integers and floats.
>
> Don't forget addresses and xt's, which are easy to get confused with
> data.
Addresses and xts *are* integers. And they do point to some other data,
which you can inspect - in an ITC Forth, even portably among different
ITC systems (Gforth's stepping debugger works only on Gforth-ITC,
because it uses this fact).
> And I don't think Forth's lack of strings, arrays, associative
> tables, closures, etc. help its attractiveness to programmers used to
> such newfangled conveniences.
Most desktop Forth systems will provide you with most of those features.
There's even a package for closures based on mini-oof, which passes
Knuth boy-or-men test.
If you haven't found Forth strings, arrays, hash tables, etc., by now,
it's because you were looking at an embedded Forth, where all these
features just don't fit.
>> I probably would use string.fs from Gforth; it's not really difficult
>> to add reasonable string handling to Forth.
>
> I'd think reasonable string handling absolutely has to use garbage
> collection (or at least, C++-style finalization on exit from a scope)
> to clean up the intermediate results of complex string manipulation.
> If strings.fs does that then it's interesting.
string.fs uses a transformation model rather than a creation model.
I.e. all you have are global string variables. Most string
manipulations aren't complex, they usually are either adding things to
the end of a string, or search/replace passes through the string, which
transform the string.
Other people have suggested and implemented string stacks. That works
even for cases where you need to create string objects dynamically, but
with a limited scope (like this C++-style finalization). You finally
have to drop it off the string stack when you leave the scope.
>> As I said, it's probably a skill issue. Just look for people who
>> have experience in incrementally and quickly compiling code at
>> run-time, and you end up finding Forth implementers.
>
> Oh come on, there just aren't that many Forth programmers. Lisp
> systems have done on-the-fly compilation since the dawn of time, Java
> probably uses the best-known JIT, etc.
Java's VM has a direct ancestral line to Forth, because Goslin worked on
Postscript before (and Postscript is highly influenced by Forth).
In any case: JavaScript *is* a Lisp, apart of the syntax. It would be
far more natural that the JavaScript engines would use Lisp compilation
techniques, which have been there since the dawn of time. It doesn't,
for whatever reason. Two out of four state-of-the-art JS engines use
Forth. None uses Lisp (ok, we don't know about Microsoft's, this is the
one closed source state-of-the-art JS engine). And there are probably
more Lisp programmers around. But for them, the on-the-fly compiler is
an "others people problem". For a Forth programmer, the compiler isn't.
This is a consequence of "don't bury your tools" philosophy. Therefore,
while you find less Forth programmers than Lisp programmers, you will
find more Forth programmers who can help you to implement a JIT.
Or Forth-influenced programmers who did work on other JITs like JVM.
They are Forth-influenced, because JVM is Forth-influenced.
>>> Rust is really a more advanced language than Java or C++.
>> Somewhat, yes. But it's still an ahead-of-time compiled language. I
>> don't consider ahead-of-time compiled languages (as only option) as
>> "advanced". Less retarded, maybe, is the right word.
>
> Meh, once you've got a fast build system (maybe not possible for
> certain styles of C++ but quite reasonable for other languages),
> ahead-of-time is fine.
Well, most of what you write in Forth is compiled ahead-of-time, too.
However, the good thing is that you aren't limited to that, and you can
do on-the-fly stuff whenever necessary. Like when running simple test
cases as part of the ahead-of-time compilation (shown above), or when
trying out new functions interactively on the terminal. And when
extending the system with features you think are lacking.
>> I'm usually not trying to reinvent wheels which are actually good.
>> So maybe I will just use Lua as the high level scripting language for
>> net2o.
>
> Probably a reasonable choice. Lua has some traction, has a very nice
> embeddable implementation, and is lightweight and efficient. I'm not
> that crazy about the Lua language itself but I think alternatives
> (mostly Lisp-based, like Guile) will probably stay unpopular.
Though Lua does away with most of the curly braces and the semicolons,
and even has multiple return values.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-04 18:11 -0700 |
| Message-ID | <7xd30x4t9c.fsf@ruckus.brouhaha.com> |
| In reply to | #15925 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
> 4 red arms
> green cylinder body
> 4 black wheels
>
> Is this a data structure or a program? I don't know, I don't care. To
> draw the robot, you have to interpret the data structure or to execute
> the program.
I'd rather that it be data since then I can write code to interpret the
data in multiple ways, and it helps to be able to write data before
starting to write code. E.g. in Python:
programmers = [
{'name':'Bernd' 'languages':['Forth','C']},
{'name':'Elizabeth','languages':['Forth','Fortran']},
{'name':'Paul','languages':['Python','Forth']}
]
I can type that directly into Python and have it create a nested data
structure, without having to write and debug any specialized code. If I
then want to be able to find the users of a given language, I can then
say (e.g.):
def lang_users(lang):
return [p['name'] for p in programmers if lang in p['languages']]
Then to find the Forth users:
>>> print lang_users('Forth')
['Bernd', 'Elizabeth', 'Paul']
This is much harder in languages without such syntax, such as Java. It
has to be done instead with code usually described as "boilerplate" in
an uncomplimentary way.
> If I make a toolkit, and make sure you can't access *my* tools, I have
> to anticipate what you will need, and implement all of that. If I
> give you my toolkit-building tools, you can implement your stuff,
If I'm supposed to implement such stuff myself, why do I want your
toolkit in the first place? Obviously as a FOSS user I want to be able
to extend the toolkit as a last resort, and obviously in the first
releases of a toolkit, the important use cases haven't necessarily been
identified. But after a few iterations I'd expect the toolkit to do
pretty much everything needed, and modularity makes me not want to
maintain my own fork if I can help it.
> I try to make these modifications one little piece at a time, and then
> test it, as well.
OK, so you make a small modification and create a bug, which makes your
test fail. What now? You have to figure out the cause of the bug.
And, I think, this is much easier in a (runtime) type-checked and
bounds-checked language, than something like Forth.
> look at John Hayes ttester (in Gforth under test/ttester.fs;
> require test/ttester.fs
> : bounds ( addr len -- last first ) over + swap ;
> t{ 3 5 bounds -> 8 3 }t
Oh this is nice, and I didn't know about it. I'm going to start using it.
> You complained that Forth doesn't check stack effects. Well, just add
> a check yourself
That's nice for checking at the function definition, but what about
making sure the callers always pass the right stuff?
> Addresses and xts *are* integers.
No really, multiplying two integers is a sensible arithmetic operation;
multiplying two pointers is not.
> If you haven't found Forth strings, arrays, hash tables, etc., by now,
> it's because you were looking at an embedded Forth, where all these
> features just don't fit.
I'm using gforth and I didn't notice any of that in the manual.
> string.fs uses a transformation model rather than a creation model.
> I.e. all you have are global string variables. Most string
> manipulations aren't complex, they usually are either adding things to
> the end of a string, or search/replace passes through the string, which
> transform the string.
Even this sounds like it needs GC.
> It would be far more natural that the JavaScript engines would use
> Lisp compilation techniques,
I think historically, Lisp compilers didn't use tracing JIT's. You'd
write the inner loops of your Lisp program to use known types if you
could, and the compiler would rely on programmer annotations or type
inference to generate optimized code for the types. In cases where the
types were unknown, you'd get runtime dispatch and an efficiency hit.
Today, PyPy, LuaJIT, and the JS compilers all use tracing, so I guess
the trade-offs have changed.
> Though Lua does away with most of the curly braces and the semicolons,
> and even has multiple return values.
My gripe with Lua mostly has to do with the looseness of the type
system, compared to Lisp or even Python.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-10-04 15:26 -1000 |
| Message-ID | <08KdnZzA3evBqvPNnZ2dnUVZ_v6dnZ2d@supernews.com> |
| In reply to | #15936 |
On 10/4/12 3:11 PM, Paul Rubin wrote: >> You complained that Forth doesn't check stack effects. Well, just add >> >a check yourself > > That's nice for checking at the function definition, but what about > making sure the callers always pass the right stuff? A data type check certainly doesn't guarantee you've got the "right stuff." The only meaningful check is for reasonable range. And the place to check that is right where the data enters the system (user interface, device register, etc.), not repetitively in each word, unless temporarily while trying to track down some stubborn bug. >> >Addresses and xts*are* integers. > > No really, multiplying two integers is a sensible arithmetic operation; > multiplying two pointers is not. That would be a programming mistake, and one that would be pretty obvious early in the test cycle. I realize that programmers who have felt comforted by syntax/data type checking compilers feel a little naked getting used to Forth, but with a little experience you'll understand the Forth programming/testing cycle and feel more comfortable. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-04 18:54 -0700 |
| Message-ID | <7xvcepy97z.fsf@ruckus.brouhaha.com> |
| In reply to | #15937 |
"Elizabeth D. Rather" <erather@forth.com> writes: > A data type check certainly doesn't guarantee you've got the "right > stuff." This was about stack effect, or correspondingly (in other languages) making sure that the caller passed the right number of args to the callee. > I realize that programmers who have felt comforted by syntax/data type > checking compilers feel a little naked getting used to Forth, but with > a little experience you'll understand the Forth programming/testing > cycle and feel more comfortable. I've written enough C code in my life to appreciate the difference between having to find the bug by examining the state of memory with gdb, and having the Python (etc.) interpreter tell me "wrong number of args at line 237, called from line 415", showing the source code at each of those two lines. I see the mismatch, say "oops" and fix the code. (# of args isn't a good example of this, since C checks that statically, but you get the idea).
[toc] | [prev] | [next] | [standalone]
| From | "A. K." <akk@nospam.org> |
|---|---|
| Date | 2012-10-05 08:19 +0200 |
| Message-ID | <506e7c01$0$9518$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #15938 |
On 05.10.2012 03:54, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> A data type check certainly doesn't guarantee you've got the "right
>> stuff."
>
> This was about stack effect, or correspondingly (in other languages)
> making sure that the caller passed the right number of args to the
> callee.
>
>> I realize that programmers who have felt comforted by syntax/data type
>> checking compilers feel a little naked getting used to Forth, but with
>> a little experience you'll understand the Forth programming/testing
>> cycle and feel more comfortable.
>
> I've written enough C code in my life to appreciate the difference
> between having to find the bug by examining the state of memory with
> gdb, and having the Python (etc.) interpreter tell me "wrong number of
> args at line 237, called from line 415", showing the source code at each
> of those two lines. I see the mismatch, say "oops" and fix the code.
> (# of args isn't a good example of this, since C checks that statically,
> but you get the idea).
>
One of my first Forth programs in my life was assert( .. )
which pretty much worked like Hayes T{ .. }.
I used to use assert( a lot in the beginning. Today my preferred way of
coding critical code sections is still with paper, pencil, and rubber
gum. :-)
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web