Completely OT: A look into the furture
Helmut Giese
if you have a couple of minutes for an OT reading.
Best regards
Helmut Giese
---
"But then, while you're sitting on your googlechair in the googleplex
sipping googleccinos and feeling smuggy smug smug smug, new versions
of the browsers come out that support cached, compiled JavaScript. And
suddenly NewSDK is really fast. And Paul Graham gives them another
6000 boxes of instant noodles to eat, so they stay in business another
three years perfecting things."
-- From "Strategy Letter VI"
http://www.joelonsoftware.com/items/2007/09/18.html
Arjen Markus
Very nice reading material ;). However, it gave birth to a
bizarre little idea: if you redefine the Tcl commands properly,
you might get an automatic translation of Tcl code into
JavaScript (at least syntactically, this seems possible).
I have not pursued it much further, knowing much less of
JavaScript than required for a more than half-hearted
attempt ;)), but I think it is not extremely hard - within
certain limitations ([eval] would be a problem and I know
little if anything at all about the various JavaScript/DOM
dialects.)
Regards,
Arjen
Helmut Giese
<arjen....@wldelft.nl> wrote:
>On 19 sep, 13:53, Helmut Giese <hgi...@ratiosoft.com> wrote:
>> well, maybe not exactly, but an interesting article. Hope you enjoy it
>> if you have a couple of minutes for an OT reading.
>> Best regards
>> Helmut Giese
>> ---
>> "But then, while you're sitting on your googlechair in the googleplex
>> sipping googleccinos and feeling smuggy smug smug smug, new versions
>> of the browsers come out that support cached, compiled JavaScript. And
>> suddenly NewSDK is really fast. And Paul Graham gives them another
>> 6000 boxes of instant noodles to eat, so they stay in business another
>> three years perfecting things."
>>
>> -- From "Strategy Letter VI"http://www.joelonsoftware.com/items/2007/09/18.html
>
>Very nice reading material ;). However, it gave birth to a
>bizarre little idea:
[snip]
Hi Arjen,
while I didn't have any precise idea (I know way too little about web
programming) I did have the persistent thought that a group of Tcl'ers
with interest and experience in web programming could achieve
something like what the article talks about.
Well, maybe ...
Best regards
Helmut Giese
Arjen Markus
>
> - Tekst uit oorspronkelijk bericht weergeven -
The same for me - my experience with that sort of thing
is fragmentary at best. It just seemed a feasible step :).
Regards,
Arjen
Helmut Giese
programming - not just any ol' future.
Keith Nash
> -- From "Strategy Letter VI"
> http://www.joelonsoftware.com/items/2007/09/18.html
"Moore’s Law meant that they shouldn’t think too hard about performance and
memory usage… just build cool stuff, and wait for the hardware to catch
up."
One of the things I like about Tk is that it is small and fast, and runs
well on old or constrained hardware. Seems I shouldn't care that the
KDE+Qt libraries amount to more than 20Mbytes stripped (not counting libc,
X11 etc). Soon my wristwatch will have enough CPU and memory to cope with
that.
Keith.
skuh...@web.de
Keith Nash wrote:
> One of the things I like about Tk is that it is small and fast, and runs
> well on old or constrained hardware. Seems I shouldn't care that the
> KDE+Qt libraries amount to more than 20Mbytes stripped (not counting libc,
> X11 etc). Soon my wristwatch will have enough CPU and memory to cope with
> that.
Does your wristwatch run Tcl/Tk currently? If so, I *must* have one of
those, too! ;-)
Although I agree in most parts with Joels article, this meaning of
Moores Law sometimes brings me into a melancholic mood. Today in
normal Workstation- or PC-programming there is no more value in the
ability to invent fast and resource saving algorithms. Just take one
of those bloated libraries and call think_for_me(), that's it. All the
baby programmers out there often don't even know about efficiency.
Write a full blown office suite as web-app in a convenient Lego-
language (of course in a visual click-programming-env, not by using an
editor!) which on the fly generates JavaScript which is streamed to
the client and interpreted in realtime in the web browsers scripting
engine which is written in another internal scripting language. *sigh*
Nevertheless, Joel is right and I'd love it, too, if Tcl/Tk would fit
into that gap! I don't think, there is a simple mapping between
JavaScript and Tcl. Tcl is too flexible. But maybe someone can write a
FULL Tcl/Tk-Interpreter in JavaScript? I mean, computers will soon be
fast enough to run that...
Stephan
wiede...@googlemail.com
Keith Nash wrote:
> Helmut Giese wrote:
>
> > -- From "Strategy Letter VI"
> > http://www.joelonsoftware.com/items/2007/09/18.html
>
> "Moore's Law meant that they shouldn't think too hard about performance and
> up."
>
> One of the things I like about Tk is that it is small and fast, and runs
> well on old or constrained hardware. Seems I shouldn't care that the
> KDE+Qt libraries amount to more than 20Mbytes stripped (not counting libc,
> X11 etc). Soon my wristwatch will have enough CPU and memory to cope with
> that.
Moore's Law does not apply to human brains.
>
> Keith.
uwe
davidn...@gmail.com
> Helmut Giese wrote:
> > -- From "Strategy Letter VI"
> >http://www.joelonsoftware.com/items/2007/09/18.html
>
> "Moore's Law meant that they shouldn't think too hard about performance and
> up."
>
> One of the things I like about Tk is that it is small and fast, and runs
> well on old or constrained hardware. Seems I shouldn't care that the
> KDE+Qt libraries amount to more than 20Mbytes stripped (not counting libc,
> X11 etc). Soon my wristwatch will have enough CPU and memory to cope with
> that.
There's already a version of Qt for mobile phones:
http://trolltech.com/products/qtopia
So... yeah... things are moving quickly.
John E. Perry
> ...
> Although I agree in most parts with Joels article, this meaning of
> Moores Law sometimes brings me into a melancholic mood. Today in
> normal Workstation- or PC-programming there is no more value in the
> ability to invent fast and resource saving algorithms. Just take one
> of those bloated libraries and call think_for_me(), that's it. All the
> baby programmers out there often don't even know about efficiency.
Arrgh!
I really hope you're not espousing what your words seem to be saying.
I was of a similar opinion in the '80's, but I've grown up now, and it's
clear that "efficiency" has moved from level to level as our technology
grew up.
When I was writing assembly code in the '70's for 100KHz
microprocessors, I was aggressively looking for tactical jumps to skip
over necessary, but unused (at the present instant) code so I could save
a couple of bytes. Several of these jumps could be the difference
between <4080 bytes (16 reserved for cpu use), and overflowing the
available ROM. RAM was measured in tens of dollars for tens of bytes,
and you spent weeks skimping on RAM usage, even in a laboratory
environment. My documentation was done in text files (I was more
forward-looking than most of my colleagues, who did it in pen or pencil)
and dropped on the desk of a full-time secretary, who finished it on a
formed-character typewriter.
I grudgingly moved to C in the '80's (after 5 years writing Pascal for a
no-limits NASA system), but I was already proof against the spaghetti
code habits of my colleagues -- an unexpected benefit of the Pascal
environment. But writing in C was orders of magnitude less
time-consuming (that is, more efficient) than assembly, even though it
consumed more memory, and usually more time. And all my documentation
was done in TEX, because the word processors were so awful -- they
forced you to do things that didn't look right because they didn't have
the facilities to do what you needed. I thought TEX was unbeatable, and
its output was much easier to read than courier. And TEX even flowed
the text around illustrations! I didn't have to measure boxes and
characters any more.
Now I use OpenOffice because it can look almost as good as TEX with
_much_ less work. So I spend all my time designing good algorithms
(where the _real_ benefits come from), and less or none watching memory
use. And, since I no longer have (or really need) a secretary, my
documentation looks the way I want it to look, rather than the way the
secretary thinks it should look. I've looked at TEXmacs, Kile, and Lyx,
but I don't really expect to ever use them seriously.
All of this because we've progressed from manually typing ASCII
characters to curses to X to QT and friends.
Hooray for bloated libraries! -- thanks to them, I can do a hundred and
more times the real work now than I could when I started as an engineer.
John Perry
skuh...@web.de
John E. Perry wrote:
> skuh...@web.de wrote:
> > ...
> > Although I agree in most parts with Joels article, this meaning of
> > Moores Law sometimes brings me into a melancholic mood. Today in
> > normal Workstation- or PC-programming there is no more value in the
> > ability to invent fast and resource saving algorithms. Just take one
> > of those bloated libraries and call think_for_me(), that's it. All the
> > baby programmers out there often don't even know about efficiency.
>
> Arrgh!
>
> I really hope you're not espousing what your words seem to be saying.
Well, I think, I mean, what I said. But maybe there is some difference
in the understanding of what I said...
> All of this because we've progressed from manually typing ASCII
> characters to curses to X to QT and friends.
I never said, that you should not use any libraries and use only "ed"
and assembler only, did I? If you use your tools to do the lower level
work, make your work more efficient and give you the time to focus on
the algorithms, that's a good thing and a wise decision. I'm not
against using modern tools instead of stone-age technology.
> Hooray for bloated libraries! -- thanks to them, I can do a hundred and
> more times the real work now than I could when I started as an engineer.
"I really hope you're not espousing what your words seem to be
saying." - Hooray for efficient, small and useful libraries, but no
hooray for bloated libraries. Also hooray for programmers who use the
right tools for the work, but also no hooray for programmers, who
don't have a clue, what efficiency is and never spend a thought about
it, who have no insight into algorithms, how the libraries in use
internally work (not specific knowledge, but having a clue) and so are
not able to make a competent decision, which libs to use, or where it
is appropiate to do something yourself, instead of including 50 MB of
libs for three lines of code needed...
Stephan
Fredderic
One must remember also, though, that we're no longer living in the days
where you only run one program at a time. The ability to share a
library's memory image between several applications does sometimes mean
that by bundling some extra stuff into one "bloated" library, you end
up with a net total saving. The concept of "efficiency" is indeed a
while lot more complex than it once was.
Although it does concern me just a little when the decorations on my
application windows are drawn using a theme engine written in Scheme.
Fredderic
skuh...@web.de
Fredderic wrote:
> One must remember also, though, that we're no longer living in the days
> where you only run one program at a time. The ability to share a
> library's memory image between several applications does sometimes mean
> that by bundling some extra stuff into one "bloated" library, you end
> up with a net total saving. The concept of "efficiency" is indeed a
> while lot more complex than it once was.
You are of course right with that. Efficiency is a very flexible term
and it all depends, what you try to achieve. And when I program for my
own fun projects, I also use libraries of course, because it's
inefficient always to invent the wheel again. But software often
doesn't really work like that. A good example are the application
bundles used on Mac OS X, where you simply install an application just
by dragging it's archive somewhere onto your HD. Really cool
feature... But those apps can't be sure, that all needed 3rd party
libs are installed on the target system, so they have to come with
them. Because many such apps do so, you end up with many different
versions of the same lib on your system and loose the advantage of
code sharing. The same is valid for other systems such as Linux or
Windows but for different reasons and different mechanisms behind it.
Libraries and code sharing are a really good idea, and one should use
it, *if necessary and useful*. However the effects of version problems
and other pitfalls often weaken the advantage of library usage.
Anyway, this wasn't the point of my complaints initially. I read Joels
article about the future of web based programming and said, that I
agree in most parts, but I really have problems with the statement,
that just adding enough layers of abstraction and indirection to
distributed AJAX-alikes, layers of JavaScript/...anyscript/VMs and so
on is the only way to go. I think, this leads in the end to
inefficient architectures and to the IMHO bad habbit of many
programmers to create and start up a gigantic machinery of libs,
interpreters and software layers, just to do nothing more as to pop up
a "Hello World"-message. You can argue, that computers are fast enough
to handle all that, so what? But aside from ecological implication of
such a CPU-cycle-wasting it is often really inefficient and lacking
elegance to do so.
Fast enough computers and efficiency: I read somewhere the following
argument: my computer today is 100 times faster than the one 20 years
ago, but the time from switching it on until the user interface is
ready for work *increased* to many times of the boot time for the old
cmoputer. An old Amiga (that was, what I head the old days) with a
small HD bootet in a few seconds to the Workbench and was ready to
use, my fast Linux-Box, Mac or smoe Windows computers need *minutes*
to be ready! Okay, they do 10 times more while booting compared to the
Amiga, but also then they should be 10 times faster, instead of
slower...
So what I say is *not* that we should not use libraries or modern
tools. I say, that adding mindlessly layer above layer of abstractions/
libs/interpreters and VMs between machine and user can't be really the
way to go.
> Although it does concern me just a little when the decorations on my
> application windows are drawn using a theme engine written in Scheme.
Exactly!
Stephan