To tell the truth, I am familiar with the Design Patterns book, and have notions about system design.
More than anything I was curious about server side Java in particular, which you claim is more scalable because it shares memory. I'm interested in hearing some more details about this - why you think it's so and any references to back it up.
So Java's answer is just to hoover up all available memory and then share it?;-)
Interesting post though - you stipulate that the java model works because it's all one process with multiple threads that can share data? How is this scalable, say, to multiple computers? Can you point to a document that explains some of this stuff without using words like 'enterprise enabled'?
I know there are some good ideas in Java land, but there is so much marketing bullshit about how it is *the* language for everything. I can't stand that myself.
I know what it is - it was my first Linux distribution a number of years ago (painfully downloaded over a 14.4K modem). I'm curious if the code described in the release is archived somewhere, and if it still runs. It would make for a fun article, I think.
It would be interesting to hear if it still runs, and how it stacks up - "then vs now".
Re:Java is bad for our industry
on
Head First Java
·
· Score: 1
The problem with Java is that it is impossible to judge it for what it's truly worth because of the marketing dollars behind it. It's good for some things, not so good for others, but to look at the industry today, you would think that it's the only thing you could use, which can't be right.
Any competent programmer can program in a variety of languages, so I don't see why we should have just one stuffed down our throats by corporations.
Right on. It's an on-line journal which no one probably cares about anyway. Blog sounds like a comic book sound (boom, pow...) for something plopping into the water. Possibly something dead.
Maybe when the economy gets better people will have less free time to fritter away letting the world know what they think.
No kidding it's written for suits. The Economist is not a technology magazine. That said, in a brief space, they manage to impart a decent amount of information that is fairly accurate from their point of view.
I find comp.lang.tcl to be a great group to participate in. I can talk to the tcl maintainers there, get advice, discuss interesting aspects of tcl, and, since I get so much out of it, I give back where I can.
Tcl's syntax is extremely simple, although slightly more complex than, say, Lisp, in order to make the programmer's life easier.
http://www.tcl.tk/scripting/syntax.html has a good introduction to it - as you can see, anyone can figure it out in a few minutes! Definitely one of Tcl's strong points.
Tcl was designed from the ground up to be 'embedded and extended', and it shows. The core C code is well documented and easy to read, and there are man pages for all the functions in the public API. It's very easy to create little extensions without using any wierd half perl, half c languages. Tcl exposes a huge portion of its internals at the C level, which lets you do all kinds of cool stuff in your C code. It's very easy to create code where all the performance critical sections are coded in C, and then tied together with Tcl.
Bdale is a very smart guy, and has been a good leader - but he has tended to stay out of the limelight, which maybe hasn't helped him in the eye of the 'electorate'.
Hopefully, Martin will do some visible leadership, leading to real accomplishments, and not just be an "evil catbert";-)
The problem is that, to my knowledge, no one in the Debian project is really qualified (a law degree, or significant experience in the field) to make these kinds of legalistic judgements when it comes down to some of the really weird cases.
I like very much that Debian is about free software, but I am at best ambivalent about all our "legal experts".
Tcl has excellent threading support, actually, in Tcl 8.4. You need an external lib to access it from Tcl itself, but it's in the core, and it's done very well. Compare with Python's "one big mutex".
* Embedding/extending - you have access to pretty much everything. The C code is a pleasure to work with. * Unicode support. * I/O system - stacked channels. * The possibility to write 'little languages' with it - you can easily write constructs such 'if', 'for', and 'while' in Tcl itself - something you can't do in the other languages. * Abstraction - all these languages do sockets, for example, but Tcl gives you a truely 'higher level' approach to them, instead of warmed-over direct access to the C layer.
It sounds like you have more than enough experience to judge whether the language works for you - one comment though. You may not like some of the rules of the language, but... the implementation is very nice, in my opinion. It gives you all kinds of wonderful stuff at the C level. Interpreters, stacked channels, linking tcl and C variables, variable and command traces, the event loop, and on and on. It's all very nicely written, and extremely well documented C code.
Lisp is definitely a beautiful thing. On the other hand, Tcl is a very practical glue language that very readily plays nice with a lot of environments. Most importantly, it's super easy to embed and extend. From what I have seen of Lisp, it has a tendency to go off in another direction completely - it's never enough just to have lisp running, they want to go for the OS too.
I think one of the best things about Tcl is the user comunity. In reality, of course you will be able to do anything you want with any of those languages.
Tcl's user comunity makes it a very positive experience to use the language, though. Not everyone values having others to ask when they need help, but if that's important to you, Tcl's certainly not a bad choice at all.
No, Java is the new cobol - people just don't realize it yet.
In any case, some people like having a language that's flexible enough that it's possible to have an object system as an extension (Scheme is like this, for example). While there is no standard object system, there are a couple of pretty popular ones, and those who need one just pick one and get on with their lives. Incr Tcl even has a book written about it.
Actually, Tcl's C source code is some of the most beautiful I have ever seen. It is a pleasure to read and study. This is one of the reasons why it is so popular for embedding/extending.
But it's also a rewarding feeling to be making a go of it as an independant consultant. No silly dot com ideas, just getting paid for work done. It's tough, but I'm happy.
That said, I don't see the long term prospects here as being very good. It's too much of a pressure cooker.
Slashdot Mirror
Tcl/Tk does what you want, even though it's cool to put it down because it's not the latest thing.
Thanks for your answer.
To tell the truth, I am familiar with the Design Patterns book, and have notions about system design.
More than anything I was curious about server side Java in particular, which you claim is more scalable because it shares memory. I'm interested in hearing some more details about this - why you think it's so and any references to back it up.
So Java's answer is just to hoover up all available memory and then share it?;-)
Interesting post though - you stipulate that the java model works because it's all one process with multiple threads that can share data? How is this scalable, say, to multiple computers? Can you point to a document that explains some of this stuff without using words like 'enterprise enabled'?
I know there are some good ideas in Java land, but there is so much marketing bullshit about how it is *the* language for everything. I can't stand that myself.
I know what it is - it was my first Linux distribution a number of years ago (painfully downloaded over a 14.4K modem). I'm curious if the code described in the release is archived somewhere, and if it still runs. It would make for a fun article, I think.
It would be interesting to hear if it still runs, and how it stacks up - "then vs now".
The problem with Java is that it is impossible to judge it for what it's truly worth because of the marketing dollars behind it. It's good for some things, not so good for others, but to look at the industry today, you would think that it's the only thing you could use, which can't be right.
Any competent programmer can program in a variety of languages, so I don't see why we should have just one stuffed down our throats by corporations.
Right on. It's an on-line journal which no one probably cares about anyway. Blog sounds like a comic book sound (boom, pow...) for something plopping into the water. Possibly something dead.
Maybe when the economy gets better people will have less free time to fritter away letting the world know what they think.
As an aside, Tcl has a very nice sandbox that is secure and has been for a while. Check it out:-)
No kidding it's written for suits. The Economist is not a technology magazine. That said, in a brief space, they manage to impart a decent amount of information that is fairly accurate from their point of view.
If you read other Linux coverage from The Economist, it's actually quite good. They understand it, and generally have positive things to say about it.
I find comp.lang.tcl to be a great group to participate in. I can talk to the tcl maintainers there, get advice, discuss interesting aspects of tcl, and, since I get so much out of it, I give back where I can.
Tcl's syntax is extremely simple, although slightly more complex than, say, Lisp, in order to make the programmer's life easier.
http://www.tcl.tk/scripting/syntax.html has a good introduction to it - as you can see, anyone can figure it out in a few minutes! Definitely one of Tcl's strong points.
Tcl was designed from the ground up to be 'embedded and extended', and it shows. The core C code is well documented and easy to read, and there are man pages for all the functions in the public API. It's very easy to create little extensions without using any wierd half perl, half c languages. Tcl exposes a huge portion of its internals at the C level, which lets you do all kinds of cool stuff in your C code. It's very easy to create code where all the performance critical sections are coded in C, and then tied together with Tcl.
Python's C API is also pretty good.
Bdale is a very smart guy, and has been a good leader - but he has tended to stay out of the limelight, which maybe hasn't helped him in the eye of the 'electorate'.
Hopefully, Martin will do some visible leadership, leading to real accomplishments, and not just be an "evil catbert";-)
The problem is that, to my knowledge, no one in the Debian project is really qualified (a law degree, or significant experience in the field) to make these kinds of legalistic judgements when it comes down to some of the really weird cases.
I like very much that Debian is about free software, but I am at best ambivalent about all our "legal experts".
Tcl has excellent threading support, actually, in Tcl 8.4. You need an external lib to access it from Tcl itself, but it's in the core, and it's done very well. Compare with Python's "one big mutex".
Some areas where Tcl is superior:
* Embedding/extending - you have access to pretty much everything. The C code is a pleasure to work with.
* Unicode support.
* I/O system - stacked channels.
* The possibility to write 'little languages' with it - you can easily write constructs such 'if', 'for', and 'while' in Tcl itself - something you can't do in the other languages.
* Abstraction - all these languages do sockets, for example, but Tcl gives you a truely 'higher level' approach to them, instead of warmed-over direct access to the C layer.
It sounds like you have more than enough experience to judge whether the language works for you - one comment though. You may not like some of the rules of the language, but... the implementation is very nice, in my opinion. It gives you all kinds of wonderful stuff at the C level. Interpreters, stacked channels, linking tcl and C variables, variable and command traces, the event loop, and on and on. It's all very nicely written, and extremely well documented C code.
Lisp is definitely a beautiful thing. On the other hand, Tcl is a very practical glue language that very readily plays nice with a lot of environments. Most importantly, it's super easy to embed and extend. From what I have seen of Lisp, it has a tendency to go off in another direction completely - it's never enough just to have lisp running, they want to go for the OS too.
I don't use windows... but apparently the look and feel there has improved a lot from Tk's early days on that platform.
I think one of the best things about Tcl is the user comunity. In reality, of course you will be able to do anything you want with any of those languages.
Tcl's user comunity makes it a very positive experience to use the language, though. Not everyone values having others to ask when they need help, but if that's important to you, Tcl's certainly not a bad choice at all.
One of my favorites is ETLinux, written by Alessandro Rubini (author of Linux Device Drivers).
Also, a lot of Cisco routers run Tcl.
Oh, and so does AOL, with AOLserver.
No, Java is the new cobol - people just don't realize it yet.
In any case, some people like having a language that's flexible enough that it's possible to have an object system as an extension (Scheme is like this, for example). While there is no standard object system, there are a couple of pretty popular ones, and those who need one just pick one and get on with their lives. Incr Tcl even has a book written about it.
Actually, Tcl's C source code is some of the most beautiful I have ever seen. It is a pleasure to read and study. This is one of the reasons why it is so popular for embedding/extending.
You can check out an HTMLized version here:
http://tcl.apache.org/sources/tcl/
But it's also a rewarding feeling to be making a go of it as an independant consultant. No silly dot com ideas, just getting paid for work done. It's tough, but I'm happy.
That said, I don't see the long term prospects here as being very good. It's too much of a pressure cooker.