having looked into doing an implementation of CallerID to add to an SPF parser -- I have come away with crossed eyes trying to work out if I'm allowed to release a BSD licensed implementation of this. I think maybe I can -- I'm pretty sure I can't release a GPL implementation though.
The VC++ toolkit is missing a number of things that are typically needed to make it usefull - no lib.exe, nmake.exe or cvtres.exe and no msvcrt.lib being the main stumbling points. Also no MFC (good) and no ATL (less good).
On the other hand you can find free (as in beer) versions of all these. The platform SDK has versions of the missing exe's in the Win64 compatability testing area and these work fine for Win32 compilation. It also has a copy of ATL 3.0 in include\win64\atl
msvcrt.lib can be obtained from the.NET Framework SDK - another free (as in beer) download.
Whilst this is a fine effort I feel that the language is over specified with 22 commands. Consider the extreme simplicity of BrainFuck or Ook! for a real programming language.
I wonder if anyone has show whitespace to be turing complete?
Now that we have TclKit and TclKit includes [incr Tcl] as standard I would say we have exactly the best of both worlds. A minimal tclsh and a generally useful tclkit.
I disagree - I _do_ feel that the object system should be an add-on. It should just be as well supported and as easily available as the core language.
What is wrong with a minimal core language?
on
Tcl Core Team Interview
·
· Score: 4, Interesting
A number of the comments above revolve around Tcl's percieved lack of a standard object system. There is one, it's called [incr Tcl]. There are also a large number of other object systems many that fit naturally into the system for which they have been designed. I see no reason to insist on incorporating any object system into the core language. Much better to keep the basics small and compact and allow extension. The now standard Tcl distribution from ActiveState supplies all the bells and whistles you might need. But if you want a minimal system, you need go no further than the tcl sourceforge project and obtain just the language core.
I would favour making the language more modular. Not less. Get the TCP sockets out into a loadable module. Chop out the regexp engine. This way if your intention is to drive a washing machine without internet access, you can use only the pieces you need. I've yet to meet another language that is as easy to extend with compiled modules as Tcl.
Minimalism - it's the way forward.
That's not really correct. What they did was put in a bytecode compiler and introduce a dual-ported data type. Instead of everything being a string, everything has a string representation and an internal representation. The currently valid rep is 'shimmered' on demand. Keeping doubles/lists in their internal rep significantly speeds up operations. The bytecode compilation step introduces some overhead, but this is recouped if the compiled procedure is ever called more than one time.
I cannot really see how you could manage to have trouble getting any of activestate's offerings to fail to work under Windows. Perhaps you attempted to install the Linux binary distribution?
Anyway, I hope that ActiveState manages to continue their fine work even in the absence of their chief.
Slashdot Mirror
having looked into doing an implementation of CallerID to add to an SPF parser -- I have come away with crossed eyes trying to work out if I'm allowed to release a BSD licensed implementation of this. I think maybe I can -- I'm pretty sure I can't release a GPL implementation though.
Damn, now where did I put that lawyer....
Can you say Platform SDK?
.NET Framework SDK - another free (as in beer) download.
The VC++ toolkit is missing a number of things that are typically needed to make it usefull - no lib.exe, nmake.exe or cvtres.exe and no msvcrt.lib being the main stumbling points. Also no MFC (good) and no ATL (less good).
On the other hand you can find free (as in beer) versions of all these. The platform SDK has versions of the missing exe's in the Win64 compatability testing area and these work fine for Win32 compilation.
It also has a copy of ATL 3.0 in include\win64\atl
msvcrt.lib can be obtained from the
There are httpd's written in pretty much every language -- although I don't think BrainF*ck has been used yet. And Malbolge certainly hasn't.
>>>>>++[<++++>-]<[<++++>-]<<<<>>++++[<+++++>-]<[ <++++++>-]<-.. >+++++[<+++>+ +++>-]<.>>>.- .>+++[<--->+ .+.
>+++++[<--->-]<.+.>++++[<+++>-]<-.>+++[<----->-]<
-]<-.---.>+++++[<--->-]<.++.++.>>>.<<<++++.>++[<+
<<<>+++[<---->-]<-.>+++[<+++>-]<.+++.>>>.<<<-----
-]<--.>++++[<+++>-]<.>++[<---->-]<.>++++[<+++>-]<
Whilst this is a fine effort I feel that the language is over specified with 22 commands. Consider the extreme simplicity of BrainFuck or Ook! for a real programming language.
I wonder if anyone has show whitespace to be turing complete?
Now that we have TclKit and TclKit includes [incr Tcl] as standard I would say we have exactly the best of both worlds. A minimal tclsh and a generally useful tclkit.
I disagree - I _do_ feel that the object system should be an add-on. It should just be as well supported and as easily available as the core language.
A number of the comments above revolve around Tcl's percieved lack of a standard object system. There is one, it's called [incr Tcl]. There are also a large number of other object systems many that fit naturally into the system for which they have been designed. I see no reason to insist on incorporating any object system into the core language. Much better to keep the basics small and compact and allow extension. The now standard Tcl distribution from ActiveState supplies all the bells and whistles you might need. But if you want a minimal system, you need go no further than the tcl sourceforge project and obtain just the language core. I would favour making the language more modular. Not less. Get the TCP sockets out into a loadable module. Chop out the regexp engine. This way if your intention is to drive a washing machine without internet access, you can use only the pieces you need. I've yet to meet another language that is as easy to extend with compiled modules as Tcl. Minimalism - it's the way forward.
So you like Perl's reference syntax better? Wierd.
That's not really correct. What they did was put in a bytecode compiler and introduce a dual-ported data type. Instead of everything being a string, everything has a string representation and an internal representation. The currently valid rep is 'shimmered' on demand. Keeping doubles/lists in their internal rep significantly speeds up operations. The bytecode compilation step introduces some overhead, but this is recouped if the compiled procedure is ever called more than one time.
In short - yes, it is good.
I cannot really see how you could manage to have trouble getting any of activestate's offerings to fail to work under Windows. Perhaps you attempted to install the Linux binary distribution?
Anyway, I hope that ActiveState manages to continue their fine work even in the absence of their chief.