.Net
arlie
There saying that .Net is the future. Is this true? Will this be the
end of Tcl/Tk?
Regards,
Arlie
Neil Madden
Yes! The end is nigh! (Again!)
-- Neil
Darren New
.NET and Tcl are orthogonal. Even if .NET replaced everything else, Tcl
would still be around, just like C# and VB.NET would.
--
Darren New / San Diego, CA, USA (PST)
New horror show, now only in Las Vegas:
HANNIBAL LUXOR!
Gerald W. Lester
Stop drinking the cool aid -- ADA is the future and will replace everything
else (the DOD said so back in the 80s).
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Shin
your way.
But mabe there is no "your way"?
Now I feel better :)
Shin
Darren New
> dotNET is just a layer over your machine, keeping you from using it
> your way.
Actually, .NET lets you use it your way whenever you want. Invoking
native system calls is quite built-in to the language, even easier than
using Tcl. One of the many things done right, I must say. ;-)
Shin
> Shin wrote:
> > dotNET is just a layer over your machine, keeping you from using it
> > your way.
>
> Actually, .NET lets you use it your way whenever you want. Invoking
> native system calls is quite built-in to the language, even easier than
> using Tcl. One of the many things done right, I must say. ;-)
>
Ok, ok, just an attempt :)
When will we see Tcl/Tk coded in C#, running on let's say "Mono"?
Shin
Michael Schlenker
Tom Poindexter
It's been done:
http://wiki.tcl.tk/tclcsharp
--
Tom Poindexter
tpoi...@nyx.net
arlie
> In article <1171483722.384791.149...@k78g2000cwa.googlegroups.com>,
Is this for real or just icing on the cake. Will this be maintained?
Will this be updated to support Tcl/Tk 8.5/9 features because this
very promising.
Regards,
Arlie
Artur
>
> > --
> > Tom Poindexter
> > tpoin...@nyx.net
>
> Is this for real or just icing on the cake. Will this be maintained?
> Will this be updated to support Tcl/Tk 8.5/9 features because this
> very promising.
>
> Regards,
>
> Arlie
No. I do not maintain it any more. It was only one time experiment for
me.
The main reason is poor performance (10-20 time slower than c coded
Tcl-Interpreter).
The second reason is lack of another c-coded Tcl extensions (Tk,
XOTcl),
so it is not usable for most Tcl projects.
I think it is more practicable to integrated standard Tcl interpreter
with .NET
per com or interop.
The right thing which should be done were to use special technics to
improve
performance like IronPython it do (using of .NET bytecodes and just-in-
time compiler)
But it is really hard job. For Tcl and its lazy compilation it could
be even more
complicated.
The next version of C# will have some features, that will make Tcl not
so interesting:
Lambda expression (Blocks) or dynamic typed variables.
There are also a bundle of script languages for .NET (Python,
JavaScript, F# (CALM) available now so I do not think, that it is a
need to have Tcl in .NET or a chance that Tcl will become
scripting killer app for .NET.
See also
http://axn.dyndns.org/tcl/tclconf/at.pdf
Artur
Donal K. Fellows
> The main reason is poor performance (10-20 time slower than c coded
> Tcl-Interpreter).
So it is actually similar in performance to the classic (pre-8)
interpreter? That's actually pretty good. Doing better than that
requires deep voodoo anyway, speaking as one of the maintainers of the
C bytecode engine. :-)
> The second reason is lack of another c-coded Tcl extensions (Tk,
> XOTcl), so it is not usable for most Tcl projects.
That's a more pertinant point. The biggest problem with porting to a
new fundamental platform is always getting the libraries transferred
too. It's probably easier to use a bridge to the .NET stuff to access
its native GUI libs, which is (IIRC) how GUIs are done with Jacl.
Donal.
Volker Hetzer
You just have to stop thinking that .NET is C#.
.NET is C++/CLI too, the primary strength being that C++ Interop (i.e. working
with native dlls) just works.
Also, for the high-performance stuff there's #pragma unmanaged, where parts
of he code get compiled into native code.
OTOH, with two extensions Tcl could go a long way towards .NET integration:
- It should be possible to integrate .NET assemblies as Packages (maybe a
third loading mechanism apart from source and load is required?)
- It should be possible for a .NET app to call packages (The package needs to
be an object then but Interop would be not a problem since COM interop works
too.)
Lots of Greetings!
Volker
--
For email replies, please substitute the obvious.
Larry W. Virden
> There is a rumor going around that .Net will replaced everything else.
> There saying that .Net is the future.
Nah - there's this rumor going on that the world is going to end this
week, so .net won't have a chance to become the future...
Seriously, there are millions of rumors. Any time you hear a rumor
that "this or that" is going to be happening wide scale in computers,
you can pretty much expect that isn't going to be the case.
Also, another useful practice is to look up what something is. Since
www.microsoft.com defines .net as "the microsoft web serfvices
strategy to connection information", then right away we can see that
it couldn't replace everything else - everything isn't web, and
everything isn't microsoft.
Certainly there are "knock offs" designed to allow non-microsoft
machines to talk to microsoft's .net. However, all of that will "come
to pass" as they say.
Things will move on, the next big fad will come along, and people will
forget that .net ever existed.
arlie
serious projects. Because I'm now starting to develop an Inventory
System using Tcl/Tk.
Would anyone advise me against it?
Your Replies here would be my basis for a GO or NO GO with my current
project using Tcl/Tk.
Regards,
Carlos "Arlie"
Robert Heller
>
> So, would anyone conclude that it's a bad idea to use Tcl/Tk now for
> serious projects. Because I'm now starting to develop an Inventory
> System using Tcl/Tk.
>
> Would anyone advise me against it?
NO! I would not advise you against it. In many ways the whole .Net
business is just a form a M$ FUD. The rumors that 'everything will be
replaced by .Net' is mostly wishfull thinking on M$ part. It is NOT
going to happen. Just as Java is not completely replacing all other
programming languages, just as Ada never completely replaced other
programming languages, just as Pascal did not replace other programming
languages... .Net is just the latest 'buz-word' -- it too shall pass...
>
> Your Replies here would be my basis for a GO or NO GO with my current
> project using Tcl/Tk.
>
> Regards,
>
> Carlos "Arlie"
>
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
Shin
> So, would anyone conclude that it's a bad idea to use Tcl/Tk now for
> serious projects. Because I'm now starting to develop an Inventory
> System using Tcl/Tk.
>
> Would anyone advise me against it?
>
system programs, glued together to perform a complex job, Tcl/Tk might
be number 1 on Linux, BSD etc.. - But if your program is mainly made
from scratch, using available system objects in an OO manner, dotNET
should be in the first row on Linux, BSD *AND* Windows.
Shin
Gerald W. Lester
> So, would anyone conclude that it's a bad idea to use Tcl/Tk now for
> serious projects. Because I'm now starting to develop an Inventory
> System using Tcl/Tk.
>
> Would anyone advise me against it?
If you want to build a system that is stable with a 5+ year life expectancy
then I would strongly advise that Tcl/Tk is the way to go -- particularly if
it the system is multi-platform.
But, before you pick your tools you need to answer a lot of questions on the
architecture and the design -- question which are language independent.
Questions such as (just a sample):
- How many tiers?
- Single or multi-platform?
- Any public APIs for import/export/exchange of data or services?
- What are the Use Cases?
- What is the Activity Model?
- What is the Object/Module Model?
- etc, etc, etc
Your design models should be pretty much the same regardless of language --
have you done these yet (if not then worrying about implementation details
like the language is putting the horse before the cart)?
suchenwi
> Your design models should be pretty much the same regardless of language --
> have you done these yet (if not then worrying about implementation details
> like the language is putting the horse before the cart)?
Isn't that a good place for it? :^)
Larry W. Virden
It would be, in my opinion, a bad idea only if you were writing for a
shop which required you to use .Net/C# or whatever exclusively.
If you have the freedom to select the language, and particularly if
you need to get something done quickly and for it to run cross-
platform, then at the very least, write the first version in Tcl/Tk
and then, if other political factors require .Net, then determine at
that time whether you need to rewrite the program (using everything
you've learned to write a better program) or to try to convince
someone to support some sort of Tcl/Tk to .Net bridge.
Bryan Oakley
> So, would anyone conclude that it's a bad idea to use Tcl/Tk now for
> serious projects. Because I'm now starting to develop an Inventory
> System using Tcl/Tk.
>
> Would anyone advise me against it?
>
Not in this group :-)
Tck/Tk is perfect for many, many, many tasks. Whether it's perfect for
your task is up to you. Tcl/Tk isn't going away and .net is not taking
over the world.
Some questions you need to answer for yourself are: do your and your
team know Tcl/Tk? Do you know .net? Will you ever need to support any
platform besides windows? Do you prefer stability and a long track
record, or bleeding edge technologies? Do you like being locked in to a
single vendor or do you like working with open source tools?
Don't let .net hype be the deciding factor. Decide what your strengths
are and whether the tool you choose can do the job or not. Most likely,
Tcl can do the job you need it to to, but that alone isn't enough to
decide to use it.
--
Bryan Oakley
http://www.tclscripting.com
Darren New
> NO! I would not advise you against it. In many ways the whole .Net
> business is just a form a M$ FUD. The rumors that 'everything will be
> replaced by .Net' is mostly wishfull thinking on M$ part.
It might happen for *Microsoft* software. That doesn't mean you have to
write code the same as Microsoft does. Remember too that Microsoft makes
their money from upgrades. I'm sure there's already a date set after
which anything you write today using MS's .NET will no longer work and
will need to be rewritten in a different system. In contrast, Tcl just
keeps getting better without breaking.
arlie
> arlie wrote:
> > So, would anyone conclude that it's a bad idea to use Tcl/Tk now for
> > serious projects. Because I'm now starting to develop an Inventory
> > System using Tcl/Tk.
>
> > Would anyone advise me against it?
>
> If you want to build a system that is stable with a 5+ year life expectancy
> then I would strongly advise that Tcl/Tk is the way to go -- particularly if
> it the system is multi-platform.
>
> But, before you pick your tools you need to answer a lot of questions on the
> architecture and the design -- question which are language independent.
> Questions such as (just a sample):
> - How many tiers?
> - Single or multi-platform?
MS Windows and Linux
> - Any public APIs for import/export/exchange of data or services?
None so far
> - What are the Use Cases?
Production/Inventory (did i understand it right?)
> - What is the Activity Model?
Please explain. I'm not familiar with this.
> - What is the Object/Module Model?
Please explain. I'm not familiar with this.
arlie
> arlie wrote:
> > So, would anyone conclude that it's a bad idea to use Tcl/Tk now for
>> > serious projects. Because I'm now starting to develop an Inventory
> > System using Tcl/Tk.
>
> > Would anyone advise me against it?
>
> Not in this group :-)
>
> Tck/Tk is perfect for many, many, many tasks. Whether it's perfect for
> your task is up to you. Tcl/Tk isn't going away and .net is not taking
> over the world.
>
> Some questions you need to answer for yourself are:
>do your and your team know Tcl/Tk?
I'm on my own here.
>Do you know .net?
NO!
>Will you ever need to support any platform besides windows?
Yes. Linux
>Do you prefer stability and a long track record, or bleeding edge technologies? Do you like being locked in to a
> single vendor or do you like working with open source tools?
Of course!
arlie
I still like Tcl's flexibility even though the langauge syntax is
awkward and archaic. I also like OO but 8.5 promised to incorporate
OOP but if it's not enough I still have snit,stooop, xotcl, itcl as
fallback.
I'm just scared that as soon as my project is done dotNet will take
over the world and I'll be jailed for using Tcl/Tk.
What really I mean is that I used to program in MS-DOS Clipper and as
soon as ms windows programming became popular nobody wanted my program
anymore even though it was working fine.
My entire life work at that time went down the drain and it was my
only source of income. Lucky for me I was able to catch up and started
getting back some my clients but it was a bloody and an up hill climb.
I also like open source very much and this group/forum is really good.
Uwe Klein
> I still like Tcl's flexibility even though the langauge syntax is
> awkward and archaic.
archaic? its ageless, always young.
uwe
Gerald W. Lester
> On Feb 15, 2:19 pm, "Gerald W. Lester" <Gerald.Les...@cox.net> wrote:
>> arlie wrote:
>>> So, would anyone conclude that it's a bad idea to use Tcl/Tk now for
>>> serious projects. Because I'm now starting to develop an Inventory
>>> System using Tcl/Tk.
>>> Would anyone advise me against it?
>> If you want to build a system that is stable with a 5+ year life expectancy
>> then I would strongly advise that Tcl/Tk is the way to go -- particularly if
>> it the system is multi-platform.
>>
>> But, before you pick your tools you need to answer a lot of questions on the
>> architecture and the design -- question which are language independent.
>> Questions such as (just a sample):
>> - How many tiers?
> Can Tcl/Tk support multi-tier?
Yes, well before Java did (did you ever hear of AOL)?
2-tier (i.e. client-server, is rather normal -- at least for me).
N-tier is doable, how you do it depends on what the needs are -- but it
always cost the client more in infrastructure and support than 2-tier. So
if it is not needed, I'd recommend against it (regardless of language).
>> - Single or multi-platform?
> MS Windows and Linux
Good indication for Tcl/Tk -- although other approaches are possible.
>> - Any public APIs for import/export/exchange of data or services?
> None so far
The next three items are design models, and IMHO should be done before
picking out tools (like a language) to implement with).
>> - What are the Use Cases?
> Production/Inventory (did i understand it right?
>
>> - What is the Activity Model?
> Please explain. I'm not familiar with this.
>
>> - What is the Object/Module Model?
> Please explain. I'm not familiar with this.
>
--
Bryan Oakley
> On Feb 15, 2:00 pm, "Shin" <t...@tcltalk.ath.cx> wrote:
>> On Feb 15, 2:16 pm, "arlie" <arli...@gmail.com> wrote:> So, would anyone conclude that it's a bad idea to use Tcl/Tk now for
>>> serious projects. Because I'm now starting to develop an Inventory
>>> System using Tcl/Tk.
>>> Would anyone advise me against it?
>> IMO it depends on the platform. If your project is mainly made of
>> system programs, glued together to perform a complex job, Tcl/Tk might
>> be number 1 on Linux, BSD etc.. - But if your program is mainly made
>> from scratch, using available system objects in an OO manner, dotNET
>> should be in the first row on Linux, BSD *AND* Windows.
>>
>> Shin
>
> I still like Tcl's flexibility even though the langauge syntax is
> awkward and archaic.
You need to do a better job spell-checking your posts; I'm sure you
meant to say "flexible and forward-thinking". :-)
Robert Heller
>
> On Feb 15, 2:00 pm, "Shin" <t...@tcltalk.ath.cx> wrote:
> > On Feb 15, 2:16 pm, "arlie" <arli...@gmail.com> wrote:> So, would anyone conclude that it's a bad idea to use Tcl/Tk now for
> > > serious projects. Because I'm now starting to develop an Inventory
> > > System using Tcl/Tk.
> >
> > > Would anyone advise me against it?
> >
> > IMO it depends on the platform. If your project is mainly made of
> > system programs, glued together to perform a complex job, Tcl/Tk might
> > be number 1 on Linux, BSD etc.. - But if your program is mainly made
> > from scratch, using available system objects in an OO manner, dotNET
> > should be in the first row on Linux, BSD *AND* Windows.
> >
> > Shin
>
> I still like Tcl's flexibility even though the langauge syntax is
> awkward and archaic. I also like OO but 8.5 promised to incorporate
> OOP but if it's not enough I still have snit,stooop, xotcl, itcl as
> fallback.
>
> I'm just scared that as soon as my project is done dotNet will take
> over the world and I'll be jailed for using Tcl/Tk.
I would not worry too much about this. .Net is not any more likly to
become the be-all-end-all platform than Java was. Yes, right now
Microsoft is 'pushing' .Net and .Net is the current buzword, at least in
some circles. This is not likely to last. Buzwords are like teenage
fashions -- they change with great speed and frequency.
>
> What really I mean is that I used to program in MS-DOS Clipper and as
> soon as ms windows programming became popular nobody wanted my program
> anymore even though it was working fine.
>
> My entire life work at that time went down the drain and it was my
> only source of income. Lucky for me I was able to catch up and started
> getting back some my clients but it was a bloody and an up hill climb.
>
> I also like open source very much and this group/forum is really good.
Tclkits and StarPacks are a good thing. It is possible to do all of
your coding in Tcl/Tk and (cross-)build StarPacks for MS-Windows.
Your clients will get MS-Windows .exe files are will likely not care
what the source language is/was.
As much as Microsoft says everything should be in .Net, not all that
much of Microsoft's application code is in a .Net framework.
Net is not likely to *ever* 'take over' in the Linux/UNIX world.
Darren New
> I'd be shocked if that were to happen.
I understand large parts of Vista are (or were to be) in .NET.
> I just don't see Microsoft Office or Sql Server being rewritten in
> ".Net" -- I see them being modified, if and where required, to work with
> .Net, but not a rewrite in something like C#.
C# != .NET. "Managed C++" is already .NET.
Sql Server already supports stored procedures written in .NET languages,
so that part's already done. I would be surprised if MS Office isn't
also doing something like that now. That's kind of what I was saying
about .NET, that it easily interfaces to other systems (at least on
Windows) without living in a world of its own, much like Tcl easily
interfaces to C.
Gerald W. Lester
> Gerald W. Lester wrote:
>> I'd be shocked if that were to happen.
>
> I understand large parts of Vista are (or were to be) in .NET.
>
>> I just don't see Microsoft Office or Sql Server being rewritten in
>> ".Net" -- I see them being modified, if and where required, to work
>> with .Net, but not a rewrite in something like C#.
>
> C# != .NET. "Managed C++" is already .NET.
>
> Sql Server already supports stored procedures written in .NET languages,
> so that part's already done. I would be surprised if MS Office isn't
> also doing something like that now. That's kind of what I was saying
> about .NET, that it easily interfaces to other systems (at least on
> Windows) without living in a world of its own, much like Tcl easily
> interfaces to C.
I understand, but the original poster seemed to be asking about "writing in
.NET" -- which most of us took to mean C#.
Tcl can already communicate with ".NET" applications in a number of ways,
including TclBridge and Web Services.
The problem is that ".NET" as it was being used is too loosely defined --
Sql Server works with .NET code and can be called by it, but it is not
"written in .NET".
arlie
a breath of fresh air for me. At least I beginning to get a clear
picture of what to expect.
Anyway, has anyone here tried programming in C#? Is it as easy to
program like Tcl and Tk? I'm just really curious since my friends here
are somewhat intrigue with C#.
Is it good for Tcl/Tk to have some .Net API/plugin or whatever you
call it?
Darren New
> Anyway, has anyone here tried programming in C#? Is it as easy to
> program like Tcl and Tk? I'm just really curious since my friends here
> are somewhat intrigue with C#.
It depends what you're trying to do, really. For console programs, C# is
nice. If you're familiar with Java, think of C# as "Java done right".
It's not too bad for GUI programs, except you wind up using a lot of
tools to do your layout. For web-based projects, you're pretty far from
the metal, so as long as you want it to look like Microsoft thinks it
should, you are OK. Go beyond or to something somewhat more
sophisticated interaction-wise, and it's a huge load of work to figure
out how to get around the "convenience" functionality.
There are definitely things in C# that make it good for huge long-life
projects, and it's worth learning about. It also has a giant library you
pretty well need to learn to do anything. It's a giant improvement on
Java, but it isn't anywhere near what you'd call a scripting language.
Most anything you could do in Tcl, you could do in ten times as much C#,
but you could do it.
Larry W. Virden
>
> What really I mean is that I used to program in MS-DOS Clipper and as
> soon as ms windows programming became popular nobody wanted my program
> anymore even though it was working fine.
1. Does Microsoft tell you what they used to program Word? Powerpoint?
I don't recall ever seeing that. Certainly Oracle, etc. don't
advertise what they are using to program their products.
So, rule of thumb 1 - don't tell them what you are using. Just show
them the finished product. If it is good enough, it doesn't matter.
2. What is Tcl? It is a C/C++/FORTRAN/Java/whatever development
library. Really! So figure out what language is acceptable, and if you
have to drop down to a lower level language to write a bit of code for
the application, then do so. Shrug. If for some reason they have to
hear what language things are written in, then let them know that
their favorite buzzword is in there.
3. Did your customers have a problem with the previous program because
it was clipper, or because it was a language no longer being
supported, or because it was a language whose look and feel was
drastically different than other applications? If it really was the
first, then one alternative is to get smarter customers! If it is the
second problem, then Tcl is open source - you can fix whatever needs
fixed, and in all likelihood, unless the internet collapses from all
the people asking if tcl is dying, there will always be others writing
tcl code. If it is the third problem, that is a touchy situation,
because even with the upcoming Tcl 8.5, the look and feel of your
application probably won't look like all the other apps on the
people's desktop - that's going to be true no matter WHAT language you
use. Because, frankly, on Linux there is no one look and feel. So
depending on what the user is using, the look and feel will differ
from tool to tool.
Volker Hetzer
> So, would anyone conclude that it's a bad idea to use Tcl/Tk now for
> serious projects. Because I'm now starting to develop an Inventory
> System using Tcl/Tk.
>
> Would anyone advise me against it?
1) It's a great language with lots of features that make it easy to use and
deploy.
2) .NET is not ant will not be the only means to develop applications for
windows. Or do you seriously expect a .NET implemented Word or Excel
anytime soon? the XML Notepad is slow enough and that's a simple app.
3) IMHO you can consume .NET services using tcom.
>
> Your Replies here would be my basis for a GO or NO GO with my current
> project using Tcl/Tk.
We don't know enough to make a "definite" recommendation.
What is the application architecture anyway? If Tcl is just a client
app for a database system, I see no problem.
However, if you are implementing a server running on windows where lots of
people want to connect locally from windows, I'd think carefully whether
I'd push TCP/IP on them.
Shin
...
> I also like open source very much and this group/forum is really good.
.NET isn't really OpenSource, but Tcl/Tk and Mono are (See http://
www.mono-project.com) :)
Shin
EKB
> There is a rumor going around that .Net will replaced everything else.
> end of Tcl/Tk?
>
> Regards,
>
> Arlie
After reading this thread, I'd say my own concerns are somewhat
different:
- Will Tcl/Tk continue to work under new versions of Windows without
heroic effort, even if MS abandons the goal of backward compatability
with programs written for earlier Windows versions?
- Will customers demand the look and feel of new UI elements in MS
software like the "ribbon"? (personal reaction: blech)
Neither of these is directly about .NET, which is (as I understand
it), a VM engine (like the Java VM), a set of languages written on top
of that VM (VB.NET, C#.NET, etc.), and a set of common libraries
accessible from those languages. I am in no rush to learn .NET,
although it looks like a very powerful development platform that has
great cross-OS potential via Mono. I'm very happy with Tcl/Tk, and to
the OP would strongly suggest it as a language with a long history, a
large and useful collection of libraries, and an active and friendly
user community.
What I am not certain about is whether, at some point, developing for
Windows will mean developing in a .NET flavor, so if you don't
do .NET, you're out of luck with the most commonly-used OS in the
world. Does anyone have a sense of whether this is likely, or is this
just deranged paranoid rambling?
Darren New
> Does anyone have a sense of whether this is likely, or is this
> just deranged paranoid rambling?
One of the primary successes of Windows is due to backwards
compatibility. Releasing a version of Windows 8 that didn't support
software from Windows 7 will have the same lifespan as Plan 9 or BeOS.
Plus, Tcl is open source. If it breaks, and it's worth it, you can
change the Windows-specific parts to work properly. C++ is compatible
with .NET.
Christian Gollwitzer
> EKB wrote:
>
>> Does anyone have a sense of whether this is likely, or is this
>> just deranged paranoid rambling?
>
> One of the primary successes of Windows is due to backwards
> compatibility.
To support this argument: Consider, that you can still execute most of
the programs written for DOS 1.0 in 1980 without any modification,
without even recompiling on a today's PC.
The few ones that break do stupid things like timing in busy-wait-loops.
I once had some joke programs that produced interesting sounds on the
speaker on an 8MHz computer. Soon they were unusuable on my brand new
33MHz..
The second concern is that even though VMs like Java or .Net are useful
and can be made quite fast with JIT compiler techniques, it is
impossible/unfeasible to write a complete OS with them. Anywhere below
them there must be native machine code, and for performance reasons it
will ever be possible to compile programs to native code.
Christian
Robert Heller
>
> EKB wrote:
> > Does anyone have a sense of whether this is likely, or is this
> > just deranged paranoid rambling?
>
> One of the primary successes of Windows is due to backwards
> compatibility. Releasing a version of Windows 8 that didn't support
> software from Windows 7 will have the same lifespan as Plan 9 or BeOS.
Speaking of 'Windows 7' or 'Windows 8'. What is the *real* Windows NT
version number of Vista? I'm getting user agents in my Apache logs
with 'Windows NT 5.2' -- is this Vista? Is Vista just a minor update
from XP (which is Windows NT 5.1)?
>
> Plus, Tcl is open source. If it breaks, and it's worth it, you can
> change the Windows-specific parts to work properly. C++ is compatible
> with .NET.
>
--
Darren New
> The second concern is that even though VMs like Java or .Net are useful
> and can be made quite fast with JIT compiler techniques, it is
> impossible/unfeasible to write a complete OS with them.
It's impossible/unfeasible to write a complete OS in C as well,
especially a modern Windows-like OS. While there are languages (Ada, for
example) that allow writing fairly simple OSes without leaving the
language, this isn't really an argument against .NET being used to write
as much of the OS that C is currently used for now. If all the interface
to the OS is from the .NET runtime, such that C can't be used without
wrapping it up in managed code, then it doesn't really matter how much
of the OS is written in .NET. If (for example) the only access to the
windowing system is via a managed window object, a program that can't
talk to .NET isn't going support windows.
And .NET is just as powerful as anything else. Arguably more powerful
than C is for accessing memory and stuff like that. Don't confuse .NET
with C# if you're going to talk about writing OS kernels. You'd do parts
of the OS kernel in .NET assembler just like you do parts of the OS
kernel in native assembler. And of course the VM would have to support
things like directing interrupts where they belong, just like you need
to arrange for C programs. You can write directly to memory as easily
with .NET as you can with C code.
David Gravereaux
> There is a rumor going around that .Net will replaced everything else.
> There saying that .Net is the future. Is this true? Will this be the
> end of Tcl/Tk?
>
> Regards,
>
> Arlie
>
Flame bait requires no on-topic reply.
BTW, emacs sux, use vim instead!
--
You know what we need, Hobbes? We need an attitude. Yeah, you can't be cool
if you don't have an attitude. -- Calvin
Robert Heller
>
> Christian Gollwitzer wrote:
> > The second concern is that even though VMs like Java or .Net are useful
> > and can be made quite fast with JIT compiler techniques, it is
> > impossible/unfeasible to write a complete OS with them.
>
> It's impossible/unfeasible to write a complete OS in C as well,
> especially a modern Windows-like OS. While there are languages (Ada, for
I believe the Linux kernel is almost completely in C. There might be
very small parts in assembler.
> example) that allow writing fairly simple OSes without leaving the
> language, this isn't really an argument against .NET being used to write
> as much of the OS that C is currently used for now. If all the interface
> to the OS is from the .NET runtime, such that C can't be used without
> wrapping it up in managed code, then it doesn't really matter how much
> of the OS is written in .NET. If (for example) the only access to the
> windowing system is via a managed window object, a program that can't
> talk to .NET isn't going support windows.
>
> And .NET is just as powerful as anything else. Arguably more powerful
> than C is for accessing memory and stuff like that. Don't confuse .NET
> with C# if you're going to talk about writing OS kernels. You'd do parts
> of the OS kernel in .NET assembler just like you do parts of the OS
> kernel in native assembler. And of course the VM would have to support
> things like directing interrupts where they belong, just like you need
> to arrange for C programs. You can write directly to memory as easily
> with .NET as you can with C code.
>
--
Darren New
> I believe the Linux kernel is almost completely in C. There might be
> very small parts in assembler.
And those small parts are the part I'm talking about. Catching
interrupts, frobbing I/O ports, modifying memory maps for processes,
playing with processor registers, etc. Even accessing arbitrary memory
addresses is "undefined" in C as such. The things you'd need to do in
assembler in for a C OS is the same thing you'd need to do in assembler
for a C# OS. Given that your CLI is already written, of course.
I suppose getting the CLI started up in the first place is more complex
than getting raw C set up, but modulo that initial
boot-up-the-interpreter, I can't think of anything you can't do in .NET
that you can do in C. Can you?
Gerald W. Lester
> Robert Heller wrote:
>> I believe the Linux kernel is almost completely in C. There might be
>> very small parts in assembler.
>
> And those small parts are the part I'm talking about. Catching
> interrupts, frobbing I/O ports, modifying memory maps for processes,
> playing with processor registers, etc. Even accessing arbitrary memory
> addresses is "undefined" in C as such. The things you'd need to do in
> assembler in for a C OS is the same thing you'd need to do in assembler
> for a C# OS. Given that your CLI is already written, of course.
>
> I suppose getting the CLI started up in the first place is more complex
> than getting raw C set up, but modulo that initial
> boot-up-the-interpreter, I can't think of anything you can't do in .NET
> that you can do in C. Can you?
>
Now Bliss or Mary could do those things, but they never caught on widely enough.
Larry W. Virden
> - Will Tcl/Tk continue to work under new versions of Windows without
> heroic effort, even if MS abandons the goal of backward compatability
> with programs written for earlier Windows versions?
You have to understand this - the reason that tcl/tk runs on windows
isn't because the tcl team was feeling generous and thought that they
would give the windows community a wonderful gift.
Tcl was ported to Windows because the people doing the tcl development
were either using windows themselves, or were developing software for
customers on windows (or both).
So, as long as people are using windows, tcl will be ported to the new
platform.
Just as the effort was made to port tcl from MacOS 9 to MacOS X, the
effort will be made to port Tcl from Vista (where it runs now) to the
successor to Vista.
As for the look and feel - as long as Microsoft provides interfaces to
developers, Tk developers will continue to work towards a native look
and feel.
EKB
Thanks for all the responses. I'll quit worrying!
arlie
They preferred GUI interface over console.
arlie
I don't really have any idea that .Net would mean C# or something
similar. I am just soliciting for info from everyone who are willing
to share it.
And the info I got is really good. Like knowing that Tcl can
communicate .Net.
Larry W. Virden
> On Feb 16, 12:00 pm, "Larry W. Virden" <lvir...@gmail.com> wrote:
> > 3. Did your customers have a problem with the previous program because
> > it was clipper, or because it was a language no longer being
> > supported, or because it was a language whose look and feel was
> > drastically different than other applications?
>
Well, you won't have that problem using Tcl/Tk. HOWEVER, you should
look around on http://wiki.tcl.tk/ and see some of the examples of
applications using Tcl/Tk 8.5 and Tile, to make certain that the look
and feel that you get with Tcl, Tk, and Ttk (the name of the Tile
extension in Tk) will meet your needs.
Lan
bauersa...@siemens.com> wrote:
> On 15 Feb., 15:19, "Gerald W. Lester" <Gerald.Les...@cox.net> wrote:
>
> > Your design models should be pretty much the same regardless of language --
> > have you done these yet (if not then worrying about implementation details
> > like the language is putting the horse before the cart)?
>
> Isn't that a good place for it? :^)
How quickly we forget when technology (horses) is outmoded.
Meaning:
You have the task of hitching a horse to a cart. To perform it, you
need to bring both out of the barn in a certain order. If you pring
the horse out first -- "put" it first -- the horse will wander away
before you get the cart. Therefore the cliche about doing things in
their proper order says that you must not "put the horse before the
cart."
Happy to help out -- no thanks necessary.
Bryan Oakley
I always herd the cliche as "don't put the cart before the horse".
http://www.phrases.org.uk/meanings/put-the-cart-before-the-horse.html
arlie
Unix? Is it suitable for developing application? Is there also C# or
something similar in Linux/Unix. Will this work with Tcl/Tk in Linux/
Unix? Do we need TclBridge or similar product to interface with it?
Darren New
> So how does mono fit into all of this? Is this .Net done in Linux/
> Unix?
Yes. It's a reimplementation of the standard. There are some differences
(like in the windowing system, as usual).
> Is it suitable for developing application? Is there also C# or
> something similar in Linux/Unix.
Yes and yes.
arlie
Will mono work with Tcl/Tk in Linux/Unix?
David Gravereaux
no. mono is a virtual framework for executing .net applications (assemblies?) in
the same way that wish is the windowing shell that interprets tcl scripts.
--
My behaviour is addictive functioning in a disease process of toxic
co-dependency. I need holistic healing and wellness before I'll accept any
responsibility for my actions. -- Calvin