Why can't they pick a better language?

Post #54,418 by ben_tilly 10/2/02 6:25:28 AM Reply	Why can't they pick a better language? Javascript is Perl designed by someone who doesn't like sigils, and doesn't understand the typing implications of overloading the operators. I don't care either way about the sigils. But it ticks me off that you both don't know the type of the data you get and have to care. Its biggest strength today is that there are a lot of non-programmers who think they know Javascript because they have tinkered with it on a few web pages. Oh, and the fact that it is your only option for a lot of client side scripting so a lot of people who wouldn't otherwise choose to use it (like me) have had to. That still doesn't make it a very good language. Cheers, Ben "Career politicians are inherently untrustworthy; if it spends its life buzzing around the outhouse, it\ufffds probably a fly." - [link\|http://www.nationalinterest.org/issues/58/Mead.html\|Walter Mead]
Post #54,425 by static 10/2/02 8:08:22 AM Reply	I agree. JavaScript is really a very ordinary language. Capable and complete in a lot of areas, but quite ordinary. I can't get quite the same thrill of making something work in JavaScript as in PHP (or Icon). I was going to add "at least it's not BASIC" but it sort of really is with a few C-ish and Java-ish things on top. :-/ Wade. "Ah. One of the difficult questions."
Post #54,436 by deSitter 10/2/02 9:48:51 AM Reply	Re: I agree. Supposedly, Adobe has tightened the language as compared to common browser Javascript. Did you notice in particular how this was done? I'm never learned enough to know what's better or worse. -drl
Post #54,479 by ChrisR 10/2/02 12:21:23 PM Reply	Same language... ...different core objects. That is, html is built on top of the Document Object Model (DOM), whereas Adobe uses their own pdf document model. Means that the syntax and basic operators are the same, but the core objects which can be manipulated are different.
Post #54,492 by deSitter 10/2/02 12:44:40 PM Reply	Re: Same language... That's sort of what I've gathered, in not so precise language. That clarifies it for me. -drl
Post #54,588 by static 10/2/02 10:16:32 PM Reply	I didn't look. The language in and of itself has been pretty good for a while. But if they meant "replacing the browser DOM with our .pdf DOM" then that's not "improving and tightening the language" in my book and they shouldn't tried to sell it as such. Wade. "Ah. One of the difficult questions."
Post #54,518 by ChrisR 10/2/02 3:03:22 PM Reply	You Perl people must like... ...to invent new vernacular. Had to look up Sigils to figure out they were those attribute characters that adorn variable names. Personally, I find them slightly distracting and of limited context - not nearly as bad as hungarian notation but of the same ilk. As for types in Javascript, I'd probably agree with the point but am not sure where the typeof() method fits into the problem/solution space.
Post #54,529 by boxley 10/2/02 4:19:33 PM Reply	not new vernacular but sigil doesnt mean sigil anymore? now if have seen c++ debug traces toss out sigil when gagging over a problem. thanks, bill will work for cash and other incentives [link\|http://home.tampabay.rr.com/boxley/resume/Resume.html\|skill set] qui mori didicit servire dedidicit
Post #54,558 by ben_tilly 10/2/02 7:03:51 PM Reply	I didn't invent it And once you have used it that way, it makes sense to say sigil rather than "funny character at the start of a variable." AS for the value of them, they don't add that much, and they don't take away enough for me to care too strongly about them. Ruby uses them as well, to indicate scoping. Not sure I care about that either way either. As for typing, I am a bit of a heretic in the Perl community in thinking that Perl does it wrong by autoconverting variables all of the time. But if you are going to try to autoconvert things, then Perl is right to provide operators that impose types on their arguments. My problem with Javasccript is that it has inconsistent rules for automagically switching types on you. In other words it tries to do what Perl does, but does not type its operators. Cheers, Ben "Career politicians are inherently untrustworthy; if it spends its life buzzing around the outhouse, it\ufffds probably a fly." - [link\|http://www.nationalinterest.org/issues/58/Mead.html\|Walter Mead]
Post #54,566 by deSitter 10/2/02 7:37:42 PM Reply	Re: I didn't invent it It's an operator, why not call it that? ARG! Mathematicians... -drl
Post #54,572 by ben_tilly 10/2/02 7:55:24 PM Reply	It isn't, necessarily In Perl it is possible to view it as an operator (though that isn't the grammatical part of speech that it plays), but Ruby has them to, and in Ruby it doesn't act like an operator. Cheers, Ben "Career politicians are inherently untrustworthy; if it spends its life buzzing around the outhouse, it\ufffds probably a fly." - [link\|http://www.nationalinterest.org/issues/58/Mead.html\|Walter Mead]
Post #54,573 by deSitter 10/2/02 7:58:33 PM Reply	Re: It isn't, necessarily What's wrong with all of us? We're all using scripting languages. -drl
Post #54,574 by ben_tilly 10/2/02 8:03:32 PM Reply	Why is that wrong? Computers have reached a point where for most of what needs to be done, programmer time is orders of magnitude more valuable than computer cycles. Scripting languages do a better job at that balance than system languages do. There is also a productivity sweet spot with teams of 2-6 people. So if you can get a development effort down to needing that many people, it is an absurdly big win. Cheers, Ben "Career politicians are inherently untrustworthy; if it spends its life buzzing around the outhouse, it\ufffds probably a fly." - [link\|http://www.nationalinterest.org/issues/58/Mead.html\|Walter Mead]
Post #54,629 by tuberculosis 10/3/02 8:37:49 AM Reply	Not me I spent the weekend marrying [link\|http://www.fscript.org\|FScript] and [link\|http://www.toodarkpark.org/computers/objc/\|Objective C] with [link\|http://www.ghg.net/clips/CLIPS.html\|CLIPS]. I need to do a cocoa UI and a palette for Interface Builder. Then you'll have expert systems capabilities at your fingertips as needed. Just define the rules for your objects and the system enforces them. Also need to define several deftemplates for common system classes. Java, C##, Javascript, these languages are all from the dark ages. Who needs em? I am out of the country for the duration of the Bush administration. Please leave a message and I'll get back to you when democracy returns.
Post #55,026 by tonytib 10/5/02 1:55:11 AM Reply	You've got life easy just try dealing with some of the stuff I sometimes have to deal with in industrial automation -- they make C look good. For example, recently, I have had to write a Logo! program in its version of ladder logic, Aromat IEC61131 program (I used Structured Text, which looks a bit like Pascal, but has some very interesting quirks), and an Animatics SmartMotor program (roughly similar to GW BASIC). At least all three of them were short. Python is so much more fun -- and productive. Thankfully, I've been doing some of that, too lately, along a bit of wiring and electrical troubleshooting. I haven't blown anything up yet -- but some of my coworkers tried. Tony
Post #54,589 by static 10/2/02 10:19:07 PM Reply	Not idiomatically. They might be lexical* operators, but they're not necessarily functional operators. The latter is what people usually mean by the term "operator" in the context of a programming language. Like "+" or "and". The semi-colon in PHP is a lexical operator, too. Wade. * That might be the wrong term: I could mean syntactic. Or semantic. "Ah. One of the difficult questions."
Post #54,590 by ben_tilly 10/2/02 10:26:22 PM Reply	In Perl they are dereferencing operators "Career politicians are inherently untrustworthy; if it spends its life buzzing around the outhouse, it\ufffds probably a fly." - [link\|http://www.nationalinterest.org/issues/58/Mead.html\|Walter Mead]
Post #54,613 by tablizer 10/3/02 1:43:33 AM Reply	semicolon rant IV The semi-colon in PHP is a lexical operator, too. @#^%@$ Semicolons! I have been hating them for multiple decades, ever since Pascal in college. They are sooooo archaic. I kind of dig the Python approach: if you want to a line to wrap, then use parenthesis (if not clear) to leave it open at the end of the line. This avoids a "continuation character" like VB's, and most wrappings are due to long function/method parameter lists anyhow. I suppose that is kind of LISPish in principle. If LISP was economically viable, I just might dig into it more. It seems to have a lot of cool features. Paul Graham is my current hero. ________________ oop.ismad.com
Post #54,631 by tuberculosis 10/3/02 8:41:17 AM Reply	Or you can use periods. Its what Smalltalk uses. Most human languages too. dictionary at: 'Greeting' put: 'Hello'. Seems OK to me. I am out of the country for the duration of the Bush administration. Please leave a message and I'll get back to you when democracy returns.
Post #54,999 by tablizer 10/5/02 12:40:32 AM Reply	re: periods Its what Smalltalk uses. Most human languages too. Nope. Don't like that either. COBOL had the problem where the presence or absense of a period can change the entire meaning. At least most C-cloned langs give a syntax error instead of a different interpretation if semi ommitted. COBOL is what happens when you try to hard to "be like English". But, I prefer to let the end-of-line be the indicator. It is more WYSIWYG imo. It is a personal preference, but that is the way I like it. ________________ oop.ismad.com
Post #55,189 by deSitter 10/6/02 6:29:49 PM Reply	re: periods But this is wrong, at least in the UNIX world where everything is stream (and "UNIX world" means - the Internet). The EOLs are delimiters in one context and not the other. Nothing could be simpler. -drl
Post #55,655 by tablizer 10/8/02 11:40:57 PM Reply	Huh? ________________ oop.ismad.com
Post #55,757 by deSitter 10/9/02 11:59:35 AM Reply	Re: Huh? When C was invented, the most popular languages, COBOL and FORTRAN, were line-oriented. Typically a program would go into the system via a punched card reader. In FORTRAN, you had columns 7 to 72 to scribble in on a keypunch machine. Everyone saw that having to worry about carriage control at the language level was brain-dead. So a delimiter was needed to tell the compiler that a line was concluded. What would you have picked? -drl
Post #57,386 by tablizer 10/17/02 3:53:17 PM Reply	Who is "everyone"? Everyone saw that having to worry about carriage control at the language level was brain-dead. I don't see the problem. I am not the only one who dislikes semicolons. Bertrand Meyer made them optional because of complaints of Eiffel semicolons, for example. Besides, there were other languages around to serve as possible solution ideas. LISP does not need semi's, for example. Just accept the fact that some people don't like semi's. ________________ oop.ismad.com
Post #57,406 by deSitter 10/17/02 5:09:06 PM Reply	Once More With Feeling Everything in UNIX is byte-stream oriented. The compiler chews on a byte stream. Because it was developed as a time-share system with terminals (a radical idea at that time), it uses newlines to format byte-streams for the screen. That's a particular delimiter. The C compiler uses another delimiter in its input stream of code - and GASP! someone had the thought that it would be a GOOD THING if humans could SEE them! The semi-colon is very expressive - stop, but keep going. It's a total, complete, non-issue. -drl
Post #57,751 by tablizer 10/18/02 11:20:43 PM Reply	I don't care about the 1970's, I hate them here and now That is a bunch of bolarky! There are plenty of non-semicolon languages that run just fine on UNIX. If semi's made stuff easier in the 70's, well, this is NOT the 70's. Get modern. I don't like semi's and work faster without the damned things. That is a FACT. If you like them, that is fine, but don't force them down everybody else's throat. ________________ oop.ismad.com
Post #57,775 by static 10/19/02 12:43:55 AM Reply	Simple solution. And that is don't use languages with semi-colons as statement terminators, if it bothers you so much. There's no need (or call) for you to insist that everyone subscribe to your view. I happen to intensely dislike identifiers with a leading underscore, but I can't make everyone stop using them. (Fortunately, it's less of an issue for me in PHP because of the leading $ on all variables.) Wade. "Ah. One of the difficult questions."
Post #57,782 by deSitter 10/19/02 1:54:47 AM Reply	The Galileo of Computing! Sorry. It's really funny to watch you have a stroke over a stupid delimiter. Maybe we should replace it by a new character just for you - the "catastrophe". -drl
Post #58,195 by tablizer 10/22/02 2:32:44 AM Reply	Others complain too It's really funny to watch you have a stroke over a stupid delimiter. That happens to be the topic at hand. If you have Bertrand Meyer's OOSC2 you will see that others have found it problematic also. Page 897 partial quote: "The War of the Semicolon [title]....Two clans inhabit the computer world, and the hatred between them is as ferocious as it is ancient...." It is just one of those annoying things that keep slowing things down. I used Pascal extensively in College, and never did get used to semi's. Perhaps if all the langs I ever used only had semi's, then it would be a natural habit by now. However, I encounter a mix. If one keeps losing their car keys once every 2 weeks, then a combination-based lock starts to look pretty good (like the Nissan Maxima). BTW, some non-semi languages do NOT need VB-style dashes or continuation characters. Python and LISP come to mind. ________________ oop.ismad.com
Post #57,407 by admin 10/17/02 5:12:06 PM Reply	Wrong. Everyone saw that having to worry about carriage control at the language level was brain-dead. No, it isn't. cf. Python Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #57,414 by deSitter 10/17/02 5:34:53 PM Reply	Re: Wrong. We're talking 1970s, FORTRAN, COBOL, etc. Carriage control was heavily device-oriented and record-oriented, because IBM made record-oriented systems. Byte-stream oriented UNIX was really radical. Some of us were around in antediluvian times :) Things change. Here's a history of carraige control: [link\|http://www.ibiblio.org/pub/languages/fortran/ch2-14.html\|http://www.ibiblio.o...rtran/ch2-14.html] -drl
Post #57,487 by ben_tilly 10/18/02 7:25:31 AM Reply	This is a general trend Later-invented systems often find simple solutions to problems that are so bad that earlier systems never considered doing it that way. Byte-oriented UNIX with lines parsed out versus records is one example. Automatic memory management in new languages is a more familiar one today. Cheers, Ben "Career politicians are inherently untrustworthy; if it spends its life buzzing around the outhouse, it\ufffds probably a fly." - [link\|http://www.nationalinterest.org/issues/58/Mead.html\|Walter Mead]
Post #57,418 by hnick 10/17/02 5:41:27 PM Reply	Historical trivia that applies... I seem to recall that the early C compilers actually had a 80 character limit that paralleled a Hollorith card. If you ran over the 80 char line limit, the line was truncated. New compilers have no line limit and span lines without a '\\' for a line break. A delimiter is needed. No question. This works. I would rather a simple syntax, than the tyranny of making everything I code intuitively readable to all potential readers_{mean?average?every bum off the street? WHO?}.
Post #57,465 by a6l6e6x 10/17/02 9:59:49 PM Reply	Nah, not Kernighan and Ritchie. K&R: Blanks, tabs, newlines, and comments (collectively called "white space") as described below are ignored except as they serve to separate tokens. Some white space is required to separate otherwise adjacent identifiers, keywords, and constants. So any C compiler that does otherwise would not be K&R. Alex "I have a truly marvelous demonstration of this proposition which this margin is too narrow to contain. -- Pierre de Fermat (1601-1665)
Post #57,488 by hnick 10/18/02 8:13:04 AM Reply	Right, Not K&R I didn't start using C until 1984 or so, and every compiler I saw was mostly K&R compliant. ISO came later. I was told that a lot of the code I was looking at was written like it was because of the 80 line limitation on the system it came from. I never saw the original system, and the story came to me as probably third hand word-of-mouth. I suppose you can say that if it's not K&R, it's not a C compiler. I suppose that the story could also be bullshit, although I did not pass it on with such knowledge. A lot of the information I possess, I have through informal sources, including this forum. I recalled the story and thought that it pertained to the thread. Sorry about that.. Hugh
Post #57,489 by CRConrad 10/18/02 8:30:21 AM Reply	Don't be. Sorry, I mean.
Post #57,548 by deSitter 10/18/02 12:37:33 PM Reply	Re: Right, Not K&R No, it's very interesting! Even as late as the late 70s, college computing was done on a Forbin Project style 'frame - ours was a Cyber, one of the fastest computers then made. The hapless student/researcher would code up his program on Hollerith cards and present the deck at the I/O window - later a public card reader was available and you could submit your own deck, eat some horrid dry cookies or chips with your 10th Dr. Pepper of the day, and wait for the I/O window troll to deliver your output. General availability of time-share terminals only came in early 80s IIRC. PROFS for VM/CMS (Professional Office System or some such), the GroupWise of its day, had "virtual card readers" and "virtual punch files". GASP! -drl
Post #58,034 by wharris2 10/21/02 12:00:00 PM Reply	Actually, might it have been a "standard" to fit terminals? When I first went to work (in the mid-80's) programming C, it was a "standard" that the code would match a certain format - and, except for long strings (back in those days C compilers didn't append adjacent strings together), it was recommended that we use 80-character lines (at worst) and preferably something like 72 columns, for readability on the Wyse75 terminals we had at the time and, I suppose, the ability to more easily print stuff out on the 80-column line printers we had at the time. If I remember correctly, you could put those Wyse's into 132-column mode, but you'd probably go blind if you did so. And if you went over 80 columns on any particular terminal, you'd have to monkey with termcap/terminal settings, and it seems to me it always seemed to take a lot more effort than it was ever worth. The lawyers would mostly rather be what they are than get out of the way even if the cost was Hammerfall. - Jerry Pournelle

Welcome to IWETHEY!