Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #15078 > unrolled thread
| Started by | visualforth@rocketmail.com |
|---|---|
| First post | 2012-08-21 21:43 -0700 |
| Last post | 2012-08-22 07:37 -0700 |
| Articles | 20 on this page of 163 — 19 participants |
Back to article view | Back to comp.lang.forth
Comparative Productivity of Programming Languages visualforth@rocketmail.com - 2012-08-21 21:43 -0700
Re: Comparative Productivity of Programming Languages "A. K." <akk@nospam.org> - 2012-08-22 07:07 +0200
Re: Comparative Productivity of Programming Languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-22 03:35 -0500
Re: Comparative Productivity of Programming Languages John Passaniti <john.passaniti@gmail.com> - 2012-08-22 14:06 -0700
Function Points (was: Comparative Productivity of Programming Languages) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-23 14:50 +0000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-23 11:43 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-25 14:13 +0000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-25 10:12 -0700
Re: Function Points Doug Hoffman <glidedog@gmail.com> - 2012-08-25 15:39 -0400
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-25 15:09 -0700
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-25 12:34 -1000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-25 16:43 -0700
Re: Function Points jacko <jackokring@gmail.com> - 2012-08-25 18:05 -0700
Re: Function Points jacko <jackokring@gmail.com> - 2012-08-25 20:34 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-26 03:24 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-25 22:44 -0700
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-25 21:19 -1000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-26 00:36 -0700
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-25 21:50 -1000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-26 01:08 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-26 23:20 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-26 19:33 -0700
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-27 13:34 -0500
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-27 22:38 +0200
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-28 02:45 -0500
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-27 18:14 -0700
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-27 18:24 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-30 14:22 +0000
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-28 03:07 -0500
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-28 08:18 -0700
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-28 12:15 -0500
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-28 23:05 -0700
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-29 03:55 -0500
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-27 22:28 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-27 20:26 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-28 23:17 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-29 01:13 -0700
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-29 02:23 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-30 02:59 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-29 22:18 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-30 20:44 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-31 01:29 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-31 09:33 +0000
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-30 02:58 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-29 19:39 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-30 14:10 +0000
Re: Function Points gavino_himself <visploveslisp@gmail.com> - 2012-08-30 20:08 -0700
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-30 17:47 -1000
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-27 13:43 -1000
Re: Function Points "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-08-27 12:14 +0100
Re: Function Points Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-27 05:12 -0700
Re: Function Points "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-08-27 15:52 +0100
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-26 13:09 +0000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-27 20:52 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-30 14:08 +0000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-30 10:43 -0700
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-30 08:25 -1000
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-30 22:42 +0200
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-31 01:23 -0400
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-31 03:08 -0500
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-31 18:56 -0400
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-01 02:35 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-31 23:52 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-01 14:27 +0000
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-01 14:18 +0000
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-01 17:45 +0200
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-01 16:14 +0000
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-01 19:13 +0200
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-09-02 03:19 -0500
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-01 16:18 -0400
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-02 03:04 +0200
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 04:02 -0400
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-02 17:40 +0200
Re: Function Points jim@rainbarrel.com - 2012-09-02 10:32 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-02 20:49 +0200
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 16:33 -0400
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 17:03 -0400
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-02 09:02 -1000
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 16:35 -0400
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-02 13:42 -1000
Re: Function Points jim@rainbarrel.com - 2012-09-02 16:54 -0700
Re: Function Points Mark Wills <markrobertwills@yahoo.co.uk> - 2012-09-03 00:29 -0700
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-03 01:30 -0400
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-02 21:21 -1000
Re: Function Points jim@rainbarrel.com - 2012-09-03 10:37 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-04 07:14 +0000
Re: Function Points Coos Haak <chforth@hccnet.nl> - 2012-09-03 21:12 +0200
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-03 17:32 -0400
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-03 17:51 -0400
Re: Function Points John Passaniti <john.passaniti@gmail.com> - 2012-09-03 22:37 -0700
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-04 04:25 -0400
Re: Function Points John Passaniti <john.passaniti@gmail.com> - 2012-09-04 07:35 -0700
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-05 02:13 -0400
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-04 20:18 -1000
Re: Function Points John Passaniti <john.passaniti@gmail.com> - 2012-09-05 10:56 -0700
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-05 16:11 -0400
Re: Function Points John Passaniti <john.passaniti@gmail.com> - 2012-09-05 14:07 -0700
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 16:27 -0400
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-03 00:52 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-02 16:28 -0700
Re: Function Points jim@rainbarrel.com - 2012-09-02 16:48 -0700
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 20:21 -0400
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-02 14:45 -1000
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-03 01:12 -0400
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-02 21:26 -1000
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-03 01:06 -0400
Re: Function Points Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-31 03:29 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-31 10:35 +0000
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-31 18:49 -0400
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-01 14:49 +0000
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-01 08:36 -1000
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-01 16:11 -0400
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-03 01:58 +0200
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-01 17:54 +0200
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-01 16:19 -0400
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-02 03:05 +0200
Re: Function Points Coos Haak <chforth@hccnet.nl> - 2012-08-31 23:10 +0200
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-31 15:50 -1000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-01 10:31 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-01 21:52 +0200
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-01 16:36 -0400
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-01 14:36 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-02 03:30 +0200
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-02 23:15 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-02 15:02 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-03 01:50 +0200
Re: Function Points jim@rainbarrel.com - 2012-09-02 16:57 -0700
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-03 23:11 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-04 14:30 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-04 10:14 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-04 22:10 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-06 00:19 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-06 17:48 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-06 12:01 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-06 22:02 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-06 14:19 -0700
Heap (was: Function Points) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-07 11:30 +0000
Re: Heap (was: Function Points) Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-07 18:12 +0200
Re: Heap (was: Function Points) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-07 16:48 +0000
Re: Heap (was: Function Points) Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-07 21:34 +0200
Re: Heap Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-09-07 22:04 +0100
Re: Heap anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-08 11:52 +0000
Re: Heap Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-08 22:48 +0200
Re: Heap (was: Function Points) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-08 12:11 +0000
priority queue (was: Function Points) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-03 11:46 +0000
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-03 15:03 +0200
Re: Function Points mhx@iae.nl (Marcel Hendrix) - 2012-09-03 22:36 +0200
Re: Function Points mhx@iae.nl (Marcel Hendrix) - 2012-09-06 20:27 +0200
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-09-02 04:00 -0500
Re: Function Points visualforth@rocketmail.com - 2012-09-03 10:40 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-03 20:26 +0200
Re: Function Points Doug Hoffman <glidedog@gmail.com> - 2012-08-27 11:49 -0400
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-27 09:16 -0700
Re: Function Points Josh Grams <josh@qualdan.com> - 2012-08-28 22:46 +0000
Re: Function Points jacko <jackokring@gmail.com> - 2012-08-28 16:06 -0700
Re: Function Points Doug Hoffman <glidedog@gmail.com> - 2012-08-28 20:50 -0400
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-26 12:59 +0000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-26 22:24 -0700
Re: Function Points (was: Comparative Productivity of Programming Languages) John Passaniti <john.passaniti@gmail.com> - 2012-08-23 15:02 -0700
Re: Function Points (was: Comparative Productivity of Programming Languages) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-25 14:57 +0000
Re: Comparative Productivity of Programming Languages "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-22 08:07 -0400
Re: Comparative Productivity of Programming Languages visualforth@rocketmail.com - 2012-08-22 08:12 -0700
Re: Comparative Productivity of Programming Languages visualforth@rocketmail.com - 2012-08-22 07:37 -0700
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2012-08-21 21:43 -0700 |
| Subject | Comparative Productivity of Programming Languages |
| Message-ID | <2bebf6e6-dab7-4134-904f-a57e90765fd3@googlegroups.com> |
Today I read an Dr.Dobb's article named "The Comparative Productivity of Programming Languages" They say "The problem is that measuring productivity is invariably viewed as more of an art than scientific work... The key unit of measure is a function point, which is a measurable amount of functionality that can be determined during the requirements phase of a program... From this data, they can see how many hours it took to take each project to completion and how those hours mapped to languages, on projects that were primarily written in one language." They list ASP (6.1), Visual Basic (8.5), Java (10.6), SQL (10.8), C++ (12.4), C (13.0), C# (15.5), PL/1 (14.2), COBOL (16.8), and ABAP (19.9) - numbers in brackets are the development hours per function point of software. Source: http://www.drdobbs.com/jvm/the-comparative-productivity-of-programm/240005881 I am wondering why Forth isn't in that list. In former years Dr.Dobb's wrote a lot about Forth.
[toc] | [next] | [standalone]
| From | "A. K." <akk@nospam.org> |
|---|---|
| Date | 2012-08-22 07:07 +0200 |
| Message-ID | <50346905$0$6581$9b4e6d93@newsspool3.arcor-online.net> |
| In reply to | #15078 |
On 22.08.2012 06:43, visualforth@rocketmail.com wrote: > Today I read an Dr.Dobb's article named > "The Comparative Productivity of Programming Languages" > > They say "The problem is that measuring productivity is invariably viewed as more of an art than scientific work... The key unit of measure is a function point, which is a measurable amount of functionality that can be determined during the requirements phase of a program... From this data, they can see how many hours it took to take each project to completion and how those hours mapped to languages, on projects that were primarily written in one language." > > They list ASP (6.1), Visual Basic (8.5), Java (10.6), SQL (10.8), C++ (12.4), C (13.0), C# (15.5), PL/1 (14.2), COBOL (16.8), and ABAP (19.9) - numbers in brackets are the development hours per function point of software. > Source: > http://www.drdobbs.com/jvm/the-comparative-productivity-of-programm/240005881 > > I am wondering why Forth isn't in that list. In former years Dr.Dobb's wrote a lot about Forth. > Because the list is utter nonsense. We are very productive in assembler and C. COBOL f.ex. would bring our product nowhere. I am wondering why Brainf*ck isn't in that list. I mean they are talking about art, aren't they? :)
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-08-22 03:35 -0500 |
| Message-ID | <zLadneWS6uQoBKnNnZ2dnUVZ8oednZ2d@supernews.com> |
| In reply to | #15078 |
visualforth@rocketmail.com wrote: > Today I read an Dr.Dobb's article named > "The Comparative Productivity of Programming Languages" > > They say "The problem is that measuring productivity is invariably > viewed as more of an art than scientific work... The key unit of > measure is a function point, which is a measurable amount of > functionality that can be determined during the requirements phase > of a program... From this data, they can see how many hours it took > to take each project to completion and how those hours mapped to > languages, on projects that were primarily written in one language." > > They list ASP (6.1), Visual Basic (8.5), Java (10.6), SQL (10.8), C++ (12.4), C (13.0), C# (15.5), PL/1 (14.2), COBOL (16.8), and ABAP (19.9) - numbers in brackets are the development hours per function point of software. > Source: > http://www.drdobbs.com/jvm/the-comparative-productivity-of-programm/240005881 > > I am wondering why Forth isn't in that list. In former years > Dr.Dobb's wrote a lot about Forth. You have to take this with a huge pinch of salt. ASP is active server pages, right? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2012-08-22 14:06 -0700 |
| Message-ID | <8545a450-d245-46ea-93cf-0b34a7bdbf8d@googlegroups.com> |
| In reply to | #15086 |
On Wednesday, August 22, 2012 4:35:01 AM UTC-4, Andrew Haley wrote: > You have to take this with a huge pinch of salt. ASP > is active server pages, right? Because ASP (and ASP.NET) are cross-language web frameworks, saying you "program in ASP(.NET)" is a nearly-meaningless statement. ASP.NET programmers actually likely (these days) programming in VB.NET or C#. That kind of imprecision isn't limited to ASP programmers. Several times when I conducted job interviews and saw the applicant put "HTML" under programming languages they knew, I sighed and asked them to code a function that did something trivial (like add up the numbers 1 to 10). Most immediately wrote out something in JavaScript without skipping a beat. When I informed them that their code wasn't in HTML but in a different language called JavaScript, many just either looked at me blankly or said something like, "well yeah, they're the same thing, right?" Whenever someone publishes a study or claim about how language X makes you Y times more productive, it causes everyone with a favorite language to flail around and make loads of assumptions about methodology and motive. Instead, it helps to go back to the source. And here, using function points is one reasonably objective factor to consider when evaluating productivity. It's only one, however, and it may or may not relate to how one chooses to work. For me, I am far more productive when using interactive languages (not just Forth) because that reflects my work style and biases. But there are people who see no value in interactive languages, either because they've never used one or because they don't use it well. And we see other language differences affecting programmers in other ways. Take for example the subject of typed versus untyped (or dynamically typed) languages. In this newsgroup, many discussions about typed languages present such languages as a straight-jacket where some totalitarian compiler prevents you from doing what you want. But when you move outside the realm of languages like C and into languages like Haskell and F# that have type inferencing and pattern matching and you view types very differently. But if your only experience with typed languages is something like C, then you just view types in the narrow context of safety and performance. It goes on and on. Procedural languages versus functional languages. Generic data structures (like key/value stores) versus application-specific data structures. Class-based object orientation versus prototype-based objects. It doesn't really matter what dichotomy people bring up regarding productivity, you'll always find some people who think they are more productive with one instead of the other. I wish people would just accept that there is no universal truth or single answer here. The reason why there are so many different programming languages is that there is more than one way to approach solving problems. Your productivity with any language is more a function of how well the problems you're trying to solve and the way you want to solve them are served by the language. And that's why programmers should learn multiple fundamentally different languages, so they can have at their disposal the right tool for the right job. Or alternatively, if they are using a language like Forth, knowing what tools they might want to add to Forth to make their jobs easier. (Put another way, it does no good for Forth to be a flexible and malleable language if the programmer doesn't have enough experience to know when it makes sense to extend Forth.)
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-08-23 14:50 +0000 |
| Subject | Function Points (was: Comparative Productivity of Programming Languages) |
| Message-ID | <2012Aug23.165054@mips.complang.tuwien.ac.at> |
| In reply to | #15108 |
John Passaniti <john.passaniti@gmail.com> writes:
> And here, using function points is=
> one reasonably objective factor to consider when evaluating productivity. =
> It's only one, however, and it may or may not relate to how one chooses to=
> work.
When I was a student, I heard about function points and got the
impression that, say, an addition was one function point, which seemed
to me a metric that's specific to some piece of code, and to evaluate
how many function points one needs requires a similar amount of effort
as doing an implementation, so it did not appear useful as an estimate
of the complexity of the task.
These days we have Wikipedia, so I checked that, and it appears that
function points are useful for classical form-report applications,
where the required effort is mostly in the forms and reports and can
be estimated from the specification of the forms and reports. I can
see how that might work.
However, for other applications I have no idea how to determine
function points for them. For example, I wrote a comparison of
programming languages based on a case study of several parser
generators with varying functionality
<http://www.complang.tuwien.ac.at/anton/euroforth/ef99/ertl99.pdf>.
Given the differing functionality of the compared parser generators,
it would be useful for that kind of study to get a number that
represents the functionality and can be related to the SLOC (source
lines of code) metric for the implementation. Are function points
usable for this kind of application?
>And we see other language differences affecting programmers in other ways. =
> Take for example the subject of typed versus untyped (or dynamically typed=
>) languages. In this newsgroup, many discussions about typed languages pre=
>sent such languages as a straight-jacket where some totalitarian compiler p=
>revents you from doing what you want. But when you move outside the realm =
>of languages like C and into languages like Haskell and F# that have type i=
>nferencing and pattern matching and you view types very differently.
Really? My experience with Haskell is that I get type error messages
that are hard to comprehend.
Closer to comp.lang.forth, Factor has type inference; we had a little
workshop at the Forth-Tagung this year, where we should write a few
programs; the type checker constantly hindered me in achieving what I
wanted to do, and most others had a similar experience. Bernd found a
solution that was accepted, but when I tried to use his ideas for my
own program, I ran into the type checker again; I think that Bernd
just found a hole in the type checker.
OTOH, C type checking complicates things, but is still simple enough
that I can get out of C what I want (or maybe I just have more
experience with it). So, yes, Haskell type checking is different, but
not in the way you imply.
- 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-08-23 11:43 -0700 |
| Subject | Re: Function Points |
| Message-ID | <7x8vd5jvoh.fsf@ruckus.brouhaha.com> |
| In reply to | #15122 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > Really? My experience with Haskell is that I get type error messages > that are hard to comprehend. GHC's error messages are often pretty bad, but they usually do result from actual program errors that would make it into the executable if the type checker hadn't found them, so they are worth it. As you get more used to Haskell, it gets easier to just look at the line number that the error message points to, and figure out what is wrong with the code by inspection. The error message usually does tell you the particular sub-expression that has gone wrong.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-08-25 14:13 +0000 |
| Subject | Re: Function Points |
| Message-ID | <2012Aug25.161317@mips.complang.tuwien.ac.at> |
| In reply to | #15124 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Really? My experience with Haskell is that I get type error messages
>> that are hard to comprehend.
>
>GHC's error messages are often pretty bad, but they usually do result
>from actual program errors that would make it into the executable if the
>type checker hadn't found them, so they are worth it.
The Haskell system was actually Hugs, not GHC, but the quality of the
error messages is due to the type system, so I would not expect any
better from a different Haskell system: The system just sees some
puzzle pieces and infers the missing pieces itself. If the pieces I
give it belong to different puzzles, it will fail at puzzing it out,
and since the system does not know which of the given puzzle pieces
are wrong, the error messages are necessarily not very helpful.
Concerning being worth, I have far fewer type errors in Forth than in
Haskell. Maybe that just reflects my familiarity with the languages,
but I believe that this is due to the languages and their type
systems. Forth is designed to be usable without type checking,
whereas Haskell is designed for static type checking with type
inference.
>As you get more
>used to Haskell, it gets easier to just look at the line number that the
>error message points to, and figure out what is wrong with the code by
>inspection.
Yes, after a while I learned some patterns of the kind, that a
particular incomprehensible error message points to this kind of
frequent error.
Anyway, my conclusion is that, while type inference sounds cool in
theory, it has more disadvantages than advantages in practice. One of
the disadvantages probably is that it allows a complex type system
that would be totally impractical without type inference; and the
Haskell designers went that way.
- 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-08-25 10:12 -0700 |
| Subject | Re: Function Points |
| Message-ID | <7x8vd299q5.fsf@ruckus.brouhaha.com> |
| In reply to | #15154 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > The Haskell system was actually Hugs, not GHC, but the quality of the > error messages is due to the type system, so I would not expect any > better from a different Haskell system I suggest trying GHC. Its messages are better, though still not that great. Nobody uses Hugs much any more, afaik. > Concerning being worth, I have far fewer type errors in Forth than in > Haskell. Do you mean type errors that the compiler didn't notice? Forth of course ignores type errors at compile time. I'd ask how many Forth runtime errors would have been caught by Haskell's type system at compile time. When I wrote my first nontrivial Forth program, I several times said + when I meant F+, and of course the runtime happily added the wrong two stack items, causing later crashes that I then had to debug. That was much more annoying than just having the compiler flag the error. > Maybe that just reflects my familiarity with the languages, That could be, though Haskell is just typed lambda calculus with syntax sugar. If you erase all the types and syntax, you're left with something like Scheme, modulo lazy evaluation. And it's quite easy to make type errors in Scheme. Haskell's type system makes it feasible to write maintainable code in a quite abstract style involving higher-order functions, parametrized data types, and so on. This can also be done in Forth or Scheme but it gets confusing rather quickly. Having a computer keep track of the types takes cognitive burden off of the programmer, and makes refactoring easier (just fix the resulting type errors until the compiler stops complaining, and you probably have working code). > Anyway, my conclusion is that, while type inference sounds cool in > theory, it has more disadvantages than advantages in practice. One of > the disadvantages probably is that it allows a complex type system > that would be totally impractical without type inference; and the > Haskell designers went that way. Preferred Haskell style is to write explicit type annotations on all top-level functions, and this helps keep the error messages useful. ML's type system is less fancy than Haskell's and I think it's more practical in ML to not write any annotations and rely completely on inference. Writing top-level annotations isn't all that bothersome, and they serve as machine-checked documentation among other things. Preferred Forth style also involves writing type annotations (stack diagrams) on all functions. The compiler just doesn't bother checking them.
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2012-08-25 15:39 -0400 |
| Subject | Re: Function Points |
| Message-ID | <503929e3$0$283$14726298@news.sunsite.dk> |
| In reply to | #15157 |
On 8/25/12 1:12 PM, Paul Rubin wrote: > When I wrote my first nontrivial Forth program, I several > times said + when I meant F+, and of course the runtime happily added > the wrong two stack items, causing later crashes that I then had to > debug. That was much more annoying than just having the compiler flag > the error. If you are writing short, factored words, and testing each word before continuing then that "+ instead of F+" should have become immediately apparent and so no problem at all to notice and fix. No type checker needed if you follow the recommended Forth way of writing a program. -Doug
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-08-25 15:09 -0700 |
| Subject | Re: Function Points |
| Message-ID | <7xfw7aipyk.fsf@ruckus.brouhaha.com> |
| In reply to | #15158 |
Doug Hoffman <glidedog@gmail.com> writes: > If you are writing short, factored words, and testing each word before > continuing then that "+ instead of F+" should have become immediately > apparent and so no problem at all to notice and fix. No type checker > needed if you follow the recommended Forth way of writing a program. As I remember, it wasn't so immediately apparent what the problem was, since the failure didn't occur til a little ways after the + happened. And the symptom was that the program crashed without much clue about what had happened. Of course fancy debugging tools would have made it easier to trace and fix the problem, and it's not inherent in Forth that the implementation I used didn't happen to have them. Looking at the code now, its factoring doesn't seem too bad, though maybe it could be better. Anyway, if a type-checked language lets me write a page full of code and fix the compile-time errors to usually get working program, while the typeless counterpart makes me stop what I'm doing after basically every single line to check for problems the type checker would have caught automatically, I'd say the type checker has made itself worthwhile.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-08-25 12:34 -1000 |
| Subject | Re: Function Points |
| Message-ID | <k8OdnXT2-6VEz6TNnZ2dnUVZ_hCdnZ2d@supernews.com> |
| In reply to | #15159 |
On 8/25/12 12:09 PM, Paul Rubin wrote: > Doug Hoffman <glidedog@gmail.com> writes: >> If you are writing short, factored words, and testing each word before >> continuing then that "+ instead of F+" should have become immediately >> apparent and so no problem at all to notice and fix. No type checker >> needed if you follow the recommended Forth way of writing a program. > > As I remember, it wasn't so immediately apparent what the problem was, > since the failure didn't occur til a little ways after the + happened. > And the symptom was that the program crashed without much clue about > what had happened. Of course fancy debugging tools would have made it > easier to trace and fix the problem, and it's not inherent in Forth that > the implementation I used didn't happen to have them. Looking at the > code now, its factoring doesn't seem too bad, though maybe it could be > better. > > Anyway, if a type-checked language lets me write a page full of code and > fix the compile-time errors to usually get working program, while the > typeless counterpart makes me stop what I'm doing after basically every > single line to check for problems the type checker would have caught > automatically, I'd say the type checker has made itself worthwhile. Unit-testing every definition pays off handsomely in saved debugging time by catching all kinds of bugs, not just type errors. And my experience is similar to Anton's, in that I make very few type errors. This may be because I'm accustomed to matching the right operators to the right data type, whereas folks who are used to languages that do type inference are less conscious of it. But the majority of errors (not only for me but for programmers I work with) are logic/algorithm errors, and they're readily detected by unit testing each definition. Takes seconds, can save hours! 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-08-25 16:43 -0700 |
| Subject | Re: Function Points |
| Message-ID | <7xy5l28rlv.fsf@ruckus.brouhaha.com> |
| In reply to | #15160 |
> Unit-testing every definition pays off handsomely in saved debugging > time by catching all kinds of bugs, not just type errors. You can think of compile-time type checking as automatic generation of a wide class of unit tests. It doesn't eliminate the need for manually-written tests, but it decreases it. The main idea of programming computers is to offload work from humans to machines, so automatic test generation seems like a win to me, at least from a productivity point of view. I'd accept that Forth builds character, by making the programmer think harder. I probably get something out of that. The older saying was "assembly language programming is good for the soul". IMHO Haskell's type system makes it practical to program in a style that while not impossible, would be much harder to manage in Forth. Basically, one where functions create other functions on the fly, and those functions create other functions and so on. From a Forth perspective, we'd probably say that style is confusing and error-prone, and therefore something bad to be avoided. In Haskell, it's beautiful and it works, because the type system guides the construction and prevents the programs from going wrong. http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ is a good article about this stuff.
[toc] | [prev] | [next] | [standalone]
| From | jacko <jackokring@gmail.com> |
|---|---|
| Date | 2012-08-25 18:05 -0700 |
| Subject | Re: Function Points |
| Message-ID | <4d10bdd5-9ffc-4682-a336-71f49bc179eb@googlegroups.com> |
| In reply to | #15161 |
My language SL written in JavaME/SE (http://jarvar.googlecode.com) has some interesting type features. I would describe it as "weak" as possible typed. Full conversion of numeric types to the lowest representational form, and numbers as single characters, (being the same thing). As a necessity of system stability, some values must be "strong" and so only assignment of the same type is allowed. Also some things have to be "constant", for the same system stability reasons. This is opposite to the idea that things are constant for speed or compile time optimization. I do not yet know how effective this language is yet. There is still much to decide. Such as IO forms, (constants vectorized) -> code minimized -> same resultant which have to be explored. The time it takes to do something already in another language is not a fit measure of language utility. Maybe the time it takes to bootstrap a compiler for (or translator to) a language in itself has some measure, but it's not the be and end all. SL is currently very small source, and binary. Cheers Jacko
[toc] | [prev] | [next] | [standalone]
| From | jacko <jackokring@gmail.com> |
|---|---|
| Date | 2012-08-25 20:34 -0700 |
| Subject | Re: Function Points |
| Message-ID | <c4b29407-0895-4cd7-8449-f353f799d477@googlegroups.com> |
| In reply to | #15162 |
Also now on github for those wishing to fork.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-08-26 03:24 +0200 |
| Subject | Re: Function Points |
| Message-ID | <3185042.MPhYQTzUyq@sunwukong.fritz.box> |
| In reply to | #15161 |
Paul Rubin wrote: > You can think of compile-time type checking as automatic generation of > a > wide class of unit tests. It doesn't eliminate the need for > manually-written tests, but it decreases it. The main idea of > programming computers is to offload work from humans to machines, so > automatic test generation seems like a win to me, at least from a > productivity point of view. I'd accept that Forth builds character, > by > making the programmer think harder. Actually not. I think harder when I program in other languages, because in Forth, I just try. The thing Forth tries to minimize is the time for feedback. This is a psychological thing, if I program in Forth, I'm not distracted, it's programming, and trying my program, nothing else. If I program in C, I can start the compiler and then play a round of some silly social network game, and come back, and the compiler might just have finished. In the meantime, I forgot what I wanted to do. Performance is a problem, even in 2012. Performance of C compilers, so to speak. The build tool to compile Android is called "lunch", for obvious reasons. If I would have to give a similar name for the build process of bigForth, it would be "blink". You start it and it's done. Which means that quickly doing some changes and seeing what they do to the system is possible. You don't have to think, you just do it. That also guides to my most-used debugging method: Inserting ~~ in suspicious places. As I can rebuild everything quickly, when I have troubles comprehending what happends inside a function, and unit testing doesn't show it (or isn't easy, because I don't know which are the input parameters that cause the crash), I insert ~~ and look. > I probably get something out of > that. The older saying was "assembly language programming is good for > the soul". Of course it is. You understand what the machine actually does. > IMHO Haskell's type system makes it practical to program in a style > that while not impossible, would be much harder to manage in Forth. > Basically, one where functions create other functions on the fly, and > those functions create other functions and so on. From a Forth > perspective, we'd probably say that style is confusing and > error-prone, and therefore something bad to be avoided. I'm not sure why you claim it is error-prone and to be avoided. We do this, we have tools for that like postpone, ]] [[, and create does> (which can be said to be some sort of currying). It certainly has a different, more fine-grained approach than the Haskell approach. Forth is a programming language which tells you to avoid unnecessary abstractions. Solve the problem, don't invent layers of layers in between you and the problem (toilet paper style programming - "keep me away from the shit"). > In Haskell, it's beautiful > and it works, because the type system guides the construction and > prevents the programs from going wrong. No type system prevents programs from going wrong. It applies a number of low-hanging fruit checks, while at the same time putting a straitjacket onto the programmer. At least that's how I feel when I program in a language with a strong type system. The compiler tells me "no, you can't do this", and "no, you can't do that". When the program finally compiles, the programmer is so happy that he forgets to actually test the program. > http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ > > is a good article about this stuff. Maybe, but some things in the article are silly and wrong. Performance is not a problem? Come on. I'm constantly seeing software which is slow as molasses, and fills memory faster than Samsung can make it (in GB/s, and Samsung produces quite a lot of GB chips per second). It's rarely the programming language which is too slow, it's the programmer mentality, like "lunch" is an adequate time to recompile something. "It used to be days". Yes, that was wrong, too. What I think would be worth to do for analytic compilers which track that information anyways: Have a stack effect checker. Warnings when it doesn't match, please, it should compile, because running it (with inserted ~~) will identify the problem quickly. Factor refuses to compile when the stack effect is wrong or perceived wrong. There are for sure cases where the compiler can't deduce the stack effect, but it is correct, nonetheless. Programs can only check low-hanging fruits of correctness. Different programming languages have different approaches, and that's reflected by their community. A Haskell programmer thinks in terms of Haskell's type system and when learning Forth will try to put a typechecker around Forth. That's not what makes Forth strong, Forth's interactivity and abstraction avoidance is what makes it strong. Interactivity is more than just a command line promt, it also means that you can recompile quickly. "Blink", not "lunch". Of course, adding features from other languages opens up new ways of doing things. We have our experiments with StrongForth and Forth typecheckers (typically written in Haskell ;-). -- 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-08-25 22:44 -0700 |
| Subject | Re: Function Points |
| Message-ID | <7xzk5i9pi3.fsf@ruckus.brouhaha.com> |
| In reply to | #15163 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
> The build tool to compile Android is called "lunch", for
> obvious reasons. If I would have to give a similar name for the build
> process of bigForth, it would be "blink".
Are you talking about compiling programs of similar size, on similar
hardware, with compilers that do similar levels of optimization? It's
certainly plausible that given more CPU power, fancy compilers will
use it to do more optimization and automation, rather than just doing
the same stuff as before and finishing sooner.
Maybe you should try TCC (tinycc.org) for development builds.
It's around 10x faster than GCC, though the output code is nowhere near
as optimized.
> That also guides to my most-used debugging method: Inserting ~~ in
> suspicious places.
This still takes a lot of runs of the program and possible creation of
new test cases, which can be pretty tedious.
>> IMHO Haskell's type system makes it practical to program in a style
>> that while not impossible, would be much harder to manage in Forth....
> I'm not sure why you claim it is error-prone and to be avoided....
> Forth is a programming language which tells you to avoid unnecessary
> abstractions.
Right, the reason it tells you to avoid unnecessary abstractions is that
using abstraction in Forth is error-prone. I wasn't thinking really of
postpone and create/does, but more of a style where you pass around
execution tokens a lot, and those xt's may take other xt's as arguments
to invoke over generic data structures, and so on. In Haskell, it's
natural to program that way, and the code still feels solid. In Scheme
or Python you can write basically the same code, but with no type system
watching over you, it feels like walking on a tightrope without a safety
net. I've programmed that way in Forth a little bit, but have been
advised against it.
> No type system prevents programs from going wrong.
Well, I'd say a well-typed program, including something like Lisp with
runtime type-checking, can at least have well-defined semantics, while
an untyped (e.g. Forth or C) program can go completely into the weeds if
there is a type error (such as a subscript overflow).
> It applies a number of low-hanging fruit checks,
Haskell typechecking can be quite powerful. I like this example:
https://gist.github.com/2659812
Explanation: Red-black trees are binary trees with the following
invariants:
1. Each internal node is colored either red or black.
All leaves are black and the root is black.
2. All children of red nodes must be black. Black nodes can
have children of either or both colors.
3. All paths from the root to the leaf contain the
same number of black nodes.
This means the tree is approximately balanced: any path from the root to
a leaf contains n black nodes, and between 0 and n red nodes, so the
worst case search depth is no more than 2x the best case. You can't get
a completely lopsided tree. To insert or delete a node, you have to do
somewhat complicated juggling operations ("tree rotations") to preserve
the invariants, and it's easy to make mistakes coding these operations.
The C++ implementation that I looked at has assert statements that check
at runtime that the code didn't hit some weird edge case that messed the
invariants up. Even after extensive testing, the assert statements are
still there in the program.
It turns out to be pretty straightforward to express those invariants as
a Haskell datatype (seen in the url above). Any value belonging to the
type must be a properly balanced tree. That means that the juggling
code cannot possibly mess up the invariants. Any attempt to make an
unbalanced tree will cause a type-checking error, and the program won't
compile. It would be pointless to have assert statements in the
executable since the compiler has statically verified that the asserted
conditions hold. I would not call this low-hanging fruit. It's a
sophisticated condition being checked, that's a source of bugs in other
real-world implementations, and the compiler verifies it to higher
confidence than even quite a lot of unit tests could give.
As an even more extreme example, Coq's type system is even stronger than
Haskell's: it can express any mathematical proposition, so it has to be
Turing complete, meaning it can't do inference and you have to manually
supply type derivations (which is tedious). But it can encode (for
example) the semantics of assembly code fragments (Hoare triples) as
types. So if you have a compiler optimization pass that is annotated to
take one fragment and returns another fragment of the same type, the Coq
typechecker is able to verify that the input and output have the same
semantics and the optimization pass has not introduced any semantic
bugs. I think I mentioned before, a sizable part of a C compiler has
been written that way (CompCert). This is not low hanging fruit at all.
It is probably the future, especially as better automation becomes
available for developing this sort of code.
> while at the same time putting a straitjacket onto the programmer. At
> least that's how I feel when I program in a language with a strong
> type system. The compiler tells me "no, you can't do this", and "no,
> you can't do that".
I never felt terribly straitjacketed programming in C, but I also felt
that the type system wasn't helping me that much. I was comfortable
programming with lots of void*'s, and programming in Lisp with runtime
types. Trying Haskell was really eye-opening for me. I'm a long way
from being a Haskell expert but I find it tremendously interesting and
different (whether that means "better" is of course a separate matter).
>> http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/
> Performance is not a problem? Come on. I'm constantly seeing
> software which is slow as molasses,
He's talking about compiled code with runtime type checks, vs. compiled
code that has been statically checked but otherwise does the same stuff,
e.g. Lisp vs ML. If the compiler is any good, the performance
difference is usually a small constant factor, maybe just a few percent.
The large, order-of-magnitude slowdowns you're seeing in the examples
you mention are due to architectural issues in the slow programs.
> What I think would be worth to do for analytic compilers which track
> that information anyways: Have a stack effect checker.
Yes, that would have caught my + vs. F+ bugs. StrongForth does
that sort of checking as you're probably aware.
> Warnings when it doesn't match, please, it should compile, because
> running it (with inserted ~~) will identify the problem quickly.
GHC now has a command-line option that lets it produce executable code
even if the program has type errors. You then get a runtime error only
if the program tries to actually evaluate an ill-typed expression. This
turns out to be handy during development even though the compiler has
already told you where the errors are. It's sometimes useful to be able
test the successfully compiling parts of your program right away,
postponing dealing with the unsuccessful parts til later.
> Forth's interactivity and abstraction avoidance is what makes it
> strong. Interactivity is more than just a command line promt, it also
> means that you can recompile quickly. "Blink", not "lunch".
I sometimes like to imagine what it must have been like to program in
Forth or Lisp in the glory days of those languages. I'd be interested
in seeing a demo sometime (maybe on video) of someone hacking on Forth
code that does something complicated, using good interactive Forth
tools. When I started using Python, I found myself thinking "this is
what the old-time Maclisp hackers must have felt like". Haskell is
different, completely different, a vision as powerful as Lisp but unlike
anything that had been used for programming before. That in some sense
outweighs any difficulties involved in trying to actually use it. ;-)
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-08-25 21:19 -1000 |
| Subject | Re: Function Points |
| Message-ID | <m62dnf4P_e-bU6TNnZ2dnUVZ_jydnZ2d@supernews.com> |
| In reply to | #15166 |
On 8/25/12 7:44 PM, Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> The build tool to compile Android is called "lunch", for >> obvious reasons. If I would have to give a similar name for the build >> process of bigForth, it would be "blink". > > Are you talking about compiling programs of similar size, on similar > hardware, with compilers that do similar levels of optimization? It's > certainly plausible that given more CPU power, fancy compilers will > use it to do more optimization and automation, rather than just doing > the same stuff as before and finishing sooner. Forth compilers have always been fast. Even with optimizing techniques in modern Forths, they're many times faster than other compilers. I have observed this many times, but don't know enough about the other compilers to know why they are so slow. >> That also guides to my most-used debugging method: Inserting ~~ in >> suspicious places. > > This still takes a lot of runs of the program and possible creation of > new test cases, which can be pretty tedious. But it doesn't involve "creation of new test cases". It's as simple as typing n m foo . ...to test foo and look at its results. ... >> Forth's interactivity and abstraction avoidance is what makes it >> strong. Interactivity is more than just a command line prompt, it also >> means that you can recompile quickly. "Blink", not "lunch". > > I sometimes like to imagine what it must have been like to program in > Forth or Lisp in the glory days of those languages. I'd be interested > in seeing a demo sometime (maybe on video) of someone hacking on Forth > code that does something complicated, using good interactive Forth > tools. When I started using Python, I found myself thinking "this is > what the old-time Maclisp hackers must have felt like". Haskell is > different, completely different, a vision as powerful as Lisp but unlike > anything that had been used for programming before. That in some sense > outweighs any difficulties involved in trying to actually use it. ;-) I know nothing of Haskell, but have seen Forth programmers "taming" complex problems many times. I wish I had a video for you, it's very instructive! The best Forth programmers are most productive without using fancy tools, even when they are available. The effect is that they are "communing" with the code, sort of "code whisperers", trying things, making tiny adjustments, trying again, and the results come. Chuck once described the effect as "synergistic". No one, or two, or even three specific things, but an overall relationship between the programmer and the code that makes the creativity flow and the results happen with what seems to be amazing ease. The key is that each "try" is a blink. There is never a perceptible pause. In effect, what happens is that the intimate interactivity of Forth opens a direct channel between the mind of the programmer and the problem space that just *works*. 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-08-26 00:36 -0700 |
| Subject | Re: Function Points |
| Message-ID | <7xlih25clu.fsf@ruckus.brouhaha.com> |
| In reply to | #15167 |
"Elizabeth D. Rather" <erather@forth.com> writes:
> But it doesn't involve "creation of new test cases". It's as simple as
> typing
> n m foo .
> ...to test foo and look at its results.
That's not realistic;
1) foo might be much more complicated (delegating most of the work to
smaller factors, but you have to test the overall operation). The
args and result could be complex data structures, it might not be
easy to check the output correctness by simple inspection, etc.
2) foo could interact with external hardware. Here's a situation I've
had to deal with (not in Forth though): foo is called when a
certain hardware event happens, and works fine if I simulate the
event, or generate a real event and watch foo do its thing. But if
there are too many of these events in a several minute period, some
kind of internal overload condition results and foo does the wrong
thing. This only happens on the target (embedded) hardware--my
development workstation is much too fast to trigger an overload.
So I have to get all the external hardware firing in order to make
foo fail while I log what it's doing. This is not instant--it
takes a few minutes every run. So minimizing the number of runs
speeds up debugging, and it would be really nice if I could debug
interactively.
> I wish I had a video for you, it's very instructive! The best Forth
> programmers are most productive without using fancy tools, even when
> they are available.
Yes. I'd also be interested in seeing one with vintage tools, like a
block editor with shadow screens for comments, etc.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-08-25 21:50 -1000 |
| Subject | Re: Function Points |
| Message-ID | <wtWdnZREuLCuSKTNnZ2dnUVZ_sudnZ2d@supernews.com> |
| In reply to | #15168 |
On 8/25/12 9:36 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> But it doesn't involve "creation of new test cases". It's as simple as >> typing >> n m foo . >> ...to test foo and look at its results. > > That's not realistic; > > 1) foo might be much more complicated (delegating most of the work to > smaller factors, but you have to test the overall operation). The > args and result could be complex data structures, it might not be > easy to check the output correctness by simple inspection, etc. If all of the smaller factors have been tested, including the components that build the complex data structures, a lot of the work has been done. But I agree, sometimes it's necessary to have code to test your results. > 2) foo could interact with external hardware. Here's a situation I've > had to deal with (not in Forth though): foo is called when a > certain hardware event happens, and works fine if I simulate the > event, or generate a real event and watch foo do its thing. But if > there are too many of these events in a several minute period, some > kind of internal overload condition results and foo does the wrong > thing. This only happens on the target (embedded) hardware--my > development workstation is much too fast to trigger an overload. > So I have to get all the external hardware firing in order to make > foo fail while I log what it's doing. This is not instant--it > takes a few minutes every run. So minimizing the number of runs > speeds up debugging, and it would be really nice if I could debug > interactively. Yes, of course, sometimes you need to set up hardware correctly for testing. But if you've tested all the low-level parts of the operation, it shouldn't be hard to set up an overload test. >> I wish I had a video for you, it's very instructive! The best Forth >> programmers are most productive without using fancy tools, even when >> they are available. > > Yes. I'd also be interested in seeing one with vintage tools, like a > block editor with shadow screens for comments, etc. Actually, the programming process is virtually unchanged, even though the details (e.g. using an external programmer's editor instead of the integrated block editor) are different. 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-08-26 01:08 -0700 |
| Subject | Re: Function Points |
| Message-ID | <7xsjba3wiv.fsf@ruckus.brouhaha.com> |
| In reply to | #15169 |
"Elizabeth D. Rather" <erather@forth.com> writes: > Yes, of course, sometimes you need to set up hardware correctly for > testing. But if you've tested all the low-level parts of the > operation, it shouldn't be hard to set up an overload test. The external hardware is something I didn't build and don't control and that has no automation. I could in principle write code to simulate it on but that would be weeks of development, not feasible under current schedule and budget conditions. So I just have to operate the thing manually, at the speed that it goes at. It's not too bad as long as I don't have to do it too often.
[toc] | [prev] | [next] | [standalone]
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web