Notes on two presentations by Gordon Bell ca. 1998
|
From: Nicholas King on 21 Feb 2010 09:29 On 02/21/2010 04:54 AM, Andy "Krazy" Glew wrote: > Morten Reistad wrote: >> In article <0384a40d$0$1344$c3e8da3(a)news.astraweb.com>, >> Nicholas King <ze(a)zerandconsulting.com> wrote: >>> On 02/10/2010 01:31 PM, Robert Myers wrote: >> The success of languages like PHP is that they make layers of languages >> to deal with that complaxity. You program the machine API in plain C, >> and build another language on top. > I mainly agree with Morton on this. Invent a new notation that > simplifies thinking about the problem, and use that notation directly to > express the solution as a program. > > Even better if somebody else can make the implementation of the idioms > of the new notation faster, better. > > My only difference is that I hope that it may be possible to define a > meta-language, in which many of the new notations can be expressed. > > Do we really need a new language that defines yet another form of > IF-THEN-ELSE syntax? Yet another form of blocking and scope? (E.g. > yesterday I learned that Javascript's curly brace { } does not have the > same scoping significance as in other languages.) I tend to agree with you both on this. Personally I think that the success of PHP isn't really because of the language but rather the toolchain , development environment (including documentation) and runtime environment. It could easily have been just another library for C++. I'm not saying C++ is perfect it has it's faults. It's grammar is far too complex and ambiguous , The C++ community resisted garbage collection and type inference for too long. I think garbage collection should have been available but not mandatory to be used. (ie if you need to turn it off you can). There are lessons to be learnt from many different languages. I doubt we'll ever get past this fragmented space of code due to backward compatibility and existing code , perhaps one day automatic translation between languages will make the problem disappear but I think we'll be waiting on AI for that. Personally I'm a big fan of the different types of languages. I think we often get too stuck in the imperative trap. I'm a big fan of declarative languages. The right language in the right place can really make a difference to managing complexity. I personally think that there are a lot of lost opportunities in the space of computing. The problem with ideas that redefine so much of the environment is that the initial cost is so prohibitive. It's the same reason x86 with it's many warts has lasted so long , the value of existing code simply puts such a high barrier to climb for overtaking it.
From: Bernd Paysan on 21 Feb 2010 11:36 Del Cecchi wrote: > Are things like SPICE, Verilog, VHDL, considered programming languages > or something else? I'd consider Verilog and VHDL as programming languages, but SPICE not. Though of course, a SPICE netlist of a Turing machine implementation in bsim3 CMOS transistors is Turing complete ;-). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
From: Robert Myers on 21 Feb 2010 16:18 On Feb 20, 9:35 pm, Del Cecchi <delcecchinospamoftheno...(a)gmail.com> wrote: .. > > You can say no one designs supercomputers anymore apparently because > those supercomputers that people are designing or have recently designed > don't fit some personal idiosyncratic definition of what a supercomputer > is supposed to be. > > So, please enlighten us and tell us what you think a supercomputer would > be if someone were designing it, and why that is indeed superior to say > a Blue Gene or a roadrunner or all the other pretend supercomputers out > there. > I think I've been pretty specific. If you have to worry about where things are, then it's a cluster, and not a supercomputer, no matter how slickly packaged. No one commented on the guardian article I posted about the realities of scientific software. There is no reason to believe any of the stuff coming out of the bomb labs. I've explained my objections already, and I think my objections are sound. These are gigantic make-work projects. There is nothing to be learned from filling up warehouses with hardware that gobbles electricity and produces results that can't readily be verified. Think small. If you can pack in teraflops and make it widely available and easy to use, that's way better than petaflops or exaflops that are of no use to anyone but the bureaucrats who draw big salaries managing them. Robert.
From: Ken Hagan on 22 Feb 2010 05:20 On Sun, 21 Feb 2010 07:42:00 -0000, Andy "Krazy" Glew <ag-news(a)patten-glew.net> wrote: > I am a big proponent of languages that use XML syntactically. XML > capable editors are now widely available. I beg to differ, but I may have mis-understood your point. > E.g. while the user might type "if(cond) { then_code(); }" > the editing system might produce, internally > <keyword>if</keyword>{then_code;} > etc. And colorize semantically to boot. If what the user types is not XML, then the language isn't using XML syntactically, but merely has (potentially) an internal representation in XML. The transformation between source and XML would have to be two-way, or else the editor couldn't present the programmer with their original text the following day, so there's little to be gained from storing the program code in the XML representation. > With this mindset, conflicting keywords in different mini-languages are > just an issue of namespace: > if modules A and B both introduce keywords "scan", it might look like > > <A::keyword>scan</A::keyword>dA_atastructure(<B::keyword>scan</B::keyword>scan(B_datastructure)); > > (Although this example has little advantage over function calls.) Now you'd be blending two different languages in the same source file, which certainly is something that XML facilitates, but what is the end-user representation here? Once again, either that representation allows the blending or you've really just invented part of a compiler for reading and combining source files in a variety of mini-languages.
From: Chris Gray on 22 Feb 2010 19:35
"Ken Hagan" <K.Hagan(a)thermoteknix.com> writes: > Now you'd be blending two different languages in the same source file, > which certainly is something that XML facilitates, but what is the > end-user representation here? Once again, either that representation > allows the blending or you've really just invented part of a compiler > for reading and combining source files in a variety of mini-languages. Using Andy's syntax choice, it could look like this: <code> ... Sql::select recordVar Sql::from ... <use recordVar and the record fields> Sql::end ... Basically, a compiler doesn't have to key its parsing on a fixed set of keywords. That's normal, but not required. Sql has been done sort-of this way before, using a preprocessor that expanded the Sql statements, etc. to C source that interacted with the C code around the Sql statements. This discussion has resulted in a page of notes in my "to do" file. It is doable in my system. Question for helpful folks here: what "mini-languages" other than Sql could benefit from being embedded into a full programming language? -- Experience should guide us, not rule us. Chris Gray |