181–190 of 191 posts
Earlier quoted context omitted.
What is so bad ab out Unix and what would be an alternative?
A world of command line interfaces and TTY text editors, instead of the powerful interactive GUI world Xerox PARC systems had.
Earlier quoted context omitted.
A world of command line interfaces and TTY text editors, instead of the powerful interactive GUI world Xerox PARC systems had.
The shell is worlds more powerful than the GUI (or CUI), because things in the shell trivially compose.
The UNIX shell is quite primitive by comparison.
Earlier quoted context omitted.
> People are still typing the same Unix commands into 25x80 terminal windows. People are still using vi to edit programs as sequential lines of text in files using languages from the 80s (C++) or 90s (Java). This seems like an almost willful misunderstanding of what programming is. The power of programs does NOT come from their syntactic structure. The power of programs comes from the non-linearity of programming lan…
One of my favorite CS professors back in the 80s used to joke that we had gone from cave paintings to written language, and now we wanted to back with our computers. (my paraphrase of whatever he actually said back then) Pictographs work for the illiterate, but that doesn't make them the most efficient interchange mechanism.
Earlier quoted context omitted.
The shell is worlds more powerful than the GUI (or CUI), because things in the shell trivially compose.
Except Xerox PARC systems also had a shell in the form of REPL and live coding. The UNIX shell is quite primitive by comparison.
"The UNIX shell is quite primitive by comparison."
I don't believe that's still the case (and hasn't been for some while). If you believe it is, rather than just making assertions please explain what you think is missing from bash in screen in urxvt.
Earlier quoted context omitted.
Except Xerox PARC systems also had a shell in the form of REPL and live coding. The UNIX shell is quite primitive by comparison.
That's all stuff we have now. "The UNIX shell is quite primitive by comparison." I don't believe that's still the case (and hasn't been for some while). If you believe it is, rather than just making assertions please explain what you think is missing from bash in screen in urxvt.
- bash is not a REPL with support for live coding.
- as consequence of the last point, bash cannot provide graphical output and respective manipulation of system data structures
Writing data to /proc to alter the OS behavior, is pretty basic compared with changing OS behaviour with a "doit" message on a expression block.
EDIT: For better understanding, imagine using something like Mathematica as an OS shell.
Earlier quoted context omitted.
I don't see a bunch of miracle cures that promise the moon, I see a bunch of things that promise, and sometimes deliver, hard-won incremental improvement. The OP seems a lot more like a moon-promising miracle-cure than all the stagnant stuff I'm wasting my attention on.
To clarify my moon examples would be NodeJS, MongoDB is web scale, HTML5/WebGL/VMs/Flash on mobiles, fast JIT/VMs for languages that aren't designed to be fast from the beginning etc. Things that are technically hard and get a lot of hype. And maybe MVC/OOP/DI/TDD design patterns and agile. The OP is promising something that's more of an architecture design issue like those of MVC libs. If he fails it will be because…
I suppose my general point is that things aren't stagnant, they are merely at a point where real progress tends to be hard-won and incremental. This may be frustrating to visionaries, but it seems both inevitable and perfectly fine to me.
Earlier quoted context omitted.
That's all stuff we have now. "The UNIX shell is quite primitive by comparison." I don't believe that's still the case (and hasn't been for some while). If you believe it is, rather than just making assertions please explain what you think is missing from bash in screen in urxvt.
- bash is just one of many possibilities, so bash != UNIX shell. It is not available by default in all UNIX systems - bash is not a REPL with support for live coding. - as consequence of the last point, bash cannot provide graphical output and respective manipulation of system data structures Writing data to /proc to alter the OS behavior, is pretty basic compared with changing OS behaviour with a "doit" message on a…
"bash is just one of many possibilities, so bash != UNIX shell. It is not available by default in all UNIX systems"
Bash is one example of a modern UNIX shell. It is not the only example - there are some that are more advanced in some ways, and some that are less advanced in some ways. I wasn't saying "BASH IS ALL UNIX", I was picking a specific setup as a point of comparison.
"bash is not a REPL with support for live coding."
What are attributes of a REPL which you see bash as lacking? Clearly, it Reads, Evaluates, and Prints. If you just object to the particular language, fine, there are certainly things to object to there - though I think it's pretty great as UI. It's certainly atrocious when you try building anything large out of it.
"as consequence of the last point, bash cannot provide graphical output and respective manipulation of system data structures"
That's mostly false, which you touch on immediately following.
'Writing data to /proc to alter the OS behavior, is pretty basic'
It can get arbitrarily sophisticated, but...
'compared with changing OS behaviour with a "doit" message on a expression block.'
I don't know what this means, please elaborate.
"For better understanding, imagine using something like Mathematica as an OS shell."
There's too many things that can mean for it to aid my understanding much. Do you mostly refer to the ability to embed graphics in the interactive session while retaining a scrolling log? or are there other relevant attributes I'm not following?
Earlier quoted context omitted.
- bash is just one of many possibilities, so bash != UNIX shell. It is not available by default in all UNIX systems - bash is not a REPL with support for live coding. - as consequence of the last point, bash cannot provide graphical output and respective manipulation of system data structures Writing data to /proc to alter the OS behavior, is pretty basic compared with changing OS behaviour with a "doit" message on a…
You're being argumentative instead of informative or useful. "bash is just one of many possibilities, so bash != UNIX shell. It is not available by default in all UNIX systems" Bash is one example of a modern UNIX shell. It is not the only example - there are some that are more advanced in some ways, and some that are less advanced in some ways. I wasn't saying "BASH IS ALL UNIX", I was picking a specific setup as a…
All those demos you see from Bret Victor are based on the experience to do live coding originally developed in these environments.
The operating system and applications are blended.
UNIX shell is based on the principle you write little programs in whatever language you feel like and you just have pipes, command line arguments and exit codes as communication mechanisms.
In Xerox PARC environments, you have a REPL experience where you can make use of any function or object in the whole OS and applications. You can change them dynamically (Interlisp, Smalltalk) or via module reload (Mesa).
Since the language of the REPL is the one of the system, you can do tasks, like select something with the mouse and then apply a REPL script to the currently selected graphical objects.
Just a few dummy examples, do a map over all selected windows to change their size for automatic tiling.
Or go over the paragraphs on the text editor and right align them.
The shell blends application macros, operating system scripts and live coding all in the same way.
For graphical editing in the shell you can pretty print data structures so that when you type a variable that represents a graphical structure, it gets drawn graphically in the command line.
You get to change running applications state from the shell, without requiring some kind of network protocol or shared memory API that they need to implement. Any public function or object can be directly accessed and manipulated.
Think of the whole experience as something like DrRacket or Mathematica being the complete OS.
Earlier quoted context omitted.
You're being argumentative instead of informative or useful. "bash is just one of many possibilities, so bash != UNIX shell. It is not available by default in all UNIX systems" Bash is one example of a modern UNIX shell. It is not the only example - there are some that are more advanced in some ways, and some that are less advanced in some ways. I wasn't saying "BASH IS ALL UNIX", I was picking a specific setup as a…
In Interlisp, Smalltalk and Mesa environments the shell interacts with the operating system. All those demos you see from Bret Victor are based on the experience to do live coding originally developed in these environments. The operating system and applications are blended. UNIX shell is based on the principle you write little programs in whatever language you feel like and you just have pipes, command line arguments…
That said, little of this is really dependent on another model. It seems your complaints boil down to 1) applications may do a poor job defining interfaces (which is either also true in the PARC setup, or they ignore the need to define interfaces in which case things are unlikely to be stable), 2) everything is too stringly typed (which I mostly agree with, though there are advantages to it), and 3) these (plus cultural attitudes) lead to insufficient/inappropriate infrastructure (which I also agree with - "the application" is typically harmful in the UNIX model).
Having said that, there doesn't seem a theoretical difference in capabilities except for the choice of a more sophisticated terminal (which is something I'd like fixed on modern systems).
As an amusing aside, "Just a few dummy examples, do a map over all selected windows to change their size for automatic tiling." I did literally this just the other day with bash + ratpoison.
Earlier quoted context omitted.
To clarify my moon examples would be NodeJS, MongoDB is web scale, HTML5/WebGL/VMs/Flash on mobiles, fast JIT/VMs for languages that aren't designed to be fast from the beginning etc. Things that are technically hard and get a lot of hype. And maybe MVC/OOP/DI/TDD design patterns and agile. The OP is promising something that's more of an architecture design issue like those of MVC libs. If he fails it will be because…
Yeah I had a fairly good sense of what you meant by promise-the-moon technologies, and I believe many of those you mentioned to be exactly the sort of hard-won incremental improvements that I was talking about. Good ideas trickling down is also the exact sort of hard-won incremental improvement I'm talking about. I suppose my general point is that things aren't stagnant, they are merely at a point where real progress…
So the marketing pivoted to being simple for MongoDB and being SSJS for Node. In Mongo's case scalability was severely hampered by the fundamental design, but many developers fell for the marketing and it cost them. Node.js can perform on some hello world benchmarks, but writing large scalable systems was a minefield of instability, callback hell bugs, lack of JS support for CPU intensive tasks, etc. It's still catching up to systems that existed in 2007.
The incremental improvement on scalability is nowhere to be seen. They do improve some other metric like programmer enthusiasm. Other newcomers did improve on easy scalability after more careful thought and years of effort but the hype machine largely left the topic.
A similar case can be made for HTML5/Flash promises for mobiles. You can use it but it often makes the process more difficult than writing two native apps in many cases. Good luck guessing which.