Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #16703 > unrolled thread
| Started by | Patricia Shanahan <pats@acm.org> |
|---|---|
| First post | 2012-10-18 08:32 +0100 |
| Last post | 2012-10-21 17:57 -0700 |
| Articles | 20 on this page of 113 — 20 participants |
Back to article view | Back to comp.lang.javascript
Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-18 08:32 +0100
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-18 10:23 +0200
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-18 13:42 +0100
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-18 17:59 +0200
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-18 09:56 -0700
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-19 00:49 +0200
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-19 11:04 -0700
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-20 11:52 +0200
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-19 12:06 -0700
Re: Programming style question Tim Streater <timstreater@greenbee.net> - 2012-10-19 23:12 +0100
Re: Programming style question "Mel Smith" <med_cutout_syntel@aol.com> - 2012-10-19 21:56 -0600
Re: Programming style question Bart Van der Donck <bart@nijlen.com> - 2012-10-20 02:21 -0700
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-20 12:03 +0200
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-20 06:31 -0700
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-20 18:30 +0200
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-20 10:32 -0700
Re: Programming style question Tim Streater <timstreater@greenbee.net> - 2012-10-20 22:34 +0100
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-21 10:12 +0200
Re: Programming style question Tim Streater <timstreater@greenbee.net> - 2012-10-21 09:34 +0100
Re: Programming style question Dr J R Stockton <reply1242@merlyn.demon.co.uk.invalid> - 2012-10-21 17:59 +0100
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-22 09:55 +0200
Re: Programming style question Tim Streater <timstreater@greenbee.net> - 2012-10-22 09:50 +0100
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-22 04:49 -0700
Re: Programming style question Tim Streater <timstreater@greenbee.net> - 2012-10-22 14:04 +0100
Re: Programming style question Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-10-22 16:07 +0200
Re: Programming style question Dr J R Stockton <reply1243@merlyn.demon.co.uk.invalid> - 2012-10-23 18:22 +0100
Re: Programming style question Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-10-22 16:01 +0200
Re: Programming style question Jim T. <x@y.z> - 2012-10-22 12:16 -0400
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-22 11:40 -0700
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-22 14:01 -0700
Re: Programming style question Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-10-23 10:07 +0200
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-23 09:43 -0700
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-23 11:49 +0200
Re: Programming style question Jim T. <x@y.z> - 2012-10-23 15:52 -0400
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-23 13:07 -0700
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-23 22:45 +0200
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-23 14:14 -0700
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-24 09:35 +0200
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-24 10:17 -0700
Re: Programming style question Dr J R Stockton <reply1243@merlyn.demon.co.uk.invalid> - 2012-10-25 18:41 +0100
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-25 17:03 -0700
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-25 20:14 -0700
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-25 20:46 -0700
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-26 09:55 +0200
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-26 06:18 -0700
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-26 17:43 +0200
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-26 09:57 -0700
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-26 10:24 -0700
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-26 14:18 -0700
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-27 10:45 +0200
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-27 12:58 +0200
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-27 16:18 +0200
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-27 18:08 +0200
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-27 18:26 +0200
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-27 19:43 +0200
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-27 21:09 +0200
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-27 22:53 +0200
Re: Programming style question John G Harris <john@nospam.demon.co.uk> - 2012-10-28 11:37 +0000
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-28 12:50 +0100
Re: Programming style question Martin Leese <please@see.Web.for.e-mail.INVALID> - 2012-10-28 13:43 -0600
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-28 23:58 +0100
Re: Programming style question John G Harris <john@nospam.demon.co.uk> - 2012-10-29 11:18 +0000
Re: Programming style question Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2012-10-27 23:58 +0200
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-28 12:43 +0100
Re: Programming style question Dr J R Stockton <reply1243@merlyn.demon.co.uk.invalid> - 2012-10-27 19:44 +0100
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-24 12:06 -0700
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-24 21:27 +0200
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-24 15:12 -0700
Re: Programming style question Tim Streater <timstreater@greenbee.net> - 2012-10-25 01:29 +0100
Re: Programming style question Stefan Weiss <krewecherl@gmail.com> - 2012-10-24 21:25 +0200
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-24 21:57 +0200
Re: Programming style question Stefan Weiss <krewecherl@gmail.com> - 2012-10-25 01:11 +0200
Re: Programming style question Christoph Becker <cmbecker69@gmx.de> - 2012-10-25 02:00 +0200
Re: Programming style question Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-24 20:27 -0700
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-25 08:44 +0200
Re: Programming style question Adam Silver <adambsilver@gmail.com> - 2012-10-25 04:28 -0700
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-25 23:18 +0200
Re: Programming style question Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-26 08:24 -0700
Re: Programming style question Stefan Weiss <krewecherl@gmail.com> - 2012-11-07 22:13 +0100
Re: Programming style question Tim Streater <timstreater@greenbee.net> - 2012-11-07 21:51 +0000
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-07 23:47 +0100
Re: Programming style question Stefan Weiss <krewecherl@gmail.com> - 2012-11-08 01:14 +0100
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-11-07 16:51 -0800
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-11-08 16:45 +0100
Re: Programming style question Scott Sauyet <scott.sauyet@gmail.com> - 2012-11-08 08:02 -0800
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-11-08 17:39 +0100
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-11-08 11:25 -0800
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-11-08 22:25 +0100
Re: Programming style question John G Harris <john@nospam.demon.co.uk> - 2012-11-09 10:19 +0000
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-11-09 17:41 +0100
Re: Programming style question Dr J R Stockton <reply1245@merlyn.demon.co.uk.invalid> - 2012-11-10 22:38 +0000
Re: Programming style question Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-22 12:32 -0700
Re: Programming style question Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-10-23 10:05 +0200
Re: Programming style question Christoph Becker <cmbecker69@gmx.de> - 2012-10-22 22:11 +0200
Re: Programming style question Stefan Weiss <krewecherl@gmail.com> - 2012-10-23 02:42 +0200
Re: Programming style question Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-10-23 10:08 +0200
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-20 18:34 +0200
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-18 11:57 +0200
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-18 13:06 +0100
Re: Programming style question "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-10-18 15:32 +0300
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-18 13:37 +0100
Re: Programming style question "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-10-18 15:55 +0300
Re: Programming style question John G Harris <john@nospam.demon.co.uk> - 2012-10-19 10:12 +0100
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-19 07:24 -0700
Re: Programming style question John G Harris <john@nospam.demon.co.uk> - 2012-10-20 17:47 +0100
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-24 01:15 +0100
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-24 01:31 +0100
Re: Programming style question "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-10-24 07:34 +0300
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-24 19:57 +0200
Re: Programming style question "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-10-24 21:02 +0300
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-18 20:15 -0700
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-24 01:21 +0100
Re: Programming style question Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-21 17:57 -0700
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2012-10-18 08:32 +0100 |
| Subject | Programming style question |
| Message-ID | <r_WdnX50haYCLeLNnZ2dnUVZ_vGdnZ2d@earthlink.com> |
I've just started writing some of my production code, as distinct from throw-away tests and practice programs. I find myself writing in a style that would work in a strongly typed language. I know the intended type of each identifier, and find myself recording types in comments. It is perhaps natural because I have been programming so long in more strongly typed languages. Is it a problem? On the one hand, it makes for very organized code, with a lot of opportunities for adding type-checking assertions, generally a good thing. On the other hand, I may be missing out on opportunities to make my code simpler and a better fit for the language. Is it enough to be aware of the dynamic aspects of the language, and be prepared to use them when strong typing gets in the way? Patricia
[toc] | [next] | [standalone]
| From | "Evertjan." <exxjxw.hannivoort@inter.nl.net> |
|---|---|
| Date | 2012-10-18 10:23 +0200 |
| Message-ID | <XnsA0F069C176694eejj99@194.109.133.133> |
| In reply to | #16703 |
Patricia Shanahan wrote on 18 okt 2012 in comp.lang.javascript: > I've just started writing some of my production code, as distinct from > throw-away tests and practice programs. I find myself writing in a style > that would work in a strongly typed language. I know the intended type > of each identifier, and find myself recording types in comments. > > It is perhaps natural because I have been programming so long in > more strongly typed languages. > > Is it a problem? Yes > On the one hand, it makes for very organized code, with a lot of > opportunities for adding type-checking assertions, generally a good > thing. On the other hand, I may be missing out on opportunities to make > my code simpler and a better fit for the language. The latter. Especially when working with and pre-testing of small modules, the consizeness of code with automatic conversion helps to understand the working of the code at hand. > Is it enough to be aware of the dynamic aspects of the language, and be > prepared to use them when strong typing gets in the way? If you keep thinking in terms of strong-typed values, you will mis the opportunities of non-typed variables and weak-typed values, of implicit type-transformation. This will perhaps not induce errors, but certainly will induce expected error handling and reporting. Optimal use of a language as complex as Javascript, especially in the sense of programming for clientside browser cross-platform execution with different engines for the same code is the norm, expects either a perfect feel of the intricacies, or a prepared nes of the users to allow for often and unexpected wrong behavour and errors. There is much to be said for strong-typed languages, but their main usefulness is or was keeping the memory-allocation for variables small in the compiled executable. Historically this was even more important than now, memory having become cheap, but in a scripting language like Javascript, where the memory is only allocated at execution-time this has been the case much longer. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2012-10-18 13:42 +0100 |
| Message-ID | <R_WdnYPwuJ3QZOLNnZ2dnUVZ_uGdnZ2d@earthlink.com> |
| In reply to | #16704 |
Evertjan. wrote: ... > There is much to be said for strong-typed languages, but their main > usefulness is or was keeping the memory-allocation for variables small in > the compiled executable. Historically this was even more important than > now, memory having become cheap, but in a scripting language like > Javascript, where the memory is only allocated at execution-time this has > been the case much longer. > I've never seen compact memory representation as the most important benefit of strong typing. Even in languages that permit global and static data, the trend is towards dynamically loading libraries and dynamically allocated memory. For one thing, most program now have to operate across a range of memory and problem sizes that would make static memory allocation very inconvenient. The primary advantage form my point of view is universally quantified assertions. In Java, I can know that in all executions, under all conditions, a particular variable is either null or a pointer to a String. The most I can know without strong typing is that it has been a String in every test I've run so far. Patricia
[toc] | [prev] | [next] | [standalone]
| From | "Evertjan." <exxjxw.hannivoort@inter.nl.net> |
|---|---|
| Date | 2012-10-18 17:59 +0200 |
| Message-ID | <XnsA0F0B70DAAC48eejj99@194.109.133.133> |
| In reply to | #16709 |
Patricia Shanahan wrote on 18 okt 2012 in comp.lang.javascript: > Evertjan. wrote: > ... >> There is much to be said for strong-typed languages, but their main >> usefulness is or was keeping the memory-allocation for variables >> small in the compiled executable. Historically this was even more >> important than now, memory having become cheap, but in a scripting >> language like Javascript, where the memory is only allocated at >> execution-time this has been the case much longer. >> > > I've never seen compact memory representation as the most important > benefit of strong typing. Even in languages that permit global and > static data, the trend The "trend" perhaps, but in older compiling languages, a typed variable got it's own permanent number of bytes. Even a string had to be definet with it's maximum length. This is still an important issue with databases, as you may well know. > is towards dynamically loading libraries and > dynamically allocated memory. For one thing, most program now have to > operate across a range of memory and problem sizes that would make > static memory allocation very inconvenient. "Now" perhaps, but strong typing was not developed for the present. > The primary advantage form my point of view is universally quantified > assertions. In Java, I can know that in all executions, under all > conditions, a particular variable is either null or a pointer to a > String. That this is an advantage could be just your preconditioned imagination, because that is the way yo were trained, or preferably you trained yourself. Howver I cannot imagine assembler or microcode to be dependent on dynamic memory. Those languages perhaps are not your piese of cake, but that does not mean they are not cricket. Dynamic memory allocation also came late in Forth, Pascal, etc. > The most I can know without strong typing is that it has been > a String in every test I've run so far. But what would be the absolute advantage, but that you are used to it? Especially when using scripting languages, either just executed as read, like batch-languages, or "late" compiled at executuion-time, have nothing to gain from strong typing in my view. Those dynamics take care of the lack of strong consystancy. In short, why would I need to do manually insert translation function to see if ( 1 == '1' ) is true? While I can test the equality of types seperately if needed [quod seldom], I can also do strong comparison ( 1 === '1' ) [quod sometimes]. As I am always fighting the notion of "best programming practice", I would not object if you like exclusively using strong comparison in Javacript, but to some or many others your preferance arguments are not convincing. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@ocis.net> |
|---|---|
| Date | 2012-10-18 09:56 -0700 |
| Message-ID | <cnc088p6pfjkes0f3klmf68a64188n85o8@4ax.com> |
| In reply to | #16711 |
On Thu, 18 Oct 2012 17:59:41 +0200, "Evertjan."
<exxjxw.hannivoort@inter.nl.net> wrote:
>Patricia Shanahan wrote on 18 okt 2012 in comp.lang.javascript:
>
>> Evertjan. wrote:
>> ...
>>> There is much to be said for strong-typed languages, but their main
>>> usefulness is or was keeping the memory-allocation for variables
>>> small in the compiled executable. Historically this was even more
>>> important than now, memory having become cheap, but in a scripting
>>> language like Javascript, where the memory is only allocated at
>>> execution-time this has been the case much longer.
>>>
>>
>> I've never seen compact memory representation as the most important
>> benefit of strong typing. Even in languages that permit global and
>> static data, the trend
>
>The "trend" perhaps, but in older compiling languages, a typed variable
>got it's own permanent number of bytes. Even a string had to be definet
That would depend on the language. For example, PL/I (started by
IBM in the '60s; old enough?) has variable length strings
declare howeverlong char(50) varying;
Whether this is permanently set aside is an implementation issue, but
not a requirement.
Compiled BASICs had and have dynamically-allocated strings. Older
languages could, too; it is not a new concept.
>with it's maximum length. This is still an important issue with databases,
>as you may well know.
Well, not really. varchar(max) in SQL Server is limited to
2^31-1 bytes. That much memory is not allocated for each such string.
[snip]
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | "Evertjan." <exxjxw.hannivoort@inter.nl.net> |
|---|---|
| Date | 2012-10-19 00:49 +0200 |
| Message-ID | <XnsA0F18794F49Feejj99@194.109.133.133> |
| In reply to | #16712 |
Gene Wirchenko wrote on 18 okt 2012 in comp.lang.javascript: >>The "trend" perhaps, but in older compiling languages, a typed >>variable got it's own permanent number of bytes. Even a string had to >>be definet > > That would depend on the language. For example, PL/I (started by > IBM in the '60s; old enough?) has variable length strings > declare howeverlong char(50) varying; > Whether this is permanently set aside is an implementation issue, but > not a requirement. > > Compiled BASICs had and have dynamically-allocated strings. Older > languages could, too; No, Gene, ofcourse there are exceptions, but those do not reduce my point. Remember that compiled basics are latecomers, and that basic used to be a script-language for many many years before that. Remember that in basic a variable name could only be a letter plus a number, not a meaningful word, making remarks necessary for nearly every line of code, that a subroutines existed but user functions not, and reentant subroutines were impossible, because they only could exist with dynamic memory, local variables [as in closures] and return values. The primary idea of basic dim-ing [and pascal and even js var-ing] was to allocate memory, not as a "option explicit" error-finding mission. > it is not a new concept. You young boys and girls perhaps do not remember programming in Assembler or Forth, [or Algol], [and think pascal is a small form of hectopascal] so have a limited definition of "new" in this field. >>with it's maximum length. This is still an important issue with >>databases, as you may well know. > > Well, not really. varchar(max) in SQL Server is limited to > 2^31-1 bytes. That much memory is not allocated for each such string. Access up to this day requires simple strings to have a maximum size, and has a seperate type for strings upto 2 meg, I believe. Javascript in most or all aplications still has the nasty habit that string-size is inmutable and that any change in size needs a new stringallocation in memory. That is not important anymore in memorywize, as we have plenty of that, but makes string-concatenation very, very slow. This does not have to be, it is just a memory of the past, but more intelligent concatenation is notr implemented [yet]. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@ocis.net> |
|---|---|
| Date | 2012-10-19 11:04 -0700 |
| Message-ID | <935388lu912j7f0ru8j1e9pb8936d2bng7@4ax.com> |
| In reply to | #16720 |
On Fri, 19 Oct 2012 00:49:58 +0200, "Evertjan."
<exxjxw.hannivoort@inter.nl.net> wrote:
>Gene Wirchenko wrote on 18 okt 2012 in comp.lang.javascript:
>
>>>The "trend" perhaps, but in older compiling languages, a typed
>>>variable got it's own permanent number of bytes. Even a string had to
>>>be definet
>>
>> That would depend on the language. For example, PL/I (started by
>> IBM in the '60s; old enough?) has variable length strings
>> declare howeverlong char(50) varying;
>> Whether this is permanently set aside is an implementation issue, but
>> not a requirement.
>>
>> Compiled BASICs had and have dynamically-allocated strings. Older
>> languages could, too;
>
>No, Gene, ofcourse there are exceptions,
>but those do not reduce my point.
You made a general statement.
>Remember that compiled basics are latecomers, and that basic used to be a
>script-language for many many years before that.
What would you consider a latecomer? I used a BASIC compiler
first about thirty years ago.
>Remember that in basic a variable name could only be a letter plus a
>number, not a meaningful word, making remarks necessary for nearly every
That has not been true for over three decades.
>line of code, that a subroutines existed but user functions not, and
User functions have existed possibly from the beginning. They
were very limited (only one line). I used DEC's BASIC-Plus in the
mid-'70s and you could define multiline functions.
>reentant subroutines were impossible, because they only could exist with
>dynamic memory, local variables [as in closures] and return values.
They were not impossible. I did it.
>The primary idea of basic dim-ing [and pascal and even js var-ing] was to
>allocate memory, not as a "option explicit" error-finding mission.
How is this even relevant? I use many features for multiple
reasons.
>> it is not a new concept.
>
>You young boys and girls perhaps do not remember programming in Assembler
>or Forth, [or Algol], [and think pascal is a small form of hectopascal] so
>have a limited definition of "new" in this field.
I will be turning 52 next month. I have used all of the
languages in your paragraph. And more.
>>>with it's maximum length. This is still an important issue with
>>>databases, as you may well know.
>>
>> Well, not really. varchar(max) in SQL Server is limited to
>> 2^31-1 bytes. That much memory is not allocated for each such string.
>
>Access up to this day requires simple strings to have a maximum size, and
>has a seperate type for strings upto 2 meg, I believe.
I use long strings in tables. I rarely need anything that long.
I would question the design.
Access is but one DBMS and a low-end one. It is hardly a good
sample of the entire field.
>Javascript in most or all aplications still has the nasty habit that
>string-size is inmutable and that any change in size needs a new
>stringallocation in memory. That is not important anymore in memorywize,
>as we have plenty of that, but makes string-concatenation very, very slow.
That is an implementation issue and hardly makes it impossible.
>This does not have to be, it is just a memory of the past, but more
>intelligent concatenation is notr implemented [yet].
It would be nice. It was a change in Visual FoxPro that some
really liked.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | "Evertjan." <exxjxw.hannivoort@inter.nl.net> |
|---|---|
| Date | 2012-10-20 11:52 +0200 |
| Message-ID | <XnsA0F278B9EDBC2eejj99@194.109.133.133> |
| In reply to | #16738 |
Gene Wirchenko wrote on 19 okt 2012 in comp.lang.javascript: > On Fri, 19 Oct 2012 00:49:58 +0200, "Evertjan." > <exxjxw.hannivoort@inter.nl.net> wrote: > >>Gene Wirchenko wrote on 18 okt 2012 in comp.lang.javascript: >> >>>>The "trend" perhaps, but in older compiling languages, a typed >>>>variable got it's own permanent number of bytes. Even a string had >>>>to be definet >>> >>> That would depend on the language. For example, PL/I (started >>> by >>> IBM in the '60s; old enough?) has variable length strings >>> declare howeverlong char(50) varying; >>> Whether this is permanently set aside is an implementation issue, >>> but not a requirement. >>> >>> Compiled BASICs had and have dynamically-allocated strings. >>> Older >>> languages could, too; >> >>No, Gene, ofcourse there are exceptions, >>but those do not reduce my point. > > You made a general statement. Indeed, I was using historical string memmoy allocation as argument. Ecxceptions do not reduce my point, as general statements surely alllow for exceptions. >>Remember that compiled basics are latecomers, and that basic used to >>be a script-language for many many years before that. > > What would you consider a latecomer? I used a BASIC compiler > first about thirty years ago. Wow, I used basic 40 years ago, when it was sort of a superion batch language [comand line interpreter], what we later called a script language [interpreter as opposed to compiler], no compiling in sight for many years to come, original Dartmouth BASIC being from 1964. I used and retro-disassembled/recompiled Central Data Basic for Signetics 2650 microprocessor [yes, the one with the many microchip registers] written [around 1977?] by someone named William Gates, then of Altair fame, I believe. [Central Date Corp., Champain, IL: Basic on tape or floppy 12kB] Before that I had some collisions with Algol-60. So yes, latecomer. >>Remember that in basic a variable name could only be a letter plus a >>number, not a meaningful word, making remarks necessary for nearly >>every > > That has not been true for over three decades. It hasn't rained for two hole days here! >>line of code, that a subroutines existed but user functions not, and > > User functions have existed possibly from the beginning. They > were very limited (only one line). I used DEC's BASIC-Plus in the > mid-'70s and you could define multiline functions. As a latecomer perhaps you don't remember the difference between subroutines and functions. I believe it had only subroutines, no user- functions. >>reentant subroutines were impossible, because they only could exist >>with dynamic memory, local variables [as in closures] and return >>values. > > They were not impossible. I did it. You did what and when? >>The primary idea of basic dim-ing [and pascal and even js var-ing] was >>to allocate memory, not as a "option explicit" error-finding mission. > > How is this even relevant? I use many features for multiple > reasons. Relevant to what? What you use for what reasons has no incling on primary ideas of basic dim-ing, methinks. What are you trying to say? >>> it is not a new concept. >> >>You young boys and girls perhaps do not remember programming in >>Assembler or Forth, [or Algol], [and think pascal is a small form of >>hectopascal] so have a limited definition of "new" in this field. > > I will be turning 52 next month. Congratulations in advance, I could be the father of your elder siblings, biologically speaking. > I have used all of the > languages in your paragraph. And more. I wrote a Forth Kernel in 1982, <http://www.forth.org/fd/FD-V04N3.pdf> but that is not relavant, as I certainly do not stipulate you are both young boys and girls, I was speaking to the group. >>>>with it's maximum length. This is still an important issue with >>>>databases, as you may well know. >>> >>> Well, not really. varchar(max) in SQL Server is limited to >>> 2^31-1 bytes. That much memory is not allocated for each such >>> string. >> >>Access up to this day requires simple strings to have a maximum size, >>and has a seperate type for strings upto 2 meg, I believe. > > I use long strings in tables. I rarely need anything that long. > I would question the design. > > Access is but one DBMS and a low-end one. It is hardly a good > sample of the entire field. You still do not seem to gasp what I am talking about, like my rainy example above. I was not criticising the field, but giving relevant examples of non dynamic string memory allotment. If MS-Access is not a relevant example, perhaps we should exclude computer programminf in general as examples? >>Javascript in most or all aplications still has the nasty habit that >>string-size is inmutable and that any change in size needs a new >>stringallocation in memory. That is not important anymore in >>memorywize, as we have plenty of that, but makes string-concatenation >>very, very slow. > > That is an implementation issue and hardly makes it impossible. Sorry, your point escapes me. I thought we were, at least I was, discussing historical string memory implementation. Not impossibilities of implementation. >>This does not have to be, it is just a memory of the past, but more >>intelligent concatenation is not implemented [yet]. > > It would be nice. It was a change in Visual FoxPro that some > really liked. It is possible in Javascript. Split() the string into an array of individual characters, then use array functions like push() and pop(), (un)shift(), slice(), splice(). Then join the array for the result. The speed gained could be disolved in the sweat of programming perspiration. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2012-10-19 12:06 -0700 |
| Message-ID | <xsadnQmiZIUSORzNnZ2dnUVZ_i2dnZ2d@earthlink.com> |
| In reply to | #16720 |
On 10/18/2012 3:49 PM, Evertjan. wrote: ... > You young boys and girls perhaps do not remember programming in Assembler > or Forth, [or Algol], [and think pascal is a small form of hectopascal] so > have a limited definition of "new" in this field. ... I don't know if you are including me in "girls", but I still remember life as an assembly language programmer in 1970. I've also done significant programming in Forth and Pascal, but I've only done some student exercises in Algol. However, I tend to be more interested in what is going on now and what will happen in the future. I see strong typing as having its major benefits in ensuring some invariants are true for all executions, not just the ones that have happened during testing. Patricia
[toc] | [prev] | [next] | [standalone]
| From | Tim Streater <timstreater@greenbee.net> |
|---|---|
| Date | 2012-10-19 23:12 +0100 |
| Message-ID | <timstreater-371628.23123019102012@news.individual.net> |
| In reply to | #16739 |
In article <xsadnQmiZIUSORzNnZ2dnUVZ_i2dnZ2d@earthlink.com>, Patricia Shanahan <pats@acm.org> wrote: > On 10/18/2012 3:49 PM, Evertjan. wrote: > ... > > You young boys and girls perhaps do not remember programming in Assembler > > or Forth, [or Algol], [and think pascal is a small form of hectopascal] so > > have a limited definition of "new" in this field. > ... > > I don't know if you are including me in "girls", but I still remember > life as an assembly language programmer in 1970. Me too at about the same time. > I've also done > significant programming in Forth and Pascal, but I've only done some > student exercises in Algol. BCPL? I wrote a Z80 cross-assembler in BCPL circa 1980. > However, I tend to be more interested in what is going on now and what > will happen in the future. I see strong typing as having its major > benefits in ensuring some invariants are true for all executions, not > just the ones that have happened during testing. I can't be doing with types, its too much faff. -- Tim "That excessive bail ought not to be required, nor excessive fines imposed, nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
[toc] | [prev] | [next] | [standalone]
| From | "Mel Smith" <med_cutout_syntel@aol.com> |
|---|---|
| Date | 2012-10-19 21:56 -0600 |
| Message-ID | <aeelmoFberqU1@mid.individual.net> |
| In reply to | #16741 |
Hi:
How about APL/360 in 1969 --- University of Alberta, and the l;ittle
type-ball I had to sign out and use and return, and the one-liner APL
'programs' we were all trying to out-do each other with. Aah, those times
of 40-odd years ago.
I remember coining the word 'gets' as the assignment operator of a line
in APL. -------- 'a <- a bunch of stuff here' where I used the word
'gets' as the assignment operator where everyone else was saying " a is
assigned the value of ... ". How stupid I was :((
...and of course Fortran IV at the same time, and Algol being developed at
the U of A. too during that time too ---
and I'm still coding every day (In Harbour and Javascript and HTML) ,
and I'm still bad at it too :((
-Mel
"Tim Streater" <timstreater@greenbee.net> wrote in message
news:timstreater-371628.23123019102012@news.individual.net...
> In article <xsadnQmiZIUSORzNnZ2dnUVZ_i2dnZ2d@earthlink.com>,
> Patricia Shanahan <pats@acm.org> wrote:
>
>> On 10/18/2012 3:49 PM, Evertjan. wrote:
>> ...
>> > You young boys and girls perhaps do not remember programming in
>> > Assembler
>> > or Forth, [or Algol], [and think pascal is a small form of hectopascal]
>> > so
>> > have a limited definition of "new" in this field.
>> ...
>>
>> I don't know if you are including me in "girls", but I still remember
>> life as an assembly language programmer in 1970.
>
> Me too at about the same time.
>
>> I've also done
>> significant programming in Forth and Pascal, but I've only done some
>> student exercises in Algol.
>
> BCPL? I wrote a Z80 cross-assembler in BCPL circa 1980.
>
>> However, I tend to be more interested in what is going on now and what
>> will happen in the future. I see strong typing as having its major
>> benefits in ensuring some invariants are true for all executions, not
>> just the ones that have happened during testing.
>
> I can't be doing with types, its too much faff.
>
> --
> Tim
>
> "That excessive bail ought not to be required, nor excessive fines
> imposed,
> nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
[toc] | [prev] | [next] | [standalone]
| From | Bart Van der Donck <bart@nijlen.com> |
|---|---|
| Date | 2012-10-20 02:21 -0700 |
| Message-ID | <a1fb26f2-1681-4e6a-8977-13715253df78@googlegroups.com> |
| In reply to | #16739 |
Patricia Shanahan wrote: > I don't know if you are including me in "girls", but I still > remember life as an assembly language programmer in 1970. I've > also done significant programming in Forth and Pascal, but > I've only done some student exercises in Algol. > > However, I tend to be more interested in what is going on now > and what will happen in the future [...] My point of view is that you give a bit too much importance to javascript. I'm coding javascript for about 15 years, and I can count on one hand my projects where javascript played the first violin. Javascript is at its best in small code snippets where not much can go wrong, in addition to the main server-side logic; in the first place to improve usability, speed and comfort for the user. In that regard, I believe javascript is certainly a must-have tool for any web developer. Personally I use javascript mostly in form checking, small to midsize calculations and user interface design (mouseovers, dropdown options, to name a few). But not much core engine tasks. I have some kind of personal rule to start a new project with the idea "OK, now this time we will use a minimum of javascript". But usually I end up with a good deal of javascript anyhow. It easily gets more and more complex. The more complexity you add to a program, the more vulnerable it becomes to weaknesses. In my experience, in javascript this counts double. Complex js projects are absolutely to avoid; the browser quirks are (still) many and your program may fail where you expect it the least. Especially as a beginner, you might see your code run fine in a web-based environment, while your neighbour is cursing who the hell wrote such a thing. It's not the coder who is a blockhead; it's about the language design itself, for a big part due to the sprawl of browser and their versions. Take some of the world's most highly qualified javascript libs/apps (JQuery, Google, ...). The risk of failure is still quite high. Extreme care is needed when using recent js syntax in production code; in my view it's often better to avoid them in stead of using trickery like browser detection, feature detection and the like (not to say that feature detection is bad; all depends on the reasonably expected compatibility of the situation). Javascript is nice. Modern. Trendy. Can do things with it that look very webby and fancy, and can assist the server side logic here and there. And that's for me a reason to keep using it. But not as reliable as C, SQL, and the like. Javascript is not unixy in the sense of building complex stuff with simple bricks. Handle sparingly and with care. Hope this helps more than confuses. -- Bart
[toc] | [prev] | [next] | [standalone]
| From | "Evertjan." <exxjxw.hannivoort@inter.nl.net> |
|---|---|
| Date | 2012-10-20 12:03 +0200 |
| Message-ID | <XnsA0F27AA36F8Beejj99@194.109.133.133> |
| In reply to | #16745 |
Bart Van der Donck wrote on 20 okt 2012 in comp.lang.javascript: > Javascript is nice. Modern. Trendy. Can do things with it that look > very webby and fancy, and can assist the server side logic here and > there. Uh, Bart? I use javascript serverside, and do not call that assisting, but a quite nice way programming. Using user-input validation modules clientside and serverside having the same code minimizes result-conflicts between the two processes. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2012-10-20 06:31 -0700 |
| Message-ID | <XKydnWaw070XOh_NnZ2dnUVZ_hednZ2d@earthlink.com> |
| In reply to | #16745 |
On 10/20/2012 2:21 AM, Bart Van der Donck wrote: > Patricia Shanahan wrote: > >> I don't know if you are including me in "girls", but I still >> remember life as an assembly language programmer in 1970. I've >> also done significant programming in Forth and Pascal, but I've >> only done some student exercises in Algol. >> >> However, I tend to be more interested in what is going on now and >> what will happen in the future [...] > > My point of view is that you give a bit too much importance to > javascript. I'm coding javascript for about 15 years, and I can > count on one hand my projects where javascript played the first > violin. > > Javascript is at its best in small code snippets where not much can > go wrong, in addition to the main server-side logic; in the first > place to improve usability, speed and comfort for the user. In that > regard, I believe javascript is certainly a must-have tool for any > web developer. > > Personally I use javascript mostly in form checking, small to > midsize calculations and user interface design (mouseovers, dropdown > options, to name a few). But not much core engine tasks. My problem is that I'm writing an application that needs to run conveniently on any tablet, including iPad. I would prefer not to write several different implementations. The application must run offline, so it cannot depend on server code. I would also prefer not to go through Apple's review process - I don't think they would reject this application, but it would be a schedule risk outside my control. As far as I can tell, the combination of HTML and JavaScript meets my portability requirements, and I have not found anything else that does. I can require installation of a reasonably current browser, reducing the amount of special case code. Although I've been forced by program requirements into implementing in JavaScript, I need to learn JavaScript well enough to write non-trivial code in it and make it not just work, but be readable and maintainable. Some of the worst, least readable programs I've seen have been written by people who wanted to be programming in a different language, and never fully entered into the spirit of the language they were actually using. I don't intend to repeat that mistake. I really have to learn to write JavaScript as JavaScript, not as though it were a strange dialect of some other language. Patricia
[toc] | [prev] | [next] | [standalone]
| From | "Evertjan." <exxjxw.hannivoort@inter.nl.net> |
|---|---|
| Date | 2012-10-20 18:30 +0200 |
| Message-ID | <XnsA0F2BC507CADEeejj99@194.109.133.133> |
| In reply to | #16750 |
Patricia Shanahan wrote on 20 okt 2012 in comp.lang.javascript: > On 10/20/2012 2:21 AM, Bart Van der Donck wrote: >> Patricia Shanahan wrote: [...] > My problem is that I'm writing an application that needs to run > conveniently on any tablet, including iPad. I would prefer not to write > several different implementations. The application must run offline, so > it cannot depend on server code. I would also prefer not to go through > Apple's review process - I don't think they would reject this > application, but it would be a schedule risk outside my control. > > As far as I can tell, the combination of HTML and JavaScript meets my > portability requirements, and I have not found anything else that does. > I can require installation of a reasonably current browser, reducing the > amount of special case code. > > Although I've been forced by program requirements into implementing in > JavaScript, I need to learn JavaScript well enough to write non-trivial > code in it and make it not just work, but be readable and maintainable. > Some of the worst, least readable programs I've seen have been written > by people who wanted to be programming in a different language, and > never fully entered into the spirit of the language they were actually > using. I don't intend to repeat that mistake. I really have to learn to > write JavaScript as JavaScript, not as though it were a strange dialect > of some other language. 'JavaScript as JavaScript' and 'spirit of the language' surely meaning accommodating Javascript's weak-typed variable value system? -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2012-10-20 10:32 -0700 |
| Message-ID | <TsCdnY1vb8aDfR_NnZ2dnUVZ_oSdnZ2d@earthlink.com> |
| In reply to | #16751 |
On 10/20/2012 9:30 AM, Evertjan. wrote: > Patricia Shanahan wrote on 20 okt 2012 in comp.lang.javascript: ... >> Although I've been forced by program requirements into implementing in >> JavaScript, I need to learn JavaScript well enough to write non-trivial >> code in it and make it not just work, but be readable and maintainable. >> Some of the worst, least readable programs I've seen have been written >> by people who wanted to be programming in a different language, and >> never fully entered into the spirit of the language they were actually >> using. I don't intend to repeat that mistake. I really have to learn to >> write JavaScript as JavaScript, not as though it were a strange dialect >> of some other language. > > 'JavaScript as JavaScript' and 'spirit of the language' surely meaning > accommodating Javascript's weak-typed variable value system? > That was the question that started this thread. The answer seems to be "yes". I've got to look for code examples, do some more reading etc. to learn how to take advantage of weak typing. Patricia
[toc] | [prev] | [next] | [standalone]
| From | Tim Streater <timstreater@greenbee.net> |
|---|---|
| Date | 2012-10-20 22:34 +0100 |
| Message-ID | <timstreater-13F0F1.22343820102012@news.individual.net> |
| In reply to | #16754 |
In article <TsCdnY1vb8aDfR_NnZ2dnUVZ_oSdnZ2d@earthlink.com>, Patricia Shanahan <pats@acm.org> wrote: > On 10/20/2012 9:30 AM, Evertjan. wrote: > > Patricia Shanahan wrote on 20 okt 2012 in comp.lang.javascript: > ... > >> Although I've been forced by program requirements into implementing in > >> JavaScript, I need to learn JavaScript well enough to write non-trivial > >> code in it and make it not just work, but be readable and maintainable. > >> Some of the worst, least readable programs I've seen have been written > >> by people who wanted to be programming in a different language, and > >> never fully entered into the spirit of the language they were actually > >> using. I don't intend to repeat that mistake. I really have to learn to > >> write JavaScript as JavaScript, not as though it were a strange dialect > >> of some other language. > > > > 'JavaScript as JavaScript' and 'spirit of the language' surely meaning > > accommodating Javascript's weak-typed variable value system? > > That was the question that started this thread. The answer seems to be > "yes". I've got to look for code examples, do some more reading etc. to > learn how to take advantage of weak typing. I'm not sure you have to specifically take advantage of it. It's simply one less thing to worry about. I might do something like: if (n==0) n = "No"; console.info (n + " results); but that's a trivial example. -- Tim "That excessive bail ought not to be required, nor excessive fines imposed, nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
[toc] | [prev] | [next] | [standalone]
| From | "Evertjan." <exxjxw.hannivoort@inter.nl.net> |
|---|---|
| Date | 2012-10-21 10:12 +0200 |
| Message-ID | <XnsA0F367CD6AE3eejj99@194.109.133.133> |
| In reply to | #16760 |
Tim Streater wrote on 20 okt 2012 in comp.lang.javascript: > I might do something like: > > if (n==0) n = "No"; > console.info (n + " results); Error ;-) console.info (n + ' results'); > > but that's a trivial example. or depending on more general contextual requirements: if (!n) n = 'No'; or n = (!n) ? 'No' : n; or n = (n) ? n : 'No'; -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
[toc] | [prev] | [next] | [standalone]
| From | Tim Streater <timstreater@greenbee.net> |
|---|---|
| Date | 2012-10-21 09:34 +0100 |
| Message-ID | <timstreater-4A0E5F.09340721102012@news.individual.net> |
| In reply to | #16763 |
In article <XnsA0F367CD6AE3eejj99@194.109.133.133>, "Evertjan." <exxjxw.hannivoort@inter.nl.net> wrote: > Tim Streater wrote on 20 okt 2012 in comp.lang.javascript: > > > I might do something like: > > > > if (n==0) n = "No"; > > console.info (n + " results); > > Error ;-) Oh tilt! -- Tim "That excessive bail ought not to be required, nor excessive fines imposed, nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
[toc] | [prev] | [next] | [standalone]
| From | Dr J R Stockton <reply1242@merlyn.demon.co.uk.invalid> |
|---|---|
| Date | 2012-10-21 17:59 +0100 |
| Message-ID | <cP4vbFDDoChQFwQo@invalid.uk.co.demon.merlyn.invalid> |
| In reply to | #16760 |
In comp.lang.javascript message <timstreater-13F0F1.22343820102012@news. individual.net>, Sat, 20 Oct 2012 22:34:38, Tim Streater <timstreater@greenbee.net> posted: > >I might do something like: > > if (n==0) n = "No"; > console.info (n + " results); > >but that's a trivial example. console.info( (n||"No") + " results" ) ; // ?? -- (c) John Stockton, nr London UK Reply address via Home Page. news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>. <http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources. <http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.lang.javascript
csiph-web