This is a distinction I first learned about working in france years ago. Without any real basis I wondered whether it is their general more precise use of language which made it a more obvious distinction for a french person to make. At the time they were more or less synonyms for me, but since then have become very distinct especially when talking about software!
Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]
11–20 of 81 posts
Re: Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]
#12I wonder what a Smalltalk-like environment would look like if had been developed in the 2000s instead of the 1970s. If you could marry up the advantages of text/files, live code, visual layouts, data visualization and perhaps machine learning in the future, maybe you could come up with a huge jump in productivity and being able to handle complexity.
I believe Red[0] is closest along to practically realizing this concept by focusing on compositions of small languages, a premise Alan Kay also worked on with the STEPS project at VPRI[1].
The main thing that stops people from beelining down this path is the sheer quantity of yak-shaving involved. We're all impatient and have near-term goals, and glue-and-iterate gets us there without having to engage in a non-linear deconstruction and analysis of what's going on.
[0] http://www.red-lang.org/ [1] http://www.vpri.org/html/writings.php
Re: Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]
#13Alan Kay has had about a few decades to empirically demonstrate that "we" have willfully made it complicated. I don't believe he has done so.
I had the same thought, if he had a solution then he should have it by now.
He actually did lead a project which took this on: STEPS. (I think this is the last annual report on the project: http://www.vpri.org/pdf/tr2012001_steps.pdf) They did build a functional proof of concept which was significantly smaller/less complex than Smalltalk/Squeak which were predecessor projects he and his team worked on. Unfortunately, it's not based on the trinity of files, curly brackets and semicolons so it's not likely to take the mainstream computing world by storm.
Re: Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]
#14The fool complicate the simple, while the wise simplify the complex.
Re: Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]
#15Alan Kay has had about a few decades to empirically demonstrate that "we" have willfully made it complicated. I don't believe he has done so.
I had the same thought, if he had a solution then he should have it by now.
His critical error is evident in his comparative analysis that places Physics and Programming on the same level. The systems that underly natural sciences are givens. The entire kettle of soup of software complexity boils on the fact that software engineering must first create the 'terra firma' of computing. That is the root cause of the complexity in software: it lacks a physics.
Re: Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]
#16I wonder what a Smalltalk-like environment would look like if had been developed in the 2000s instead of the 1970s. If you could marry up the advantages of text/files, live code, visual layouts, data visualization and perhaps machine learning in the future, maybe you could come up with a huge jump in productivity and being able to handle complexity.
If you could marry up the advantages of text/files
Is that really such an advantage? What kind of advantage does having source code scattered in files have over Smalltalk's Change Log? The Change Log greatly simplifies having live code, and having a runtime environment where you could crash the system with a runtime change. Source code in text files complicates this. It's also a powerful development tool all by itself. What's more, it's just a clever use of a text file!
Re: Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]
#17Pah, "complex" is just latin for "put together". Take it apart, divide and rule.
Re: Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]
#18I wonder what a Smalltalk-like environment would look like if had been developed in the 2000s instead of the 1970s. If you could marry up the advantages of text/files, live code, visual layouts, data visualization and perhaps machine learning in the future, maybe you could come up with a huge jump in productivity and being able to handle complexity.
How about an Erlang unikernel with its relup functionality, running under a VM with the ability to hibernate to disk? That gives you nearly the same set of benefits as Smalltalk, without being nearly as "fossilized."
Re: Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]
#19This is a distinction I first learned about working in france years ago. Without any real basis I wondered whether it is their general more precise use of language which made it a more obvious distinction for a french person to make. At the time they were more or less synonyms for me, but since then have become very distinct especially when talking about software!
> their general more precise use of language
This isn't really true, it's just a snobby idea the French have somehow successfully convinced us of. (It goes along with the idea that they have the most "refined" culture or something).
Re: Is it really “Complex”? Or did we make it “Complicated”? (2014) [video]
#20Is it theoretically impossible to fit an interpreter for a dynamic programming language in the L1 cache of a modern chip? (I understand there are physical constraints that prohibit super low-latency memory lookups (of unconstrained size) in 0+epsilon time (where epsilon is small))
Even fitting the interpreter in cache, there's obviously still some overhead to interpreting instructions rather than executing them directly.
Also, I suspect most of the memory related slowdown with interpreters is due to the indirections in memory representation of data/code, not the interpreter itself falling out of cache.