Anyone who's a lisp fan (and those who'd like to be converted) should really read Graham's writeup of his LL1 presentation at http://www.paulgraham.com/arc.html
I'm really excited about this language. They're going to give an honest shot at making a lisp that will have more general appeal (read the part about onions: they're taking the "onions" out of common lisp), yet still maintain the raw power of macros. It should be very exciting.
Java troll alert! You're trying to tell me that Java's lack of enumerations is a good thing? That's silly. C's lack of classes also makes it faster, but is this really a good thing?
Also, I believe with C# the foo.size++ above actually works with getters and setters, not just public member variables. It's a shortened syntax which does improve readability, but doesn't do a whole lot for understanding, IMHO.
At first this just sounds like trolling, but I think he's got a point. If you're writing a commercial software installer, you undoubtedly have test machines in-house where you could test your script as well as the application.
If you're writing free software, you've got a bit more of a challenge, but I'd argue that you might as well just put a #!/bin/bash at the top of your script. If you're writing free software, it's pretty safe to assume that the person installing it will have bash...
Have you seen thousands of threads running on one of Linus' kernels? He isn't particularly fond of the idea, and isn't going to tweak the kernel to support that sort of thing. There's a reason Linux native threads JVMs do poorly on the scalability portion of VolanoMark...
Everything you're saying makes sense on a system where processes really are heavyweight monsters. On Linux, processes and threads are much more similar. The difference is copy-on-write semantics for memory pages. Up until you actually modify a page, it is shared by child and parent. This means that using processes instead of threads doesn't automatically mean that you're grossly increasing memory needs.
You're still glossing over things. When using threads, *anything* on the heap can potentially be accessed by two threads simulataneously. If you're using processes, you know exactly when and where data is being shared (it's kind of hard to miss data moving through a pipe). It's much easier to control, but it does come at the expense of efficiency. The only really efficient IPC mechanism is shared memory, which of course has the exact same problems as multi-threaded code.
Threads do have their place--whenever you need concurrency and a large amount of data needs to be shared, go with them. But saying that you should use them when you have largely independent tasks which don't share data is silly. That's exactly what processes are for, and you eliminate any risk of threads stomping on each other. If you need to have thousands of them, maybe you should look into threads, but it would probably be best to check your algorithm. Any time you think you need huge numbers of processes or threads, you'd best think again. Context switches are going to kill whether you're using threads or processes.
Programming threads is just as hard as programming with processes on a conceptual level. The type of problems you encounter are the same.
This makes it sound as if the two models have equivalent obstacles, and that neither is easier than the other. It's true that separate processes are used for stability reasons, but that stability isn't gained only because one process can crash without taking all other processes with it. The main problem with threads that doesn't exist with processes is with shared memory. All variables on the heap can potentially be accessed by two threads at any given time, and access to them must be synchronized. Bugs related to these race conditions can be very hard to track down, and many people would rather forego the problem entirely and just use processes.
Re:Yes, but he's the essence of the /. user
on
Coder or Architect?
·
· Score: 1
Mod this guy up! A post on Slashdot that actually changed my opinion...imagine that!
Fully compiled? Servlets? C#? Apparently you've never heard about this thing called "byte-code". It's definitely not fully compiled. Perl doesn't have to be spaghetti, either. Read the article. If you know how to use Perl 5's OO features and ensure that you (and everyone you devlop with) always use them, you can stay on top of things. Not to mention the advantage you get from using a higher-level language.
I've never actually had *any* problems getting Tomcat installed. Perhaps it's just that I'm a Java developer and have most of the requisite libraries already installed? I don't know. Either way, I definitely agree with you on the ~username issue. Since I'm not a Tomcat developer I can't say I know with certainty why that hasn't been implemented, but I'll bet it has a whole lot to do with portability. It's Java's wonderful super-duper feature that just never really works out right. As far as I know, there is no way to get an arbitrary user's home directory in Java. The home of the user that's running the java process is available in the system propery "user.home" but that's the only one you can have access to without using native calls, which Tomcat has avoided completely, I believe. I guess you could also parse/etc/passwd directly, but again, it impedes portability.
I'd rather sacrifice portability for usability, but that's not the dominant ethos among most Java coders.
I completely agree that J2EE is a big stinkin' mess, but it's what managers want and are willing to pay big $$ for. WebLogic licenses run over $10k per CPU, and I'm sure Lutris smells some of that cash. Sure, they could continue to sell a superior product, but if it's a product that no one wants to buy, what's the point? You've got to listen to your customers.
The VM was not fundamentally design with objects and message passing in mind? For one, I don't know what you mean by VM. I'm guessing "virtual machine," but if you knew anything about LISP, you'd know that there's no requirement of a virtual machine. Some LISP's use them, but most don't. Many are fully compiled.
Your point that the "VM" wasn't designed with message passing in mind is completely correct. However, it's pretty easy to write message passing objects in LISP. The CLOS is written in LISP and is a more general object model than that possessed by Smalltalk. LISP isn't fundamentally designed with objects in mind--it's designed around more general principles in which many other paradigms can be implemented.
Startup time is almost negligible if you do it frequently? I'm afraid that's a load of hogwash. Yes, it's faster than the first time, but it's still unbelievably slow. Check out the Hello World benchmark in Bagley's language shootout. It just runs a hello world program in each language from a shell script to measure the relative startup times of languages. Java comes in dead last because it's startup time is pathetic.
Re:Some Annoying Features of Ruby
on
Why not Ruby?
·
· Score: 1
I often try to split at operators (+, =, etc.) and put the operator at the beginning of the continuation line.
Then put the operator at the end of the line. In this sense, Ruby is reminiscent of Python--the language dictates style.
Though it would certainly be hard to make changes to the behavior of strings, every problem you mention (with the exception of native floats) is really just a library problem, and could easily be fixed when the time comes. If those particular annoyances are what would keep you from using the language, then by all means, fix the annoyances! This isn't Java, where opinions only count when coupled with deep pockets.
Re:because you are ignorant?
on
Why not Ruby?
·
· Score: 1
You're understanding is lacking in that you think an iterator is an object in Ruby. It's actually a method that can invoke a block of code. In other words, it's a higher-order function. The only stumbling area is that Ruby makes it easy to pass a single block to a method, but not quite as simple to pass multiple blocks. In practice, this really isn't too much of a problem, however. If you absolutely must pass several functions to a method, you can convert blocks to procedure objects and pass them quite easily.
An example from page 15 of "Programming Ruby":
a = %w( ant bee cat dog elk )
a.each { |animal| puts animal }
prints out the 5 animals names. The following pseudo code shows how the each method could be implemented in class Array:
def each
for each element
yield(element)
end
end
The yield call invokes the block, using it as a higher-order function.
Ditto this. We have three 420R's and one 220R and they've had a bad serial port (had to replace the motherboard!), bad CPU's (the dreaded cache problem), bad RAM, it's been one thing after another. We have over 30 PCs, and the only problem we've had with them has been one bad serial port knocked out by static and my power supply fan started making a lot of noise. Other than that, nothing. I don't think very highly of Sun's hardware anymore. It used to be good. Not anymore.
Yes, it really isn't possible to define mathematically whether an algorithm will generate "true" random numbers. However, if that algorithm uses sources of entropy which are believed to be "true," like quantum mechanics, then you can feel pretty good about it. But since the physics doesn't necessarily describe the universe correctly (you can't open the watch), you can't be sure. If quantum mechanics were deterministic, it sure would change a lot of things, though...
Actually, capabilities aren't implemented in the filesystem yet, so you have to have root privilege in the first place to fiddle with capabilities, and in that case you are removing privilege, not elevating it. Root has to run sucap or capexec and specify the privileges he wants. Thus, the need for suid programs hasn't gone away, just the need for most daemons to run with full root permission when started by root, like in system boot scripts.
The problems you mention will exist when capability support is added to the filesystem, however.
Perhaps the universe has always existed and always will exist...perhaps it's just oscillating from singularity to big bang back to singularity, then another big bang, etc. etc. etc. Why not just say that the universe was not created, there is no God, and remove one extra layer of complication?
This argument really could go either way, depending on the size of the system in question. If it's small enough that you actually can understand almost all of it, then a rewrite will probably be superior to the first implementation. However, you're definitely right in asserting that a rewrite of something you don't really understand will turn out to be just as crummy as the original, but that's because you didn't really learn the subtleties of the problem space from the original. Rewriting something small can be a winning situation, but bigger systems will almost always be a nightmare. I think Netscape 6 would be a good example. Sure, it's finally getting good, what, 2 years after the rewrite began?
XSLT just plains blows. Why translate an XML document to another XML document or an HTML document when you can just use CSS to specify how the original document should be displayed? I can understand using XSLT if you really *want* to translate from one document type to another, but it sucks for display. The only real reason to use it is if you have to deal with clients that can't display XML, so you convert to HTML.
CSS actually makes sense--just describe how you want your tags to be rendered and off you go. Semantic content and presentation are completely separated, and simply. If browsers actually *supported* it instead of wasting all their time half-implementing crappy ideas like XSLT, web developers could finally get something done...
Slashdot Mirror
I'm really excited about this language. They're going to give an honest shot at making a lisp that will have more general appeal (read the part about onions: they're taking the "onions" out of common lisp), yet still maintain the raw power of macros. It should be very exciting.
Also, I believe with C# the foo.size++ above actually works with getters and setters, not just public member variables. It's a shortened syntax which does improve readability, but doesn't do a whole lot for understanding, IMHO.
If you're writing free software, you've got a bit more of a challenge, but I'd argue that you might as well just put a #!/bin/bash at the top of your script. If you're writing free software, it's pretty safe to assume that the person installing it will have bash...
Everything you're saying makes sense on a system where processes really are heavyweight monsters. On Linux, processes and threads are much more similar. The difference is copy-on-write semantics for memory pages. Up until you actually modify a page, it is shared by child and parent. This means that using processes instead of threads doesn't automatically mean that you're grossly increasing memory needs.
Threads do have their place--whenever you need concurrency and a large amount of data needs to be shared, go with them. But saying that you should use them when you have largely independent tasks which don't share data is silly. That's exactly what processes are for, and you eliminate any risk of threads stomping on each other. If you need to have thousands of them, maybe you should look into threads, but it would probably be best to check your algorithm. Any time you think you need huge numbers of processes or threads, you'd best think again. Context switches are going to kill whether you're using threads or processes.
This makes it sound as if the two models have equivalent obstacles, and that neither is easier than the other. It's true that separate processes are used for stability reasons, but that stability isn't gained only because one process can crash without taking all other processes with it. The main problem with threads that doesn't exist with processes is with shared memory. All variables on the heap can potentially be accessed by two threads at any given time, and access to them must be synchronized. Bugs related to these race conditions can be very hard to track down, and many people would rather forego the problem entirely and just use processes.
Mod this guy up! A post on Slashdot that actually changed my opinion...imagine that!
Fully compiled? Servlets? C#? Apparently you've never heard about this thing called "byte-code". It's definitely not fully compiled. Perl doesn't have to be spaghetti, either. Read the article. If you know how to use Perl 5's OO features and ensure that you (and everyone you devlop with) always use them, you can stay on top of things. Not to mention the advantage you get from using a higher-level language.
You know you've been watching way too much Stars Wars when you start talking like Yoda.
Oops! I retract this statement.
This isn't SMP, either. It's a NUMA architecture.
I'm surprised you didn't realize that everyone else was pointing this out while you were in the process of pointing it out.
I'd rather sacrifice portability for usability, but that's not the dominant ethos among most Java coders.
I completely agree that J2EE is a big stinkin' mess, but it's what managers want and are willing to pay big $$ for. WebLogic licenses run over $10k per CPU, and I'm sure Lutris smells some of that cash. Sure, they could continue to sell a superior product, but if it's a product that no one wants to buy, what's the point? You've got to listen to your customers.
Your point that the "VM" wasn't designed with message passing in mind is completely correct. However, it's pretty easy to write message passing objects in LISP. The CLOS is written in LISP and is a more general object model than that possessed by Smalltalk. LISP isn't fundamentally designed with objects in mind--it's designed around more general principles in which many other paradigms can be implemented.
The last I heard, dump didn't work with ext2, either. It makes assumptions about the buffer (page?) cache that are no longer valid.
Startup time is almost negligible if you do it frequently? I'm afraid that's a load of hogwash. Yes, it's faster than the first time, but it's still unbelievably slow. Check out the Hello World benchmark in Bagley's language shootout. It just runs a hello world program in each language from a shell script to measure the relative startup times of languages. Java comes in dead last because it's startup time is pathetic.
Then put the operator at the end of the line. In this sense, Ruby is reminiscent of Python--the language dictates style.
Though it would certainly be hard to make changes to the behavior of strings, every problem you mention (with the exception of native floats) is really just a library problem, and could easily be fixed when the time comes. If those particular annoyances are what would keep you from using the language, then by all means, fix the annoyances! This isn't Java, where opinions only count when coupled with deep pockets.
An example from page 15 of "Programming Ruby":
a = %w( ant bee cat dog elk )
a.each { |animal| puts animal }
prints out the 5 animals names. The following pseudo code shows how the each method could be implemented in class Array:
def each
for each element
yield(element)
end
end
The yield call invokes the block, using it as a higher-order function.
I hope this clears up any confusion.
Ditto this. We have three 420R's and one 220R and they've had a bad serial port (had to replace the motherboard!), bad CPU's (the dreaded cache problem), bad RAM, it's been one thing after another. We have over 30 PCs, and the only problem we've had with them has been one bad serial port knocked out by static and my power supply fan started making a lot of noise. Other than that, nothing. I don't think very highly of Sun's hardware anymore. It used to be good. Not anymore.
Yes, it really isn't possible to define mathematically whether an algorithm will generate "true" random numbers. However, if that algorithm uses sources of entropy which are believed to be "true," like quantum mechanics, then you can feel pretty good about it. But since the physics doesn't necessarily describe the universe correctly (you can't open the watch), you can't be sure. If quantum mechanics were deterministic, it sure would change a lot of things, though...
The problems you mention will exist when capability support is added to the filesystem, however.
Perhaps the universe has always existed and always will exist...perhaps it's just oscillating from singularity to big bang back to singularity, then another big bang, etc. etc. etc. Why not just say that the universe was not created, there is no God, and remove one extra layer of complication?
This argument really could go either way, depending on the size of the system in question. If it's small enough that you actually can understand almost all of it, then a rewrite will probably be superior to the first implementation. However, you're definitely right in asserting that a rewrite of something you don't really understand will turn out to be just as crummy as the original, but that's because you didn't really learn the subtleties of the problem space from the original. Rewriting something small can be a winning situation, but bigger systems will almost always be a nightmare. I think Netscape 6 would be a good example. Sure, it's finally getting good, what, 2 years after the rewrite began?
CSS actually makes sense--just describe how you want your tags to be rendered and off you go. Semantic content and presentation are completely separated, and simply. If browsers actually *supported* it instead of wasting all their time half-implementing crappy ideas like XSLT, web developers could finally get something done...