The category "Government contractor" is just as broad a generalization as the category "information technology worker". Government contractors vary wildly in size and bureaucracy level, mostly related to the branch of the Government they work for.
Little contractors who work for researchy bureaus like NASA, NOAA, NIH, have IT jobs that feel a lot like CS graduate school. with firmer deadlines. Big contractors who work for the IRS or Social Security have IT jobs whose atmosphere rivals IBM in the old, pre-Microsoft days.
... slowly and methodically picking through all of your code to make sure that no buffers can overflow is just uninteresting and unglamorous.
But it doesn't have to be done manually! A simple Google search turned up lots of tools that eat raw C and C++ code and detect potential buffer overflows. Use of tools like these ought to be a mandatory quality control step for any organization that really cares about secure and reliable applications.
And of course, all of this completely ignores the possibility of using otherlanguages where buffer overflows and stack smashes are implementation problems rather than application programmer errors.
In my opinion, shipping code written in unsafe languages without at least an automatic static check for potential security problems should make the shipper liable for damages.
People are the same, conditions are different
on
True Names
·
· Score: 2
... we humans are pretty much the same as we always were, as any student of history, ancient literature, or anthropology could tell you.
We humans may still be the same, but conditions now are different. The big difference is that for the last five hundred years or so, we've been collectively building a description of the world that continuously checks itself against reality, and doesn't backslide (new descriptions have to be consistent with all previous observations). We use that description to build tools to control our environment and improve our lives.
Before empiricism and the scientific method, change was so slow and so random that most people never saw it during their lifetimes. Today, people take exponential progress in computer hardware performance as a given, and expect visible change in their surroundings multiple times during their lives.
You use a programming language for one primary reason: you believe most other people in your domain space are using it.
I can think of a few other reasons to consider, the biggest one being:
You believe it will help you solve your problems.
If your problem is "there is no known efficient algorithm to solve this", you choose a language where you can rapidly experiment and profile different solutions, then tune the hell out of the best ones and deploy them. That's why Orbitz chose Lisp for their core fare search engine.
If your problem is "we need 50 coders to maintain our external Web site", you choose a language where lots of people are available and there are lots of libraries to do the standard stuff. That's why Orbitz's Web site code is in Java.
Most of his arguments boil down to "if you learned LISP, you'd like it." But that's bogus.
I guess what Kent should have said more explicitly here was "most people's idea of Lisp comes from bad teaching by people who don't know and use the langauge. If you got to know Lisp properly, you'd like it more."
I was first exposed to Lisp as an undergrad, in probably the worst possible way. It was as part of the canonical language survey course, taught by someone who didn't really know Lisp, using an atrocious little monograph titled "Lisp for Fortran Programmers". List processing using only PROG, SETQ,and GO *shudder*. No macros, no arrays, no structures. And the implementation we used was essentially a batch interpreter - no emacs, no debugger, just a raw command-line read-eval-print loop.
When I saw Lisp again, in my second year of graduate school, it was taught by someone who used it to get real work done, with an implementation that had most of the features I have come to know and love.
A large fraction of current Lisp users (judging from comments in comp.lang.lisp) are people who started out knowing other languages, became frustrated with their instability or limitations, and went out looking for alternatives. Their choice of Lisp was not made in ignorance.
Lisp is not perfect, but it is an excellent balance of features in progrmming space. Lisp allows you to do imperative code, functional code, and OO code, without forcing you exclusively down one road or another. It is still one of the languages of choice when you want to do something truly new, and it will likely remain so.
We agree on logic - now about those premises...
on
God's Debris
·
· Score: 2
Whether it is religion, politics, or your choice of shoes... always try to take a logical and rational outlook instead of an emotionally reaction.
We are in violent agreement here. Everyone basically agrees on the rules of logic and argument, in science and religion. Where the differences come in is in which premises you start from, and how you check them.
In science, all the premises are supposed to be of the form "Someone I trust went out and looked. Here's what they say they saw, and you can go out yourself and look if you don't believe me."
In religion, the premises seem to be of the form "Someone I trust talked to a Supreme Being, and they say this is what they were told." Some religions extend this with "And you can talk to the Supreme Being yourself if you don't believe me."
@
Representing programs as S-expressions, incidentally, has one terrible cost - it's hostile to comments. Because there's no place to hang the comments, LISP code tends to be uncommented within the text of the code.
Just curious - when did you stop writing Lisp? If you actually used a Symbolics, how could you have missed the standard semi-colon commenting conventions, which Lisp-aware editors grok quite nicely:
; - inside code (at end of line)
;; - inside code (beginning of line, indented)
;;; - function header comments (column 1)
;;;; - Big block comments
Or have you never heard of the ANSI standard generic function (documentation place &optional type) that lets you access comment strings, which can be hung just about anywhere? I even have a little package I picked up in 1997 that trolls Lisp source code, extracts the documentation strings, and emits javadoc-like documents, in HTML or TeX or RTF.
"no place to hang the comments", indeed.
You might, just possibly, be thinking of Interlisp, which did have a comment form that could be placed inside your function code and was edited with the structure editor like everything else. In ancient times you had to be a little careful as to where you put comments, but that problem went away with Xerox Common Lisp, around 1986 or so.
When a distinguished but elderly scientist states that something is possible he is almost certainly right. When he states that something is impossible, he is very probably wrong.
I don't know if the author in question qualifies here, but it is something to consider.
Nobody ever claimed that XML is a major innovation in lexical encodings.
Lots of people claiim XML is going to change the world; the hype level surrounding it is astounding. You're not, and I thank you for that.
Neither for that matter is LISP which is no more than Lambda calculus.
I take minor issue with that. Lisp is the lambda calculus, made useful. Go look at this for more.
The problem with S-Expressions is that one misplaced parenthesis can cause the entire semantics of the expression to be changed, or as we computer scientists say 'be fucked beyond recognition'.
And this is different from dropping one {double-quote/greater-than/closing XML tag} in what way? Redundancy is good, redundant redundancy is bad. The only case where the redundancy matters is when the parser fails, and a human tries to repair the damage. In either case, you want a smart editor to help you, and S-expressions are easier to parse (hence more editors support them than do XML).
Packaging counts for an awful lot.
Exactly the right words for XML. XML is a lot of awful packaging, full of syntactic complexity without semantic benefit. What, for example, is the justification for the difference between XML attributes and XML contents, other than "the DTD treats them differently"? XML schemas are trying to fix this, but since they have to maintain backward compatibility with DTDs, they'll never get back to anything nearly as clean as S-expressions.
Please try your post again, and this time be sure to choose "Extrans (html tags to text)" instead of "Plain old text". Slash clobbers html-like postings unless you do that, as I discovered the first time I previewed my posting.
And if they did that, they might have to admit that XML is semantically equivalent to Lisp S-expressions, and not a major advance in computer science after all.
For my money, these two together cover Lisp's enduring advantages over newcomers.
Yes, you can get many advantages with strongly typed functional programming languages. But, you can get most of their abstraction power with Lisp's first-class functions and macros, without the pain and suffering of adhering to formality. Most Lisp hackers acknowledge the utility and power of functional programming, but use Lisp anyway because it doesn't force them to do everything functionally
Yes, Java, Python and Ruby have many of Lisp's features without Lisp's syntax. But, they don't have Lisp macros, so the abstraction power of designing your own language is not available to them. I use Lisp because it allows me to take
FileInputStream infile = null;
try {
infile = new FileInputStream("foo")
// Do stuff with infile
} catch (Exception e) {
// Report error munging infile
} finally {
infile.close();
}
and replace it with:
(with-open-file
(infile "foo":direction:input)
;; Do stuff with infile
)
and get the same level of safety, with a lot less repetitious code.
Forty billion dollars has been allocated to the cause of chasing shadows, yet we know that shadows can never be caught. A mere four billion, on shining the light of information around the world, would have gone a long way to prevent the shadows from being there to start with.
People are proposing that the World Trade Center be rebuilt to "spit in the terrorists' eye". I suggest we take that money and put it into high-bandwidth networking infrastructure for a 100-mile radius of New York city. The vast majority of workers in the WTC were information workers - they didn't really need to be physically close to each other to do their jobs.
Let's spit in the terrorists' eye by presenting them with smaller targets, and doing business more efficiently to boot.
But here's something else I'm wondering about -- why are people still creating Aqua themes? Apple has asked repeatedly for people to stop. Why does this continue? Surely theme creators can come up with something new.
Why not do something that changes Aqua for the better and release that? Rather than slavishly copying the colors and curves of the buttons, do something useful, like move the kill and shrink buttons to opposite corners of the window where they belong, dammit!
DS1's AI ran on more than "just" Suns. The probe itself runs VxWorks on a rad-hardened RS6000 (PowerPC) at the awesome speed of 25 MHz (see here).
Development of the planning/scheduling was done on Suns and Power Macs, using two different vendors' Common Lisp implementations (see here for a message from one of the implementors). During development, NASA management decided there were too many programming languages flying in DS1, so they decided to drop one of C, C++, or Lisp. C++ lost, but is being wedged back in for political reasons.
The planner was only given 10% of the CPU, which meant DS1 was doing real-world AI at 2 MHz (!).
From a civil liberties point of view, I have few problems with investigation (aimed at specific people, with probable cause and court approval). I have a lot of problems with surveillance (aimed at large groups, without oversight). The reason surveillance is scary is that now it's cheap. The constant monitoring on display in "1984" is becoming feasible, thanks to automation.
Previous suspensions of civil liberties eventually went away because they were too expensive to keep up after the threat was over. The new ones being proposed won't have that drawback - if we give up oversight this time, we'll never get it back.
The lambda calculus is not inherently sequential, and languages based on the lambda calculus can be massively parallel in execution, just by using simple tricks like evaluating the arguments. The ideas have been floating around for decades - they boil down to:
Functional, side-effect-less programs and primitives
Richard Gabriel, software aesthetics, and patterns
on
Software Aesthetics
·
· Score: 2
Go look here for Richard Gabriel's ideas on this subject. In particular check out the Feyerabend project and one of his many "worse is better" essays, which has this to say about the current pattern movement and its effect on software aesthetics:
More disappointing is witnessing this same effect at work in the patterns community. Christopher
Alexander's ideas of patterns has as its smallest part the pattern form--the concept of patterns really
has to do with pattern languages and QWAN (the Quality Without a Name). It is not about con-struction
tricks. It is about building artifacts not only suitable for human habitation, but artifacts
that increase their human inhabitants' feeling of life and wholeness. Alexander is all about beauty and
quality, not about how to stick things together cleverly.
Yet, the most popular form of software patterns is exemplified by those found in "Design Patterns,"
by Gamma, Helm, Johnson, and Vlissides, which contains little more than techniques for coding in
C++ constructs found in other programming languages--for example, 16 of the 23 patterns represent
constructs found in the Common Lisp language. There is no pattern language involved, and
there is nothing about QWAN. Interest in patterns is coagulating around the so-called Gang of Four
style, and it looks like things could get worse. In fact, I would say that patterns are alive and well as a
form of documentation and a quest for clever solutions to common programming problems, and pattern
languages, QWAN, and the quest for a better future are now on their way to the sewage treatment
plant--the same place they went to in the world of architecture. Down with quality, up with
clever hacks. Why worry about what makes a user interface beautiful and usable when you can wonder
how to do mapcar in C++.
If the accused had been one of their reporters, the words "chilling effect" and "First Amendment" would have been all over that piece. They clearly don't really understand what's at stake here.
I'm going to write them a letter mentioning that foreign researchers like Alan Cox are already suppressing research due to the DMCA. Maybe if I mention the sainted Katharine Graham, they'll sit up and take notice...
In the long run, elegant, minimalistic code is easier to understand, and therefore easier to secure (examples are Sendmail vs. qmail, or BIND vs. djbdns).
That's the first (and hopefully only) time I ever hope to see the words "elegant", "minimalistic", and "Sendmail" together in the same sentence.
Re:The Great Microsoft Problem
on
Windows in 2020
·
· Score: 2
The basic tenet of a capitalist, free-enterprise system is that through competition and the invisible hand of supply-demand, products and productivity will constantly improve and thus society as a whole will prosper.
The number one reason this doesn't work in the computer market is that most people who buy computers simply don't know enough about them to choose intelligently. Most people reading this can choose things other than Windows, because they are skilled enough to convert file formats, configure devices, etc.
Interoperability good, homogeneity bad
on
Windows in 2020
·
· Score: 2
The best of all possible worlds is:
* open standards
* with multiple, open implementations
That way, you get interoperability (like the Internet) without the problems that you get with Microsoft-led homogeneity, which is built on
* closed standards
* with single, closed implementations
A world where everyone ran Linux, but no distribution dominated, would be much safer than the current one.
Slashdot Mirror
The category "Government contractor" is just as broad a generalization as the category "information technology worker". Government contractors vary wildly in size and bureaucracy level, mostly related to the branch of the Government they work for.
Little contractors who work for researchy bureaus like NASA, NOAA, NIH, have IT jobs that feel a lot like CS graduate school. with firmer deadlines. Big contractors who work for the IRS or Social Security have IT jobs whose atmosphere rivals IBM in the old, pre-Microsoft days.
But it doesn't have to be done manually! A simple Google search turned up lots of tools that eat raw C and C++ code and detect potential buffer overflows. Use of tools like these ought to be a mandatory quality control step for any organization that really cares about secure and reliable applications.
And of course, all of this completely ignores the possibility of using other languages where buffer overflows and stack smashes are implementation problems rather than application programmer errors.
In my opinion, shipping code written in unsafe languages without at least an automatic static check for potential security problems should make the shipper liable for damages.
Before empiricism and the scientific method, change was so slow and so random that most people never saw it during their lifetimes. Today, people take exponential progress in computer hardware performance as a given, and expect visible change in their surroundings multiple times during their lives.
How hard would it be to write an MS Word virus that would change this preference when a document was opened?
If your problem is "we need 50 coders to maintain our external Web site", you choose a language where lots of people are available and there are lots of libraries to do the standard stuff. That's why Orbitz's Web site code is in Java.
I was first exposed to Lisp as an undergrad, in probably the worst possible way. It was as part of the canonical language survey course, taught by someone who didn't really know Lisp, using an atrocious little monograph titled "Lisp for Fortran Programmers". List processing using only PROG, SETQ,and GO *shudder*. No macros, no arrays, no structures. And the implementation we used was essentially a batch interpreter - no emacs, no debugger, just a raw command-line read-eval-print loop.
When I saw Lisp again, in my second year of graduate school, it was taught by someone who used it to get real work done, with an implementation that had most of the features I have come to know and love.
A large fraction of current Lisp users (judging from comments in comp.lang.lisp) are people who started out knowing other languages, became frustrated with their instability or limitations, and went out looking for alternatives. Their choice of Lisp was not made in ignorance.
Lisp is not perfect, but it is an excellent balance of features in progrmming space. Lisp allows you to do imperative code, functional code, and OO code, without forcing you exclusively down one road or another. It is still one of the languages of choice when you want to do something truly new, and it will likely remain so.
In science, all the premises are supposed to be of the form "Someone I trust went out and looked. Here's what they say they saw, and you can go out yourself and look if you don't believe me."
In religion, the premises seem to be of the form "Someone I trust talked to a Supreme Being, and they say this is what they were told." Some religions extend this with "And you can talk to the Supreme Being yourself if you don't believe me."
@ Representing programs as S-expressions, incidentally, has one terrible cost - it's hostile to comments. Because there's no place to hang the comments, LISP code tends to be uncommented within the text of the code. Just curious - when did you stop writing Lisp? If you actually used a Symbolics, how could you have missed the standard semi-colon commenting conventions, which Lisp-aware editors grok quite nicely:
;; - inside code (beginning of line, indented)
;;; - function header comments (column 1)
;;;; - Big block comments
; - inside code (at end of line)
Or have you never heard of the ANSI standard generic function (documentation place &optional type) that lets you access comment strings, which can be hung just about anywhere? I even have a little package I picked up in 1997 that trolls Lisp source code, extracts the documentation strings, and emits javadoc-like documents, in HTML or TeX or RTF.
"no place to hang the comments", indeed.
You might, just possibly, be thinking of Interlisp, which did have a comment form that could be placed inside your function code and was edited with the structure editor like everything else. In ancient times you had to be a little careful as to where you put comments, but that problem went away with Xerox Common Lisp, around 1986 or so.
Me, bitter? Depressed? Yeah, a little...
Please try your post again, and this time be sure to choose "Extrans (html tags to text)" instead of "Plain old text". Slash clobbers html-like postings unless you do that, as I discovered the first time I previewed my posting.
... because if they did, people might realize that:
<foo> <bar>baz</bar> <mumble>grumble</mumble></foo>
is equivalent to
<foo> <bar>baz</> <mumble>grumble</></>
which is semantically equivalent to
(foo (bar "baz") (mumble "grumble"))
And if they did that, they might have to admit that XML is semantically equivalent to Lisp S-expressions, and not a major advance in computer science after all.
And they'd never do that.
Yes, you can get many advantages with strongly typed functional programming languages. But, you can get most of their abstraction power with Lisp's first-class functions and macros, without the pain and suffering of adhering to formality. Most Lisp hackers acknowledge the utility and power of functional programming, but use Lisp anyway because it doesn't force them to do everything functionally
Yes, Java, Python and Ruby have many of Lisp's features without Lisp's syntax. But, they don't have Lisp macros, so the abstraction power of designing your own language is not available to them. I use Lisp because it allows me to take
FileInputStream infile = null;
try {
infile = new FileInputStream("foo")
} catch (Exception e) {
} finally {
infile.close();
}
and replace it with:
(with-open-file
(infile "foo"
)
and get the same level of safety, with a lot less repetitious code.
Let's spit in the terrorists' eye by presenting them with smaller targets, and doing business more efficiently to boot.
DS1's AI ran on more than "just" Suns. The probe itself runs VxWorks on a rad-hardened RS6000 (PowerPC) at the awesome speed of 25 MHz (see here).
Development of the planning/scheduling was done on Suns and Power Macs, using two different vendors' Common Lisp implementations (see here for a message from one of the implementors). During development, NASA management decided there were too many programming languages flying in DS1, so they decided to drop one of C, C++, or Lisp. C++ lost, but is being wedged back in for political reasons.
The planner was only given 10% of the CPU, which meant DS1 was doing real-world AI at 2 MHz (!).
From a civil liberties point of view, I have few problems with investigation (aimed at specific people, with probable cause and court approval). I have a lot of problems with surveillance (aimed at large groups, without oversight). The reason surveillance is scary is that now it's cheap. The constant monitoring on display in "1984" is becoming feasible, thanks to automation.
Previous suspensions of civil liberties eventually went away because they were too expensive to keep up after the threat was over. The new ones being proposed won't have that drawback - if we give up oversight this time, we'll never get it back.
Functional, side-effect-less programs and primitives
Parallel evaluation of arguments
Parallel evaluation of mapping primitives
See here for a recent reference.
If the accused had been one of their reporters, the words "chilling effect" and "First Amendment" would have been all over that piece. They clearly don't really understand what's at stake here.
I'm going to write them a letter mentioning that foreign researchers like Alan Cox are already suppressing research due to the DMCA. Maybe if I mention the sainted Katharine Graham, they'll sit up and take notice...
My bad. Your sentence was clear enough - I just misread it. My only defense is that three moderators misread it too.
Let's see, how can you give back karma points received under false pretenses...
The best of all possible worlds is:
* open standards
* with multiple, open implementations
That way, you get interoperability (like the Internet) without the problems that you get with Microsoft-led homogeneity, which is built on
* closed standards
* with single, closed implementations
A world where everyone ran Linux, but no distribution dominated, would be much safer than the current one.
Some IP-addressable objects move around. Should my laptop have to change its address every time zone as I fly across the ocean?
.leo domain.
How about computers in orbit? Yeah, we probably need a