Does the "nobody got fired for Java" comment indicate that this was written after Java escaped being a minority language? Or does somebody update the essay as language "fashion" changes? With this kind of advice, new languages can never be mainstream, and old languages can never see a resurgence.
Not to worry, though. The "fashion" people will be swept along eventually, whether by new fashion, or by old fashion making a comeback.
What's the point of x in these loops? You never use it in constructing the result. If your purpose is to scare people away from Scheme, no need to deliberately obfuscate the algorithm. Keywords like null?, car and cdr look scary enough, at least until people learn their simple meanings.
I think it's important to note that Common Lisp, upon which most of Kent's comments are based, does not have an equivalent to Scheme's continuations either. Nor does the spec guarantee tail call elimination.
It should also be noted that "outward" continuations (not captured) are supported by Kawa. I use them.
From hearsay about a PostgreSQL to Oracle port, I previously assumed that it was just for SFEE at companies where they were already using Oracle. However, that job description really does look like a transition of sourceforge.net away from free software.
"Banning them outright?" Read the article before you post the article:
The existence of such a technology, the amendment states, ''may
seriously intrude on the privacy of these users. The use of such
devices should therefore be prohibited unless the explicit,
well-informed and freely given consent of the users concerned
has been obtained.''
Obviously MSFT-charset quotes are not really smart. You should have used double quotes to qualify that adjective, like this: what?s with the ?smart? quotes?
Check out demoronizer if using perl and the brl-msft-escape function if using BRL.
So the only way to really do it is to kill software patents, right? No.. then you'll see companies and universities going the "trade
secret" route. Free Code could disappear like turkey on thanksgiving.
You're saying free code would disappear without software patents? Nonsense. I'd say less than 1% of free code is released because the owner can protect it with patents. Much free code predates the introduction of legislation (by the judiciary, not the legislature) that allows software patents, which are patents on mathematical algorithms no matter what the lawyers say.
Get a digital camera, take some pictures, and do things to them in gimp. Create a web photo album. Later, when you have kids and no more time for games, you'll still want to make albums.
The most important skill you need to learn if you're going to build
database-driven web sites is SQL. If you learn how to massage the
data into the form you want before you present it, you'll
save yourself a lot of work, and likely have a better-performing app
as well.
SQL has been around a long time and is not going away. It's more
important to learn it deeply than to learn any of the plethora of
languages out there for tying databases into the web, even mine.
The problem is not the nature of dynamic scripting languages (which I take to mean languages that let you prototype quickly). The problem is design choices made in the particular languages you've looked at. BRL has no problem scaling to more complex applications. And if you choose to prototype quickly and end up with "dirty" code in pages, cleaning it out is a mindless process, as I described in another comment.
The SPA audits software used internally in an organization. The FSF audits software that is incorporated into derived works that the organization distributes and charges license fees for as if it were their own. It seems the former is a lot easier to do by accident than the latter.
If the FSF were making deals that required organizations to only use free software internally, then you could draw comparisons with the SPA.
This is a genuine question from an actual student with no choice as to what language will be used for homework. Not just lisp vs. non-lisp, but no choice as to which dialect to use. Probably no choice as to which implementation.
Slashdot articles that mention more than one programming language are forums for language wars. You don't come here for actual, help, silly!
Why don't you pop on over to comp.lang.lisp and ask about Common Lisp reference texts other than the one you're dissatisfied with. They might point you to one that would be more to your liking.
Now please pardon me while I go flame at those who denigrate my favorite language or languages similar to it.:-)
If you're already using JDBC, seems like BRL would be an obvious choice for the database-to-XML part. With Kawa Scheme underneath, you can continue to use whatever Java objects you're already using.
This is where the "everything is an expression" model of Scheme wins out over the package/class/method/statement/expression hierarchy of Java. If Java statements in a JSP get unwieldy, you need to come up with a package, class and method to put them in. With Scheme/BRL, you just wrap a function definition around the code in question (define (show-user-name)...) and toss it in sitedefs.scm.
How much harder is [(show-user-name)] than <jsp:show-user-name/>? In either case, the content editor is just treating it as a black box. They need to understand what goes in and comes out, but don't otherwise care how it works. The logic hasn't really been separated, just abstracted.
There are varying degrees of abstraction. For example, conditionals would be less abstracted. The content editor needs to understand the logic in order to have control over what is shown to the user, e.g. "If this and that form field are blank, then show this message, otherwise do that." This is the beginning of programming. The more ambitious the content editor, the more "programming" gets involved.
BRL gives you complete choice to vary the amount of abstraction according to the ambition and ability of the content editor. And you're not stuck if you change your mind later.
When debugging, I find it handy to have the HTML and code mixed in front of me. I'm looking at actual HTML generated, and I want to find the code responsible. With little abstraction, it's one-stop shopping. Forcing an n-tier architecture from the start would be cumbersome. It's unnecessary. BRL is not like JSP, where once code goes into a page it's unlikely to ever come out.
Does Java? The typical Java-fan critique of JSP acknowledges that Java is a lousy language to embed in web templates. There's a plethora of templating systems out there that implement various non-java syntax to embed in web pages -- webmacro, XMLC, etc. Is there one of them that could legitimately be called the "Java" web page templating system?
JSP taglibs are a kit to build your own non-Java language to embed in HTML.
Why not use a well-designed language that lends itself well to embedding in HTML and other markup, the Scheme-based BRL. I'm using it very successfully at work. Compare its code for sending e-mail or dealing with a database with any other language or system. I'm biased, but the code isn't. For rapid development of database-driven web apps, it cranks.
BRL is a Scheme-based language for server-side web programming. It uses a JVM-based Scheme underneath called Kawa, so all the Java class libraries are available as well.
Reading through some of the example code on the Dylan team's page, much of the style seems similar to Scheme, but without the paren notation. I find the paren notation easier to scan, but then I use Scheme a lot and no Dylan. Can someone who works actively with both Dylan and Scheme make a comparison?
I understand Scheme was a big influence in the design of Dylan.
Having an outsider find and report a bug is usually a much happier situation than having in-house users encounter the same bug while conducting our business.
Slashdot Mirror
See my reply to your posting of this same essay 4 minutes previous.
Does the "nobody got fired for Java" comment indicate that this was written after Java escaped being a minority language? Or does somebody update the essay as language "fashion" changes? With this kind of advice, new languages can never be mainstream, and old languages can never see a resurgence.
Not to worry, though. The "fashion" people will be swept along eventually, whether by new fashion, or by old fashion making a comeback.
What's the point of x in these loops? You never use it in constructing the result. If your purpose is to scare people away from Scheme, no need to deliberately obfuscate the algorithm. Keywords like null?, car and cdr look scary enough, at least until people learn their simple meanings.
I think it's important to note that Common Lisp, upon which most of Kent's comments are based, does not have an equivalent to Scheme's continuations either. Nor does the spec guarantee tail call elimination.
It should also be noted that "outward" continuations (not captured) are supported by Kawa. I use them.
From hearsay about a PostgreSQL to Oracle port, I previously assumed that it was just for SFEE at companies where they were already using Oracle. However, that job description really does look like a transition of sourceforge.net away from free software.
I see nothing in Pat McGovern's post denying such a transition.
Most ironic is the part at the end of the job listing: "A plus if you understand what the Open Source community is all about!"
I'm using it in my learnbrl tutorial. It's not well documented, but easy to use from the examples.
...except Amazon just filed a business method patent on it.
Obviously MSFT-charset quotes are not really smart. You should have used double quotes to qualify that adjective, like this: what?s with the ?smart? quotes?
Check out demoronizer if using perl and the brl-msft-escape function if using BRL.
You're completely correct, of course. I'm glad I never stated that.
Get a digital camera, take some pictures, and do things to them in gimp. Create a web photo album. Later, when you have kids and no more time for games, you'll still want to make albums.
MIT doesn't think so.
I think your numbers are high, given that MIT's faculty+students number under 11,000. However, I do think there are many more linux machines than the hundred or so in MIT's interdepartmental clusters.
The most important skill you need to learn if you're going to build database-driven web sites is SQL. If you learn how to massage the data into the form you want before you present it, you'll save yourself a lot of work, and likely have a better-performing app as well.
SQL has been around a long time and is not going away. It's more important to learn it deeply than to learn any of the plethora of languages out there for tying databases into the web, even mine.
The problem is not the nature of dynamic scripting languages (which I take to mean languages that let you prototype quickly). The problem is design choices made in the particular languages you've looked at. BRL has no problem scaling to more complex applications. And if you choose to prototype quickly and end up with "dirty" code in pages, cleaning it out is a mindless process, as I described in another comment.
The SPA audits software used internally in an organization. The FSF audits software that is incorporated into derived works that the organization distributes and charges license fees for as if it were their own. It seems the former is a lot easier to do by accident than the latter.
If the FSF were making deals that required organizations to only use free software internally, then you could draw comparisons with the SPA.
Not sure I completely understand the equivalence here. What perl code would be equivalent to the following Scheme code?
(define (foo n)(lambda (m) (+ m n)))
(define bar (foo 1))
(define baz (foo 2))
(display (bar 5))
(display (baz 5))
This is a genuine question from an actual student with no choice as to what language will be used for homework. Not just lisp vs. non-lisp, but no choice as to which dialect to use. Probably no choice as to which implementation.
Slashdot articles that mention more than one programming language are forums for language wars. You don't come here for actual, help, silly!
Why don't you pop on over to comp.lang.lisp and ask about Common Lisp reference texts other than the one you're dissatisfied with. They might point you to one that would be more to your liking.
Now please pardon me while I go flame at those who denigrate my favorite language or languages similar to it. :-)
If you're already using JDBC, seems like BRL would be an obvious choice for the database-to-XML part. With Kawa Scheme underneath, you can continue to use whatever Java objects you're already using.
This is where the "everything is an expression" model of Scheme wins out over the package/class/method/statement/expression hierarchy of Java. If Java statements in a JSP get unwieldy, you need to come up with a package, class and method to put them in. With Scheme/BRL, you just wrap a function definition around the code in question (define (show-user-name) ...) and toss it in sitedefs.scm.
How much harder is [(show-user-name)] than <jsp:show-user-name/>? In either case, the content editor is just treating it as a black box. They need to understand what goes in and comes out, but don't otherwise care how it works. The logic hasn't really been separated, just abstracted.
There are varying degrees of abstraction. For example, conditionals would be less abstracted. The content editor needs to understand the logic in order to have control over what is shown to the user, e.g. "If this and that form field are blank, then show this message, otherwise do that." This is the beginning of programming. The more ambitious the content editor, the more "programming" gets involved.
BRL gives you complete choice to vary the amount of abstraction according to the ambition and ability of the content editor. And you're not stuck if you change your mind later.
When debugging, I find it handy to have the HTML and code mixed in front of me. I'm looking at actual HTML generated, and I want to find the code responsible. With little abstraction, it's one-stop shopping. Forcing an n-tier architecture from the start would be cumbersome. It's unnecessary. BRL is not like JSP, where once code goes into a page it's unlikely to ever come out.
Does Java? The typical Java-fan critique of JSP acknowledges that Java is a lousy language to embed in web templates. There's a plethora of templating systems out there that implement various non-java syntax to embed in web pages -- webmacro, XMLC, etc. Is there one of them that could legitimately be called the "Java" web page templating system?
JSP taglibs are a kit to build your own non-Java language to embed in HTML.
Why not use a well-designed language that lends itself well to embedding in HTML and other markup, the Scheme-based BRL. I'm using it very successfully at work. Compare its code for sending e-mail or dealing with a database with any other language or system. I'm biased, but the code isn't. For rapid development of database-driven web apps, it cranks.
BRL is a Scheme-based language for server-side web programming. It uses a JVM-based Scheme underneath called Kawa, so all the Java class libraries are available as well.
Reading through some of the example code on the Dylan team's page, much of the style seems similar to Scheme, but without the paren notation. I find the paren notation easier to scan, but then I use Scheme a lot and no Dylan. Can someone who works actively with both Dylan and Scheme make a comparison?
I understand Scheme was a big influence in the design of Dylan.
Having an outsider find and report a bug is usually a much happier situation than having in-house users encounter the same bug while conducting our business.
For more details, see my essay: Free Software: Solving the Buy/Build Dilemma.