Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Leapfrogging Abstractions

By Arkaein in Technology
Thu Mar 03, 2005 at 09:25:35 PM EST
Tags: Software (all tags)
Software

Since nearly the beginning of modern computing programmers have used what have traditionally been called high level languages to make the task of developing large applications a manageable task. As computers have grown in power the tasks which we attempt to accomplish with them have grown in proportion. Language development has progressed towards higher and higher levels of representation. Near the high end we have a fairly recent set of languages which are designed to run on virtual machines (VMs), allowing the hardware and even the operating system to be largely abstracted away.

But is this really a solid step forward in programming language progress, or is it an evolutionary dead end? I believe it may be the latter, and I would propose that the progress of software development might be better served by leapfrogging this stage towards the higher levels of abstraction that lie ahead, and which are already permeating areas just outside of mainstream application development.


The Language Continuum

The term higher level language (hereafter HLL) seems to cover a narrower landscape than it did in the past. While C might have once been considered a HLL most computer scientists nowadays would likely consider it a middle level language (MLL); significantly more expressive than assembly and featuring basic platform independence, but quite a bit closer to the bare metal than, say, Java. Java, C++, and C# would all be considered modern HLLs (some might quibble with the inclusion of C++ because some C++ programs are basically C with a few extra features, but I definitely consider the modern features of the language such as the Standard Template Library and full OOP support to be high level components). The exact continuum is not something that can be specified precisely, but in general the higher the level the fewer the lines of code needed to accomplish a task and the greater the set of standard libraries available to eliminate the tedium of reinventing well solved wheels.

Any complete system generally requires some software to be written at many levels. Device drivers and operating systems will require some assembly (a low level language, or LLL) and tend to be written mainly in MLLs like C, while modern applications tend to use C as a minimum with preference for HLLs. The trend at all levels is upward, as improvement in development tools such as compilers with fairly automatic optimizations have reduced or eliminated the need for human developers to dig into the nitty gritty details of a piece of code to ensure decent performance. In addition, hardware architectures have begun to grow past the levels of complexity at which humans can reliably outperform compilers at determining optimal implementations at the assembly code level.

Moving to higher levels typically trades off performance for reduced development and maintenance costs. With today's increasingly fast PCs, with the processor idle 99% of the time under the not-so-strenuous loads imposed by web browsing, email, and word processing that the best choice for many new applications would be one of the highest level languages available. Can we not do better than Java and C#, even today? What about the so called scripting languages, such as Python and Ruby? These languages are rarely considered for full-fledged applications, but is it really because they aren't up to the task?

The Level of Optimal Optimization

For high level application development it seems obvious that high level languages are desirable because they can reduce total project complexity, especially in terms of total lines of code written specifically for the given project. But many projects require some code to be written at lower levels as well. A 3D game engine that renders a million triangles every few seconds needs to squeeze every bit of performance out of the inner sections of rendering loops, and this might require a bit of hand tuned assembly inserted into what is already highly optimized C to achieve this performance. What's key is that modern compilers can optimize C or C++ code better than most programmers, and these tools should only continue to get better. Meanwhile, the skills of a typical programmer from generation to generation will stay fairly constant unless huge breakthroughs are made in educational techniques.

What does this all mean? I think it means that the Level of Optimal Optimization will rise near monotonically over time. That is to say, in maybe 15 years hand coded assembly routines may become obsolete (accessing architecture specific features not withstanding) because the compiler will produce more optimal code than a human could in 99.99% of cases. In maybe 30 years hand optimizations at the middle levels may similarly be obsoleted by advanced development tools. So how far can this be extended? Is there any reason why a future compiler could not turn a decently written Perl script into a chunk of object code that runs faster than hand tuned C? Possibly optimistic projections aside, if these trends continue eventually even modern HLLs may be obsoleted by the one-two punch of future languages and their super-compiler/optimizers.

Upping the Ante: Dynamic Typing

This question was posed above: "Are scripting languages up to the task of full scale application development?" The big knock on Python et al. in this domain is not so much that they are typically used for scripting (which I believe is a bit of a Red Herring), but that most are dynamically typed. While dynamic typing facilitates rapid development (making prototyping a solid niche for these languages), the thought is that scalability and long term maintainability will suffer. Strongly typed languages ensure that a basic error such as an assignment between incompatible variable types is caught at compile time, but with dynamic typing such bug discoveries will not occur until run time (when generally an exception is thrown). I believe that this run time verses compile time trade-off underlies the primary objection to dynamically typed languages for large application development.

My personal opinion is that this is flawed thinking. The errors caught by the compiler are generally the simplest errors because the compiler can only judge syntax. Logic errors (legal expressions that result in flawed program behavior) are usually much more work to find and debug, and are language agnostic. Such errors are best caught using solid software engineering principles, including modular design and unit testing. These principles also apply regardless of chosen language. Even if software bugs written in dynamic languages truly are more difficult to debug, I believe that the trade-off between ease of debugging and quickness of development, as well as reductions in total code size for dynamically typed languages must be weighed against this primary drawback before truly determining the best approach for any project.

Virtual Roadblocks

Using dynamically typed languages has the potential for full scale application development today. Just as assembly can be be used to optimize MLLs, MLLs can be used to write modules called from what could be called a general class of very high level languages (VHLLs). Even without the advanced compilers of the future, use of profiling to identify performance bottlenecks and replacement of only such bottlenecks with more efficient modules coded in C, C++ or Fortran can capture some of the best of all worlds between MLLs and VHLLs.

There's a problem with this picture though, and that is where do the VM-based languages fit? Java and C# being the most prominent examples, this class of language has no problem making use of lower level components through invocation of native methods, but it is a problem coming from the other direction, e.g. calling a Java method from Python. VHLLs provide higher levels of abstraction and reduced code complexity, but the cost of invoking a VM to run specific modules from a VHLL interpreter may be too costly to make it worthwhile in any sort of optimization strategy. It would be simply easier to cut the VM-based HLL out of the loop and create interpreter callable modules in MLLs, or at least HLLs such as C++ that are typically compiled to native code.

The VM roadblock issue is primarily historical/cultural and has little to do with the language itself. Rather it is an issue with the standard implementations of the language. There is no reason why Java cannot be compiled to native code. Simply replace the VM provided for each platform with standard libraries providing the necessary support. From the viewpoint of an application distributor or end user performing installation the difference is significant because the "write once run everywhere" condition is violated, but from pure coding and application usage standpoints the differences should be nil. What would be gained is the ability to seamlessly integrate Java or C# object code into applications written primarily in VHLLs, just as is already possible with C, C++, Fortran, etc. object code. Whether the VHLLs use a VM, an interpreter or native compilation is of no consequence as long as they themselves are at the top of the application hierarchy.

As a consequence I think that the VM strategy is a potential dead end, or at least a roadblock on the path of programming language progress. Developers looking to use the best application development tools of the near future may find themselves locked into a suboptimal level of abstraction today if a VM-based language is chosen as the foundation of a new project. Even if a decision is made to move up to a VHLL later on, existing projects may be stuck with no easy way to utilize their VM entrenched code base from the VHLL unless tools to produce native binaries from the VM-based HLL code become more common and as mature as their bytecode producing counterparts. My suggestion? Leapfrog the VM roadblock completely. The overlap between the VHLLs, with their rich libraries often rivaling those of the VM-based HLLs, and the performance benefits of the natively compiled MLLs and HLLs leave few gaps which need filling.

The Ultimate Goal: Programming the Holodeck

By this point you might be wondering where can this all lead? What is the logical conclusion of the chain of ever ascending levels of abstraction, processing power, and optimization capabilities? Star Trek: The Next Generation introduced us to the holodeck, in essence the ultimate virtual reality producing environment. What really fascinated me about the idea of the holodeck though was its incredible programmability. The user was in effect writing a new program each time he used the holodeck, though no esoteric programming code or extensive training was required. The language used was natural language, which while not as concise or succinct as Lisp, more than makes up for it in terms of sheer expressivity.

A typical usage scenario goes like this: the user would first describe the general setting (application) in just a few sentences. The computer would produce a prototype setting, presumably by calling upon an incredibly vast knowledge base containing huge sets of templates. This knowledge base is the logical (though extreme) extension of the increasingly featureful core libraries and APIs that are becoming standard parts of modern programming languages. This prototype will obviously be lacking in details the user might wish implemented, but would start with a reasonable set of default values in cases of uncertainty. After initial inspection of the prototype the user may specify progressively finer details until the application meets desired specifications. While such tuning could no doubt go on for hours in some cases, the program was typically usable in mere seconds and well customized within minutes, and it was all done interactively. Perhaps most importantly the tuning was done by the actual user, rather than by some programmer who could only hope to anticipate the actual needs of the actual user.

While the holodeck is sci-fi, it's characteristic of ultimate programmability should be the grand vision of programming language, development library and API designers. If a tool doesn't help someone finish a job more quickly, effectively, or cheaply compared to what's already available then it isn't a very worthwhile tool. The gap between modern languages and natural language processing is a great one, but it will only be achieved by pushing for higher and higher levels of abstraction. Lower level programmers will still be necessary, but their functions should be increasingly shielded from the end users and even the developers of end user applications to tackle problems of increasing complexity.

Final Thoughts

For now I'm doing most of my own development in C/C++, with some supplemental Python. Why not more Python and less C/C++? Partly it's portability issues, in the case of my current project (a fluid flow simulation visualizer) it's simply easier to output binaries with only a few common dependencies for the target machines than to generate Python that will incur additional dependencies simply for the appropriate Python-to-C bindings. Performance is also an issue, as fluid flow visual visualization can be fairly memory and CPU hungry.

My hope is that in the near future dependency issues at least will become nearly insignificant. If I cannot rely on the package "foo" being available on most machines (much less the additional Python bindings for package "foo"), it would be almost as good if I could be sure that an end user could easily or automatically acquire such dependencies as needed. My preferred OS makes such actions relatively easy, and a few other projects may provide their own solutions. Better optimizers for VHLLs will help my cause as well.

In any case, the VM-based languages are one step on the ladder of progress I'll probably be skipping over.



Copyright (C) 2005 Matt Heinzen. Redistribution allowed under the terms of the GNU Free Documentation License.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Favorite Execution Style?
o Native binary 49%
o Virtual Machine 16%
o Interpreted 13%
o Emulated 1%
o Don't mess with Texas 19%

Votes: 61
Results | Other Polls

Related Links
o Java
o C++
o C#
o Standard Template Library
o Python
o Ruby
o Perl
o typing
o Fortran
o Lisp
o My preferred OS
o other
o projects
o Better optimizers for VHLLs
o GNU Free Documentation License
o Also by Arkaein


Display: Sort:
Leapfrogging Abstractions | 178 comments (137 topical, 41 editorial, 0 hidden)
why people like static compiled languages (3.00 / 8) (#6)
by speek on Wed Mar 02, 2005 at 07:26:19 AM EST

Because their IDE can help them navigate quickly through their code, do code completion and code help, and automatic refactorings. Advocates of dynamically typed languages always bring up Smalltalk at this point and say you can do the same with Smalltalk. Well, but the point is, you can't do it with Python or Ruby, Not even close. IDE's for these languages are little more than notepad with colors. That makes working on your 500,000 line python program a bit difficult.

--
al queda is kicking themsleves for not knowing about the levees

Or just use your brain (3.00 / 2) (#8)
by sholden on Wed Mar 02, 2005 at 09:18:08 AM EST

My IDE doesn't even do colors...

Currently it has a few python files open in it from a 100,000 line python program and it's not difficult to work with.

500,000 lines of python would be a large system but I can't see why it would be a problem. Provided it hasn't been touched by monkeys pretending to be programmers, you should never have to deal with more than a snippet of the code base at any time.

Of course keeping the monkeys away can be difficult, though python has less (percentage wise) of them than say Java making that a little easier. Simply because Java gets taught at universities, and the majority of CS/IT/"whatever it's called this week" graduates make monkeys look like brilliant programmers.

--
The world's dullest web page


[ Parent ]
Type less, think more (none / 0) (#41)
by enthalpyX on Wed Mar 02, 2005 at 03:36:30 PM EST

Refactoring is quite possibly the best programmer productivity tool ever invented. I lived in the world of colorless vi until I witnessed this marvel. It's that large quantities of code are hard to *extend* (I don't know what this nebulous "manage" term means). When requirements change, wading through dependencies and object relations is a mess. Search and replace is completely antiquated in the light of development environments like Eclipse. Obstinately refusing to use tools that let you type less & think more is quite the opposite of what you're suggesting.

[ Parent ]
I'm intrigued (none / 0) (#48)
by mpalczew on Wed Mar 02, 2005 at 04:40:33 PM EST

I live in the land of colorfull vi. Always looking for ways to extend my productivity(so I can post more stupid shit, onto k5).  

From my understandign refacoring is kind of like autocomplete. If found it usefull when working with an unfamiliar API.  Would you agree that this is when it's most usefull?  Though I believe that the best way to type less & think more is to increase your typing speed.
-- Death to all Fanatics!
[ Parent ]

it's not a bit like autocomplete (none / 0) (#55)
by speek on Wed Mar 02, 2005 at 06:27:23 PM EST

Refactoring tools rearrange your code for you automatically. Extracting code snippets into their own method or class, for instance. You are thinking code completion.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

I already do (none / 0) (#49)
by sholden on Wed Mar 02, 2005 at 04:40:48 PM EST

My editor already lets me type less and think more.

I just don't need colored words to tell me what is a comment and what is a keyword and what is a variable name.

It lets me do refactoring stuff by typing some text and clicking a mouse button. It simply calls a specialised refactoring tool that does the actual work - rather than embedding everything in the universe into one bloated super-editor.

--
The world's dullest web page


[ Parent ]
tell me more (none / 0) (#57)
by speek on Wed Mar 02, 2005 at 06:34:49 PM EST

I just don't need colored words to tell me what is a comment and what is a keyword and what is a variable name.

This is not the useful stuff we're talking about. In fact, I pointed out that just coloring stuff made for a lame editor.

I'd like to hear about what kinds of refactorings you can do. I'd like to know if you can click on a variable to jump to the class that defines the variable's type. I'd like to know if you can click a method and find out everywhere that calls it (without false positives). I'd like to know if you can type a variable and instantly see a list of all the valid methods on that variable. I'd like to know if you can look at a method call and tell me exactly what kind of object that method returns without relying on developer documetation or reading the code of the method.

If you can do all that, I'd like to know what your python development environment setup is. I don't really believe you when you say your 100,000 lines of python aren't a problem. Usually, every developer thinks their code is not a problem, but others will find it an unholy mess and incomprehensible. I'd bet your python program is unmanageable (but then, I'd have 99% odds on my side with that bet...)

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

no, almost, no, and no... (none / 0) (#60)
by sholden on Wed Mar 02, 2005 at 07:53:56 PM EST

I'd like to hear about what kinds of refactorings you can do. I'd like to know if you can click on a variable to jump to the class that defines the variable's type.

Python isn't statically typed so obviously not, the type of a variable isn't defined until runtime, and in a large number of cases changes at runtime (from NoneType to some other type).

At runtime I can, and I do do editing with the code running reasonably often.

I'd like to know if you can click a method and find out everywhere that calls it (without false positives).

Yes, though you select the method and click a command word. It's certainly not fool-proof either but I haven't had any problems.

I'd like to know if you can type a variable and instantly see a list of all the valid methods on that variable.

Nope. I can easily get a list of all the methods for a given class, but I don't use that much. The most similar thing is getting a list of such things at runtime, which I do a fair bit - I tend to edit code while it's running.

I'd like to know if you can look at a method call and tell me exactly what kind of object that method returns without relying on developer documetation or reading the code of the method.

No, since the return type isn't fixed and hence that's simply impossible.

These are the costs of dynamic typing. They are outweighed by the benefits, mainly speed of development and reduction in code base. That reduction in code size means you don't need a lot of the scaffolding that you would otherwise need.

If you can do all that, I'd like to know what your python development environment setup is.

Well I can't, but I don't find them necessary.

I don't really believe you when you say your 100,000 lines of python aren't a problem. Usually, every developer thinks their code is not a problem, but others will find it an unholy mess and incomprehensible. I'd bet your python program is unmanageable (but then, I'd have 99% odds on my side with that bet...)


; wc -l `find . -name '*.py'` | tail -1
 113391 total

I didn't write the code, I have had it for less than a week and I'm doing some redesign and refactoring of a section of it. I haven't run into any problems comprehending the code, even though most of it was written to a very tight schedule.

Maybe I'm just a genius who can work with an incomprehensible unholy mess of code without needing a magical editor? Or maybe (and significantly more likely), when code isn't written by monkeys the problems that plague code that is just don't manifest and geniuses with magical tools aren't necessary? Maybe I just haven't stumbled across the incomprehensible disaster area hidden in the depths of the code somewhere?

I have also worked on code that I'm pretty sure was written by retarded monkeys. A genius with a magical editor wouldn't have helped much then either. The only thing that would was 'rm'. It was production code in a bank - I even used a snippet of it as an example of "code worse than anything even you could manage" when I was teaching C++ (and if you've ever marked university student coding assignments, you'll realise how big a claim that is :).

--
The world's dullest web page


[ Parent ]
So? (none / 0) (#64)
by Coryoth on Wed Mar 02, 2005 at 09:57:11 PM EST

I presume you're using a language without Design by Contract.  Can you tell exactly what the constraints on inputs to a method (not just the types, but maximal integer values, lengths of lists, keys required is hashes etc.) are without reading the code?  Can you tell what properties you can expect to be guaranteed when a method returns (how was the object changed, if at all?  What are the constraints on any return values - again, not just the type) without having to read the code?  What properties of the object can you know will always be guaranteed to  remain invariant?

Those all sound like extremely useful things to know, instead of just types, yet I don't see how you're IDE is going to manage it.  Does that mean your language sucks and it unproductive?  No, not really - it just means you don't have this particular feature set (as powerful, and useful as it is) - I presume you are amanging to get by without it.  Then again, maybe your code is unmanageable.

The really odd thing is that all that stuff is available if you use Contract Python and Eclipse with PyDev.  You can even do refactoring through Eclipse, PyDev and BicycleRepairMan, which is a fantastic refactoring tool.  Odd how things turn out eh?

Jedidiah.

[ Parent ]

never tried design by contract (none / 0) (#86)
by speek on Thu Mar 03, 2005 at 08:34:55 AM EST

I might like it a lot. But, I get the feeling that I'd really only feel it to be useful on about 5% of the methods, the rest being too trivially simple to need it. On such methods, there are javadocs, which, yes, I can browse during code completion very easily. The ContractPython almost looks like unit testing written with the code, an idea I don't particularly like as it means that a) your code is somewhat obfuscated by these unit tests, b)the type of tests you can write in this space is very limited, and c)the unit tests end up in your production code. I'd rather keep my unit tests separate, where I have more flexibility.

Though, having the IDE show you unit tests for a given method at a glance is not a bad idea.

BTW, my code is completely unmanageable.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

Design by contract (none / 0) (#89)
by sholden on Thu Mar 03, 2005 at 10:09:26 AM EST

It's a great way of developing large systems. Many moons ago the first years I sometimes taught had to use it, until they swiched to Java for unfathomably stupid reasons.

Unit testing is different, since it is designed to thoroughly test a unit of code not specify what it does. Design by contract just specifies the interface of the unit of code. Unit tests could be viewed as a form of design by contract, since the tests specify the contract the unit of code must meet - however, you miss out on the joys of proofs. .

Design by contract tells you that for every method/function/procedure/whatever that if the set of preconditions is satified then the set of postconditions will be satisfied after the method/etc has returned.

If the pre and post conditions are specified in a  formal way, such as OCL, then you can start to prove things about the code. Of course code which doesn't satisfy the contract will cause the proofs to be meaningless so unit testing is still very necessary.

In an OO system it also allows you to enforce substitutability, the preconditions of the parent's methods must logically imply the preconditions of the child's versions of them, and the child's postconditions must logically imply the parent's postconditions.

Then you get the joys of class invariants and loop invariants.

It's the antithesis of currently favoured methodologies. As indicated by the name it is very upfront design heavy.

--
The world's dullest web page


[ Parent ]
yes, it does sound interesting (none / 0) (#90)
by speek on Thu Mar 03, 2005 at 10:21:19 AM EST

I'm still thinking it's only appropriate for a tiny set of all the methods you want to write. Every Java class has a toString() method - do you really want every one to have a contract? In fact, you could argue that a goodly percentage of Java methods could do without the type information, and I wouldn't disagree - maybe an optionally statically typed language would make me happiest too. I suspect it is optional in ContractPython whether a given method has any contract, so that is probably pretty nice, to be able to use it when you need. Correct me if I'm wrong.

In the example on the ContractPython page, I noticed one of their pre-conditions is to assert the incoming parameter is of type list. An unfortunate example, don't you think? :-)

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

Only for methods you actually implement (none / 1) (#91)
by sholden on Thu Mar 03, 2005 at 10:58:14 AM EST

toString() wouldn't usually actually be implemented (unless your a "printf school" debugger when you might always implement one I guess) anyway.

If you don't implement it you just use the parent's version and don't need to specify the contract, since you inherit that as well.

Design by contract is about specifying the interface of methods/etc in a formal way so that you can use them safely. It's unlikely toString() would often be specified as doing something. For a class representing an XML document, toString() might be contracted to always return a string containing the canonical form of the XML or something; but for most classes you don't care at all (it's all about a contract for interaction purposes - and I haven't seen many classes where the result of toString() matters - Integer would be one where it does...). So you have:

pre: true
post: result != null

Or something...

I've never used ContractPython so I don't know how it works, but I would guess it would default to:

pre: true
post: true

Which tells you absolutely nothing.

And yes asserting that an argument is a certain type in python is awful. You lose the very useful ability to reuse code based on interface instead of type. But there's no standard way of specifying:

is_sequence(a) and is_mutable(a) and callable(a.sort)

Which is what I would guess they really want to say, though that assumes the sort method does an in-place sort instead of some other random thing.

But design by contract would work best with statically typed languages anyway. Inheritance and substitutability are what let you derive a lot from simple pre and post conditions. Without enforcing type constraints you lose that. Then again, what would I know, I've never tried it with a dynamic language but given the existance of ContractPython others clearly have...

--
The world's dullest web page


[ Parent ]
There is a java design by contract (none / 0) (#173)
by communistpoet on Sun Mar 13, 2005 at 10:55:11 PM EST

It's called iContract,
http://www.javaworld.com/javaworld/jw-02-2001/jw-0216-cooltools.html

The site for the iContract project is down unfortunately.
http://www.reliable-systems.com/tools/iContract/

I myself implemented precodnitions on java code with reflection. not using the code from above. DBC is a great thing.

We must become better men to make a better world.
[ Parent ]

Some completion (none / 0) (#124)
by m50d on Fri Mar 04, 2005 at 10:49:22 AM EST

My IDE can complete as far as listing an object's methods or those in a library, and list parameters for a function I've typed. What more do you want?

[ Parent ]
what IDE/language is that? (none / 0) (#142)
by speek on Sat Mar 05, 2005 at 10:19:44 AM EST

There's other things like refactoring, navigation of code and the like as well. Of course, if your IDE can already do code completion, I would think it could (potentially at least) also provide easy code navigation. I'm not going to explain all the benefits of refactoring help though, but as an example, I often want to change my method names (cause I'm anal), and when I do, I let the computer fix everywhere that references the method. Which is another thing - instantly finding everywhere in the code that uses a method/class/variable is very useful too.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

Eclipse + PyDev or TruStudio (none / 0) (#143)
by Coryoth on Sat Mar 05, 2005 at 02:59:17 PM EST

Either Eclipse with PyDev or Trustudio (which is just Eclipse with a different set of extensions) will let you do code completion, refactoring, navigation of code, integrated debugging etc. with Python.  I don't see what the problem is here.  I haven't really used TruStudio (was just told about it), but PyDev does a remarkably good job of refactoring using BicycleRepairMan a specialised Python refactoring tool that is surprisingly powerful.  What is it your missing from a Python IDE again?

Jedidiah

[ Parent ]

maybe it's had some significant updates (none / 0) (#146)
by speek on Sat Mar 05, 2005 at 03:56:25 PM EST

I've used PyDev and never seen it offer any code completion, or anything other than syntax coloring. I just checked. It claims autocompletion is on and activated with ".", but it did nothing on any of the objects I tried it on.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

Not sure what to tell you (none / 0) (#150)
by Coryoth on Sun Mar 06, 2005 at 12:58:34 AM EST

It works for me for objects, but doesn't do anything for modules (which is a little irrtating, because presumably that wouldn't be all that hard).  I can't honestly say what your problems are, but I do admit that PyDev is still gearing up as a project and is a little patchy for now.  It isn't a restriction of the language that is causing the problem though.

Try TruStudio (there is a free download version), I've been told that has a more developed featureset.

Jedidiah.

[ Parent ]

I see it (none / 0) (#153)
by speek on Sun Mar 06, 2005 at 02:58:27 PM EST

I upgraded my PyDev (been about a year...). You're right, it can show objects but not modules. Compared to eclipse's java editor, it's lame, but I imagine in time it will be quite useful. I suppose it's somewhat dependent on how you write your code too (ie, you could write a method that can return various dramatically different objects, depending on runtime conditions, and a compile-time parser could never get that right). I can see myself writing in python in a year or so as these tools improve.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

The field of programming languages ... (3.00 / 4) (#12)
by Kalani on Wed Mar 02, 2005 at 09:36:23 AM EST

... is incredibly interesting.  You might talk about the possibilities of shoving language features into syntactic transformations (and the lambda calculus built purely on such a system).  You might talk about the different underlying semantic models of software: functional, declarative, stateful.  You could even talk about the interesting ways that these models are synthesized or extended, for example concurrent declarative programs present an interesting way of writing multi-threaded software (where threads transparently block waiting for unbound variables to be unified in other threads).

But instead you decided to talk vaguely about informal type systems (ie: "dynamic typing") and Star Trek.

:)

-----
"I have often made the hypothesis that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed

Holodeck and associated ideas (none / 0) (#14)
by whazat on Wed Mar 02, 2005 at 10:03:44 AM EST

How is the process you describe in programming the holodeck different from giving an order to a subservient human?

Imagine for instance that the system you are programming was a robot, you would want it to be able to follow instructions such as "Pick up a butter knife" and "Compose a sonnet in the style of Shakespeare". Something that could follow these instructions would seem to be a classical robot as in Asimov etc.

So what you are actually wanting is full intelligence in these systems. I have come across a star trek analogy for advanced computing (whilst ignoring the intelligence aspect) in the overview for Autonomic Computing. I find it vaguely annoying mainly because it is trying to solve the intelligence problem (with respect to general computing problems) with the same tools and approaches that have generally not been useful in solving the robotic intelligence problem.

knowledge base vs intelligence (none / 0) (#15)
by Arkaein on Wed Mar 02, 2005 at 10:18:05 AM EST

I think you may be reading a little more power into the system I tried toi describe than I intended.

I was thinking terms of two components: a natural language processor and an extremely rich base of application templates. The natural language part would require significant advancements in AI, but is likely just one possible interfaces to the application templating system.

The system might work like this if it existed using modern components:

"Computer, I want to create a web browsing application"

(computer shows Firefox as the default webbrowser)

"Okay, instead of tabs I want a field of icons displaying minimized versions of each open page"

(computer loads the Konqueror icon system and connects it to a desktop pager system, which exports its output to the Firefox main view)

and so on. Obviously this can't be done now, more sophisticated components and connectors are needed. But this is the goal I was looking at. More unique applications would not start with a single temples so close to the target, but could probably be fashioned mainly from 3 or 4 of the most significant components to start out.

----
The ultimate plays for Madden 2005
[ Parent ]

Don't use the holodeck as an example (none / 0) (#61)
by whazat on Wed Mar 02, 2005 at 08:06:52 PM EST

It could fake human level intelligence pretty well and even in it's capabilities to create scenaries was at a level I would consider the intelligence problem solved. It never seemed to have many limitations in what it could create or what it knew.

If you have to use that example, explain what you expect it would do when it didn't understand what you were asking it to do. If someone would have to tinker for a long time to, for example, create an EEG processing module. Also would you expect it to be able to go from specific problems to generalities? For example if someone asked it to create a program to calculate optimum place to put distribution centres needing to be visited by a distribution truck, would you expect it to be able to realise that this is related to the travelling salesman problem and use the related information?

[ Parent ]

ooh (3.00 / 2) (#16)
by Cat Huggles on Wed Mar 02, 2005 at 10:27:33 AM EST

I want to program things like in the movies, by sticking 3D blocks together and stuff. I suppose Labview is kind of like this, but without the cool.

See, why can't this be done? (none / 0) (#17)
by GenerationY on Wed Mar 02, 2005 at 10:45:46 AM EST

Isn't it about time programming became a complete and utter piece of piss? I don't see the problem.
All I needs if for one of you damn nerds to break ranks and stop protecting 4 years grinding away at maths and your job and sort this shit out.

[ Parent ]
math is nice (none / 0) (#19)
by Cat Huggles on Wed Mar 02, 2005 at 11:37:20 AM EST

But, it seems to me that very little code out there is actual real (ie. floating point) math. Most seems to be control structures and data rearranging. Should be able to do that with drawn 'data pipelines'. Worst of all is the damn text processing.

[ Parent ]
Real math? (none / 1) (#20)
by Kalani on Wed Mar 02, 2005 at 11:41:51 AM EST

Is that supposed to mean math with real (ie: continuous) numbers?  That's a nice pun, if so.

Otherwise, not to be an ass, but text processing, control structures, and "data rearranging" really do have strong mathematical foundations.  Once I understood formal language theory and built a parser generator, for example, I could never maintain somebody else's informal monolithic hand-made parser.

-----
"I have often made the hypothesis that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed
[ Parent ]

OK but why can't we program (none / 0) (#26)
by GenerationY on Wed Mar 02, 2005 at 12:28:45 PM EST

using, er, these structures in a topographical (if thats the right word) form?
You know the sort of thing, where loops look like loops and structures have arrows or pipes pointing to bits of other structures. You could define a class by defining groups of linked boxes who could drop onto the screen as needed and relabel. I'm kind of speaking out my rear here a bit not knowing much about the theory of programming, but hopefully you get what I'm trying to say.

[ Parent ]
it's called visual basic (none / 0) (#29)
by mpalczew on Wed Mar 02, 2005 at 12:57:13 PM EST

because attempts to move in that direction have sucked.  The programmers that end up programming this way have no clue and make shitty programs.  Besides when programming one likes to have control over their program.  
-- Death to all Fanatics!
[ Parent ]
emm (none / 0) (#30)
by Cat Huggles on Wed Mar 02, 2005 at 01:06:05 PM EST

Visual basic only had visual UI design, if I recall correctly. We're talking about programming logic visually. Sort of like a flowchart that you can compile.

[ Parent ]
A flowchart that you can compile ... (none / 0) (#33)
by Kalani on Wed Mar 02, 2005 at 01:28:20 PM EST

... that's a computer program.

I think that visual representations of computer programs can be helpful in certain contexts.  For example, a circuit diagram model of a computer program makes concurrent processes explicit (it's hard to ignore a fork in a circuit), so issues of resource contention can be easier to spot.

But I think that the class of problems that benefit from this sort of code design is limited.  It's rather like the geometry/algebra arguments of ye olde Trinity.  Or, to use a more current example, it's similar to operating on files in Explorer versus a command prompt.  The visual metaphor extends only so far before the textual (symbolic) method becomes easier.

-----
"I have often made the hypothesis that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed
[ Parent ]

arghhh! (none / 0) (#35)
by GenerationY on Wed Mar 02, 2005 at 01:43:51 PM EST

But I think that the class of problems that benefit from this sort of code design is limited.

How about a class of people in the world?
i.e., everyone who hasn't got time to do (or do the equivalent) of a couple of degrees in computer science? Most people understand simple diagrams. Most people understand simple mechanical and spatial metaphors metaphors (you put things in containers, if you pass a container to something else you pass the contents whilst you are doing this etc). Most people understand the notion behind assembling subcomponents to make something (engine, bookshelf, etc.) Its still easier to open files in Explorer. Its more efficient to use the command line prompt perhaps.

I am well aware programming is indeed a abstraction of all that, but why does it have to be some damn abstract? What is the limiting factor?

In the style of CTS...

WOOD

TREES

What the fuck is wrong with you nerds?!!!


[ Parent ]

Why do you assume programming is easy? (none / 0) (#36)
by jobi on Wed Mar 02, 2005 at 01:59:30 PM EST

"If you don't think carefully, you might think that programming
is just typing statements in a programming language."
        - Ward Cunningham

---
"[Y]ou can lecture me on bad language when you learn to use a fucking apostrophe."
[ Parent ]
I don't (none / 0) (#37)
by GenerationY on Wed Mar 02, 2005 at 02:41:22 PM EST

But I believe it should be. I think the average man in the street has all the skills necessary but nobody wants to help him. Why not utilise the kind of processing power we now have to assist him in this end?

If he can change the oil on his car, why can't he do the software equivalent? He's not a master carpenter but he put up a book shelf. He's not an engineer but he's had success with flat pack furniture. He's not a chef but he throw something into the microwave. He can change a washer but he's not a plumber. Watch him cunningly join the "right queue" at the supermarket.

Thus he can follow instructions, knows a rich vocabulary of metaphors and abstractions the most useful of which for the logic of programming are I feel more likely spatial and mechanical rather than lingustic. Thats probably where I'm coming from thinking about it.

The tool kit is there, but then he has to spend years learning how to translate this stuff into lines in a given syntax.

I can see that such a "programming language" wouldn't do everything and in particular both "software engineering" and "computer science" aren't just about translating simple concepts in syntax, but thats beside the point. Same as with the mechanics, chefs, carpenters, plumbers in the above.

[ Parent ]

I should say (none / 0) (#39)
by GenerationY on Wed Mar 02, 2005 at 02:53:10 PM EST

I'm well aware there are periodic attempts at using the visual metaphor more and implementing it. Nothing has really stuck although bits of do exist in diverse things like Macromedia Director, music software packages, VB and even Visio - objects having properties is a start I suppose. My point is more rhetorical and I was hoping to talk about it.

[ Parent ]
Is it easier to count sets of apples? (none / 0) (#113)
by saltmine on Fri Mar 04, 2005 at 05:23:58 AM EST

Things that are easier to desing visually often are. Video game poly-meshes are done in a 3-D editor and exported as a set of points. User Interfaces for a program are usually designed with a visual layout tool and then they generate code to interact with your code. I'm sure there are a million other examples. The question is, how do you use pictures to describe really abstract things? Containers, sure that's easy but how would I go about have a picture of algorithm Foo? Is it a box with code in it?

[ Parent ]
Yah (none / 0) (#71)
by jongleur on Wed Mar 02, 2005 at 11:32:09 PM EST

| he can follow instructions, knows a rich vocabulary of metaphors and abstractions

You're right, even for ordinary programmers there is felt need to harness people's everyday understanding. There was an article about an Russian? Rumanian? woman at Sun working on a language like that, trying to build in new metaphors; also, Perl6 will have a lot of different ways to organize things (meaning a better chance to fit the way you see a problem yourself). Multi-paradigm, flexible languages like Oz & Occaml try to be that way too, somewhat. But that's incremental movement from the existing language idea, not what you're suggesting.

I'd have to say the biggest obvious thing that we don't have, is an ontology of human knowledge. Writing in that formalism directly wouldn't be natural to use, but if we had such a thing I think it could be used to help 'map' a naive programmer's ideas to code.

Or you know, some subset that captures all or most of the ideas in programming, and lets you use that. I think though it'd be so fine-grained as to be equivalent to code, or, clunky, making resulting code inefficient or inelegant.

As for a visual language, if it was 'fine' as above it'd be baroque looking, the equivalent of code, or if clunky, the programs would be simple, or else, hard to represent in just 3 dimensions - there are so many relationships to represent: 'calls', 'inherits' 'one-to-one association' vs 'one-to-many' .. on and on. I mentioned UML in an earlier response, that's probably close to what you're thinking, and even it is not fine-grained enough to map to code completely (or at least, back, from code).
--
"If you can't imagine a better way let silence bury you" - Midnight Oil
[ Parent ]

Yes... (none / 1) (#97)
by GenerationY on Thu Mar 03, 2005 at 03:04:55 PM EST

A lot of good thoughts there. I do actually think as described anyway it would be somewhat clunky and baroque as well, although presumably one wouldn't implement all the features currently seen in C++.

Also, whilst I'm here I haven't replied to all your comments in this thread singly but I am genuinely interested in the general notion of what might be termed "user centric" programming using, as you sort of say, a more ecologically valid set of ontologies (I mean ecologically in the most technical Gibsonian sense, pun not really intended. Don Norman also has a distinct but similar notion of "affordances" to Gibson's which might be more CompSci friendly I guess but a bit less accurate to what I'm imagining). Thanks for all the links and things, much appreciated.

[ Parent ]

Average man as a programmer (none / 0) (#100)
by jobi on Thu Mar 03, 2005 at 06:12:37 PM EST

I think the average man in the street has all the skills necessary [to do programming]

I don't. I teach programming (amongst other things), and I meet quite a few of those average men in my classes. The average man in the street need to aquire a few skills through hard work if he is to do any programming at all, and a few more if he's to do any quality programming. One of the most important (and often underappreciated) skills he needs to aquire is an intuitive understanding of how computers work that is only gained through exposure to computers for literally years.

If he can change the oil on his car, why can't he do the software equivalent?

But what is the software equivalent of changing the oil on the car? Changing the oil certainly isn't anything creative, and if programming is anything, it is a creative endeavor.

[...] master carpenter [...] engineer [...] chef [...] plumber

Strangely enough, these are all professions that takes a few years to learn to do well. I just can't see why you would believe that learning to program computers would be any different.

Generally, it's said that it takes about ten years to become really skilled in any area. I don't see why programming should be any different from, say, playing the violin or athletics in this regard.

Anyway, I suspect that creating that "language" of yours might be a very hard programming task. And that's hard as in "hard AI" hard.

---
"[Y]ou can lecture me on bad language when you learn to use a fucking apostrophe."
[ Parent ]
Creativity in Programming (none / 0) (#101)
by Arkaein on Thu Mar 03, 2005 at 06:40:44 PM EST

I mostly agree with your post, but I have a minor quibble with the creativity part.

As a programmer and computer scientist, I would say that creativity is an important aspect of computer science and in tackling unknown problems in general, but is much less important in pure programming situations, i.e. taking well know methods for solving a problem and turning them into working code.

It's fun to figure things out on your own, but in most cases that non-expert programmers are going to deal with someone has already been there before, and relying on creativity to figure out a solution is only necessary because the programmer is simply not familiar with the proven methods. This isn't to say that programming even in these cases is completely lacking in the need for creativity, as few real world problems map precisely onto the methods learned from a CS textbook, but in most cases it simply boils down to experience needed to recognize the proper method. This would be where the ten years thing likely comes in.

I imagine that as the field of CS matures there will be a greater premium put on people who simply have extensive knowledge of proven methods, and less emphasis on creativity. A progression from somewhat of an art into a more rigorous engineering discipline.

----
The ultimate plays for Madden 2005
[ Parent ]

Well actually (none / 0) (#125)
by GenerationY on Fri Mar 04, 2005 at 11:04:32 AM EST

I don't really think programming should be a creative endeavour.

Its better characterised a problem solving exercise with regard to the implementing a solution adequate with regard to the specification. That its only adequate is important.

In essence then it shouldn't be so hard if you understand (a) the specification, (b) the methods by which you can implement a solution (c) best practice with regard to implementation and (d) a means of evaluating the success of implementation with regard to the specification.

Thats called engineering. The sooner software becomes an engineering rather than a creative discipline the better. People want things that work and do what they want but they are often let down by "creative" programmers who think their "art" is more important than the needs of their customers.

AI hard? I don't think so, there are plenty of implementations that are similar to what I'm saying albeit found in well-defined settings (e.g., Visiquest). Also you can drop the speech marks around "language". If you can represent production rules graphically you can represent grammar graphically.


[ Parent ]

I demand to be able to play the violin! (none / 0) (#135)
by jobi on Fri Mar 04, 2005 at 06:50:44 PM EST

I don't really think programming should be a creative endeavour.
Its better characterised a problem solving exercise


Problem solving is a creative endeavor, unless the problem is trivial, so I don't see how you think that helps you avoid the creative nature of programming. Normally there's little that is trivial about original programming.

it shouldn't be so hard if you understand (a) the specification, (b) the [...] implement[ation] (c) best practice [...] (d) a means of evaluating the success

And all that amounts to a lot more skill and/or tools than the average man on the street possesses, which means you have to study a bit to be able to get the understanding needed.

The sooner software becomes an engineering rather than a creative discipline the better.

Engineering isn't creative? I can't see where you're coming from here...

Why can't I play the violin? Why can't I run a hundred meters in 10 seconds? Why can't I solve complex math problems? Why can't I build a car, a house, a boat? Why can't I write a bestselling novel? Because I'm not skilled in these areas. So why then do you assume (demand, from reading between the lines) that programming should be any different?

I have to ask you again: Do you think that programming is that easy? Either you're a much, much better programmer than I am, or you've never really given it much thought at all.

From some of your responses (Programmings should be easy, programming shouldn't be creative, etc) I get the feeling that you have no idea whatsoever what you're talking about. There's no way we can reduce a complex mathematical problem to an easy-to-understand concept by just making it visual instead of textual. Visualisation helps with some problems, of course, but it's not a cure-all. Some problems cannot be abstracted away without losing sight of either the problem or the solution.

In this case, I don't believe there's a way to do any serious general programming by just arranging blocks - the main problem being that in most cases the resolution of the blocks would need to be at just about the resolution of an individual letter or word - and then what's the use?

---
"[Y]ou can lecture me on bad language when you learn to use a fucking apostrophe."
[ Parent ]
OK, quickly (none / 0) (#141)
by GenerationY on Sat Mar 05, 2005 at 03:20:52 AM EST

I've already conceeded.

Engineering = standards + best practice + rigor. Perfect world, best practice 100%, no creativity required. Never going to happen as not everything is knowable, but software is utterly shit in quality compared to the standards of other engineering disciplines so there is a problem somewhere. Clean maintainable source code is knowable, there are standards and best practice advice around. Yet still people shovel out utter shite. Creativity can be a vice in some cases anyway where it isn't required.

You can build a boat with less expertise than you had to have 100 years ago. You can build a house with a modular kit from Ikea. Etc. etc. Programming is easier today than it was ever before; ever tried to use a magnetic cards? This trend will continue. As it does new concepts will matter but the ceiling will be raised. What do VB programmers care about assembler instructions? Nothing. But 20 years ago they would have had to know all about it to draw a GUI. Yes, some advanced concepts remain but with VB and modern processors they can ignore many of them bludgeon their way through anyway. This absolutely contradicts the above, but you seem to be forgetting that I wasn't thinking that people who can't handle BASIC have the same agenda here as software professionals.

Finally, not that I care anymore, blocks are made of blocks. Your program is one block made up of a set of function blocks etc. down to logical operators at the atomic level. You'd have prefabs presumably. Then again, meh, you'd have to keep your writing insanely modular. Crap idea anyway.

[ Parent ]

You don't really deserve a reply ... (none / 0) (#40)
by Kalani on Wed Mar 02, 2005 at 02:53:19 PM EST

... being as ridiculously hostile as you are. But your response is off-base, so I'll respond to that.

Most people understand simple diagrams. Most people understand simple mechanical and spatial metaphors

If you just choose a particular set of metaphors and go along in life refusing to use any others, you will limit the number of problems that you can reasonably understand. For example, maybe you understand pushing containers around (that's an easy concept to grasp), but if you want to model (say) a generic text processing process that way, you're going to have a very hard time. It's also more likely that your model will be incorrect than if you'd used something like regular expressions or context-free grammars.

In fact, describing generic text processing in terms of pushing around buckets is *exactly* what is meant by missing the forest for the trees. Context-free grammars are the "forest" to the trees of byte twiddling.

-----
"I have often made the hypothesis that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed
[ Parent ]
Oops. (none / 0) (#44)
by GenerationY on Wed Mar 02, 2005 at 04:08:50 PM EST

I was joking :) Don't you know who CTS is?
It was I can assure you mock outrage (c.f., "ridiculously hostile" yes?).
Where I'm from its a signifier of humour...

I think the level you are discussing this at is slightly awry with regard to my point (or at least the point I have in mind). Ultimately its all production rules which are drawn as pictures anyway in books. Its not necessarily textual its symbol manipulation. Thats the whole point!

As regards a visual data flow programming language its just an object you type your regular expression in and connect pipes to and from. But to make things easier we might also have a drop down menu with the most common things you might want to do in it and a written explanation. Easy.

[ Parent ]

Uh huh ... (none / 0) (#52)
by Kalani on Wed Mar 02, 2005 at 05:49:09 PM EST

Ultimately its all production rules which are drawn as pictures anyway in books. Its not necessarily textual its symbol manipulation. Thats the whole point!

I think everybody who writes much software thinks about it on the symbolic level. What's your point? That symbol manipulation is better done in a graphical interface than a text editor? I think that's highly questionable in the general case.

As regards a visual data flow programming language its just an object you type your regular expression in and connect pipes to and from.

What you're doing there is ignoring the thing that's most complex and "simplifying" the thing that's already simple. You're replacing f(x, y) with a box named f, to which a wire named "x" and a wire named "y" are connected. Then you say, "oh just let the user type a regular expression into a text field." But the regular expression itself is the most complex part of that. Can you come up with a graphical representation of regular expressions, or are you just infatuated with the function/parameter:box/wire metaphor?

Again, there's a very limited set of problems where this kind of visual wire/diagram is simpler than "traditional" representations.

-----
"I have often made the hypothesis that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed
[ Parent ]
In that instance (none / 0) (#54)
by GenerationY on Wed Mar 02, 2005 at 06:19:53 PM EST

its not simpler but its not harder either. Its exactly the same as you'd do it already to all intents and purposes as you point out. But the benefit with regard to the problems that graphical data flow model help with are still there. I have no investment in this, I was just thinking out loud and being a bit provocative. I think what would be a problem is if you can find the instance where lines and boxes make something simple harder and the metaphor would shear if I tried to do same trick I just did with regular expressions. I expect many instances do indeed exist.

OTOH what I'd disallow perhaps is examples where we have Joe Public trying to do something ludicrously complex (which is like Joe Public going from changing a light bulb to rewiring his house).

What I was really interested in was the cultural issue, is there any recognition that it might be worth trading off performance/power/flexibility to help democratise the control of computers. I'm getting the feeling that isn't something people are interested in, although at least you have an underlying reason for thinking that; ie. it wouldn't work anyway, which is fair enough.

[ Parent ]

You'll want to know about Alan Kay (none / 0) (#73)
by jongleur on Wed Mar 02, 2005 at 11:45:23 PM EST

He either invented or advanced Object Oriented programming a great deal, and indeed with Smalltalk (latest version, Squeak) he made programming that much faster (a teacher says 4x over C/C++. I don't know whether I believe him). I haven't looked at Squeak but I do understand that children are able to make their own dancing, interacting objects and so on. It's partly due to the power of the supporting tools, as I understand it. But that is the claim. BTW, if you haven't heard of Alan Kay he's one of CS' pioneers and he's pushing at the same stuff you are. Eg he's very unhappy with the current state of the practice; by the nature of Squeak you can tell he's also about democratizing. He was one of the guys at Xerox Parc, where 1) the modern gui 2) networking 3) probably more were invented. You should look him up.
--
"If you can't imagine a better way let silence bury you" - Midnight Oil
[ Parent ]
Sorry (none / 0) (#77)
by Kalani on Wed Mar 02, 2005 at 11:58:04 PM EST

I think what would be a problem is if you can find the instance where lines and boxes make something simple harder

Well first let me explain where it makes something complex into something (somewhat) simple. This is in the area of writing programs with parallel execution paths. With a visual diagram (where sequential instructions are represented as stages along a circuit), you represent the start of two parallel processes by splitting a circuit. This also makes it obvious when one execution path tries to access a resource used by another.

However, the same representation can make otherwise simple things more complicated. For example, multiple calls to specific functions at different places in the program will result in a tangled mess of 'wires' (note that if this is not so, the benefit of representing parallel execution paths must also be lost).

I was just thinking out loud and being a bit provocative.

No offense, but if I had a nickel for every time I've heard somebody suggest this exact thing, I'd have at least a few bucks.

What I was really interested in was the cultural issue, is there any recognition that it might be worth trading off performance/power/flexibility to help democratise the control of computers.

I'm not sure what you mean about democratizing the control of computers. I assume you mean that programming should be comprehensible to the "common man." I would argue that the best way to give the common man the power of computer programming is to give him a programming language that's tailored to the problem domain he's interested in.

On a personal note, I don't feel that programming and "Computer Science concepts" are beyond the grasp of the common man. I am myself a common man, having no college degree or formal training in CompSci.

-----
"I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn
[ Parent ]
Thats not a problem (none / 0) (#93)
by GenerationY on Thu Mar 03, 2005 at 12:04:38 PM EST

In designing any visualisation system you would have the ability to switch on or off the representation of redundancies as required. That would be a good example. I don't see that option would diminish anything.

A mess or wires is no worse than a mess of spaghetti code. At the least the logic behind understanding it is consistent with regard to conceptual underpinnings and intuitive. Not so spaghetti code which may require multiple approaches and multiple interacting complex concepts to understand. You have to teach someone the process by which they can come to understand code, you don't if the logic is implicit within the representation itself.

Finally I think you underestimate the difficulty some people have with mathematical and programming abstract concepts. Thats all I can say about it, but I see it all the time.

[ Parent ]

Well (none / 0) (#95)
by Kalani on Thu Mar 03, 2005 at 12:43:44 PM EST

In designing any visualisation system you would have the ability to switch on or off the representation of redundancies as required.

But I think that the trouble with that is that you can lose the benefit of a visual diagram of program behavior in the process. Where I see the greatest value in this kind of representation is in displaying parallel execution paths -- but that requires all references to values to be explicit (so you can see that thread A and thread B will both contend for resource C).

But maybe you see a different benefit to this kind of representation. Is there something else that you think it'll make simpler?

A mess or wires is no worse than a mess of spaghetti code.

Of course, but the problem is that what looks like a mess in one model will often look like a compact elegant expression in another. 50,000 references to the function "ucase" might look awkward in a wire diagram, but it's perfectly sensible in textual code.

Or, as another poster pointed out, you can use the example of finite-state automatons (a sort of wire diagram for language processing) to model the behavior of regular expressions. A regular expression like "[^a-e]{3}.*?\." could generate a mess of a finite-state automaton, but that's OK because no human being has to deal with it.

I think that's the crux of the matter here. It's important to recognize where a wire diagram representation saves you time and where it gets in your way.

-----
"I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn
[ Parent ]
Concurrency (none / 0) (#99)
by Coryoth on Thu Mar 03, 2005 at 06:01:10 PM EST

If you want a good way to tackle concurrency in an organized way that allows for easy analysis, try something like CSP or CCS process algebras.  With the techniques available there, multithreaded programs become quite trivial to write and analyse.

Jedidiah.

[ Parent ]

REs as diagrams (none / 1) (#92)
by curien on Thu Mar 03, 2005 at 11:15:30 AM EST

Actually, you can easily represent an RE using a series of boxes with connecting wires. They're called finite-state automata.

--
This sig is umop apisdn.
[ Parent ]
Yeah (none / 0) (#94)
by Kalani on Thu Mar 03, 2005 at 12:33:06 PM EST

I think those diagrams are really helpful too. I've written a regex library to convert a regex into a non-deterministic FSA, which is converted to a deterministic one, and it certainly helps to picture the generated FSA.

But I think that the textual regular expression is much easier to manage (and think about) than the generated deterministic FSA. What do you think?

Anyway, I don't disagree that visual diagrams can be useful (as long as they're not used for their own sake).

-----
"I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn
[ Parent ]
Six of one (none / 0) (#102)
by curien on Thu Mar 03, 2005 at 07:12:24 PM EST

I think sometimes it's easier as an FSA, other times as a regex. I'm not a very visual person, though, so the FSAs are of somewhat limited use for me, but I know some people that just "get" the diagrams in a way that doesn't happen with regexes.

--
This sig is umop apisdn.
[ Parent ]
Generally yes (none / 0) (#111)
by saltmine on Fri Mar 04, 2005 at 04:53:59 AM EST

"But I think that the textual regular expression is much easier to manage (and think about) than the generated deterministic FSA. What do you think?"

I would much rather write a regex instead of a DFA/NFA.  I mean, if you've ever used Flex/Lex to write a scanner for a compiler you use regex's and then the Flex tool generates a state based DFA of sorts...well, a DFA that is C code of course.  But the point is a regex should generally be insanely easier to write than diagraming a DFA/NFA.

[ Parent ]

Regular is the weakest set (none / 0) (#112)
by saltmine on Fri Mar 04, 2005 at 05:19:01 AM EST

"As regards a visual data flow programming language its just an object you type your regular expression in and connect pipes to and from."

Generally the only thing regular in a given program is the syntax of it.  But, it is easily shown that if you want anykind of n^k m^k production, regular expressions simply don't work.  So, considering your "pipes" are abstractions recursion/loops I still fail to see how you handle a n^k m^k production of any type.  

I mean, what you have described is simply a DFA or an NFA (if you got some cool AI working) that's able to decide its next state based not only on the current input character but on a sequence of characters.

You won't get very far writing anything of any complexity.

After reading many of your posts I'd like comment.  It's great to be creative and think of "new" things but it's also important to be rational.  You're not just going to get everyday people to become programmers.  It requires a lot of thought and no matter how many pictures a programmer is able to draw (see Rational's tool sets), at the end of the day you're going to have to describe how something works in a very abstract manner.  The theroy of computation is not to be taken lightly.  We use text right now for the same reason we use text to write.  It's an extreamly dynamic form of symbolic expression.  

Why are you so fixated on using pictures?  I mean, this is what cavemen did.  This is what many primitive societies used as the earliest forms of communicating abstractally.  Simply put, letters and words and general text is more powerful.  

If it's so hard to deal with, just think of each letter on your keyboard as a piece to an infinite set of pictures and the return/enter key as your pipes.  See the beauty in this?  It's everything you asked for and it's syntax is even regular!

<forgive any poor spelling..it's late, on some oddball machine without a spell checker and 100 more exuses>  

[ Parent ]

learn to program (none / 0) (#47)
by mpalczew on Wed Mar 02, 2005 at 04:30:56 PM EST

How about a class of people in the world? i.e., everyone who hasn't got time to do (or do the equivalent) of a couple of degrees in computer science?
WTF are you talking about. People write books like, teachyourself C in 21 days. They work. An hour a day for 21 days and you too can program. The "couple of degrees in computer science" talk could only come from some beligerant without a clue.
Most people understand simple diagrams. Most people understand simple mechanical and spatial metaphors metaphors (you put things in containers, if you pass a container to something else you pass the contents whilst you are doing this etc). Most people understand the notion behind assembling subcomponents to make something (engine, bookshelf, etc. I am well aware programming is indeed a abstraction of all that, but why does it have to be some damn abstract? What is the limiting factor?
That is highly simplistic. By the time you have written all these boxes and containers you want to have available, and made sure that they fit together, most of the hardwork is done. Though this is only in the most idealized code. Most code has some spaghetti. Think about it you have dvd player software. Sure In theory one could write such a player by rearranging boxes putting a play button here, a stop button there, and connecting it to some other magical box that decodes an mpeg stream from a dvd player. But when it comes down to it, you still need the code to translate mpeg. Object oriented programing is just an organization of your algorithms. And guess what using Visual C++/Glade/or your favorite rad tool you can do exactly that. Though you still have to link in your magical dvd decoder box. That being said there are some programs that let you program visually. However if you actually want these programs to do anything other than pop up more dialogs and be user interfaces to nothing, you have to write code. People talk about abstraction on a high level, but when it comes down to it programming is a complicated labor intensive process, and there is little to get around the fact. Creating boxes which can later be organized is the hard part.
Its still easier to open files in Explorer. Its more efficient to use the command line prompt perhaps.
Correction: It's more intuative for most people to open files in explorer. For many it's far more efficient to use the command prompt. If you wanted someone to get alot of file managment done, you would hire the more efficient person.
What the fuck is wrong with you nerds?
They know what they are doing better than those who form opinions on things they have no clue about.
-- Death to all Fanatics!
[ Parent ]
Golf clap <nt> (none / 0) (#56)
by GenerationY on Wed Mar 02, 2005 at 06:29:29 PM EST



[ Parent ]
Abstraction visualization - a dream (none / 0) (#67)
by jongleur on Wed Mar 02, 2005 at 11:02:32 PM EST

I've long wished to make a tool that would help visualize abstractions; mostly for help in learning math. I haven't gotten anywhere at all in it, but it would be great if it were possible.

You're saying it might apply to code as well; humm, possibly. You know what I think the problem is though? That it consists so much of different kinds of relationships, and how are you going to show so many in just 3space? Soon you're back to lines with labels, and I bet it'll be only marginally more helpful, if at all, than a regular sequence of definitions / theorems. Still, now that we've got these powerful computers I'd sure like to see someone try.
--
"If you can't imagine a better way let silence bury you" - Midnight Oil
[ Parent ]

Visualizing abstraction is silly, (none / 0) (#74)
by Coryoth on Wed Mar 02, 2005 at 11:47:12 PM EST

As long as your abstractions don't have to live in euclidean, small dimensional space.  Hell, we have problems visualizing 3 dimensions effectively (we have to project to 2 and then allow you to "move around" the space), let alone messing with, say, projective or hyperbolic spaces (though I have seen a halfways decent hyperbolic 3 space viewer).

Basically, mathematics allows for some very weird shit, and you can pretty much guarantee that you won't be able to visualize some of it.

Jedidiah.

[ Parent ]

Just limited subsets at a time (none / 0) (#82)
by jongleur on Thu Mar 03, 2005 at 02:58:54 AM EST

I was thinking, with jiggling, sliding, whatever objects; possibly hand-tuned (though that would reduce its usefulness) to elucidate different relationships/constraints.

I don't know that it's possible, but I don't know that it isn't either. But I agree, 3 dimensions is a small number to be limited to.
--
"If you can't imagine a better way let silence bury you" - Midnight Oil
[ Parent ]

Nothing like VB (none / 0) (#32)
by GenerationY on Wed Mar 02, 2005 at 01:21:15 PM EST

And you miss the point:

The programmers that end up programming this way have no clue and make shitty programs.  

Thats irrelevant. Programmers programming with C++, "hand tooled assembler" (lols) and punch cards have all produced shitty programmes in their time. Consider too that the ultimate value of a programme is meeting a functional requirement as well its technical aspects. Perhaps a "programmer" isn't always the best person to be doing the work.

Besides when programming one likes to have control over their program.

Why is this necessarily the case?

I know where you are coming from but people used to say this sort of thing about WYSIWYG word processing, fly-by-wire, votes for women etc etc, as well.


[ Parent ]

There are UML tools actually (none / 0) (#66)
by jongleur on Wed Mar 02, 2005 at 10:54:40 PM EST

that might be most of what you want - draw your data structures & so on & it'll generate your code for you, or at least its skeleton.

For algorithms/logic of any complexity though I'd say a text editor is faster; I've played with Lego Mindstorms and it was much quicker to just type directly (though, I'm practiced at it). Still though I think code in a text editor is more malleable than blocks on a screen. And if the logic is tough, the hard part is getting it right, not dragging boxes / scribbling text, anyway.
--
"If you can't imagine a better way let silence bury you" - Midnight Oil
[ Parent ]

I know what you mean (none / 0) (#80)
by Battle Troll on Thu Mar 03, 2005 at 01:13:34 AM EST

I know a guy who has a great program in him, but he'll never learn to code. So instead, he wastes countless hours doing this interesting stuff by hand instead of taking it to the next level.
--
Skarphedinn was carrying the axe with which he had killed Thrainn Sigfusson and which he called 'Battle Troll.'
Njal's Saga, ca 1280 AD
[ Parent ]
The visual metaphor tangent (none / 0) (#62)
by whazat on Wed Mar 02, 2005 at 08:17:02 PM EST

Matlab is a fair place to look at if you want visual representations. Used in engineering mainly and so has an engineering bias. One of the reasons that I don't think it has moved into other domains is that most of what joe public might want done and have the expertise to do(that isn't done by Excel and access) is dealing with text (e.g. web scraping and email parsing). And pipes don't work so well in this context as if you have multiple pipes coming from a box it is hard to know exactly what is coming out of each (how long etc).

On a vaguely related note, I'm currently trying to get my head round tensor diagrams, which I don't find easier than the related equation at the moment. But that may just be my unfamiliarity with them.

[ Parent ]

ASSEMBLING OBJECTS... SEND SPIKE (NT) (none / 1) (#25)
by ksandstr on Wed Mar 02, 2005 at 11:59:49 AM EST



[ Parent ]
Lego mindstorms (3.00 / 2) (#43)
by drivers on Wed Mar 02, 2005 at 03:57:18 PM EST

The program environment that comes with lego mindstorms is based on assembling lego looking program blocks. Here's a screenshot courtesy of google image search: screenshot. In this case the programmer is doing single commands (green block) triggered by specified events. You drag the green blocks from the left side of the screen over to where you want them to be in the flow of the program.

[ Parent ]
well, perhaps I'm old school. (2.66 / 3) (#28)
by mpalczew on Wed Mar 02, 2005 at 12:51:56 PM EST

> With today's increasingly fast PCs, with the processor idle 99% of the time

The rate at which computers are getting faster has slowed down.  I have always believed that those spare cycles should be used to have the computer do more for you, and not be wasted.

I have always prefered strongly typed languages.  I believe that a strict framework within wich to program leaves less room for error and less worrying about the choices that the compiler makes.

I believe that we have already reached the point where at least for quite a few applications we have gotten close to all that we are going to get from compiler advances and it is the algorithms themselves that need to be optimized.  No compiler will ever be able to generally optimized algorithms.

> Is there any reason why a future compiler could not turn a decently written Perl script into a chunk of object code that runs faster than hand tuned C?

well, considering that the compiler(the way it works now anyway) needs to compile the perl script everytime it runs, it will necessarily be slower than a c executable.  Startup times will always be longer.  This is also the area where people care about.  I don't hear too many complaints about openoffice being slow when it's started, but plenty about waiting for openoffice to start.

I think your attitude towards software development is too developer centric.  There have been plenty of projects that chose a language not because it was the best tool for the job, but because the developers preferred programing in it.  An example is freenet, which is a total resource hog.  For a program that is supposed to run in the background it is horribly innefficient.  Alot of this has to do with the increased memory footprint and cpu utilization of the java vm.  In order to develop successfull software one has to make descisions primarily based on what makes the user experience the best.  Most projects with lasting appeal have been made this way.  Though there are some exceptions(mozilla).
-- Death to all Fanatics!

Not the point (none / 0) (#122)
by m50d on Fri Mar 04, 2005 at 10:29:56 AM EST

Yes, but compilers for perl will be written. Well, probably not for perl since it磗 such a mess, but for other high level languages. OCaml IIRC already has one. I磎 confident python will get one even though it currently doesn磘 have one. If compilers were written for such languages, I think with enough time they would get to be faster than C.

[ Parent ]
Perl Will Not Get One (none / 0) (#127)
by hardburn on Fri Mar 04, 2005 at 12:04:57 PM EST

Perl5 won't get one, not because it's a mess (it is, but that's not the main problem), but because its implementation doesn't allow it very easily.

There are two ways to implement a VM: bytecode and tree. Java, Python, and Parrot are bytecode VMs, which are more or less like hardware instruction sets. Trees are basically the syntax tree that came out of the parser.

Transferring bytecode to disk is easy--you just write to disk what you have after the compile phase is done. But serailizing an abstract syntax tree to disk is much harder. The tradeoff is compile time--the tree-based implementation is done as soon as the parser is finished.

To get Perl5 into bytecode or native machine code, you'd pretty much have to rewrite its implementation from scratch. Which is hard because, as we agreed before, Perl5 is a mess.

However, it's more or less being done in Perl 5.10, which will be released in two versions--one running on the old implementation, and a new version called "Ponie" which targets the Parrot VM. And Perl6 is bytecode all the way.


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
Perl 5 on Parrot: True compilation (none / 0) (#178)
by ajs on Thu May 05, 2005 at 01:27:49 PM EST

Check out Ponie for details on the front-end for Perl 5 on a VM.

The task is three-fold:

  • Take the P5 source base, run it under Parrot
  • Translate some constructs
  • Replace the P5 runtime with Parrot
We're in phase 2 now, where some hard decisions need to be made.

Perl (the language) isn't "a mess", as suggested. The problem is the same as that with many other single-implementation languages: the code in the wild has come to rely on all of the features of the default compiler, not just those that were intended to be part of the language. This is why P6 is being fully specified FIRST.

Thus, for P5 on Parrot, some code will have to break, but if we can keep that amount down to a level where trivial amounts of changes need to be made to a trivial fraction of the code base, then Ponie will be a roaring success, and hopefully much faster than P5 ever was before.

-- Aaron Sherman <ajs@ajs.com>
[ Parent ]

On typing (none / 0) (#31)
by imrdkl on Wed Mar 02, 2005 at 01:21:08 PM EST

I find your discussion of language typing somewhat confusing. You compare dynamic typing with strong typing, but it seems to me that the only appropriate comparison to dynamic typing is static typing. Python is strongly-typed and dynamically typed.

Oops (none / 0) (#45)
by Arkaein on Wed Mar 02, 2005 at 04:14:44 PM EST

You compare dynamic typing with strong typing

That's my mistake. I never meant to bring strong typing into the mix. I did mean to write static typing.

----
The ultimate plays for Madden 2005
[ Parent ]

Well (none / 0) (#51)
by imrdkl on Wed Mar 02, 2005 at 05:36:52 PM EST

I still voted it up. I did understand your meaning, it just threw me off a bit.

, I would argue though, that strong vs. weak typing is just as important a consideration as static vs. dynamic, at least when choosing a prototype language. Whether it be building a holodeck program, or simply hacking together a nice discussion forum software, weak-typing rates an honorable mention.

[ Parent ]

Your syntax makes me want to scratch my eyes out (none / 1) (#59)
by thelizman on Wed Mar 02, 2005 at 06:47:46 PM EST

...actually, it makes me want to cut your fingers off so you can no longer type.
--

"Our language is sufficiently clumsy enough to allow us to believe foolish things." - George Orwell
"I'm thelizman, and I suck." (none / 1) (#175)
by Harvey Anderson on Tue Mar 15, 2005 at 10:58:51 AM EST

"It's nice to meet you.  So you like Orwell too?  We are cool like in Clockwork Orange and Fight Club!  Geek geek geek geek dur dur dur."

[ Parent ]
Language Consideration (none / 0) (#69)
by The Amazing Idiot on Wed Mar 02, 2005 at 11:14:14 PM EST

Have you taken into account Medium Independant Language Fluctations?

Sometimes, the way you say things, or a way a computer "infers" as in the case of the Holodeck, comes out to mean something totally different.

Good luck. +1

A few points.. (none / 0) (#83)
by tonyenkiducx on Thu Mar 03, 2005 at 05:28:21 AM EST

I voted this -1, but I think you should look at re-doing it and submitting it again. It seems like you just sat down and wrote this without looking into the matter properly and getting some more opinions. A lot of what you talk about is well covered ground, and most of your points are just obvious to anyone who is into programming. If your not into programming, then the article wouldn't make a lot of sense.

I kind of see your point about VHLLs, but at the same time I dont think you can really draw such simple comparisons. Current VHLLs do provide much easier programming, but often at greatly reduced capacity. Which is kind of the point. Until the computer can extract the meaning of what we want, VHLs will remain in the realms of the poor quality game makers we see these days. Then your getting into AI and the realms of science fiction, as our limited applications of AI and our current level of computing power is nowhere near what would be needed.

Tony.
I see a planet where love is foremost, where war is none existant. A planet of peace, and a planet of understanding. I see a planet called
You should realize that VMs are an old concept. (none / 0) (#96)
by lukme on Thu Mar 03, 2005 at 02:42:14 PM EST

Pascal, the language developed for teaching in the late 70's, origonally compiled to p-code which ran on an p-code interpeter.


-----------------------------------
It's awfully hard to fly with eagles when you're a turkey.
Yeah (none / 0) (#115)
by zakalwe on Fri Mar 04, 2005 at 06:21:18 AM EST

They're not even really a language concept. Languages like lisp have been running on both VMs as well as being compiled for a long time now. The VM is just an irrelevant implementation detail.

[ Parent ]
That's a great article (3.00 / 3) (#103)
by Big Sexxy Joe on Thu Mar 03, 2005 at 10:39:26 PM EST

I printed it out and sold it to my roomate for a dollar.  I modified the document extensively without noting my changes and would not allow him to view the source code despite his most ferverant requests.

Do something about it, bitch.

I'm like Jesus, only better.
Democracy Now! - your daily, uncensored, corporate-free grassroots news hour

I have high HLLs talk to each other all the time. (none / 0) (#104)
by skyknight on Thu Mar 03, 2005 at 10:52:18 PM EST

There are these things called text and pipes. They are your friends. Sometimes I even use sockets.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
Please remove (3.00 / 5) (#108)
by Thought Assassin on Fri Mar 04, 2005 at 02:42:46 AM EST

I struggle to find a single line of this that isn't meaningless, factually incorrect, short-sighted or some combination of the three. Why write an article this long when you know so little about the topic? There have been sixty years of research in this field already, so it's laughable to think that you can come with anything useful to say without first accquainting yourself with what is already known. If you are interested, then start reading; it's a fascinating field.

To make a start on your education:

Java, C++ and C# are neither particularly high-level, nor even remotely modern languages.

Static type systems don't really introduce any overhead for rapidly writing small simple programs. Explicit typing where the programmer must name the type of each variable certainly introduces some overhead, but explicit typing has long been obsolete.

Scripting languages tend to gain their advantages for small simple programs by making basic functionality easily usable at the expense of usability for advanced language features and consistency between the two (and also by having convenient niche libraries). This is naturally a disadvantage for large programs, team programming, and maintenance.

Type systems pick up semantic errors, not syntactical ones (dynamically-typed programs still pick up syntax errors before running them!) The inexorable trend is towards finer and finer-grained typing which picks up more and more subtle errors in the programmer's logic. They also allow the compiler to know a lot more about what a piece of code does, and hence make a much better starting point for optimization.

As you say, modular design is the key to programming in-the-large, and the most rigorous definition of a module boundary/interface comes from the static type definition.

Calling into VMs is becoming easier and easier as they become both more language-agnostic and more foreign-call-aware.

Natural language is far too ambiguous to make a good programming language. Instead, your ultimate goal is to create an AI powerful enough to speak natural language well enough for specification refinement and write programs in a real programming language to match those specs.

Finally just a heads-up: your link to "optimizing Very High Level Languages" appears to point to an optimizer for Python instead. Better fix that up.

cheers (none / 0) (#171)
by metalotus on Thu Mar 10, 2005 at 01:46:34 AM EST

This article made me cringe. One of the hardest things for a programmer to learn, is how to abstract an idea from all the concrete details. I know lots of developers who still have trouble with this basic concept. The attitude that optimization rules is usually the first sign of this deficiency.

I've thought a lot about the holodeck program as well. It's more of an application than a programming language.

I wouldn't classify it as 'The ultimate goal'. Consider a fun computer role playing game. This is basically a 'world' some game company created over the course of a year or two. The holodeck is a more physical version of the same thing, except that is finished in a minute rather than a year. A better goal for the imporsonal computer languages of today: A language that teaches you something about yourself as you use it.

[ Parent ]
translation of post: (none / 1) (#174)
by Harvey Anderson on Tue Mar 15, 2005 at 10:55:24 AM EST

"I'm a big old dork. dork dork dork dork dork dork dork dork dork dork dork dork twinkie dork dork dork dork twinkie dork.

You are not as much of a dork as me; therefore, bow before my dorky doo doo. munch munch bucktooth breathe mouth breathe mouth."

[ Parent ]

Curse you, dynamic typing (none / 0) (#109)
by bugmaster on Fri Mar 04, 2005 at 04:37:58 AM EST

You heard me. I hate dynamic typing, for the same reason that I hate global variables.

Debugging is really hard, regardless of what language you program in. That is because debugging is ultimately a battle between yourself and your own misconceptions -- a battle which no amount of technology can help you win (until we get Strong AI).

Thus, any feature that makes debugging even marginally easier is a good thing. This is why most compilers (as well as interpreters) report mundane syntax errors and abort, instead of guessing what the user might have meant.

Static typing is yet another mundane error which could be very costly in the long run. For example, consider the following code:

printSalary(name, salary)
This code calls a function that prints something; the function evidently has two arguments: name and salary. Simple, right ? But what if we look at the function definition, and see something like this (in pseudocode):
printSalary(salary, name) {
  printText(name);
  printText(": ");
  printMoney(salary);
}
Oops ! It looks like we switched the order of arguments to the function !

In a statically typed language, this program would not compile. The types of the function arguments would not match up to the variables you're passing in, and you'd get an error. But, in a dynamically typed language, this program will run just fine -- until you begin to wonder who this person "80000" is whose salary is $0. If your function call is embedded deep inside some other routine, and isn't called all that often, you may never find the error.

I am not making this example up -- I've seen it multiple times in actual production code, some of which was written by me. The situation gets even worse when you start getting into inheritance/polymorphism, or -- Turing forbid -- operator overloading.

Sure, dynamic typing makes it easier for you to write simple programs. Instead of writing "a=5", you have to write out "int a=5"... That's four extra characters, right there ! Wow, what a waste ! However, in reality this inefficiency is minimal compared to the hours and hours of frustration and pain that you'll get when you actually start debugging.

Soft typing should burn in Hell.
>|<*:=

IT wouldn't compile (none / 0) (#114)
by saltmine on Fri Mar 04, 2005 at 05:36:15 AM EST

"printSalary(name, salary)"

"printSalary(salary, name) {
  printText(name);
  printText(": ");
  printMoney(salary);
}"

That would throw a runtime error.  Obviosuly name and salary are different types so during the runtime when it got to "printText(name);" it would see that the type is currently one of "money"? and vice-versa when it gets to "printMoney(salary);".  So, when you do your unit test you would quickly find this.

If they are both just text objects of some sort (ie the same class type) then you would be screwed in any type system.

In a dynamic type environment, things have types, it's just that they are determined at runtime as opposed to compile time and there are bindings on things at a certain point.  The type checker won't see it (because it doesn't exist) but the runtime system will have a hardtime looking up a method for a now known type when it doesn't exist!

As a side note, dynamic checking is used in many scripting languages because programs are generally smaller but more importantly the system doesn't have to run more passes on a type checker during execution.  I personally love it.  I can see why people hate it.

[ Parent ]

Re: IT wouldn't compile (none / 0) (#134)
by bugmaster on Fri Mar 04, 2005 at 04:28:42 PM EST

In a dynamic type environment, things have types, it's just that they are determined at runtime as opposed to compile time and there are bindings on things at a certain point. The type checker won't see it (because it doesn't exist) but the runtime system will have a hardtime looking up a method for a now known type when it doesn't exist!
First of all, most dynamic typing languages automatically convert between types (to make your life easier, of course !). For example, "0" becomes 0, -1 becomes "-1", and "25a" becomes... well that depends on the language.

But the worst problem is that I'd actually have to run my program, and execute the method in question, to find the error. As other posters have pointed out, I should have a wide array of unit tests to ensure that every line of every method gets tested. However, that shifts the burden or erorr-checking from the compiler to myself. So, I need to write error-free (and omission-free) unit tests in order to test my possibly erroneous code... do you see the problem with this ?

In trivial cases, this is actually pretty easy. But, in large projects, having an automated system (i.e., the compiler) that finds even the simplest of errors for you can mean the difference between delivering on time, or delaying for a year.
>|<*:=
[ Parent ]

Type conversions (none / 0) (#136)
by ensignyu on Fri Mar 04, 2005 at 07:43:37 PM EST

First of all, most dynamic typing languages automatically convert between types (to make your life easier, of course !). For example, "0" becomes 0, -1 becomes "-1", and "25a" becomes... well that depends on the language.

No, that's pretty much just Perl and TCL. It's a feature of weakly-typed languages, not dynamic ones. Python, for example, is a strongly-typed and dynamically-typed language. You don't have to declare the type at compile-time, but many operations will raise an exception if it can't do an operation on that type, like converting between a string and an int. You can't even do something like "4" + 3 like you can in Java, although there's certainly other ways to make mistakes with operator overloading.

[ Parent ]

Er (none / 0) (#138)
by ensignyu on Fri Mar 04, 2005 at 08:07:24 PM EST

Not "4" + 3, because that's more like Perl nonsense ... better example would be like "foo" + 3.

On the topic of Perl, I find it kind of dangerous that in Perl, some potentially serious mistakes are only warnings and not runtime errors:

my $x = undef();
print $x->{"a"};

So ... $x is undefined, essentially a NULL reference, yet if you get an item out of the NULL hash, it suddenly decides to initialize $x to an empty hash.

Worse,

my $x = undef();
$x->{"a"} = 3;

Generates no warning at all. It just creates $x out of thin air and goes on its way. Maybe $x is passed as a function argument, and it's supposed to be an object that's been created using the normal constructor, but in this case, you suddenly have an unblessed (classless) object in its place, and if you store that object in a data structure or something, the error might not show up until much later.

I don't think that's reasonable behavior even for weakly-typed languages.

[ Parent ]

Autovivification (none / 0) (#140)
by hardburn on Fri Mar 04, 2005 at 09:35:10 PM EST

Autovivification is there because Perl builds complex datastructures by simply attaching references:

my %h;
$h{foo}{bar} = 1;
$h{foo}{baz} = 2;
$h{foo}{barf}[0] = 3;

The alternative is to add some sort of syntax to specify when you're explicitly adding another level to your datastructure, such as:

my %h;
$h{foo} is {};
$h{foo}{barf} is [];
$h{foo}{bar} = 1;
$h{foo}{baz} = 2;
$h{foo}{barf}[0] = 3;
$h{foo}{barf}[1][2] = 4; # Error if you use strict

But that would require extra syntax (Perl has too much syntax already) and would require extra lines (Perl programmers don't like extra lines).

In practice, I've never found this particularly problematic.

If you still don't like it, the standard perl distribution has Hash::Util::lock_keys so that it's impossible to add new keys to an existing hash.

In short, language design is hard.


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
Static Typing (none / 0) (#116)
by Arkaein on Fri Mar 04, 2005 at 09:05:59 AM EST

Funny you use an example like this, because some of the most fiendish errors I've dealt with were of a similar flavor, but where variables of the same type got mixed up. I done this a few time in 3D modeling or rendering code, where you can easily end up with things like vertex triples (for triangles), small fixed size sets of edges, and so on.

These errors caused neither compiler time nor run time errors, and in some cases the data stored was similar enough between the swapped variables (or the variable that was duplicated and the variable the duplication replaced) that the behavior was wrong, but not in obvious ways or all of the time.

You're right in that these types of situations will always be tough to debug, but my argument is that while certain languages expose bugs of type that others don't, the most difficult class of bugs are possible in all languages.

----
The ultimate plays for Madden 2005
[ Parent ]

Re: Static Typing (none / 0) (#133)
by bugmaster on Fri Mar 04, 2005 at 04:23:15 PM EST

You're right in that these types of situations will always be tough to debug, but my argument is that while certain languages expose bugs of type that others don't, the most difficult class of bugs are possible in all languages.
Absolutely. However, just because hard bugs are impossible to automatically debug, doesn't mean that we should give up on automatically fixing the easy bugs, too.
>|<*:=
[ Parent ]
code size/bugs tradeoff (none / 0) (#152)
by Arkaein on Sun Mar 06, 2005 at 12:41:45 PM EST

just because hard bugs are impossible to automatically debug, doesn't mean that we should give up on automatically fixing the easy bugs, too.

I agree, but in the case of Python vs. C++/Java/etc. I'll take the tradeoff of a few more of the easy bugs for what is likely a significantly smaller set of code to maintain.

----
The ultimate plays for Madden 2005
[ Parent ]

Re: code size/bugs tradeoff (none / 0) (#158)
by bugmaster on Mon Mar 07, 2005 at 05:31:12 AM EST

I agree, but in the case of Python vs. C++/Java/etc. I'll take the tradeoff of a few more of the easy bugs for what is likely a significantly smaller set of code to maintain.
While it is true that a Java program contains more characters than a Python program, I doubt that the Java program contains more code. There's not any major difference between "a=5" and "int a=5"; it's really the same code (most of the time).

Perl and Python may have an advantage over Java because of their libraries, and easy access to regexps. Both of them, as well as Java, have a major advantage over C++ because of automatic garbage collection. But, IMO, dynamic typing is not an advantage at all.
>|<*:=
[ Parent ]

Other savings (none / 0) (#160)
by Arkaein on Mon Mar 07, 2005 at 10:44:49 AM EST

There are other savings that can be had in Python. Inclusion of list, tuple and dictionary (hash table) types directly in the language means that I often can create fairly complex structures implicitly.

Other advantages come in terms of functional mappings. A single function can be mapped to an entire list of items or objects in a single line of python code, and if this function is short enough you can declare it inline as a lambda function. Say you want to square all values in a list:

sqrlist = map(lambda x: x * x, mylist)

This will work even if mylist contains objects for where the "*" operator is overloaded. I haven't really kept up on the newest update to Java, so maybe something like this would be possible with generics and anonymous functions, but you'd probably be better off not doing it.

----
The ultimate plays for Madden 2005
[ Parent ]

Eyes wide shut (none / 0) (#119)
by schrotie on Fri Mar 04, 2005 at 09:57:08 AM EST

Looks like you never programmed a dynamically typed scripting language. Funny thing is, your example would work flawlessly in ruby. To print something, it has to be converted to a string. Everything in ruby is an object (EVERYTHING!) and everything (bolditalicscapslocked!) is ultimately inherited from Object. Guess what, object has a method to_s which returns a string representation of Object. You can hardly screw that. If you swap the orders in the function call, you'll swap printing orders. If that has bad consequences on your program that go unnoticed, than your problem is not dynamic typing but a lack of testing. If you write a large app. you have to write those tests or you'll likely break the project, no matter what language you use.

Sure, dynamic typing makes it easier for you to write simple programs. Instead of writing "a=5", you have to write out "int a=5"... That's four extra characters, right there ! Wow, what a waste ! However, in reality this inefficiency is minimal compared to the hours and hours of frustration and pain that you'll get when you actually start debugging.
Is that so? Well depending on the problem at hand your gain with python/ruby over C/C++ is up to a factor of ten in lines of code. Get that? One tenth the lines of code in VHLL. If you did not grasp that: this implies you have to debug one tenth the lines of code.

The type-mismatch bugs cost no time to debug regardless of language type. You get runtime errors instead of compile time errors, but errors you get. And since you don't compile ruby/python you'll have your results as fast as with a compiler. What costs me the most time are memory bugs especially perforated stacks - does not happen with VHLLs. I hate casting and do it extremely sparingly, but it is done a lot in MLLs and HLLs. And I guess imprudent casting is also hard to debug - does not happen in VHLLs. You obviously make the same logic errors, but you write considerably less code for the same problem in VHLLs, so you make accordingly fewer logic errors.

Your comment makes you look a bit clueless. You should indeed look into ruby or python. The best strategy is prototyping in VHLL, than profile and reimplement time critical stuff in MLL or HLL. I have yet to hear a sane argument against this (apart from company policy and stuff like that).

[ Parent ]

Re: Eyes wide shut (none / 0) (#132)
by bugmaster on Fri Mar 04, 2005 at 04:21:28 PM EST

Looks like you never programmed a dynamically typed scripting language. Funny thing is, your example would work flawlessly in ruby. To print something, it has to be converted to a string. Everything in ruby is an object (EVERYTHING!) and everything (bolditalicscapslocked!) is ultimately inherited from Object.
I have programmed in Visual Basic (shudder), TCL, a bit of Perl, and Ruby. What you say about printing is true -- except that, usually, when I print something out, I want it to print in a certain order. For example, like this:
Smith    50000
Jones    60000
70000        0
McLeod  100000
Can you spot the problem ? It gets even worse with non-trivial examples, when you don't print stuff on the screen, but pass strings, numbers and complex objects into methods of other objects for further processing.

The danger of dynamic typing is precisely that the interpreter will run your program even if you've really made a stupid mistake, because the interpreter has its own ideas about how your program should run.

You are right when you say,

If that has bad consequences on your program that go unnoticed, than your problem is not dynamic typing but a lack of testing...
You get runtime errors instead of compile time errors, but errors you get.
In other words, instead of the infallible (or very nearly so) compiler doing the basic testing for me, I, the fallible (and busy) human have to write additional tests. I think I have better things to do with my time, don't you ?
>|<*:=
[ Parent ]
the infallible compiler - hark, hark! (none / 0) (#137)
by schrotie on Fri Mar 04, 2005 at 08:06:46 PM EST

I do most of my programming in C++, a statically, though not strongly typed language. You probably program in the same or closely related language (C, Java, Pascal, Delphy ...).
All of these languages are badly broken, C++ being probably the worst, but that may be because I know it best. It's a cruel trick of history that that language family won language evolution, and I can only consider it bitter irony of you to ascribe godly capabilities to the compiler.

If you were an Ocaml programmer I would probably have to agree, but the curly braces in your original comment give away your blotted descent :-) From what I hear functional languages (ML descendants) can contrary to your claims find hard bugs for you. But the curly braces languages can't. And the C++ type system gets in my way more than it helps me. Anything seems to be better than that system: both programmers of functional languages and programmers of dynamically typed languages are more productive than their poor cousins. When the former are at home playing with their kids, the later are still at work closing some stupid curly braces. That wasn't put very authoratively, but you can google up numbers to support that view. It's not a knock out argument, but it's astrong hint that there is something wrong with the Cobol heritage. It might be though, that the curly guys do it for the money, while the others actually like programming enough to learn obscure languages ...

So unit testing is stupid? Ok, agreed. You are right and the better part of the industry is wrong. I mean everybody knows they are in the business of wasting money, right? </irony>

Have I been trolled?

[ Parent ]

Re: the infallible compiler - hark, hark! (none / 0) (#145)
by bugmaster on Sat Mar 05, 2005 at 03:21:34 PM EST

All of these languages are badly broken, C++ being probably the worst, but that may be because I know it best.
You're right about C++; I hate that object pointer crap. However, I think you're wrong about C, as C is nothing but a thin shell above assembly language. It's not designed to be powerful, it's designed to be compact, and it works wonders for embedded programming.
From what I hear functional languages (ML descendants) can contrary to your claims find hard bugs for you.
How do they do that ?
When the former are at home playing with their kids, the later are still at work closing some stupid curly braces.
Uh... closing parentheses of any kind is really not that much work. It's actually helpful at times, because it helps you think about what blocks in your program are doing what. Surely, a genius of some kind could envision his entire 1e6-line program at a glance without any braces... but I'm not that genius, and I suspect that neither are you.
So unit testing is stupid? Ok, agreed. You are right and the better part of the industry is wrong.
Huh ??? I never said that unit testing is stupid. That would be like saying that loops are stupid. What I said was that it's stupid to have to write unit tests for small yet very harmful errors that the compiler can automatically detect for me. I'd rather write unit tests for my actual logic.
Have I been trolled?
No, but apparently I have...
>|<*:=
[ Parent ]
trolling, trolling, trolling ... (none / 0) (#154)
by schrotie on Sun Mar 06, 2005 at 04:04:14 PM EST

... though the streams are swollen

No, but apparently I have...
Ok, sorry, no I'm not trolling.

On C
I agree that C is not as bad as it is frequently made. At its time (i.e. 30 years ago) it was indeed a major achievement. But from todays perspective it seems alltogether far to stupid for large projects (a common rule of thumb says that C breaks at about 50.000 lines when particular care is not taken to separate "namespaces") and - concerning our discussion - its type system is badly broken. Whenever I compile other people's code, I get dozens (at least) of warnings from the type system. These warnings are commonly ignored because they are much too frequent. Still some of these warning point out serious problems that are veiled under the warning flood. On the other hand some type errors go unnoticed by C's type system. In conclusion a lot of times C's type system gets in your way while at times it does not detect serious problems.

On functional programming
I'm not proficient with that. Those languages apparently have an incredibly intelligent type system. The type system is static and implicit. That means you barely or never (depending oin the language) tell the compiler which types you are using. This is infered from your code. And this inference system is said to be able to ocasionally spot logic errors. Though what it does is not tell you "Hey dumbass look what you've done there, this'll do foo and certainly not what you expected" but they'll assign weird types to your broken code. Functional languages can also not break in many ways that C and company can.

On parenthesis
This was a pun. VHLL are more productive for other reasons than not having to close curly braces. But a dynamical type system is part of the productivity boost. I haven often cursed C++ for not letting me do some kind of abstraction. In ruby/python your code will work if you objects respond correctly to the requested messages. In C++ I sometimes have to build stupid nonlogical hirarchies just to satisfy the stupid compiler. Hirarchies are very valuable, but not for satisfying the compiler for crying out loud. I want to structure my code logically, I want to encapsulate functionality and namespaces logically, but I do not want to have to argue with the damn compiler every time I want to abstract something differently for a certain task.
So in C++ you make a prototype (where you may have to choose from the available forms of abstraction: inheritance, composition, templates, makros and mixed forms), make it work, than marry it to your existing code, quarrel with your hirarchies, and finally make it work again. In dynamically typed languages you just make it work.

On Unit testing
Sorry, I misunderstood you on this. I think a unit test should probably catch the argument exchange problem you presented in your original code - at least if that problem has already occured at that point. If you find such a logic bug, you should write a test to catch it so that you can be sure, you fixed it for good.

[ Parent ]

Re: trolling, trolling, trolling ... (none / 0) (#157)
by bugmaster on Mon Mar 07, 2005 at 05:27:04 AM EST

I agree that C is not as bad as it is frequently made. At its time (i.e. 30 years ago) it was indeed a major achievement. But from todays perspective it seems alltogether far to stupid for large projects (a common rule of thumb says that C breaks at about 50.000 lines when particular care is not taken to separate "namespaces")
Right - C is unsuited for large, convoluted projects that require managing complex data structures -- because the only data structure C has is a struct. Just because C is great for some things, doesn't mean it should be used for everything.
Whenever I compile other people's code, I get dozens (at least) of warnings from the type system.
The problem here is not with C -- it's with people who try to build an entirely different programming language (such as, oh, I don't know, WINDOWS API) on top of C, armed with nothing but macros and typedefs. What ends up happening is a horrible, convoluted mess of spaghetti code, that approximates a C++ or Java interpreter in some fashion, but is not nearly as good. Would any sane man use Hungarian notation if he had the power to use actual inheritance ? I doubt it.
In ruby/python your code will work if you objects respond correctly to the requested messages.
Yes, but I claim that it's much more productive to have a system that informs you right away of all the places in your code where objects won't respond to the requested messages.
In C++ I sometimes have to build stupid nonlogical hirarchies just to satisfy the stupid compiler.
What do you mean ? I have found myself in this predicament in Java, but never C++, since C++ has multiple inheritance. Can you give an example ?
I think a unit test should probably catch the argument exchange problem you presented in your original code - at least if that problem has already occured at that point.
Exactly. What if the problem has not yet occurred, and I (being the fallible human that I am) have not yet constructed a unit test for it ?
>|<*:=
[ Parent ]
dystatical (none / 0) (#159)
by schrotie on Mon Mar 07, 2005 at 08:25:40 AM EST

The problem here is not with C -- it's with people who try to build an entirely different programming language (such as, oh, I don't know, WINDOWS API) on top of C, armed with nothing but macros and typedefs. What ends up happening is a horrible, convoluted mess of spaghetti code, that approximates a C++ or Java interpreter in some fashion, but is not nearly as good.
That might be a question, that leaves too much to personal tastes to be argued consequently. I would say if people using a system make the same mistake again and again (in this case ignoring warnings), than the problem is not with the people but with the system - especially if other systems that solve the same kinds of problems are not suffering from the same malady.
Some huge open source projects (e.g. Gnome) are mostly written in C. They implemented an Object model in C to do this, but the important point is: it is possible. C just makes it hard. Other languages show that type systems (e.g. strong, implicit, static systems or weak dynamic systems but not weak static systems as C uses) can be efficient and practical while C IMHO fails to prove the worth of its type system.
I agree that static typing makes sense, when the available types are few enough to keep them all in mind. It has been shown that such systems can work very well (not by C, though). But today, with OOP, even mid sized projects have hundreds or thousands of types. In such complex systems it can be a great advantage when you just can make it work and don't have to care what the compiler thinks of your hirarchies.
People are very productive in dynamically typed languages. This s not up for discussion, it is a fact. This strongly indicates that your fears of dynamic typing may be irrational.

What do you mean ? I have found myself in this predicament in Java, but never C++, since C++ has multiple inheritance. Can you give an example ?
I once had to abstract methods. A method could have arbitrary many inputs and outputs (doubles), and those values could be arbitrarily routed through the program (a cybernetic system simulator). The base class was called Cymod. Some such modules would only get inputs from the configurable module network (those were called Plug), others would only provide input for modules but get their input from other sources (those were called Socket). Plug and Socket were inherited from Cymod. But most modules both got their input from other such modules and provided input for other modules. Such were called Node and were inherited from both Plug and Socket. This implied multiple inheritance that inherited from Cymod twice - such a construct is called a diamond. Such diamonds are possible to implement but I'd strongly advice against it. They cause all kinds of problems. You can fix all of these problems, but it is a lot of work.
For the same project I wrote a dynamics simulation. I built it on top of the ODE dynamics library, which had a C++ wrapper. The provided API hirarchy sucked for my purpose, so I put my own hirarchy on top of it, just to be able to abstract my physical objects. Different aspects of such objects were implemented in different parts of the API hirarchy. But my objects had inertia, could collide, could be drawn and more. To save time I used parts of the original hirarchy and then had to fix problems with multiple inheritance and such.
In ruby both problems would have been much simpler due to dynamic typing.

Exactly. What if the problem has not yet occurred, and I (being the fallible human that I am) have not yet constructed a unit test for it ?
Than you have an undiscovered bug. I have tons of those, want some? :-)
The question is not "Does dynamic typing cause trouble?", but "Does dynamic typing cause more trouble than it avoids?" I have tried to argue, that dynamic typing saves you a lot of time and you have to spend only a minor fraction of this time on fixing bugs caused by dynamic typing. I cannot force you to accept that view, you will probably have to find out yourself.

[ Parent ]
Re: dystatical (none / 0) (#161)
by bugmaster on Mon Mar 07, 2005 at 03:20:00 PM EST

Some huge open source projects (e.g. Gnome) are mostly written in C. They implemented an Object model in C to do this, but the important point is: it is possible.
Anything is possible. Ultimately, you can program anything you want on a Turing machine. That doesn't mean you actually have to go out and do it, however. C is unsuitable for large projects, because it has no garbage collection and no OOP; types have nothing to do with it.
People are very productive in dynamically typed languages. This s not up for discussion, it is a fact. This strongly indicates that your fears of dynamic typing may be irrational.
Well gee ! Since you say it's a fact, it must be a fact, right ? There, discussion over !
I once had to abstract methods. A method could have arbitrary many inputs and outputs (doubles), and those values could be arbitrarily routed through the program (a cybernetic system simulator).
I am not sure what a "cybernetic system" is. If that's a kind of neural network, then you probably should've used an array, a list, or some other type of collection. You could then pass in this collection as a parameter to your method, and you could return a collection, as well. And, since all the inputs and outputs are doubles, the typing system neither helps nor hinders you (until you try to pass in a string).

The rest of your description sounds like an OOP issue, not a typing issue. Multiple inheritance is notoriously hard (which is why Java doesn't have it in full capacity). It's even harder in dynamically typed languages, where you may potentially not know at all which implementation of a method will be called when an object recieves a message.

A common way of alleviating confusion is to replace multiple inheritance with multiple containment. I.e., in Java, you'd write something like this:

public interface Intertial { ... }
public interface Collidable { ... }
public interface Renderable { ... }

public class IntertiaHandler implements Inertial {
  // handle some inertia logic here
}
public class CollisionHandler implements Collidable {
  // handle some collision logic here
}
public class RenderHandler implements Renderable {
  // handle some render logic here
}
public class LumpOfRock implements Collidable, Inertial, Renderable {
  CollisionHandler colHandler;
  IntertiaHandler inrHandler;
  RenderHandler renHandler;
  // ...
}
I'm not saying that this is a good pattern for your project -- I have no idea how your project works -- I'm just saying that's one alternative way to do it.

I don't understand why you wanted to mix-and-match parts of some original class hierarchy. It sounds like you were trying to defeat the original author's purpose behind his code. True, this is easier (though not by much) in dynamically typed languages, but ask yourself: is that really what you want to do ?

Than you have an undiscovered bug. I have tons of those, want some? :-)
Sure -- I have a system that discovers such bugs automatically. Want some ? :-)
The question is not "Does dynamic typing cause trouble?", but "Does dynamic typing cause more trouble than it avoids?" I have tried to argue, that dynamic typing saves you a lot of time and you have to spend only a minor fraction of this time on fixing bugs caused by dynamic typing.
However, I am still not convinced. So far, the only tangible benefit from dynamic typing is the time it saves you on keystrokes ("a=5" vs. "int a=5"). I claim that this time is minor, and pales in comparison with the time you spend debugging all these "undiscovered bugs". You have tried to provide an example of another way that dynamic typing saves you time, but it was not detailed enough to demonstrate your point. I remain unconvinced.
>|<*:=
[ Parent ]
Your subjects are not creative (none / 0) (#163)
by schrotie on Mon Mar 07, 2005 at 05:53:37 PM EST

Well gee ! Since you say it's a fact, it must be a fact, right ? There, discussion over !
Cool! It's that easy? Should have known earlier!

Cybernetics simulator
It's kind of like a neural network, where neurons can implement arbitrary functions. My design was logical but I finally got rid of the diamond and implemented plug functionality with composition. Doing that in Plugs and Nodes was simpler than the hassle with the diamond.

Dynamics simulation
It was a rather small part of the whole project (maybe 1000 or 2000 lines). I swallowed my lust for beauty and wanted to get it running with the minimum effort. That I did. And it was a hassle. What you propose implies a hirarchy designed from scratch. I know how I would have done it, but I did not want to invest the time. The existing API was a barely OOP C-wrapper (not even using polymorphism). It does not matter. I could have argued for days with the compiler to finally get a well written, logical hirarchy. But it was not worth it. And as it was it was a hassle that would not have occured with dynamic typing. But thanks for trying to fix my programs.

However, I am still not convinced.
Och. Above you said the discussion was over? Well, to get back to the beginning that led you to this ironic statement: The discussion is certainly not over, since existing dynamic languages are not C++ without static typing but a whole lot more. This leaves ample room for discussion, why they are more productive. The fact, that they are, does however indicate that dynamic typing is not the showstopper you claim it to be.
If you are really interested in the issue, rather than in winning a discussion: Language level as used in the original article above, probably refer to capers language level. The reason languages are called "high level" is that you need less lines of code for solving the same problem than in other languages. The difference between ruby/python and C++/java is very significant. Of the languages from the linked table of which I know the type (about half of it), almost all the winners are dynamical or implicitely typed and all have strong typesystems (as opposed to C/C++, which are weakly typed). All the loosers I recognise are statically typed. I know, you are still not convinced, since what's counted is not the time needed for debugging the horrors of dynamic typing, but the mere lines of code. It is still an indicator, that static typing causes more trouble than having to write out the occasional "int" (which would not even enter the lines of code count).
The best C++ book I yet read was by Bruce Eckel, who is (I think) also on the C++ standards commitee. Here is what he has to say on that issue (he is a huge python fan, so guess what). I particularly like the part about the 7 +- 2 things one can keep in one's head (which is a proven biological fact for most humans, so discussion over ;-> ). And the stuff about rapid redesign. I am a huge fan of refactoring and dynamic typing makes that much easier.
Finally there is my experience. I have written some projects in ruby, no big ones though. It is a hell of a lot more productive, only partly due to dynamic typing, but there you go. And it is fun, it does not get in your way. I love it and would recommend it to enyone who actually likes programming.

No, I don't expect you to be convinced.

[ Parent ]

Re: Your subjects are not creative (none / 0) (#164)
by bugmaster on Mon Mar 07, 2005 at 09:05:48 PM EST

The existing API was a barely OOP C-wrapper (not even using polymorphism)... And as it was it was a hassle that would not have occured with dynamic typing.
I just don't see the connection. The original API was crappy, so, the solution is... dynamic typing ! Nope, still makes no sense. If the API is designed poorly, it doesn't matter what language you use, not even Lisp will save you. It will still suck. I guess I'll need an example in order to understand what you mean.
The discussion is certainly not over, since existing dynamic languages are not C++ without static typing but a whole lot more. This leaves ample room for discussion, why they are more productive.
I think you hit the nail right on the head, here. I claim that the "...a whole lot more" part of the new languages is so powerful that it compensates for the loss of productivity due to dynamic typing. You claim that dynamic typing is the major contributor to productivity. So far, you haven't explained to me exactly how dynamic typing contributes to productivity (besides saving keystrokes), whereas I have explained how it can hinder it (more errors, harder to find errors, reliance on unit tests which might be forgotten). Thus, I remain unconvinced.

I read Bruce Eckel's article, and it seems that he agrees with me, not with you. He says repeatedly that strong typing is a good thing:

We need help in order to create accurate programs, and it's pretty hard to argue against strong typing. The type system is the water in which our object- oriented fish swim, and to allow holes and back doors says "these things are true about a type, but you can only rely on it if people know what they are doing and are behaving well," which is not very reassuring. Strong typing actually helps us think about our object models by ensuring their proper behavior.
I agree completely, especially with the last sentence. He then goes on to say,
Put another way, I don't think you will need extra unit tests in order to produce syntax checking [for dynamic typing], but that the syntax checking will fall out naturally when the unit tests exercise the class interfaces. I don't have direct evidence for this other than not having to do this extra work myself.
Well, I had the personal experience of having to do the extra work, so I guess YMMV.

Bruce Eckel also describes the problems with operator overloading in C++, and with checked exceptions in Java. He is absolutely right about those; both things are a pain (though Java fixed the exceptions recently). I wasn't thinking of the copy constructors and exceptions as parts of the type-checking system -- that was probably wrong of me. I wholeheartedly agree with Bruce Eckel that these things are pure evil; however, my original argument about strong typing did not take them into account. I was thinking of the lowest possible level of the typing system, which ensures that correct messages are passed to objects, and stops incorrect messages from being passed in at compile time. I still stand by my original statement: such a system is a good thing.

Finally, Bruce Eckel is completely right when he says that strong typing doesn't automatically prove that our program works correctly. That thought has never occured to me, because I personally think that anyone who relies on the compiler and nothing else for program correctness is, to put it mildly, completely insane. I support strong typing because it helps me get to the correctness-checking stage faster, not because it checks correctness for me. He is also right in saying that type-checking should be taken to the extremes; I would add that nothing should be taken to the extremes, because otherwise you get a monster such as Xtreme Programming of doom.

Which brings me to my next point. You keep saying that dynamic typing lets you hack things out quicker. Firstly, please provide an example, because, try as I might, I can't come up with one where typing of any kind would make a major difference (excluding evil things such as strict checked exceptions and operator overloading -- if those indeed count as parts of the typing system). Secondly, while I do believe that refactoring is a very good thing, I have found that the need for constant refactoring is a good indicator that you're doing something horribly wrong. Prototyping is all well and good, but, at some point, you have to stop prototyping and start writing actual code.
>|<*:=
[ Parent ]

Interrupting... (none / 1) (#165)
by Arkaein on Tue Mar 08, 2005 at 12:08:54 AM EST

Sorry to interrupt the ongoing conversation, but I felt compelled by your repeated confusion (at least in what you've written) of strong and static typing. You quote the argument in favor of strong typing which, let me emphasize has nothing to do with static vs. dynamic typing! Python uses strong, dynamic typing; this means you will get a runtime exception if you attempt to use a string where an numeric argument is required, for example.

I sincerely hope you aren't trolling, but seeing this kind of ongoing issue when the difference between strong/static typing has been spelled out in multiple comments by myself and other makes me wonder (and BTW, if you didn't see my explanation in another comment my one reference to strong typing in the article was a mistake, I meant static).

----
The ultimate plays for Madden 2005
[ Parent ]

Is he trolling? (none / 0) (#166)
by schrotie on Tue Mar 08, 2005 at 05:48:56 AM EST

Do you think bugmaster is trolling? I continually have that feeling, but I'm not sure, so I argue on ...

To bugmaster: You completely misunderstood Eckel. The only weakly typed languages I know are C/C++. I have have never argued for weak typing, and I have repeatedly written that the type system of C/C++ is broken, exactly because it's weak. ruby/python are both strongly typed.
Eckel repeatedly says that dynamic typing (in e.g. ruby/python as opposed to C/C++/Java) works amazingly well, even in large projects. Those projects do even have a surprisingly low bugcount, which contradicts your claims that dynamic typing leads to ample bugs that would have been caught by static typing. I understand your reservation. The success of ruby/python might be a success instead of dynamic typing rather than because of.

Well, Bugmaster, that's it. I'm not on a mission of converting you. The debate that ours is tiny part of has raged for years and we are not going to settle it. Discussing with you was insightful though, even if you were indeed trolling - if this is not the case I apologize for suspecting such. However, if you are really a troll, congratulate yourself for being a master that brings out the best in trolling (one could probably argue that Sokrates was one such troll). So thanks for the discussion and fare thee well.

Thorsten Roggendorf

[ Parent ]

Less debugging (none / 0) (#120)
by m50d on Fri Mar 04, 2005 at 10:25:16 AM EST

I hate coding in compiled languages, because there are two stages of debugging - making it compile, then making it work, which necessitates frequent trips back to the make it compile stage. With a dynamic language there is only one debugging phase. The difference might be all in my head in terms of time, but it does mean I have much more of a feeling of achievement for having debugged one section. It does feel much nicer, really.

[ Parent ]
Code review, Code review, Code review (none / 0) (#123)
by jrincayc on Fri Mar 04, 2005 at 10:39:34 AM EST

Here is a hint: Read the code you just wrote before hitting compile. (It helps if you make a list of mistakes that you commonly make so you know what to look for. Don't forget to add new mistakes as you realize you are missing them in the review.) I have found if I carefully review my code, I will usually find the simple typo's and usually some of the more complicated bugs. I also look especially close at bugs that the compiler will not find, like x,y transpose mistakes. If I am careful, I can get the number of bugs found by testing and compiling to less than around 1 per hundred lines of code.

[ Parent ]
Re: Less debugging (none / 0) (#131)
by bugmaster on Fri Mar 04, 2005 at 04:13:08 PM EST

It sounds like you hate compiled languages for the same reason that I like them: the compiler catches most of your really stupid errors (typos, switched function arguments, unreachable code, etc.) in a single pass. I personally cannot imagine why you wouldn't want the compiler to do that, unless you are addicted to pain. I personally don't find it exciting having to find and fix stupid errors manually.
>|<*:=
[ Parent ]
Compile Phase (none / 0) (#139)
by hardburn on Fri Mar 04, 2005 at 09:18:49 PM EST

Most "scripting" languages have a seperate compile phase, which either compiles to bytecode (Python, Ruby) or to a tree representation (Perl). Many times, the compile phase can be run seperately. With Perl, "perl -c" will run the compile phase only (with the cavet that code in a BEGIN block will still run, but this isn't common).

So I think you're complaining over non-issue.


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
Re: Compile Phase (none / 0) (#144)
by bugmaster on Sat Mar 05, 2005 at 03:12:40 PM EST

Most "scripting" languages have a seperate compile phase, which either compiles to bytecode (Python, Ruby) or to a tree representation (Perl)... So I think you're complaining over non-issue.
Fair enough. If the language has a mechanism to turn off soft typing (by pre-compiling everything on demand), then I've got no beef with it.
>|<*:=
[ Parent ]
Even more insidious with dynamic typing... (none / 0) (#147)
by skyknight on Sat Mar 05, 2005 at 06:25:31 PM EST

is method invocation for objects. Since the type of the object is not known until run time, binding of the method invocation to either a function or a virtual function table cannot happen until the the object method call actually occurs.

As such, you may have a class with a method called doFoo, and somewhere in the code you might have an object of this class called o, and you might invoke o.doFo0(), accidentally mistyping its name. Your program will compile, but it will crash when it reaches this instruction as there is no doFo0 method. This is not a big deal if your programs executes such that it hits this line quickly, but if the code path is such that you don't reach this bogus line until after running for a couple of minutes it can be a very aggravating experience. Good unit testing can mitigate this problem to some extent, but that is still not a wholly satisfying solution in my mind.

Personally, I long for a language with the power of Perl, the cleanliness of Python, the guardedness of Java, and (when I want it) the low level access of C. While we're at it, I want a pony, and failing that, I want better access to Prolog from the more mainstream programming environments.

Programming language design is a notoriously hard problem. We have a panoply of flawed languages as evidence of this, which is to say, all of them.



It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Pony ! (none / 0) (#148)
by bugmaster on Sat Mar 05, 2005 at 08:38:05 PM EST

Personally, I long for a language with the power of Perl, the cleanliness of Python, the guardedness of Java, and (when I want it) the low level access of C.
Personally, I'd settle for Java with templated types (C# ain't it). But a pony would be nice, too, so I could ride it to work.
>|<*:=
[ Parent ]
I thought 1.5 has templated types. (none / 0) (#149)
by skyknight on Sat Mar 05, 2005 at 08:52:47 PM EST

In any case, Java's iteration over collections is tedious, and I rather like Perl's native support for regular expressions and such.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Explicit typing considered... (none / 0) (#169)
by gruk on Tue Mar 08, 2005 at 12:22:03 PM EST

Sure, dynamic typing makes it easier for you to write simple programs. Instead of writing "a=5", you have to write out "int a=5"... That's four extra characters, right there ! Wow, what a waste !

From a "write once, never maintain" POV it's not too bad. But, what happens tomorrow when you need your "a" to be a float? How much time does it take to propagate this all through the codebase?

Saying that. It's not all bad, explicit typing. I usually write my code and see how much type the compiler can infer and where it warns me it cannot derive types and thus needs to use less efficient constructs. If it's close to the critical path, I then declare the types and my code is faster.

[ Parent ]

typedef (or macro) (none / 0) (#172)
by Viliam Bur on Thu Mar 10, 2005 at 08:15:35 AM EST

But, what happens tomorrow when you need your "a" to be a float?

The good programming language should allow programmer in such situation to define an abstract type "type_of_a", which could be int, float, or whatever. Like this:

#define type_of_a int;
type_of_a a = 5;

And later:

#define type_of_a float;
type_of_a a = 5;

Just because some things in code may later change, we do not have to give up all hope for compile-time checking...

[ Parent ]

Won't work (none / 0) (#110)
by bugmaster on Fri Mar 04, 2005 at 04:45:47 AM EST

typical usage scenario goes like this: the user would first describe the general setting (application) in just a few sentences. The computer would produce a prototype setting, presumably by calling upon an incredibly vast knowledge base containing huge sets of templates.
That won't work. ("That won't DO anything !" *) Essentially, what you're trying to do is build Strong AI by using a giant lookup table, maybe with some hard-coded rules. This has been tried before, and the consensus is that you'll need some sort of a learning mechanism; building AI by hardcoding a bunch of data is simply not an efficient enough process.

*10 geek points to whomever can spot the reference !

>|<*:=

another approach (none / 0) (#117)
by Arkaein on Fri Mar 04, 2005 at 09:19:57 AM EST

Maybe the natural language processing is stretching things a bit, but it is not the only possible interface to such a high level programming system.

A simpler approach might some sort of catalog system. The user would start by finding a top-level template in a component catalog. This catalog would be categorized, sorted and indexed to make this process a little less painful. In an above comment I gave an example of creating a web browser with a specialized thumbnail view of all open pages instead of using tabs. The user would first pick out a web browser template, say Firefox is in the DB so they use that. Next they pick an icon view from the Konqueror File Manager in KDE, which can show thumbnail views of many types of files (text and html in addition to images).

The tricky part would be figuring out exactly how to merge the two elements in a way that "Just Works" without any fuss. It would probably require a great deal of component interface standardization, but I don't think it's too optimistic. Objects in Microsoft Office have been cross embeddable between applications for years, and KDE has lots of component parts that are shared between applications, such as common text editor parts.

Hopefully this clears up the intended separation betwen the the natural language processing system and the template/component database.

----
The ultimate plays for Madden 2005
[ Parent ]

Re: another approach (none / 0) (#130)
by bugmaster on Fri Mar 04, 2005 at 04:10:37 PM EST

The tricky part would be figuring out exactly how to merge the two elements in a way that "Just Works" without any fuss.
Yeah, that's the tricky part, all right. Ultimately, what the original poster wanted to do is tell the computer, "make me a cookbook datavase out of MySql and Perl", and expect the computer to reply, "here you go, master".

This step would be impossible to achieve -- at least, not for non-trivial cases -- without some sort of Strong AI, because the computer would have to automatically understand what you want it to do. So far, we haven't been able to create a computer like that; this is why we have programming languages.
>|<*:=
[ Parent ]

We'll have strong AI ... (none / 0) (#118)
by schrotie on Fri Mar 04, 2005 at 09:28:41 AM EST

... some day. I work on the outer brims of AI research and I expect that we'll eventually have strong AI. I don't expect that that happens in my livetime though (i.e. not in the next 60 to 70 years).

What he proposes does probably not require strong AI though. The moral implications of programming a strong AI alone are a nightmare for todays ethics. But anyway, apart from what you commonly hear in the media, AI research is in its infancy. It is only maybe 15 years old. The research before that was probably mostly wasted (with the exception of the very early birds like Turing and von Neumann). They ran into all kinds of dead ends. I think the research is now on the right track. Trouble is that track leads through unpenetrable jungle and contempory researchers only have scissors to cut through the undergrowth.

The most basic functionality you need to understand human language is fault tolerance and relevance estimation. Common technologies for this are artificial neural networks (humans have noisy, unsymmetric, recurrent monstrosities - nobody has a clue how to keep such a system stable) and bayseian nets. There are actually amazingly few concepts on what could be called "information ecology". And AI still suffers from engeneering concepts. Biped robots for example have nothing at all to do with walking humans. They do something completely different (trouble is, nobody knows what humans do, they cannot however do what robots do, because their brains are too slow and too bad at physics - and they are too expensive to be wasted on walking). AI research is fundamental research. Don't expect applications anytime soon.

But you might want to prepare your children for it :-)

[ Parent ]

Information ecology (none / 0) (#128)
by whazat on Fri Mar 04, 2005 at 01:35:27 PM EST

Pretty much describes what I started working on here.

I have worked more on it than that website shows, but have got sidetracked attempting to semi-formally justify the expected messy/parrellel/redundant approach rather than the clean provably correct approach such as AIXI and the Goedel Machine.

[ Parent ]

Re: We'll have strong AI ... (none / 0) (#129)
by bugmaster on Fri Mar 04, 2005 at 04:07:16 PM EST

I work on the outer brims of AI research and I expect that we'll eventually have strong AI. I don't expect that that happens in my livetime though (i.e. not in the next 60 to 70 years).
I never said that Strong AI in general won't work. I see no reason why we shouldn't eventually have it. What I said was that building a Strong AI by using a lookup table (or fixed rules) is a futile task.
>|<*:=
[ Parent ]
Static typing (2.00 / 3) (#121)
by jrincayc on Fri Mar 04, 2005 at 10:28:15 AM EST

First point. Compiler found bugs can be fixed on average in less than a minute. Testing found bugs take longer. The reason is that for compiler found bugs, you generally know exactly where the bug is, sometimes to the specific character. Also, you don't have to think of the test. For most people, here is the order for time to fix bugs: compiler found, code review found, unit test found, system test found. So, most things that you do to move finding the bug earlier are better.

Second point. Not all statically typed languages require the programmer to specify the type. For example, Ocaml will infer the type from the use of the variable. For example given this definition:

let rec length list = match list with
| [] -> 0
| head :: tail -> 1 + length tail;;

Ocaml figured out that the type was: 'a list -> int = <fun>, which means length takes a list of arbitrary type, and returns an integer. So, the programmer does not need to specify types, but the errors are caught at compile time. So, if you are complaining about having to figure out the type, or having to explicitly state a function is generic, your complaint is not with static typing, but with the lack of type inference.



Strong Typing and VMs (3.00 / 4) (#126)
by hardburn on Fri Mar 04, 2005 at 11:42:12 AM EST

What's key is that modern compilers can optimize C or C++ code better than most programmers, and these tools should only continue to get better.

C/C++ and the rest of the curly-brace languages do not have the semantics required for further optimization--what we have now is about as good as it gets. You'd have to redesign the langauge into something un-C-like to do any better. Which is fine.

The errors caught by the compiler are generally the simplest errors because the compiler can only judge syntax. Logic errors (legal expressions that result in flawed program behavior) are usually much more work to find and debug, and are language agnostic.

The secret is to design your language with better syntax that can then support better semantics. And no, C/Java/et al. are not strongly typed. Type theorists have been laughing at those languages for years.

Note that type theory comes out of formal logic, not CS. It's superiority was proven before Turing started playing with infinate paper tape.

I'll refer you to MJD's talk Strong Typing and Perl. He shows an O'Caml program where the type system saves him from an infinate loop bug. Think about that.

I'll also refer you to the LtU Strong Typing flamewar discussion.

Simply replace the VM provided for each platform with standard libraries providing the necessary support . . . What would be gained is the ability to seamlessly integrate Java or C# object code into applications written primarily in VHLLs, just as is already possible with C, C++, Fortran, etc. object code.

A good VM will help interoperability between languages, not hinder it. For instance, the Parrot VM (being designed for Perl6, but also targetting Python and Ruby) has the concept of a "Parrot Magic Cookie" (PMC). Essentially, these implement the details of how each language handles its variables. For instance, each language may do something different when you try to add a string to a number. The PMC lets each language transparently pass around its variables to other languages, but ensures the correct behavior for each language's specification.

Java's VM is designed specifically for Java, as is Python's reference VM. There is no theoretical reason you couldn't host another language on them (and there are some for Java), but it's not necessarily easy. Other VMs (like Parrot and the .NET runtime) are much better for that task.


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


VM's and What Runs on Them (none / 0) (#162)
by czolgosz on Mon Mar 07, 2005 at 04:39:51 PM EST

Java's VM is designed specifically for Java, as is Python's reference VM. There is no theoretical reason you couldn't host another language on them (and there are some for Java), but it's not necessarily easy. Other VMs (like Parrot and the .NET runtime) are much better for that task.
This is not just hypothetical. There are a number of languages other than Java that are now implemented and running on the JVM. One of them is Jython, which is a full Python implementation on the Java runtime. Similarly, there are a number of languages other than those anticipated by Microsoft that run on the .NET CLR. I've never seen any info that indicates that the .NET runtime is all that much better than the Java runtime for such purposes. the CLR was engineered for "multilanguage support," the main targets were VB and C#. Both are staticly typed and declarative, which exclues a lot of interesting and useful language features.

Some runtimes have design limitations that shouldn't be minimized when thinking of porting. For example, neither the Java nor .NET runtimes were really designed with multiple inheritance or dynamic typing in mind. So you'll find little low-level support in the VM for such frequently-used features. Such blind spots can make efficient implementations more difficult than they need to be.

Why should I let the toad work squat on my life? --Larkin
[ Parent ]
That's what I said (none / 0) (#168)
by hardburn on Tue Mar 08, 2005 at 09:23:48 AM EST

This is not just hypothetical. There are a number of languages other than Java that are now implemented . . .

I thought I said that: "There is no theoretical reason you couldn't host another language on them (and there are some for Java)"

For example, neither the Java nor .NET runtimes were really designed with multiple inheritance or dynamic typing in mind.

Multiple inheritance is a quagmire for language designers, implementers, and programmers. Although many people complain about the lack of it in Java, I find it hard to blame the designers for leaving it out. But if you leave it out, you need something to take its place for the 0.01% of code where it is absolutely critical; interfaces are not good enough.

There was a lot of debate on the Parrot development list on how to implement multiple inheritance, being that the target languages (Perl6, Python, and Ruby) all work differently in that regard. The "best" solution is to just pick a way and run with it.


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
You Did (none / 0) (#170)
by czolgosz on Wed Mar 09, 2005 at 01:08:30 PM EST

I thought I said that: "There is no theoretical reason you couldn't host another language on them (and there are some for Java)"
Oops, an ADD moment. Sorry. Wow, look at that blue jay!

There are some reasons to avoid multiple inheritance, and many to be disciplined if using it (I know about cycles too, and the nasty semantics of resolving which inheritance path is authoritative), but in many instances it's a really good way to model the real world. The designers of Java excluded it mainly because they feared it would confuse inexperienced programmers at a time when OO concepts were not well-known, and it has since become another item of folkloric dogma that it's always a Bad Thing. Interfaces were added to mitigate the fact that there are a lot of cases where such features are actually quite useful.

Anyway, my point wasn't so much the software-engineering justification for whether or not to use multiple inheritance; more that runtimes that don't have hooks for it pose problems when you try to port those languages that have it. As the chatter on the Parrot list demonstrates.


Why should I let the toad work squat on my life? --Larkin
[ Parent ]
Strange. (none / 0) (#151)
by Wolfbone on Sun Mar 06, 2005 at 12:30:43 PM EST

"The language used was natural language, which while not as concise or succinct as Lisp, more than makes up for it in terms of sheer expressivity."

The only mention of Lisp in an article that really should have been full of references to the "programmable programming language", especially now that the AI winter seems to be over ;-)  and it rather gratuitously and perversely compares Lisp's expressivity to that of natural languages, as though Lisp exemplifies all the limitations the other languages have.

But it is well known that  exactly the opposite is true of Lisp; it makes other languages look like BASIC (line numbers included) and since no-one has yet written a compiler/interpreter for English or Russian, it would have been far more enlightening I think to compare the expressivity and abstractional power of Lisp to that of the other programming languages mentioned. At least with Lisp, a holodeck program wouldn't seem like a complete fantasy.

There were some good points and well made in the article but they do seem rather quaint from the point of view of a Lisper. BTW - a fluid flow simulation visualizer sounds just the sort of task Lush (lush.sf.net) is ideally suited to.
 

Looks Interesting (none / 0) (#155)
by Arkaein on Sun Mar 06, 2005 at 05:31:52 PM EST

I was not aware of Lush, I'll have to check it out further.

Lisp really isn't my area, I'm aware of the arguments for it being a great language, with many modern VHLLs simply "rediscovering" many of its qualities, but don't have much direct experience with it. Partly this is due to being turned off of it by early impressions of Scheme in my first year of undergrad, where all I knew was that the assignments I was given seemed a lot harder than they should of. I knew how they could be easily done in C or C++ due to my prior experience, but Scheme just seemed foreign and strange.

My attitude towards different languages has matured since but I haven't gotten around to getting into Lisp. The other part of this is that I usually don't end up doing anything with new (to me) languages unless I have some purpose to actually put them to. Lush might have been a good fit, although the actual visualization component I'm writing doesn't do any of the numerical analysis stuff, and reusing some of my older code for vector and matrix stuff saved me from reinventing too many wheels.

----
The ultimate plays for Madden 2005
[ Parent ]

I don't think the problem is inherent to VMs. (none / 1) (#156)
by Lisa Dawn on Mon Mar 07, 2005 at 04:44:07 AM EST

I know a lot of sucky VMs, and I know a few that are great. Others are toys. Sometimes a VM is truly the best solution (op-based languages, funges), and makes portability an easier problem to solve.

I really don't see why you think that the VM is inherent to the problem. Consider: that VM is a collection of further abstraction. Not only that, it also serves to make a level and (hopefully) stable foundation. In truth, I think the VM can save us, the way you suspect that senseless* abstraction will do on its own. In fact, I think it can do even better.

Specifically, I have in mind the perl6 VM. The reason I suspect this is actually a good idea, instead of "YASVM" (S={Stupid, Sucky, Stack, etc.}) is that it was designed in parallel with the perl6 language, and with the express intention of being useful beyond a single source language. And this is the failing of most other common VMs, even the beloved z-machine. Consider: if you have multiple sources for a single target VM, and that is built, in turn, for multiple targets.

I don't want to say that this particular VM will solve computing's problems, but I think there is a clear advantage in this approach, and that it simply needs to be well-implemented and well-adopted to cause a revolution. Computing loses its centricity and if well-done, sharing between languages might be lubricated at the level of object code.

I've been hoping that this particular VM would enable me to inline C with my perl, etc. I haven't really followed closely enough, but I think it can be done, with some trickery at the pre-intermediate compilation stage. And to make even simpler use of objects from other languages. If those objects are in native bytecode, then there's no telling them apart anyway. (Well, there's heuristics, but why would you care at that point?)

I'm trying not to get my hopes up at this stage, but I think there's a lot of potential in this direction, whether or not it manifests itself at present.

*Forgive me, your description of it doesn't imbue any particular sense, other than "not VM."

Inline C (none / 0) (#167)
by hardburn on Tue Mar 08, 2005 at 09:14:28 AM EST

You mean like Inline::C?

Parrot will have a native call interface for calling external code.


----
while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


[ Parent ]
Best website link (1.00 / 6) (#176)
by ginozhu on Wed Mar 16, 2005 at 05:10:19 AM EST

http://www.18zo.com/wangyesheji 网页设计 http://www.18zo.com/wangzhanjianshe 网站建设 http://www.18zo.com/wangzhanweihu 网站维护 http://www.18zo.com/wangzhantuiguang 网站推广 http://www.18zo.com/visheji vi设计 http://www.18zo.com/cisheji ci设计 http://www.18zo.com/googletuiguang google推广 http://www.18zo.com/longxiong 隆胸 http://www.18zo.com/zhengxing 整形 http://www.18zo.com/meidu 梅毒 http://www.18zo.com/xingbing 性病 http://www.18zo.com/buyunbuyu 不孕不育 http://www.18zo.com/zigongjiliu 子宫肌瘤 http://www.18zo.com/gongjingyan 宫颈炎 http://www.18zo.com/gongjingmilan 宫颈糜烂 http://www.18zo.com/fukebing 妇科病 http://www.18zo.com/duanxinqunfa 短信群发 http://www.18zo.com/lingshengxiazai 铃声下载 http://www.18zo.com/baozhuangjixie 包装机械 http://www.18zo.com/zhiyaojixie 制药机械 http://www.18zo.com/suliaotuopan 塑料托盘 http://www.18zo.com/liuhecai 六合彩 http://www.18zo.com/guanlizixun 管理咨询 http://www.18zo.com/caipiao 彩票 http://www.18zo.com/shiyanshebei 试验设备 http://www.18zo.com/gaodiwenshiyanxiang 高低温试验箱 http://www.18zo.com/famen 阀门 http://www.18zo.com/jiezhifa 截止阀 http://www.18zo.com/jieliufa 节流阀 http://www.18zo.com/qiufa 球阀 http://www.18zo.com/diefa 碟阀 http://www.18zo.com/beng 泵 http://www.18zo.com/lixinbeng 离心泵 http://www.18zo.com/zhenkongbeng 真空泵 http://www.18zo.com/youbeng 油泵 http://www.18zo.com/liuchengben 流程泵 http://www.18zo.com/zhoucheng 轴承 http://www.18zo.com/xiangxinqiuzhoucheng 向心球轴承 http://www.18zo.com/tuidongqiuzhoucheng 推动球轴承 http://www.18zo.com/moju 模具 http://www.18zo.com/suliaomoju 塑料模具 http://www.18zo.com/chongyamoju 冲压模具 http://www.18zo.com/wujinmoju 五金模具 http://www.18zo.com/jinggujian 紧固件 http://www.18zo.com/mifengjian 密封件 http://www.18zo.com/liantiao 链条 http://www.18zo.com/chuansongdai 传送带 http://www.18zo.com/yasuoji 压缩机 http://www.18zo.com/diandongji 电动机 http://www.18zo.com/sifudianji 伺服电机 http://www.18zo.com/gongyefengshang 工业风扇 http://www.18zo.com/tiaomaji 条码机 http://www.18zo.com/pengmaji 喷码机 http://www.18zo.com/huojia 货架 http://www.18zo.com/gouwuche 购物车 http://www.18zo.com/guolu 锅炉 http://www.18zo.com/diandonggongju 电动工具 http://www.18zo.com/wanju 玩具 http://www.18zo.com/maorongwanju 毛绒玩具 http://www.18zo.com/zhanshigui 展示柜 http://www.18zo.com/fangzhijixie 纺织机械 http://www.18zo.com/hongxiang 烘箱 http://www.18zo.com/gaoyakaiguan 高压开关 http://www.18zo.com/jiechuqi 接触器 http://www.18zo.com/huanbaoshebei 环保设备 http://www.18zo.com/shipinjixie 食品机械 http://www.18zo.com/shuichulishebei 水处理设备 http://www.18zo.com/fadianjizu 发电机组 http://www.18zo.com/zusuji 注塑机 http://www.18zo.com/ganzhaoshebei 干燥设备 http://www.18zo.com/baozhuangdai 包装袋 http://www.18zo.com/pemo pe膜 http://www.18zo.com/mba mba http://www.18zo.com/emba emba http://www.18zo.com/pmp pmp http://www.18zo.com/ccie ccie http://www.18zo.com/ccna ccna http://www.18zo.com/yingyupeixun 英语培训 http://www.18zo.com/jisuanjipeixun 计算机培训 http://www.18zo.com/erp erp http://www.18zo.com/crm crm http://www.18zo.com/scm scm http://www.18zo.com/liuxigema 六西格玛 http://www.18zo.com/kehuguanxiguanli 客户关系管理 http://www.18zo.com/gongyinglianguanli 供应链管理 http://www.18zo.com/shichangdiaocha 市场调查 http://www.18zo.com/piaowufuwu 票务服务 http://www.18zo.com/jipiaoyuding 机票预定 http://www.18zo.com/jichuang 机床 http://www.18zo.com/chechuang 车床 http://www.18zo.com/xichuang 铣床 http://www.18zo.com/shiyanyiqi 实验仪器 http://www.18zo.com/shiyanji 试验机 http://www.18zo.com/redianou 热电偶 http://www.18zo.com/wenduji 温度计 http://www.18zo.com/yalibiao 压力表 http://www.18zo.com/jiliangqiju 计量器具 http://www.18zo.com/bianyaqi 变压器 http://www.18zo.com/wengyaqi 稳压器 http://www.18zo.com/zhengliuqi 整流器 http://www.18zo.com/jidianqi 继电器 http://www.18zo.com/diancifa 电磁阀 http://www.18zo.com/dianchi 电池 http://www.18zo.com/shoujidianchi 手机电池 http://www.18zo.com/chongdianqi 充电器 http://www.18zo.com/wanyongbiao 万用表 http://www.18zo.com/erjiguan 二级管 http://www.18zo.com/sanjiguan 三极管 http://www.18zo.com/chaiyoufadianji 柴油发电机 http://www.18zo.com/qiyoufadianji 汽油发电机 http://www.18zo.com/jienengdeng 节能灯 http://www.18zo.com/lusudeng 卤素灯 http://www.18zo.com/nihongdeng 霓虹灯 http://www.18zo.com/nadeng 钠灯 http://www.18zo.com/dianyuanshebei 电源设备 http://www.18zo.com/guangqian 光纤 http://www.18zo.com/dianlan 电缆 http://www.18zo.com/youjiyanliao 有机颜料 http://www.18zo.com/wujiyanliao 无机颜料 http://www.18zo.com/suliao 塑料 http://www.18zo.com/gongyeqiti 工业气体 http://www.18zo.com/gongchengsuliao 工程塑料 http://www.18zo.com/semu 色母 http://www.18zo.com/wujiyan 无机盐 http://www.18zo.com/suliaobomo 塑料薄膜 http://www.18zo.com/tuliaozuji 涂料助剂 http://www.18zo.com/tianjiaji 添加剂 http://www.18zo.com/xiaodushui 消毒水 http://www.18zo.com/hechengxiangjiao 合成橡胶 http://www.18zo.com/jiaonianji 胶粘剂 http://www.18zo.com/shipintianjiaji 食品添加剂 http://www.18zo.com/cuihuaji 催化剂 http://www.18zo.com/guanggaolipin 广告礼品 http://www.18zo.com/liuligongyipin 琉璃工艺品 http://www.18zo.com/hunqinggongsi 婚庆公司 http://www.18zo.com/gongyipin 工艺品 http://www.18zo.com/ganxi 干洗 http://www.18zo.com/ganxiji 干洗机 http://www.18zo.com/liansuojiameng 连锁加盟 http://www.18zo.com/chuangye 创业 http://www.18zo.com/xiangbao 箱包 http://www.18zo.com/bijiben 笔记本 http://www.18zo.com/bijibendiannao 笔记本电脑 http://www.18zo.com/gaoerfu 高尔夫 http://www.18zo.com/bangongjiaju 办公家具 http://www.18zo.com/jiajuzhuanghuan 家居装潢 http://www.18zo.com/zhuanghuanggongsi 装潢公司 http://www.18zo.com/chugui 橱柜 http://www.18zo.com/xingligui 行李柜 http://www.18zo.com/xietaoji 鞋套机 http://www.18zo.com/kafeiji 咖啡机 http://www.18zo.com/tuliao 涂料 http://www.18zo.com/fangshuituliao 防水涂料 http://www.18zo.com/cizhuang 瓷砖 http://www.18zo.com/diban 地板 http://www.18zo.com/fuhediban 复合地板 http://www.18zo.com/fangjingdiandiban 防静电地板 http://www.18zo.com/xiaofangshebei 消防设备 http://www.18zo.com/jiankong 监控 http://www.18zo.com/jiankongshebei 监控设备 http://www.18zo.com/duijiangji 对讲机 http://www.18zo.com/fangdaoqicai 防盗器材 http://www.18zo.com/gerecailiao 隔热材料 http://www.18zo.com/laobaoyongpin 劳保用品 http://www.18zo.com/shipinhuiyi 视频会议 http://www.18zo.com/dianhuahuiyi 电话会议 http://www.18zo.com/cpu cpu http://www.18zo.com/zhuban 主板 http://www.18zo.com/yingpan 硬盘 http://www.18zo.com/ups ups http://www.18zo.com/touyingji 投影机 http://www.18zo.com/cunchushebei 存储设备 http://www.18zo.com/fuwuqi 服务器 http://www.18zo.com/luyouqi 路由器 http://www.18zo.com/jiaohuanji 交换机 http://www.18zo.com/gongzuozhan 工作站 http://www.18zo.com/yinxiang 音响 http://www.18zo.com/lunhuayou 润滑油 http://www.18zo.com/chengrenyongpin 成人用品 http://www.18zo.com/zhongyangkongtiao 中央空调 http://www.18zo.com/chongwu 宠物 http://www.18zo.com/xiezilou 写字楼 http://www.18zo.com/biesu 别墅 http://www.18zo.com/zhanlangongsi 展览公司 http://www.18zo.com/liuxue 留学 http://www.18zo.com/qianzheng 签证 http://www.18zo.com/yiming 移民 http://www.18zo.com/gongsizhuce 公司注册 http://www.18zo.com/jiazhengfuwu 家政服务 http://www.18zo.com/diandang 典当 http://www.18zo.com/waihui 外汇 http://www.18zo.com/tongbanzhi 铜版纸 http://www.18zo.com/xinwenzhi 新闻纸 http://www.18zo.com/biaoqianzhi 标签纸 http://www.18zo.com/zaozhishebei 造纸设备 http://www.18zo.com/lianjieqi 连接器 http://www.18zo.com/tongxundianlan 通讯电缆 http://www.18zo.com/vpn vpn http://www.18zo.com/keshidianhua 可视电话 http://www.18zo.com/wangqiao 网桥 http://www.18zo.com/jituandianhua 集团电话 http://www.18zo.com/jiemaqi 解码器 http://www.18zo.com/gps gps http://www.18zo.com/dianhuajifeiqi 电话计费器 http://www.18zo.com/shuijingtou 水晶头 http://www.18zo.com/jixianqi 集线器 http://www.18zo.com/buxiugang 不锈钢 http://www.18zo.com/yelanshebei 冶炼设备 http://www.18zo.com/rezhagangban 热轧钢板 http://www.18zo.com/renzhagangban 冷轧钢板 http://www.18zo.com/zhifu 制服 http://www.18zo.com/jiaotongjingshideng 交通警示灯 http://www.18zo.com/luzhang 路障 http://www.18zo.com/liheqi 离合器 http://www.18zo.com/biansuqi 变速器 http://www.18zo.com/qicheyinxiang 汽车音响 http://www.18zo.com/shuziweixinjieshouqi 数字卫星接收器 http://www.18zo.com/pindaozhuanhuanqi 频道转换器 http://www.18zo.com/sheluyitiji 摄录一体机 http://www.18zo.com/wutaidengju 舞台灯具 http://www.18zo.com/qiqiu 气球 http://www.18zo.com/guanggaopai 广告牌 http://www.18zo.com/sanjiaojia 三脚架

website link (1.00 / 7) (#177)
by ginozhu on Wed Mar 16, 2005 at 05:11:04 AM EST

网页设计 网站建设 网站维护 网站推广 vi设计 ci设计 google推广 隆胸 整形 梅毒 性病 不孕不育 子宫肌瘤 宫颈炎 宫颈糜烂 妇科病 短信群发 铃声下载 包装机械 制药机械 塑料托盘 六合彩 管理咨询 彩票 试验设备 高低温试验箱 阀门 截止阀 节流阀 球阀 碟阀 离心泵 真空泵 油泵 流程泵 轴承 向心球轴承 推动球轴承 模具 塑料模具 冲压模具 五金模具 紧固件 密封件 链条 传送带 压缩机 电动机 伺服电机 工业风扇 条码机 喷码机 货架 购物车 锅炉 电动工具 玩具 毛绒玩具 展示柜 纺织机械 烘箱 高压开关 接触器 环保设备 食品机械 水处理设备 发电机组 注塑机 干燥设备 包装袋 pe膜 mba emba pmp ccie ccna 英语培训 计算机培训 erp crm scm 六西格玛 客户关系管理 供应链管理 市场调查 票务服务 机票预定 机床 车床 铣床 实验仪器 试验机 热电偶 温度计 压力表 计量器具 变压器 稳压器 整流器 继电器 电磁阀 电池 手机电池 充电器 万用表 二级管 三极管 柴油发电机 汽油发电机 节能灯 卤素灯 霓虹灯 钠灯 电源设备 光纤 电缆 有机颜料 无机颜料 塑料 工业气体 工程塑料 色母 无机盐 塑料薄膜 涂料助剂 添加剂 消毒水 合成橡胶 胶粘剂 食品添加剂 催化剂 广告礼品 琉璃工艺品 婚庆公司 工艺品 干洗 干洗机 连锁加盟 创业 箱包 笔记本 笔记本电脑 高尔夫 办公家具 家居装潢 装潢公司 橱柜 行李柜 鞋套机 咖啡机 涂料 防水涂料 瓷砖 地板 复合地板 防静电地板 消防设备 监控 监控设备 对讲机 防盗器材 隔热材料 劳保用品 视频会议 电话会议 cpu 主板 硬盘 ups 投影机 存储设备 服务器 路由器 交换机 工作站 音响 润滑油 成人用品 中央空调 宠物 写字楼 别墅 展览公司 留学 签证 移民 公司注册 家政服务 典当 外汇 铜版纸 新闻纸 标签纸 造纸设备 连接器 通讯电缆 vpn 可视电话 网桥 集团电话 解码器 gps 电话计费器 水晶头 集线器 不锈钢 冶炼设备 热轧钢板 冷轧钢板 制服 交通警示灯 路障 离合器 变速器 汽车音响 数字卫星接收器 频道转换器 摄录一体机 舞台灯具 气球 广告牌 三脚架

Leapfrogging Abstractions | 178 comments (137 topical, 41 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!