Well, I stayed a big Common Lisp* fan - one idea I've been toying with (i.e. I'll probably never actually do it and even if I started I'd probably never finish) is an APL-syntax parser for Common Lisp arrays, so one could write (apl-eval "...") and have it transform the APL in "..." into CL functions operating on arrays. And with CL, one could easily implement even the fancy stuff like function composition.
Would be quite cool, because one could then mix Maxima symbolic math stuff, APL numeric math stuff and Lisp... stuff... in the one program.
There's a paper which shows that a good CL compiler can be competitive with a fortran compiler for numerical processing.
* Beware that Scheme is rather different in many ways to Common Lisp - if you've investigated Scheme but decided it wasn't for you, but haven't investigated Common Lisp, then I suggest having a look at it.
People are programming with images, all the time. "visual" editors for GUI forms even make a big deal about it.
I just don't get your word-length argument. "hello" is a compound symbol, manipulated as a unit. More often used symbols tend to become shorter. That's why people say "hi" now. So if programming languages are just like spoken languages, we should see shorter and shorter symbols being used for common problems in that language. Oh wait, we DO see that. And in APL-like languages, mathematical operations on large multidimensional arrays are most common.
***Yes, but the easiest to learn a language is, the easiest it is to find people to hire. No one is willing to learn K, but most are willing to learn Java and Visual Basic. And this clearly affects the budget of a project. ***
When hiring, it is best to hire people who are willing to learn. And if you're hiring criterion is "the cheapest person who is cheapest because he's too lazy to learn anything new" then welcome to project-failure land. I've seen it happen before, no doubt it will happen again and again as inexperienced managers make that mistake.
"No one is willing to learn K" - obviously they are. We've got examples right here on this message board. And if one K coder can do the work of 20 VB monkeys (or more likely, do something that's impossible to do efficently in VB without dropping into COM objects written in C++) then using K could affect the budget positively.
If the lines of code remain constant - why on earth would you use english??? - kfg's post demonstrates that english is more verbose, not less, than mathematical notation, for example, so for certain domains, mathematical notations makes far more sense.
I agree that having the code be a mess of symbols doesn't help understanding the code - I get that feeling when present with a load of COBOL or VB code - lots of big huge english-like symbols meaning that I can only see a few of them at a time on screen, all relating to bits that are off-screen, and the symbols are often not properly encapsulated or abstracted, owing to, e.g. VB's singularly crappy function/subroutine stuff. Means I have to maintain more state in my brain, and while I am very intelligent (modest, too), I am also somewhat lazy, and don't like doing that, it slows me down. It's a "can't see the forest for the trees" effect.
***But humans have the ability to extract the meaning of a word based on context. "Open door" and "open file" is a good convention, made by humans for humans. But "@#$ 35, 22" is not. ***
Of course they do, but that can lead to MAJOR misapprehensions. Unlearning is harder than learning, too, so those misapprehensions can be hard to shift, so in effect, it's a false "easy learning" effect - and context-sensitive stuff is more work (the ascii-line-noise example also illustrates this - because all those symbols are already overloaded with lots of meanings)
I've already said I prefer the APL-symbol APLs to the ASCII-art ones.
And who do you think K was made for? Martians? Not much of a market there.:-)
Maybe it was made for people who simply aren't exactly like you. People are different. Some people may even like the fact that APL-like languages make it easy to use vectorised operations. They may come from VB and realise how much error-prone make-work all those loops were, and PREFER K.
Would you suggest that musical notation, another language, would be better expressed as reams of english text??? It would make it easier for novices to play simple tunes on a piano. But would you hire that novice as a concert pianist?
Firstly, I would like to echo the sentiment in kfg's reply to your post.
Secondly, all html formatting seems to have stopped working- dunno why, so I apologise for the poor formatting of this post.
Thirdly:
*** Now, some programming languages are closer to english in appearance than others. However, for long-term use, that doesn't matter so much - it's just a barrier to entry for lazy people. ***
*** I don't think so. Using symbols for expressions is not the same as using English, especially if one is developing in more than one language. ***
O.K. I may have been oversimplifiing - but: ENGLISH IS SYMBOLS TOO. Using English is exactly the same as using symbols - since using english, or any language, *is* using symbols. That's how humans abstract. In written english you have letters, composed into compund symbols (aside: these compund symbols, "words", are often treated as primitve symbols by fast readers, whose symbol-recognition wetware seems to recognise them in one swoop.)
Now, one could argue "then why not use familiar symbols" - but I find using familiar symbols just because they're familiar to be a bit silly and often dangerously misleading. Think of the emotive symbols "theft" or "piracy" applied to "violation of copyright law", in reality a quite different concept. Or "=" used for both assignment and equality testing (arrgh!!!!), neither of which correspond to mathematics-=, which is a statement of equality.
***You should also consider other facts: ***
***the introduction of new members in the development team, especially if the new members don't know the language ***
It is often better to just budget for bringing the new member up to speed in the language. Or just decide to only hire "speakers" of the language in question. You'll have to bring the new member up to speed on all the little pecularities of your codebase anyway, a much harder task for the new member than merely learning another new computer language.
***maintenance and service after installation; it may not be the original developer (who was so efficient in K) that maintains the project ***
No, but one would hire or train someone capable of maintaining it. Here's usually where the strong arguments for using COBOL or Java come in - "what if one can't hire a K developer in 3 years?", and so on. But learning a new language should be VERY EASY for anyone who calls himself a "programmer" - the hard part will be understanding the code, not the language.
***readability; after long coding hours, ',' is easily mistaken for '.', for example; and with so many symbols packed together in such tiny space, the problem only gets worse. ***
Yes, that is true - but, interestingly, the number of lines of code written by a programmer in a day stays roughly constant - regardless of language used - so the more verbose the language, the less your programmer is doing. And non-ASCII APLs, for example, have much easier to distinguish symbols than #\, and #\.:-)
***learning curve; much higher than a language based on English. ***
Somewhat higher.
Note that I consider "A language based on english" very different to a language in which symbols^Wkeywords happen to correspond somewhat to english words. There are very few programming languages based on english, in which the grammatical structure of the language corresponds closely to english. Many programming languages, however, have keywords based (loosely - printf ??? like "print" followed by a stifled sneeze...) on english words - but the symbols are strung together in ways that are very different to english, and have their own meanings in that language that are typically very different to their english meanings. You can english-open an english-door, but you can mainly only unix-open a unix-file. I won't mention "ontological commitments" right now.
Once you know what "printf" does, you manipulate it as a whole in a c program, you don't spell it out each time you write it "p-r-i-n-t-f" spells "print". A Chinese person can write in C quite easily without knowing much English - once he knows what the symbol "printf" does in the context of C, he doesn't *need* to know that there is an english word "print" or that "f" is the first letter of the english word "file".
So english-like symbols can indeed help in the discovery phase, when you are trying to guess what a symbol does - but so could spanish-like. Or chinese-like. RTFTM (Read-the-fucking-translated-manual) can help here - as a programmer you are manipulating symbols when you are writing a programs, and one of the things programmers spend most of their timing doing is looking up definitions of the meanings of symbols in a particular context - if the definition is in french, and you're french, you can use the symbol, even if the symbol doesn't look french.
***relevance to documentation/pseudocode; for example, it is much easier to make someone understand that the developed code follows the pseudocode defined in a project's specifications when the code is as close as possible to the English language than when the code is a bunch of symbols thrown together. ***
Not if the documentation or pseudocode is in any language other than english. Note that I am European, so I am probably more used to a multilingual environment than you if you are American.
***Although Python/Lisp/C++/whatever are readable, this is because they are based on English. The more a language is based on English, the better it is for big project development. ***
I would disagree e.g. Lisp is SO not based on english. The symbols defined by the language spec are. The "sentence structure" is almost completely alien.
Yes - but readability depends on the reader. And I'd prefer "use meaningful variable names". So english variable names make sense on a big project, since chances are your reader speaks english. But would you suggest using "BEGIN" and "END" instead of "{" and "}" on the same project ???
*** If things were as you claim, we all be programming in assembly or with 0 or 1s; after all, how hard to make a mistake with 2 symbols only:-) ? ***
Not at all - you misrepresent me. That would be antithetical to forming abstractions via new symbols. (aside: don't forget, most stuff is in fact written in "portable assembler" like languages like C - most good assemblers allow macros and therefore the beginnings of higher-level languages -.e.g Amiga m68k macro assembler.i header includer files had a near 1:1 mapping to the Amiga C.h header include files, including macros for structs and so on.)
***Don't forget that Hypercard has been claimed as one of the best programming environments because of its ability to program almost in English. ***
(a) Hypercard was claimed as one of the best programming environments for "non-programmers". (b) Hypercard was one of those few languages where the grammatical structure of the language, not just the keywords, are english-like.
***The attitude "symbols are ok, as long as I understand them" shows that you are ignorant of the issues of real development (with managers, deadlines, multiple and heterogenous environments, different coders, testers, bug reports and bug databases, etc). ***
I assure you, that not my attitude. I am a professional developer and encounter all of the above issues on a daily basis). English-like symbols do indeed help when trying to understand a system. They can also mislead - a variable called "applecount" that holds a count of "all oranges, pears and apples since last tuesday" are very annoying, for example.
My attitude is "symbols are ok, so long as the intended readership (including the computer:-) ) understands them". I include English-like symbols in that.
***Finally, the obfuscated C code contents would not exist if code readability did not play an important role!!! ***
True. To make the point in my previous comment more concrete: But have you ever seen legalese or a patent document? They're supposed to be in english - all legalese looks obfuscated because they're trying to fit a precise layer on top of an imprecise natural language, and patents are deliberately obfuscated as a matter of course.
You should consider the readability of the language for someone WHO KNOWS THE LANGUAGE, dammit.
I don't go round claiming japanese or arabic is unreadable - I just don't know the language.
The analogy extends further - it is possible to construct almost unreadable drivel in natural languages, and it is possible to construct almost unreadable drivel even in python.
However normal code written in python, forth, common lisp, or even, god forbid, c++ or perl is readable to someone who knows the language.
Now, some programming languages are closer to english in appearance than others. However, for long-term use, that doesn't matter so much - it's just a barrier to entry for lazy people.
I don't happen to know K. I do know APL, though - APL didn't look like K, since it had its own non-ASCII symbol set. I do find it difficult to read the relatively new asciified line-noise APL-derived languages. But that's because I haven't bothered to learn 'em! I do suspect they would be harder to learn than APL, since the ASCII symbols are already overloaded with so many other meanings already - but once I'd learned them, I would expect that problem to fade - just like I'm not confused that "gift" in German means "poison" in english.
Actually, now that Unicode is widely supported, I would love to see a resurgence in APLs that use APL symbols, since they're much clearer to me - but so many people have been using the ASCIIfied APLs for so long now that that may never happen.
Repeated because I disagree with mod of AC comment:
And product activation sucks but so does having perhaps the most pirated piece of software in the world so you really can't blame them.
Microsoft WANTS it pirated. Because pirated Windows is what keeps Linux out of the desktop in a large part of the world.
If all eastern Asia had to pay the price Microsoft asks for its software, you'd be sure to see a lot of local OSes spawned from BSD or Linux, with great support for local languages.
But when you can have a pirated copy of a fully-featured Windows for 3$, why bother ?
Personally, I won't be bothering with eBooks until I have a 300DPI+ A4-sized display*, but anyway:
Of course "readable to the human eye" is not the same as "pleasantly readable to the human eye" - you could just buy a print book if the ebook becomes too annoyingly full of wobbly characters.
And also, researchers, spurred on by the challenge of descrambling those obfuscated text things, are already having some success. See "Breaking gimpy: Researchers crack Security System Designed to prevent internet Robots"
* LCD Manufacturers: I want a high DPI screen, not a physically huge one. Why the hell can't I get a 15" 1600x1200 DESKTOP LCD Monitor???
As far as I can tell, the schools that use computers to actually teach computing are few and far between. To my mind, programming should be regarded as a life skill like arithmetic, reading, writing. I really don't think programming in most languages is harder than arithmetic, let alone basic calculus (which is taught- and if taught early enough, many more people would grasp it.
Current "computer" classes are often "how to use MS Word and MS Excel, maybe even MS IE and MS Outlook Express".
If kids were introduced to proper computing (i.e. CompSci stuff and languages like Logo and Lisp) at an earlier age, they'd realise that computers can be extensions of your mind, and can do arbitrary virtual things (at least until Palladium/TCPA) - they're not just glorified TVs or typewriters, and the absurd effect we have now where companies like Microsoft take mathematical algorithms and sell them as products to the ignorant masses would perhaps be reduced.
Sure, "Computer Programmer" might become less of an elite job description, but at the same time, we'd see much better code.
While we're at it, we should bring back lessons in basic logical reasoning, skeptical thinking, though the marketing departments of corporations and religious organisations mightn't like that...
No one has EVER told me that burn in "stopped being a problem" (I'm in europe). I've seen monitors that were bought early this year with noticeable burn in after about a year's (ab)use by clueless office drones.
Must be some propoganda campaign by monitor manufacturers in america, or something.
The Transparent Society Will Technology Force Us To Choose Between Privacy And Freedom?
In New York and Baltimore, police cameras scan public areas twenty-four hours a day. Huge commercial databases track you finances and sell that information to anyone willing to pay. Host sites on the World Wide Web record every page you view, and "smart" toll roads know where you drive. Every day, new technology nibbles at our privacy.Does that make you nervous?
David Brin is worried, but not just about privacy. He fears that society will overreact to these technologies by restricting the flow of information, frantically enforcing a reign of secrecy. Such measures, he warns, won't really preserve our privacy. Governments, the wealthy, criminals, and the techno-elite will still find ways to watch us. But we'll have fewer ways to watch them. We'll lose the key to a free society: accountability.The Transparent Society is a call for "reciprocal transparency." If police cameras watch us, shouldn't we be able to watch police stations? If credit bureaus sell our data, shouldn't we know who buys it?
Rather than cling to an illusion of anonymity-a historical anomaly, given our origins in close-knit villages-we should focus on guarding the most important forms of privacy and preserving mutual accountability. The biggest threat to our freedom, Brin warns, is that surveillance technology will be used by too few people, now by too many.A society of glass houses may seem too fragile. Fearing technology-aided crime, governments seek to restrict online anonymity; fearing technology-aided tyranny, citizens call for encrypting all data.
Brins shows how, contrary to both approaches, windows offer us much better protection than walls; after all, the strongest deterrent against snooping has always been the fear of being spotted. Furthermore, Brin argues, Western culture now encourages eccentricity-we're programmed to rebel! That gives our society a natural protection against error and wrong-doing, like a body's immune system. But "social T-cells" need openness to spot trouble and get the word out.
The Transparent Society is full of such provocative and far-reaching analysis.The inescapable rush of technology is forcing us to make new choices about how we want to live. This daring book reminds us that an open society is more robust and flexible than one where secrecy reigns. In an era of gnat-sized cameras, universal databases, and clothes-penetrating radar, it will be more vital than ever for us to be able to watch the watchers. With reciprocal transparency we can detect dangers early and expose wrong-doers. We can gauge the credibility of pundits and politicians. We can share technological advances and news. But all of these benefits depend on the free, two-way flow of information.
In The Transparent Society, award-winning author David Brin details the startling argument that privacy, far from being a right, hampers the real foundation of a civil society: accountability. Using examples as disparate as security cameras in Scotland and Gay Pride events in Tucson, Brin shows that openness is far more liberating than secrecy and advocates for a society in which everyone (not just the government and not just the rich) could look over everyone else's shoulders.
The biggest threat to our society, he warns, is that surveillance technology will be used by too few people not by too many.
David Brin has a Ph.D. in physics, but is best known for his science fiction. His books include the New York Times bestseller The Uplift War, Hugo Award-winner Startide Rising, and The Postman. He lives in Encinitas, California.
Well, I like Virus 2000, by the original Virus author, published by Grolier Interactive. Can be difficult to find, but is an excellent modern retread of Virus.
Unfortunately windows-only directX, not OpenGL. (I think there might be a playstation version.)
I would say that XML isn't a markup language - a markup language would allow the "bad nesting", since a markup language should be "layers of virtual highlighter pen" applied to an underlying data stream. XML, since it requires "proper nesting", is just Lisp sexps reimplemented, but with terrible syntax. It's yet-another-tree-structured-data-format. Big Wow. A true markup language environment would facilitate part-structured data, like HTML used to be, rather than shoehorning everything into trees.
Lisp sexps would just say (stuff (things "text"))
In fact, that's pretty much all there is to lisp syntax right there. The above is (a) a potentially valid lisp program and (b) a valid lisp data structure.
XML is a data format designed mainly to allow C and Java programmers to use vaguely Lisp-like processing techniques without realising it and/or admitting it to themselves.
I reckon we're under way to little surveillance - but that that includes the people doing the watching. If everyone could watch everyone else, there would be less information flow imbalance, and elites with surveillance tech would not have quite so much power (like the police and government do now).
David Brin's thesis in his book "The Transparent Society: Will Technology force us to choose between Privacy and Freedom?" is that given that surveillance technologies have already been rolled out, and they're not going to go away, no matter how people with laser pens try (imagine multiple, hidden, cameras), the best response is to embrace the technology, and make it as easy for me to watch the police as it is for the police to watch me, enshrine that right in law, and be done with it.
That is to say, the only way to avoid an Orwellian dystopia might be to embrace "total societal transparency".
I strongly suggest that both privacy advocates and "think of the children" police-state types read his book - it illustrates the fundamentally illogical nature of both their positions. The first chapter is available online here
I do disagree with him on some points- e.g. I think the explosive growth in webcams suggests that a move toward total transparency might begin, not end, in the home.
Note also that strong crypto is still vital in such a society, for authentication rather than information-hiding...
The muddleing you speak of was different between implementaions
That's not really my point:
I'm actually arguing that the XML and XHTML language syntax and structure itself is poor - I do, however, beleive that a common set of HTML tags should be standardised - just not that those tags should _have_ to be in arranged in a rigid tree-structured document. e.g. There should be a consensus that p should continue to mean paragraph. I do not believe that I should have to remember to close my p tags.
Er. The "linux release" version is the "trimmed down" version. Check out redhat or mandrake distro kernels sometime - the amount of add-on doohickeys they include is astounding.
Dunno about that - only a few people I've met disliked HTML for that reason, and they were all finicky computer-geek types like myself (but less observant of what the "norms" do) - everyone else:
(a) Just assumes everyone else has the same browser they do.
(b) For non-trivial documents, just uses a WYSIWIG edifor of some description, and just dives into the HTML and tweaks the tags here and there if they feel like it, with the net result that even if the WYSIWIG editor spat out valid XHTML to begin with (unlikely in the first place), it sure isn't when they're through with it.
(c) For trivial documents, writes fragmentary html, maybe even remembering that head and body both exist.
HTML brought online document authoring to masses of people who don't really care about computers, but love the fact they can now build an online community of lacrosse players or some such. I beleive HTML became popular in part because it was actually simple enough that it was _easier_ to write HTML than learn to use a new type of wysiwig editor. These days, new editions of HTML books have big scary warnings about not forgetting to close your tags, to remember to close them in the right order, remember to put in / in singleton tags like br, why you should separate content and presentation, etc. None of which the average joe _wants_ to care about. And a bunch of geeks telling him to will just annoy him.
They didn't "steal" it from BSD. It was used, nice and legal - that's the BSD license. And the Regents copyright was included for the TCP stack.
Anyway, you don't often steal code (unless you make off with the only copy of it rather than copying it), you can infringe on the copyright of code. Not the same thing, despite the propaganda put out by the proprietary software industry and (some) lawyers.
If I had a magic cloning ray, and I cloned your car, would I have stolen it? Of course not. Now you have a car, I have a car, everyone's better off...
No really, it's a tree language. If it was MARKUP - i.e. layers of "virtual highlighter pen", it would allow overlapping tags, and wouldn't shoehorn weakly structured data into rigid trees*. As it is, XML corresponds closely to Lisp sexps, but reimplemented badly with shitty redundant syntax.
XHTML is a particularly bad application of XML, because HTML text is intended to be authored by humans, not autogenerated by and for some bloated SAX parser/DOM tacked onto a bloated Java/CLR VM.
People liked HTML before XHTML because it was forgiving. One could forget a few close tags, one could <b>overlap <i>tag<b> runs <i> and the browser would muddle through.
There's no particularly good reason to burden people with maintaining rigid tree structure if it doesn't make sense. One of the major problems I have with people usng XML is is the weeks/months they spend agonising over their Schemas, on the correct way to shorehorn their transient data into pretty trees - for god's sake, people! If you're using tools so inflexible that you can't just change your mind halfway through, maybe it's time you stopped using the buzzword-laden marketware of XML/Java/C++/C# and moved to a more flexible platform, like Perl, let alone Lisp! 90% of the time, the stuff I see could just be a ASCII CSV dump of an array, or just a stream of bytes! At least Lisp sexps don't force you to bother with close tags that redundantly echo the open tags - and they have identical expressivity, since XML is a tree, not a markup, language.
Bring back real Markup languages! The XMLers have lost their way. They're busily reinventing lisp, badly (yet again) - they've just come from the other side (data-side) to all those scripting languages (code-side) that are slowly mutating into Lisp, where data is code and code is data.
* (And yes, I know that you can eventually make most everything look like a very broad tree-structure by placing a virtual root before an arbitrary collection - witness the UNIX filesystem! - but I hope the reader can see that that's not really my point)
MS Sharepoint Portal Server is the a next round in MS's binding of the corporate office bureaucracy to them. It's basically a Web CMS and DMS that fully integrates with the rest of MS Office.
It's a pretty damn poor Document Manager, and a really abysmal Content Manager in most respects (except for - again a killer feature - WYSIWIG page editing inclusive of component embedding), but the MS Office integration is the key. And of course, no-one can integrate with MS Office better than MS.
If there was a decent "Open Office Portal Server" then things would be just dandy - but, as it is, Sharepoint will act to lock people into another round of MS-dependency. Sharepoint Portal Server has been used by people talking to me as an argument to stick with MS Office even with the existence of open office and star office.
Did you click on the grey box - that's all there is until you press a mouse button to display the menu:-)
The source is in the jar, placed into the public domain. No fonts are specified - Though a custom mouse pointer graphic of "invisible" is used, which is not necessarily supported on all platforms.
Slashdot Mirror
Well, I stayed a big Common Lisp* fan - one idea I've been toying with (i.e. I'll probably never actually do it and even if I started I'd probably never finish) is an APL-syntax parser for Common Lisp arrays, so one could write (apl-eval "...") and have it transform the APL in "..." into CL functions operating on arrays. And with CL, one could easily implement even the fancy stuff like function composition.
Would be quite cool, because one could then mix Maxima symbolic math stuff, APL numeric math stuff and Lisp... stuff... in the one program.
There's a paper which shows that a good CL compiler can be competitive with a fortran compiler for numerical processing.
* Beware that Scheme is rather different in many ways to Common Lisp - if you've investigated Scheme but decided it wasn't for you, but haven't investigated Common Lisp, then I suggest having a look at it.
Sigh.
:-)
People are programming with images, all the time. "visual" editors for GUI forms even make a big deal about it.
I just don't get your word-length argument. "hello" is a compound symbol, manipulated as a unit. More often used symbols tend to become shorter. That's why people say "hi" now. So if programming languages are just like spoken languages, we should see shorter and shorter symbols being used for common problems in that language. Oh wait, we DO see that. And in APL-like languages, mathematical operations on large multidimensional arrays are most common.
***Yes, but the easiest to learn a language is, the easiest it is to find people to hire. No one is willing to learn K, but most are willing to learn Java and Visual Basic. And this clearly affects the budget of a project.
***
When hiring, it is best to hire people who are willing to learn. And if you're hiring criterion is "the cheapest person who is cheapest because he's too lazy to learn anything new" then welcome to project-failure land. I've seen it happen before, no doubt it will happen again and again as inexperienced managers make that mistake.
"No one is willing to learn K" - obviously they are. We've got examples right here on this message board. And if one K coder can do the work of 20 VB monkeys (or more likely, do something that's impossible to do efficently in VB without dropping into COM objects written in C++) then using K could affect the budget positively.
If the lines of code remain constant - why on earth would you use english??? - kfg's post demonstrates that english is more verbose, not less, than mathematical notation, for example, so for certain domains, mathematical notations makes far more sense.
I agree that having the code be a mess of symbols doesn't help understanding the code - I get that feeling when present with a load of COBOL or VB code - lots of big huge english-like symbols meaning that I can only see a few of them at a time on screen, all relating to bits that are off-screen, and the symbols are often not properly encapsulated or abstracted, owing to, e.g. VB's singularly crappy function/subroutine stuff. Means I have to maintain more state in my brain, and while I am very intelligent (modest, too), I am also somewhat lazy, and don't like doing that, it slows me down. It's a "can't see the forest for the trees" effect.
***But humans have the ability to extract the meaning of a word based on context. "Open door" and "open file" is a good convention, made by humans for humans. But "@#$ 35, 22" is not.
***
Of course they do, but that can lead to MAJOR misapprehensions. Unlearning is harder than learning, too, so those misapprehensions can be hard to shift, so in effect, it's a false "easy learning" effect - and context-sensitive stuff is more work (the ascii-line-noise example also illustrates this - because all those symbols are already overloaded with lots of meanings)
I've already said I prefer the APL-symbol APLs to the ASCII-art ones.
And who do you think K was made for? Martians? Not much of a market there.
Maybe it was made for people who simply aren't exactly like you. People are different. Some people may even like the fact that APL-like languages make it easy to use vectorised operations. They may come from VB and realise how much error-prone make-work all those loops were, and PREFER K.
Would you suggest that musical notation, another language, would be better expressed as reams of english text??? It would make it easier for novices to play simple tunes on a piano. But would you hire that novice as a concert pianist?
And I can use printf without even knowing what the f stands for! :-)
(Asctually, I did, but it had momentarily slipped my mind for some reason and it's a while since I had to write C.)
Firstly, I would like to echo the sentiment in kfg's reply to your post.
:-)
:-) ?
.i header includer files had a near 1:1 mapping to the Amiga C .h header include files, including macros for structs and so on.)
:-) ) understands them". I include English-like symbols in that.
Secondly, all html formatting seems to have stopped working- dunno why, so I apologise for the poor formatting of this post.
Thirdly:
*** Now, some programming languages are closer to english in appearance than others. However, for long-term use, that doesn't matter so much - it's just a barrier to entry for lazy people.
***
*** I don't think so. Using symbols for expressions is not the same as using English, especially if one is developing in more than one language.
***
O.K. I may have been oversimplifiing - but: ENGLISH IS SYMBOLS TOO. Using English is exactly the same as using symbols - since using english, or any language, *is* using symbols. That's how humans abstract. In written english you have letters, composed into compund symbols (aside: these compund symbols, "words", are often treated as primitve symbols by fast readers, whose symbol-recognition wetware seems to recognise them in one swoop.)
Now, one could argue "then why not use familiar symbols" - but I find using familiar symbols just because they're familiar to be a bit silly and often dangerously misleading. Think of the emotive symbols "theft" or "piracy" applied to "violation of copyright law", in reality a quite different concept. Or "=" used for both assignment and equality testing (arrgh!!!!), neither of which correspond to mathematics-=, which is a statement of equality.
***You should also consider other facts:
***
***the introduction of new members in the development team, especially if the new members don't know the language
***
It is often better to just budget for bringing the new member up to speed in the language. Or just decide to only hire "speakers" of the language in question. You'll have to bring the new member up to speed on all the little pecularities of your codebase anyway, a much harder task for the new member than merely learning another new computer language.
***maintenance and service after installation; it may not be the original developer (who was so efficient in K) that maintains the project
***
No, but one would hire or train someone capable of maintaining it. Here's usually where the strong arguments for using COBOL or Java come in - "what if one can't hire a K developer in 3 years?", and so on. But learning a new language should be VERY EASY for anyone who calls himself a "programmer" - the hard part will be understanding the code, not the language.
***readability; after long coding hours, ',' is easily mistaken for '.', for example; and with so many symbols packed together in such tiny space, the problem only gets worse.
***
Yes, that is true - but, interestingly, the number of lines of code written by a programmer in a day stays roughly constant - regardless of language used - so the more verbose the language, the less your programmer is doing. And non-ASCII APLs, for example, have much easier to distinguish symbols than #\, and #\.
***learning curve; much higher than a language based on English.
***
Somewhat higher.
Note that I consider "A language based on english" very different to a language in which symbols^Wkeywords happen to correspond somewhat to english words. There are very few programming languages based on english, in which the grammatical structure of the language corresponds closely to english. Many programming languages, however, have keywords based (loosely - printf ??? like "print" followed by a stifled sneeze...) on english words - but the symbols are strung together in ways that are very different to english, and have their own meanings in that language that are typically very different to their english meanings. You can english-open an english-door, but you can mainly only unix-open a unix-file. I won't mention "ontological commitments" right now.
Once you know what "printf" does, you manipulate it as a whole in a c program, you don't spell it out each time you write it "p-r-i-n-t-f" spells "print". A Chinese person can write in C quite easily without knowing much English - once he knows what the symbol "printf" does in the context of C, he doesn't *need* to know that there is an english word "print" or that "f" is the first letter of the english word "file".
So english-like symbols can indeed help in the discovery phase, when you are trying to guess what a symbol does - but so could spanish-like. Or chinese-like. RTFTM (Read-the-fucking-translated-manual) can help here - as a programmer you are manipulating symbols when you are writing a programs, and one of the things programmers spend most of their timing doing is looking up definitions of the meanings of symbols in a particular context - if the definition is in french, and you're french, you can use the symbol, even if the symbol doesn't look french.
***relevance to documentation/pseudocode; for example, it is much easier to make someone understand that the developed code follows the pseudocode defined in a project's specifications when the code is as close as possible to the English language than when the code is a bunch of symbols thrown together.
***
Not if the documentation or pseudocode is in any language other than english. Note that I am European, so I am probably more used to a multilingual environment than you if you are American.
***Although Python/Lisp/C++/whatever are readable, this is because they are based on English. The more a language is based on English, the better it is for big project development.
***
I would disagree e.g. Lisp is SO not based on english. The symbols defined by the language spec are. The "sentence structure" is almost completely alien.
***
That's why every coding style says "use readable variable names"...***
Yes - but readability depends on the reader. And I'd prefer "use meaningful variable names". So english variable names make sense on a big project, since chances are your reader speaks english. But would you suggest using "BEGIN" and "END" instead of "{" and "}" on the same project ???
*** If things were as you claim, we all be programming in assembly or with 0 or 1s; after all, how hard to make a mistake with 2 symbols only
***
Not at all - you misrepresent me. That would be antithetical to forming abstractions via new symbols. (aside: don't forget, most stuff is in fact written in "portable assembler" like languages like C - most good assemblers allow macros and therefore the beginnings of higher-level languages -.e.g Amiga m68k macro assembler
***Don't forget that Hypercard has been claimed as one of the best programming environments because of its ability to program almost in English.
***
(a) Hypercard was claimed as one of the best programming environments for "non-programmers".
(b) Hypercard was one of those few languages where the grammatical structure of the language, not just the keywords, are english-like.
***The attitude "symbols are ok, as long as I understand them" shows that you are ignorant of the issues of real development (with managers, deadlines, multiple and heterogenous environments, different coders, testers, bug reports and bug databases, etc).
***
I assure you, that not my attitude. I am a professional developer and encounter all of the above issues on a daily basis). English-like symbols do indeed help when trying to understand a system. They can also mislead - a variable called "applecount" that holds a count of "all oranges, pears and apples since last tuesday" are very annoying, for example.
My attitude is "symbols are ok, so long as the intended readership (including the computer
***Finally, the obfuscated C code contents would not exist if code readability did not play an important role!!!
***
True. To make the point in my previous comment more concrete: But have you ever seen legalese or a patent document? They're supposed to be in english - all legalese looks obfuscated because they're trying to fit a precise layer on top of an imprecise natural language, and patents are deliberately obfuscated as a matter of course.
You should consider the readability of the language for someone WHO KNOWS THE LANGUAGE, dammit.
I don't go round claiming japanese or arabic is unreadable - I just don't know the language.
The analogy extends further - it is possible to construct almost unreadable drivel in natural languages, and it is possible to construct almost unreadable drivel even in python.
However normal code written in python, forth, common lisp, or even, god forbid, c++ or perl is readable to someone who knows the language.
Now, some programming languages are closer to english in appearance than others. However, for long-term use, that doesn't matter so much - it's just a barrier to entry for lazy people.
I don't happen to know K. I do know APL, though - APL didn't look like K, since it had its own non-ASCII symbol set. I do find it difficult to read the relatively new asciified line-noise APL-derived languages. But that's because I haven't bothered to learn 'em! I do suspect they would be harder to learn than APL, since the ASCII symbols are already overloaded with so many other meanings already - but once I'd learned them, I would expect that problem to fade - just like I'm not confused that "gift" in German means "poison" in english.
Actually, now that Unicode is widely supported, I would love to see a resurgence in APLs that use APL symbols, since they're much clearer to me - but so many people have been using the ASCIIfied APLs for so long now that that may never happen.
I yearn for an Amiga DPaint workalike. Maybe someday I'll get sufficiently bored to write one myself.
Photogenics is available on Linux, and has an excellent UI, but it doesn't do animation.
Repeated because I disagree with mod of AC comment:
And product activation sucks but so does having perhaps the most pirated piece of software in the world so you really can't blame them.
Microsoft WANTS it pirated. Because pirated Windows is what keeps Linux out of the desktop in a large part of the world.
If all eastern Asia had to pay the price Microsoft asks for its software, you'd be sure to see a lot of local OSes spawned from BSD or Linux, with great support for local languages.
But when you can have a pirated copy of a fully-featured Windows for 3$, why bother ?
Personally, I won't be bothering with eBooks until I have a 300DPI+ A4-sized display*, but anyway:
Of course "readable to the human eye" is not the same as "pleasantly readable to the human eye" - you could just buy a print book if the ebook becomes too annoyingly full of wobbly characters.
And also, researchers, spurred on by the challenge of descrambling those obfuscated text things, are already having some success. See
"Breaking gimpy: Researchers crack Security System Designed to prevent internet Robots"
* LCD Manufacturers: I want a high DPI screen, not a physically huge one. Why the hell can't I get a 15" 1600x1200 DESKTOP LCD Monitor???
As far as I can tell, the schools that use computers to actually teach computing are few and far between. To my mind, programming should be regarded as a life skill like arithmetic, reading, writing. I really don't think programming in most languages is harder than arithmetic, let alone basic calculus (which is taught- and if taught early enough, many more people would grasp it.
Current "computer" classes are often "how to use MS Word and MS Excel, maybe even MS IE and MS Outlook Express".
If kids were introduced to proper computing (i.e. CompSci stuff and languages like Logo and Lisp) at an earlier age, they'd realise that computers can be extensions of your mind, and can do arbitrary virtual things (at least until Palladium/TCPA) - they're not just glorified TVs or typewriters, and the absurd effect we have now where companies like Microsoft take mathematical algorithms and sell them as products to the ignorant masses would perhaps be reduced.
Sure, "Computer Programmer" might become less of an elite job description, but at the same time, we'd see much better code.
While we're at it, we should bring back lessons in basic logical reasoning, skeptical thinking, though the marketing departments of corporations and religious organisations mightn't like that...
No one has EVER told me that burn in "stopped being a problem" (I'm in europe). I've seen monitors that were bought early this year with noticeable burn in after about a year's (ab)use by clueless office drones.
Must be some propoganda campaign by monitor manufacturers in america, or something.
I STRONGLY suggest people read The Transparent Society: Will Technology Force Us to Choose between Privacy and Freedom? before drawing conclusions about surveillance technologies
Here's the publisher's blurb:
The Transparent Society
Will Technology Force Us To Choose Between Privacy And Freedom?
In New York and Baltimore, police cameras scan public areas twenty-four hours a day. Huge commercial databases track you finances and sell that information to anyone willing to pay. Host sites on the World Wide Web record every page you view, and "smart" toll roads know where you drive. Every day, new technology nibbles at our privacy.Does that make you nervous?
David Brin is worried, but not just about privacy. He fears that society will overreact to these technologies by restricting the flow of information, frantically enforcing a reign of secrecy. Such measures, he warns, won't really preserve our privacy. Governments, the wealthy, criminals, and the techno-elite will still find ways to watch us. But we'll have fewer ways to watch them. We'll lose the key to a free society: accountability.The Transparent Society is a call for "reciprocal transparency." If police cameras watch us, shouldn't we be able to watch police stations? If credit bureaus sell our data, shouldn't we know who buys it?
Rather than cling to an illusion of anonymity-a historical anomaly, given our origins in close-knit villages-we should focus on guarding the most important forms of privacy and preserving mutual accountability. The biggest threat to our freedom, Brin warns, is that surveillance technology will be used by too few people, now by too many.A society of glass houses may seem too fragile. Fearing technology-aided crime, governments seek to restrict online anonymity; fearing technology-aided tyranny, citizens call for encrypting all data.
Brins shows how, contrary to both approaches, windows offer us much better protection than walls; after all, the strongest deterrent against snooping has always been the fear of being spotted. Furthermore, Brin argues, Western culture now encourages eccentricity-we're programmed to rebel! That gives our society a natural protection against error and wrong-doing, like a body's immune system. But "social T-cells" need openness to spot trouble and get the word out.
The Transparent Society is full of such provocative and far-reaching analysis.The inescapable rush of technology is forcing us to make new choices about how we want to live. This daring book reminds us that an open society is more robust and flexible than one where secrecy reigns. In an era of gnat-sized cameras, universal databases, and clothes-penetrating radar, it will be more vital than ever for us to be able to watch the watchers. With reciprocal transparency we can detect dangers early and expose wrong-doers. We can gauge the credibility of pundits and politicians. We can share technological advances and news. But all of these benefits depend on the free, two-way flow of information.
In The Transparent Society, award-winning author David Brin details the startling argument that privacy, far from being a right, hampers the real foundation of a civil society: accountability. Using examples as disparate as security cameras in Scotland and Gay Pride events in Tucson, Brin shows that openness is far more liberating than secrecy and advocates for a society in which everyone (not just the government and not just the rich) could look over everyone else's shoulders.
The biggest threat to our society, he warns, is that surveillance technology will be used by too few people not by too many.
David Brin has a Ph.D. in physics, but is best known for his science fiction. His books include the New York Times bestseller The Uplift War, Hugo Award-winner Startide Rising, and The Postman. He lives in Encinitas, California.
Well, I like Virus 2000, by the original Virus author, published by Grolier Interactive. Can be difficult to find, but is an excellent modern retread of Virus.
Unfortunately windows-only directX, not OpenGL. (I think there might be a playstation version.)
Learn Common Lisp CLOS instead! Don't get mired in the methods "in" classes
swamp!
Here's my pet rant:
I would say that XML isn't a markup language - a markup language would allow the "bad nesting", since a markup language should be "layers of virtual highlighter pen" applied to an underlying data stream. XML, since it requires "proper nesting", is just Lisp sexps reimplemented, but with terrible syntax. It's yet-another-tree-structured-data-format. Big Wow. A true markup language environment would facilitate part-structured data, like HTML used to be, rather than shoehorning everything into trees.
Lisp sexps would just say (stuff (things "text"))
In fact, that's pretty much all there is to lisp syntax right there. The above is (a) a potentially valid lisp program and (b) a valid lisp data structure.
XML is a data format designed mainly to allow C and Java programmers to use vaguely Lisp-like processing techniques without realising it and/or admitting it to themselves.
Jeez. For the humour-impaired: :-)
Clearly the work of Aum Shinryiko and the Scalar Interferometry Machines leased from the KGB. See here
I reckon we're under way to little surveillance - but that that includes the people doing the watching. If everyone could watch everyone else, there would be less information flow imbalance, and elites with surveillance tech would not have quite so much power (like the police and government do now).
David Brin's thesis in his book "The Transparent Society: Will Technology force us to choose between Privacy and Freedom?" is that given that surveillance technologies have already been rolled out, and they're not going to go away, no matter how people with laser pens try (imagine multiple, hidden, cameras), the best response is to embrace the technology, and make it as easy for me to watch the police as it is for the police to watch me, enshrine that right in law, and be done with it.
That is to say, the only way to avoid an Orwellian dystopia might be to embrace "total societal transparency".
I strongly suggest that both privacy advocates and "think of the children" police-state types read his book - it illustrates the fundamentally illogical nature of both their positions. The first chapter is available online here
I do disagree with him on some points- e.g. I think the explosive growth in webcams suggests that a move toward total transparency might begin, not end, in the home.
Note also that strong crypto is still vital in such a society, for authentication rather than information-hiding...
It could be becuse CSS is readable and writable for humans, and XML turns out to be butt-ugly for CSS - just see XSL-FO if you don't beieve me...
The muddleing you speak of was different between implementaions
That's not really my point:
I'm actually arguing that the XML and XHTML language syntax and structure itself is poor - I do, however, beleive that a common set of HTML tags should be standardised - just not that those tags should _have_ to be in arranged in a rigid tree-structured document. e.g. There should be a consensus that p should continue to mean paragraph. I do not believe that I should have to remember to close my p tags.
Er. The "linux release" version is the "trimmed down" version. Check out redhat or mandrake distro kernels sometime - the amount of add-on doohickeys they include is astounding.
Dunno about that - only a few people I've met disliked HTML for that reason, and they were all finicky computer-geek types like myself (but less observant of what the "norms" do) - everyone else:
(a) Just assumes everyone else has the same browser they do.
(b) For non-trivial documents, just uses a WYSIWIG edifor of some description, and just dives into the HTML and tweaks the tags here and there if they feel like it, with the net result that even if the WYSIWIG editor spat out valid XHTML to begin with (unlikely in the first place), it sure isn't when they're through with it.
(c) For trivial documents, writes fragmentary html, maybe even remembering that head and body both exist.
HTML brought online document authoring to masses of people who don't really care about computers, but love the fact they can now build an online community of lacrosse players or some such. I beleive HTML became popular in part because it was actually simple enough that it was _easier_ to write HTML than learn to use a new type of wysiwig editor. These days, new editions of HTML books have big scary warnings about not forgetting to close your tags, to remember to close them in the right order, remember to put in / in singleton tags like br, why you should separate content and presentation, etc. None of which the average joe _wants_ to care about. And a bunch of geeks telling him to will just annoy him.
They didn't "steal" it from BSD. It was used, nice and legal - that's the BSD license. And the Regents copyright was included for the TCP stack.
Anyway, you don't often steal code (unless you make off with the only copy of it rather than copying it), you can infringe on the copyright of code. Not the same thing, despite the propaganda put out by the proprietary software industry and (some) lawyers.
If I had a magic cloning ray, and I cloned your car, would I have stolen it? Of course not. Now you have a car, I have a car, everyone's better off...
No really, it's a tree language. If it was MARKUP - i.e. layers of "virtual highlighter pen", it would allow overlapping tags, and wouldn't shoehorn weakly structured data into rigid trees*. As it is, XML corresponds closely to Lisp sexps, but reimplemented badly with shitty redundant syntax.
XHTML is a particularly bad application of XML, because HTML text is intended to be authored by humans, not autogenerated by and for some bloated SAX parser/DOM tacked onto a bloated Java/CLR VM.
People liked HTML before XHTML because it was forgiving. One could forget a few close tags, one could <b>overlap <i>tag<b> runs <i> and the browser would muddle through.
There's no particularly good reason to burden people with maintaining rigid tree structure if it doesn't make sense. One of the major problems I have with people usng XML is is the weeks/months they spend agonising over their Schemas, on the correct way to shorehorn their transient data into pretty trees - for god's sake, people! If you're using tools so inflexible that you can't just change your mind halfway through, maybe it's time you stopped using the buzzword-laden marketware of XML/Java/C++/C# and moved to a more flexible platform, like Perl, let alone Lisp! 90% of the time, the stuff I see could just be a ASCII CSV dump of an array, or just a stream of bytes! At least Lisp sexps don't force you to bother with close tags that redundantly echo the open tags - and they have identical expressivity, since XML is a tree, not a markup, language.
Bring back real Markup languages! The XMLers have lost their way. They're busily reinventing lisp, badly (yet again) - they've just come from the other side (data-side) to all those scripting languages (code-side) that are slowly mutating into Lisp, where data is code and code is data.
* (And yes, I know that you can eventually make most everything look like a very broad tree-structure by placing a virtual root before an arbitrary collection - witness the UNIX filesystem! - but I hope the reader can see that that's not really my point)
MS Sharepoint Portal Server is the a next round in MS's binding of the corporate office bureaucracy to them. It's basically a Web CMS and DMS that fully integrates with the rest of MS Office.
It's a pretty damn poor Document Manager, and a really abysmal Content Manager in most respects (except for - again a killer feature - WYSIWIG page editing inclusive of component embedding), but the MS Office integration is the key. And of course, no-one can integrate with MS Office better than MS.
If there was a decent "Open Office Portal Server" then things would be just dandy - but, as it is, Sharepoint will act to lock people into another round of MS-dependency. Sharepoint Portal Server has been used by people talking to me as an argument to stick with MS Office even with the existence of open office and star office.
Did you click on the grey box - that's all there is until you press a mouse button to display the menu :-)
The source is in the jar, placed into the public domain. No fonts are specified - Though a custom mouse pointer graphic of "invisible" is used, which is not necessarily supported on all platforms.