Slashdot Mirror
What are the Next Programming Models?
jg21 writes "In this opinion piece, Simeon Simeonov contemplates what truly new programming models have emerged recently, and nominates two: RIAs and what he calls 'composite applications' (i.e. using Java, .NET or any other programming language). He notes that Microsoft will be trying to achieve RIAs in Avalon, but that it's late out of the gate. He also cites David Heinemeier Hansson's Ruby on Rails project as showing great promise. 'As both a technologist and an investor I'm excited about the future,' Simeonov concludes. It's a thoughtful piece, infectious in its quiet enthusiasm. But what new models are missing from his essay?"
1. Come up with a great idea. 2. Write a bunch of spaghetti code. 3. ??? 4. Profit!
Reminder: Apple owns 1/255th of the internet.
Functional Programming, not First Post!
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
Nothing is permanent. However, after so long you're gonna start getting rehashed methods. It's like a big circle everyone is running around in, looking for the absolute best. Yes, there are ones better than others, but there is no perfect one. Need OO for a simple 10 line php script? Hell no, unless you're relying on a lot of 3rd party libraries. Need Ruby on Rails for a statistics generator with no front end what so ever? Nope. It all changes, but there is some good stuff we take along the way. But I don't think we'll ever find something that is just "perfect", more of a never ending quest to find the better one, and to stay on top of all the ones from the past.
No new 'paradigms' until we get all the other 'salvations' under control.
Who are the next programming models?
Two posts too late.
I still do not get what "new programming style" is being metioned here.
Are we talking new like the emergence of Object Oriented Programming? or simply new in terms of what technology is being used (.NET, java, Ruby, Jscript/AJAX)?
NOTE: If its the latter this whole topic is useless.
That's the first one I learned. Now I'm in to the lasagna model, with nice layers. Anything beyond that? Well, not me.
Here's a new model who can program:
"Prior to being crowned Miss Universe 2005, Natalie was a motivational speaker, model and a fundraiser. She recently received a Bachelor's Degree in Information Technology Management and Marketing from Ryerson University..."
Life is like a web application. Sometime you need cookies just to get by.
I nominate this woman.
l ery/Unauthorised/08WWDCMysteryWoman.jpg
http://www.quinn.echidna.id.au/Quinn/WWW/PhotoGal
...it wants your conclusions back.
Rich internet apps and EAI have been around forever. Possibly one could argue that composite apps using web services instead of message queues and plain-old text files might be new, but even that is pretty old hat.
I have heard marvels of Embryo Enlightenment version of SMALL
Is it just me or is this guy speaking English? I'm not a web programmer but geez...that article seems like a steaming pile of drivel.
the Cocoa/Objective-C implementation might be worth talking about, especially as how it has evolved from it's roots in next step.
www.omglolh4x.com
...we stop creating new languages and use what's out there to do something useful for a bit.
In a specification oriented programming model, you specify the behaviour, not all the million little steps that are needed to perform it. A specification oriented programming model is independent of the underlying techniques, such a networking protocols and marshalling techniques. I think such a specification oriented programming model should be data oriented, meaning that data is the starting point, not an event driven GUI front-end, as it is now with most programming models.
I won't discount the importance of Ajax and "RIAs" as a deployment model -- even as a kind of domain within in which system architectures could be grouped. But these aren't new programming models. We use the same old programming models to build new kinds of apps.
Examples of Programming Models:
0) Hardware based programming (plugboards etc)
1) Stored program (program as data)
2) Assembly programming
3) High level language programming
4) Structured
5) Functional
6) Object oriented
7) Aspect oriented
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Actually, he missed the anti-pattern. It's really: One of the common anti-patterns is over-relying on tools and frameworks and programming paradigms and processes instead of improving the skills and knowledge of the people doing the programming.
I've been programming for a long time too, and I don't think that new programming models do all that much for productivity compared to finding good people or investing in improving the people you have. The recent Joel on Software article discusses this at length. This is one of the big reasons I'm so interested in agile methods and principles.
Helping with organizational effectiveness is our job.
Rich Internet Applications are hardly the next "new" thing. The idea of doing asynchronous applications HTML/DHTML has been around since at least 1997. It's only the recent broad-based browser support that has led to the growth of AJAX, etc. However, trying to program an RIA that targets multiple browsers is like trying to write portable C code all over again. Thought CSS was screwed up between Firefox and IE? Try looking at the JavaScript implementation differences between the two platforms. Throw in a bit of Safari and Opera and you have all the makings of some super-gross client code.
The trend towards RIA's/webapps has traditionally been restricted to those in a database centric role, but with the increasing use of AJAX and the like, the webapp is pushing further into the desktop application space. Obviously the centralization and server-side nature of the applications helps deployment and maintainance, but developers are basically trading the platform of an operating system for the platform of a web browser, with all the intricacies and compatibility issues that follow both.
Webapps are a good direction to take for data access apps, but where the line becomes less clear cut and extreme amounts of javascript/dhtml are needed to achieve behaviours, the apps can become somewhat clunky and difficult to use. To me, it's essential that the designers of today's webapps realise the limitations of what they're working with and when to use traditional desktop apps.
Business Voyeur
Well lets see now, programming metaphors for the modern age?
Theres oil-oriented programming (everything is a pipeline), terror-oriented programming (everything is a suicide bomber) and dollar-oriented programming (everything has a mandatory dollar sign at the beginning), to name but a few.
In the free world the media isn't government run; the government is media run.
Shit that works (tm).
http://www.nwcpp.org/Downloads/2005/Lock-Free.pdf
-- -pjk Perry Kundert perry@kundert.ca http://kundert.2y.net
Functional programming is awesome, and I'm thoroughly convinced that it will take over just about everything its feasible for it to take over. There is nothing like the feeling of writing a program, having it type check, and not having to test it because you can look at the code and tell that it proves its own correctness.
See Beating the averages for a well-written and thoughtful essay.
In a nutshell, languages themselves vary in power. No one disputes that. All things being equal, you should generally choose the most powerful language you can all the time. As we move more and more to server-hosted software, your choice of language is incredibly important because a) it's your choice, not forced on your by being the language of the OS and b) it can be a huge competitive advantage.
Matz (Ruby's creator) acknowledges ripping off ideas from Lisp (but putting a friendlier face to it). Python is Lispy. Javascript has been called Lisp in C's clothing. These are all functional languages, or can be used functionally.
Graham noted how all languages are trending more towards Lisp in terms of features (see the essay linked above). Want further proof? C# 2.0 is getting lexical closures. Innovation from Microsoft! These were available in Lisp for 30 years, javascript for 10 (since it was created), they're in Perl 5, Ruby, I can go on...
If languages continue to become higher and higher level, wouldn't we need to investigate this weird AI language from 1958 and see what features it doesn't have in order to do more meaningful research? 'cause these days, all the "new" features of today's languages are decades old...
What on earth? This article is tripe unfit for anyone but managers. He's put new buzzwords on the things he's describing here, but not one of them is actually new.
.net", and . We have some new and better tools for RPC-based programming, what with WDSL or WSDL or whatever and all these other new acronyms, but we're still doing the exact same thing in the exact same way that we were doing in the 80s with CORBA and Distributed Objects.
First off, the "rich internet application" model he harps on is at this point about ten years old, since CGI programming first appeared. It hasn't changed that much since then. We figured out the idioms and patterns to make that work very quickly, and we've been using them since then. The only new development here is the "on rails" type stuff-- but that is nothing more, or less than the same model as all CGI has used, only now it runs faster. It is an optimization. Not anything new.
Second off, what the hell is a "composite application"? Seriously? It sounds like he's just describing an application which embeds a client server model. Well lah de frickin dah. This is not new, this is not at ALL linked to "java and
If when this guy says "recent" he means "the last 20 years", then yes, that is a good coverage of the improvements in programming we have had since 1980. But since he seems to mean things a bit more recent than that, it looks like he's just playing the old analyst game of putting a new name on an old concept and pretending it's the most important thing ever. Unfortunately, giving something a buzzword isn't the same thing as inventing it.
http://www.martinfowler.com/articles/languageWorkb ench.html
"Most new ideas in software developments are really new variations on old ideas. This article describes one of these, the growing idea of a class of tools that I call Language Workbenches - examples of which include Intentional Software, JetBrains's Meta Programming System, and Microsoft's Software Factories. These tools take an old style of development - which I call language oriented programming and use IDE tooling in a bid to make language oriented programming a viable approach. Although I'm not enough of a prognosticator to say whether they will succeed in their ambition, I do think that these tools are some of the most interesting things on the horizon of software development. Interesting enough to write this essay to try to explain, at least in outline, how they work and the main issues around their future usefulness."
Functional programming greatly simplifies the task of the programmer by removing execution order from the things that programmers have to keep track of. Just as garbage collection in Java got rid of the need to recycle memory manually, so in Haskell the execution order is a matter for the compiler to optimise rather than for the programmer to worry about.
Historically functional programming has had problems doing IO: languages have had to admit impure side effects to do IO. Haskell has a wonderful solution to this problem, which unfortunately this post is too small to contain (really: go see!).
Paul.
You are lost in a twisty maze of little standards, all different.
COBOL on Rails?
I hear that this is the best that the community could offer.
Pick a good language/environment, even a not so good one, say C and a text editor, and then use some engineering discipline to really DESIGN THE DAMN application. Don't just throw features at it, don't just hack the code. Think about the real world problem you are supposedly trying to solve and work your way through it. Build it right, you don't have to worry about operation, maintenance, or longevity. Build it wrong, and you make a career of fixing it.
Ooops, maybe I've stumbled onto the real secret of IT...
Behold, this dreamer cometh. Come now, and let us slay him... and we shall see what will become of his dreams.
I guess when I think of 'models of programming' I think about things like Object Oriented or Functional programming categories. This article seems to confuse the idea of 'models of programming' with actual types of applications: desktop vs. Web apps or perhaps a fusion of the two. Now one could program either a desktop or web app (or an RIA) using either an Object-Oriented approach, declarative, functional or even a combination of them. Let's not confuse the application with the programming model (or perhaps programming metaphor would work here?)
If the question is what will the next model of programming be (beyond the current reigning Object Oriented model) then the answer could probably lie in the direction of Aspect Oriented Programming. RIA's may be implemented usian an AOP approach, but I don't think it's right to say that RIA's will be the new programming model. RIA's may be the new application model.
When parrot/perl6/pirate/etc. gets off the ground, the open source community will have a vm of their own, and it will be much easier to move between languages within an application. I suspect this will mean that much more language specialization will take place. You'll see all sorts of small languages pop up for tasks like gui programming, stored procedures, templating, and for domains we haven't even thought of as needing their own language.
To my mind what we need is not more models, but some FINAL model - i.e. a way to impliment programming logic in such a way that it will never need to be implimented again.
Think about it - how much programming out there is a duplication of some other effort, at least in some of its logical components? I'd say what we need is two things:
a) A database of implimented programming logic - maybe not a database proper, but something that contains the ability to say "given this, do this" exists.
b) A programming method that involves designing an application such that you break each top level logical component/ability down until you a) know that you have to impliment it or b) it is found to have already been done. I'm guessing b will be the norm, and as more and more logical components are added to the database the point at which b) is found should get higher and higher in the design stage.
And the programming language bias should, at the database level, be a moot point. The database itself should define its algorithms and logic in such a way as to be workable in automatic proof assistants like acl2 and HOL4, and generate code in the required language as needed. Surely for a properly specified algorithm there must be some well defined way to generate it as code, provided the language specs are up to par. This is deterministic behavior, after all. Perhaps different algorithms for the same function can be added, and a choice made on a per language basis, but I'm dubious that this would be needed in an ideal world.
In a world with open source as a working reality, there should never be a need to impliment anything non-trivial. Design should be specifying only things that don't already exist. Object oriented programming is a nice step in that direction, but that doesn't let people know a) what's out there and b) what the quality of it is. I say let's bring formal methods to their full potential, and reduce the amount of work the programmer must do to the irreducable minimum. Programmer time is too valuable to waste on re-implimenting things. Standardize everything that can be done "right", and have the human being do ONLY the part he/she is good at - deciding what needs to be done from a USER standpoint - i.e. WHAT to do. How to do it should be, as much as possible, decided once and correctly, and then not again.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
While there are a lot of new technologies out there, they all have 'roots' in older technologies. Python is written in C for one example. IMHO, the next language breakthroughs will be developed with programmable hardware, a CPU that is a non-directed series of gates, which can be recombined to form whole new series of CPU's. With that kind of system a whole new construct of operations can be experimented with, and can be bound directly to the languages of the future. Functions become commands, commands become operands and so forth. Pipelining on demand, as many channels as you want. Virtualized sub processors each with it's own unique I/O. Imagine running the program, it 'compiles' it's own virtual cpu based around the task at hand. Those new 'instructions' could become the swappible DNA of a new generation of processors. And the languages will have the ability to develop lust as natural languages do, by evolving.
"Can there be a Klein bottle that is an efficient and effective beer pitcher?"
Functional programming and continuations. One present day example is the UnCommon Web, which is a web application framework implemented with continuations.
BillG embraces his customers' asses and extends his organ of (de)generation into them, all the while simultaneously snatching said customers' wallets. Quite a trick, indeed, and one that never ceases to give pleasure.
Some of the new programming models are very powerful and easy to work with which is making .NET obsolete. In fact, .NET is already considered a reminescent of the Y2K era.
Is Agile development secure?
Mod me down as flamebait for pointing this out, but did anyone else notice that the posted link for .NET went to the Mono homepage? Yeah, they deserve all of the credit for .NET. As a counterpoint, the Java link went to the Sun homepage...what's the deal?
Those who can, do. Those who can't, go into business for themselves.
Most of the new languages are designed to make life easier on the programmer (ie, php making db data very web accessable), but I would prefer to stick with the devil I know. I'd prefer to get my job done, not learn another language.
Of course, I run the risk of becoming obsolete if I don't jump on the next big bandwagon that actually does end up 'changing the world'.
Since when did operating systems become a religion?
I was thinking of Object Disoriented Programming...
d e l a y sl a sh f i l t err
how long until
http://www.uncoverip.com/
Next programming model is right here
-Don
Take a look and feel free: http://www.PieMenu.com
C.
Learn it, live it, love it.
Everything else is just a pretend language made for lesser beings.
And for you idiots who say it's insecure: there are people who suck at C. Don't let their crappy bug-filled programs ruin your perception of how great C is.
It turns out there's this Python-based application server/templating language called SkunkWeb (http://www.skunkweb.org/) which seems to be the Holy Grail for me of, well, a Python-based web framework that doesn't completely suck (Okay, I know 1995 and CGI was awesome and everything, but no one should be writing "print '<html><head>'..." statements within Python code to make web pages, and don't get me started on Zope.) And no, I'm not affiliated with the project or its developers.
I don't know about Ruby/Ruby on Rails, but I'd rather write in Python which, to me, has a more accessible syntax and a truly badass standard library. And doesn't make you want to jump blindfolded off of tall buildings.
Skunkweb lets you combine the best of Python and PHP -- you create real Python classes to do the heavy lifting/DB accesses/app logic (and you can unit test those separately) without the PHP spaghetti code mess, and then you use Skunkweb's refreshingly sane blend-of-HTML-and-Python template language (contrived example -- need a list of usernames? It's this easy) to tie it all together. The win is that this way you can separate logic (standalone Python modules) from presentation (templated HTML/Python) in a much cleaner manner than other web development frameworks.
In addition, it was built from the ground up for scalability (ok, the application server itself is probably slower than Apache/PHP, but I don't notice the difference, and you can use psyco or other methods to speed things up) and has caching and db connection pooling and other performance-oriented features built in.
I've been doing web development for nearly a decade, and Skunkweb has recently been my best-kept secret and a big competitive advantage. It's at the core of two companies I'm starting (one of which is a comprehensive online SAT prep course and is already profitable, the other which is earlier stage but angel-funded) It lends itself to clean and quick development and if it didn't have the stupid name (good luck convincing your boss to bet the farm on something with "skunk" in the name) it would have taken over the world by now.
Anyway, you heard it here first, folks. If anyone else out there is using Skunk, drop me a line (houston at mit.edu) because it would be nice to start a little community.
-fren
"Where are we going, and why am I in this handbasket?"
Allowing for true teamwork in programming.
Right now we have horrid CVS systems and isolated programmers each taking a chunk of a problem... forcing everyone else to catch up after the fact. Programming *can* be a group activity (see Extreme Programming for the lightest taste) , with all the advantages that groups can bring to any creative process.
Right now, almost all programming languages are written for the single programmer, and the programming environments are retrofitted to make it possible for multiple programmers to work on the same project. It's a messy bottleneck that doesn't need to exist but is maintained by social convention.
What's needed is a model where the language is open to multiple creators through an interface that makes collaboration easy and seamless while allowing project managers a way to keep track of contributions and responsibilities.
Let's have a look at programming languages http://www.linuks.mine.nu/gnustep/langs.txt
And an excerpt from a book (I can find you the title and ISBN if you want): Although both Objective-C and C++ derive from C, C++ is a systems-level language, whereas Objective-C is an applications-level language. The distinction can be summarized by saying that C++ was designed with program efficiency in mind, while Objective-C is geared more toward programmer efficiency. The difference is substantial--C++ is driven by a philosophy of efficiency and compatibility with existing C which, while necessary for a low-level language, proves quite restrictive in other contexts.
And now, the almighty Allen-Booze study: Quote of the Booz-Allen Study
* took 100+ senior programmers and trained them on NeXTstep, then asked them to write the same app on both NeXT and their previous system.
* First application written was written 2 - 5 times faster.
* Savings were 90%
* 83% less lines of code in the NEXTstep version
* 82% said NeXTstep was better in ALL categories
* It isn't faster to code on NeXTstep; you just have to write less of it. The revolution is "getting rid of software".
more about all this stuff, here: http://livecd.gnustep.org/
Windoze not found: (C)heer, (P)arty or (D)ance
-Don
Take a look and feel free: http://www.PieMenu.com
I used to think we could do everything through reuse.
My present conclusion is that we will always implement things, and some of them will always be non-trivial. The cost of *finding out if a solution fit the problem* is often so high that it's cheaper to just do it from scratch - and *know* that the solution fit the problem, and that there won't be introduced new problems due to people doing changes elsewhere, and that the code will follow the local coding standards and documentation standards and - for at least a while - have a person locally that have written the code and knows how to change it.
Of course, we can and should try to make software easier to reuse, easier to evaluate whether to reuse, etc. There's a lot of benefit to be had there. You can see some work that I've been involved in that area at http://rubyarchive.org/
Yet - I think we will perpertually have to deal with local code often being cheaper than using external code - even when there exists code that does the same thing.
Eivind.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
RIA is more of a type of architectural pattern...it is definately not a programming model like modular programming, object oriented programming, etc... Although I guess "programming model" could mean just about anything. The author of the article should not have mixed something very specific ("framework") with something very general ("programming model").
total system build.
as in, live CD's. as in, roll your own OS, stick whatever app you need in it, in whatever language you choose.
seriously, i've thought about it. the era of 'trusted software' starts with the total system build, and its at the point now where, to get your own full OS kit, frameworks, hardware support/tight driver integration, its pretty much easy. no need to chase the philosophy of language much further: build your own OSKit+AppPackage, boot it on whatever hardware you've got, run it, leave it alone.
honest, the new programming model isn't. its a build model, and reflects all hosted languages/kits/tools.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
Dumb ass. you're obviously trying to install the JRE on a platform it isn't certified to run on. probably oracle on a Debian system. Try installing the .NET runtime one the same platform, I'm sure the installer will work just as well.
.NET is controlled by a convicted monopoly what wont even fully disclose the API. They're willing to standardize the language, but not the standard API. Duhhh?
I like Java, it pays my bills.
-Don
Take a look and feel free: http://www.PieMenu.com
you're just too .. anonymous.
Sorry.
The next paradigm shift (I hate that expresion) is one where we stop embedding references to an object in another object and start using relationships between objects.
Most of your objects are simple objects (as are their real world analogues.) The perceived complexity is because we continue to embed pointers to other objects. That costs a great deal in maintainance and gives our software a great deal of inertia.
A brick doesn't have any pointers to the brick it participates in a wall with. A wall is composed of the relationships of the bricks to each other.
One database I worked on held about 750 objects and 'implied' about 1,200 relationships. If we had treated these imlpied relationships as first-class objects, maintainance would have been almost free.
As it was there were big meetings over embedding pointers and long, expensive data base conversions required over things that culd have been easily adn cheqaply handled by relationships and their instances: connections.
There are other advantages too. You can express N:M relationships naturally since 1:1, 1:N and N;1 relationships are just subsets (existential cases) of N:M relationships.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
I find it amusing that the sole reason one can come up with for not using a language is parenthesis. But no one's running towards smalltalk.
Windows user: "It's not like what I'm use to"
Slashdot Geek: "It's not like what I'm use to"
Nice to know Windows users, and Slashdot geeks have some things in common.
---
The "are you a script" word for today is reasons.
as a RAD it blows away even the best that .NET has to offer. complete cross platform, insanely fast RAD and very high level with reuseability.
I've been kicking myself for weeks after decideing to dink with Python. The same app for accessing an MSSQL database and running a query to produce a excel spreadsheet of the results is 1/5th the amount of code in Python as it is in VB.NET the learning curve is less steep than VB or C# and has the advantage of total cross platform compatability. the same app I use under Windows works under linux or OSX.
Many people ignore python, but it's things like this (ruby included) that sneak in under everyones radar.
Do not look at laser with remaining good eye.
Their is a programming model that must come out sometime soon; but its nothing like this article discusses. Chips are coming out that have multiple cores in them, but there is no good way to take advantage of them. To be clear: right now with only a handful of cores, the old chunky OS process model works fine. However, as the number of cores goes up, no current popular language or OS scales properly.
What we need is a parallel programming language that makes it easy and natural to take advantage of multi-core processors.
should be:
Haskell has a wonderful solution to this problem, which unfortunately this margin is too small to contain
And we all see how good compilers are at optimizing the execution order. Many articles and theses have been written, and it all boils down to the fact that lazy evaluation is a b*tch to optimise.
I think you'd be better off with rails. The base library for ruby is much nicer (and much better documented) than pythons', and the rails community is already rather huge and growing. Another important factor is there are now a million python projects all trying to take a stab at what rails can do, none which realize that rails is capable of doing what it can because of ruby. This also has the added side effect of splitting apart the entire python web community into splinters. You'll have one hell of a time getting SkunkWeb up to par with the features of rails even today. Imagine how far behind it will be in a few years when the (likely) chance is that skunkweb will be one of the projects to fall-out after the python web framework bust.
- tristan
So basically we'll link objects together using tuples.
I think he's wrong and right. First of all, Avalon and Ruby on Rails are in no way new programming models. Ruby on Rails is just a framework for abstracting and automating the programming of the old MVC model.
I do think that multi-language programming is a promising method though. It's not a new model persay, but it lets you mix your models. Where functional makes the most sense, you use functional. Where object-oriented makes the most sense, you use object-oriented. It would be great if I could use mathematically proven implementations of common data types in applications that are, shall we say, less than functional.
Boy, you missed Zope. By a long shot... or did you try a really old release without Page Templates?
I used Erlang professionally some, and liked it, but I have some doubts as well. It did not make me 10 times more productive, nor my code error free. It was not quite as good as a "scripting language" in terms of productivity, I felt, although it runs quite quickly, and like the concurrency model a lot.
In any case, I was left with a feeling of "yeah, I like this and would use it again, but it's not something that is going to wipe the floor with older models".
Also, I have some doubts as to how much FP "Scales Down" in the sense that it initially confuses people who are used to "normal" languages. I think perhaps FP might be more successful if someone were to take a more bottom up approach - let it "escape from the ivory tower". Languages like Erlang are doing this already, and of course people will be able to provide links to this or that Haskell or ML system used commercially, but to really make inroads, you've got to bridge the gap...
Just some musings.
http://www.welton.it/davidw/
I'm pretty sure it will never be the rage, but I like Programming Language Oriented Programming for difficult problems that don't seem doable in C/++ or something similar.
Most programs can be written practally in most languages, since all you really need is "if", "decrement" and "goto". Some problems aren't a good fit for a given language. That's why there's more than one.
Any program that breaks its problem into chunks is in effect creating its own mini-language. Whether you call it Abstact Data Typing or Object Orientation or Functional Programming or even Top Down Design, what it comes down to is dividing the problem into manageable chunks and working with those chunks until done.
I wish all CS students were taught from day one, or maybe day fifteen, how to create their own programming language. Usually you have to take a compilers course to get that.
Creating a new language is not that hard. It gets a bad rap because people think they have to write a backend for a given architecture, but writing the backend to generate C++ or some other HLL is just as good, since they've already done the heavy lifting and you can automate the compile train with your favorite maker.
Raise your children as if you were teaching them to raise your grandchildren, because you are.
BINGO !!! You lose ...
Your next project will be Perl 7.0 object oriented scripts calling aspect oriented ruby on rails methods in a dot net environment on top of a real time vmware model of the Hurd microkernel running on Longhorn. This will interface a remote Java serving running SOAP. You may use the fortran libraries somebody wrote in 1979.
It was funny joke when it originally came out. The reason it was funny was that no Python programmer in their right mind would ever think of merging Python with Perl -- why take such a giant step backwards, for no good reason?
It was even funnier that so many Perl programmers took Parrot seriously, and actually wanted to merge Perl and Python. But that's because Perl is so hopelessly flawed, that it seemed like a good idea to those people.
It's hillarious that they can't see why it's such a bad idea, because they're so blinded by Perl. But it's sad that anyone's actually wasted any effort on Parrot.
It would be much less effort to just learn a decent programming language like Python or Lisp, instead of putting so much work into hopelessly trying to salvage a sucky programming language like Perl.
If you want to implement all sorts of small domain specific languages, then you need something like Lisp macros. Perl doesn't have macros like Lisp, and it never will, because Perl's pointlessly ridiculous syntax makes that impossible.
-Don
Take a look and feel free: http://www.PieMenu.com
file is atrojan that installs keylogger and other apps.
nice try scumbag, but real warez ppl get their stuff from real people.
-Don
Take a look and feel free: http://www.PieMenu.com
All character-based languages are just variations on a theme. Why not have the specification be primarily graphical, as in interface builders, flowcharts and object relationship diagrams, then go directly to a low-level representation such as object code, machine language or bytecode with no traditional semi-readable character-based language at all? That would really be a big change.
If the link between graphic representation and runtime code were 2-way, it would beat the heck out of traditional debuggers, too.
"Is life so dear, or peace so sweet, as to be purchased at the price of chains and slavery?" - Patrick Henry
nobody seems to be interested in developing.
I program console games. We've got very strict RAM limits - from 384kb on the GBA to 64mb on the amazingly spacious XBox. (With some curious design decisions that can make it feel smaller than the 32+4mb PS2, but I digress.)
On systems like this you've got to track pretty much every byte. One meg of garbage collector overhead means one meg you don't have available for useful stuff. I generally don't use standard dynamic allocation - at all - it's just too expensive. Maybe one big pool to load files into on the PS2 that can be cleared entirely between levels. Nothing like that on the GBA of course.
As far as I can see, there's three languages that provide this necessary feature - ASM, C, and C++. So I use C++.
I'd love to see an "improved" C++. But it seems like every time someone decides to improve C++, the first thing they do is tack on a garbage collector and get rid of direct memory access. And, you know, those are features I desperately need. Frequently those unwanted features are the only way I can even display graphics.
And yes, it's possible to write modern games in languages with garbage collectors (as I understand it, the entire Jak and Daxter series was written in Lisp) but I know what lengths I go to to squeeze performance out of these systems - I really don't need a garbage-collected albatross hanging off my shoulder.
And before anyone says "garbage collectors are faster than deallocating things manually!" - if I don't *allocate* anything, what makes you think I need *deallocation*? There is no heap. Move on.
Breaking Into the Industry - A development log about starting a game studio.
The winner is...
b ench.html
I think DSLs are going to radically change the way that people code. DSLs potentially provide the meta-prgramming ccapabilities of LISP with the transparency and idiot-proofing of a language like Java. We may even see a hierarchy of software engineeringh develop, with one type of hihg-level coder deveoping DSLs and others able to use these languages easily within their own areas of expertise. For more, check the following links:
http://www.jetbrains.com/mps//
http://www.martinfowler.com/articles/languageWork
http://intentsoft.com/
So far, I wrote a parser using Boost::Spirit that translates combination C++/Matlab code to C++, which is then just compiled using g++. So I can write things like:This loads a type of MRI image called EPI, and reverses the order of the data in every other line while applying a phase correction. (Note matrix indices are zero based not 1 based like in Matlab.) matrix is just a templated matrix class. You can also specify a matrix using a bracket syntax:This creates a two row matrix with the values 1 to 10 in the first row and 10 to 1 in the second row. (The backquote just makes it easier for my parser to disambiguate the brackets, reminicent of quoting a list in lisp.)
The specific motivation in this example was to combine the speed of C++ with the syntactical convenience of Matlab. There are a lot of additional features I'd like to add, such as some inspired by Haskell:
matrix<double> M = [j | j <- A, i <- B, i==j];
This would be a list comprehension that finds the elements common to matrices A and B. C++ may be difficult enough as it is withoutout bastardizing it with tons of new language features, but my interest is in having as much power as possible under one roof, not necessarily making it easy for beginners to get up to speed.
Good Design (aka Big Design Up Front) is very effective when the problem domain is well understood or there exist a reasonable number of known solutions to choose from. Text editing is a good example of this, people have been writing text editors for over 40 years so there shouldn't be too many surprises and there are lots of examples. (Telephone signal exchange is similar...) For these problems a very formal approach should work well and result in a well documented and well designed system.
Other problems, usually in newer fields of endeavor, lend themselves to more dynamic software creation strategies with less stringent design phases such as hacking, exploratory programming, prototyping and good old XP. It's very hard to write requirements, functional specifications or even UML diagrams for a system that does things nobody has even dreamed about.
In an ideal world both approaches will result in a good design. What started as a hack can turn into a prototype and evolve into a design, the trick is to document it all... but that would require infinite time and infinite resources. This might occur in large open source projects where the user and development communities are large enough to represent statistical universes but in the corporate world where the bottom line drives everything and therefore time and resources are limited shortcuts are taken. Sometimes this results in brilliantly designed but undocumented applications, but just as often the result is a giant ball of mud that will scare the willies out of the first intern or student hired to maintain code.
XML is a known as a key material required to create SMD: Software of Mass Destruction
What I like about these new programming models such as Ruby, Ruby on Rails etc. etc. is how much like Lisp they are.
If you've never done a real programming course you've never been taught Lisp...
Yippee, less bluffers in the pool, more fish for those who can hunt.
threadeds blog
You seem to imply that this is somehow new. The
way it's described in the presentation is fairly
academic, but once applied to the real design it
will result in a trivial replace-on-write pattern.
Hardly a hot thing, leave alone 'next hot thing'.
http://www.quinn.echidna.id.au/Quinn/WWW/PhotoGall ery/Unauthorised/08WWDCMysteryWoman.jpg
I've seen a lot of ravioli code lately. You know, the API exterior is nice and clean, but once you have to open it up, you've got a nice surprise.
Ironically, the word ironically is often used incorrectly.
He notes that Microsoft will be trying to achieve RIAs in Avalon, but that it's late out of the gate.
It matters little when Microsoft controls the browser and the operating system. They could start deploying RIAs (Avalon web apps) tomorrow and have broad support for it in the browser and OS if they wanted.
One thing's for sure: I have yet to see a web UI framework look as good as Avalon web apps. Aeroglass over the web looks great. I wonder how well it will be accepted by the public.
Tech, life, family, faith: Give me a visit
Read this book: The Laws of Software Process; A new model for the Production and managment of Software by Phillip G. Armour
Chapter 8, page 194 is especially interestion as a possible future for programming.
Rich.
libguestfs - tools for accessing and modifying virtual machine disk images
All improvements I have seen the last 10 years in programming language have already been done in Smalltalk from the beginning.
/visual-basic (user-interface) (skipped many ST examples)
That is because everything is an object, even the programming constructs (like classes which are objects, and if/then which are called #ifTrue:ifFalse).
The future languages might even be more dynamic, and include Lisp (or Hascell) like constructions that solve problems by defining the answer (functional and logic programming).
Which is in the smalltalk-syntax: [i][:x| x*x=5.0] SolveFor: #x.[/i]
While smalltalk (ST) is advanced, it also encounters the problem of managing 60,000 classes (or more). And everyone can see that simply grouping the classes in seperate modules does not help, which is done in Java. Even the Object-class should be redefinable, preferably on local level. There are some programs on top of ST that help a bit, but I would personnaly like to see it a bit better
Another problem is that there are so many interfaces to different storages and systems. So we need C-interfaces, C++-interfaces, SQL-interfaces, XML-interfaces... etc..
So any future programming model should have:
- objects everywhere. (ST)
- Be very simple and compact. (ST)
- Easy to use and understand. (ST)
- allow scripting (or runtime compilation) possibilities (ST)
- easy modularizing of classes, methods and objects.
- Allow distributed data and execution. (ST)
- Allow easy interfaces to different storages and systems.
- Integrate easily in the system
Any future Object-system will be graphical and allow different programming models (logical, functional, procedural, storage, user-interface) to be build in graphical building-blocks..
Already we can see some of this happening in:
* XML-tools (data-definitions and interfacing),
* visual-age (procedural program definition, ST again).
* net-beans / delphi
* web-tools (ruby-on-rails (ruby is based on ST), seaside (build in ST))
Multiple language apps (MLA) is another serious contender in future is in programming paradigms. By prototyping in scripting languages like Python or Ruby and porting refined code to Java, Obj-C, C++ or C is the ideal design for large and complex apps.
:]
The MLA design is not new and has been used by Apple for several years now and also by open source and other developers through Jython, PyObjC...
These MLAs would be ideal to run n-tier server apps but should have alot of success with many client side only applications.
Both OSX and GNUStep are using MLAs extensively.
JsD
GNUStep + Gnome + Moz + OOo ==
"LISP is a simple languages that is used to create small languages to solve specific problems."
You do realize that this can also be done with FORTH? The toolbox approach to programming isn't the exclusive domain of big languages* like LISP or Scheme.
*Big compared to FORTH.
Is not
Well, other than some, that is...
ColdFusion's only been doing this sort of thing for years now...
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
You know, they were saying that back in 1980 when I was a CS student at SFU ...
... again.
The theory is nice, but the reality is different.
I figure in 2020 they'll be proposing Smalltalk as the next programming language
-- Tigger warning: This post may contain tiggers! --
The best programming models are the ones from the past, as usual. Lisp, Forth, these languages created a community of best-practices that we are all reinventing all over again.
Ruby on Rails is great, not because it's something NEW, but because it wraps up all these best practices with a friendly face.
Creating simple domain-specific languages is how talented programmers do things already, with powerful languages like Lisp. However languages like PHP, Python, Java, TOOK AWAY this ability because language designers thought it was "unnecessary" or "too complicated" for the average programmer.
Along comes Ruby, which gives you back some of that power. And a talented programmer took it and "did the right thing" by creating a tight domain-specific language. Now everybody is so excited. Great, whatever makes programs simpler and more expressive is fine by me.
But can we please stop talking about the "next" great thing, when hardly anybody remembers the great things from the past?
If there's any problem in this industry, it's that programmers have ZERO knowledge of fundamentals. Instead of standing on the shoulders of giants, they constantly re-invent wheels.
Directions given in this manner ARE dependant on execution order.
However if you specify a location in another way you can let the "system" determine the best path.
For example, if you want something to move, you give it the source and destination location.
Maybe I want to fly, drive, walk, sail, or bike. Depending on what is most convenient I will perform different actions in different orders, or take an entirely different path. Let me (or the compiler) decide how will allow you to function more on your task then the mechanics of my task.
Of course you can further constrain me however you want, but only as much as required.
I'm also interested in other Python based web frameworks. I've done lots of Zope/Plone programming, and I share your frustration with that "skyscraper stack" of software. I'm curious to know why you think webware and cherrypy suck.
I've been using an ORM (object relational manager) called SQLObject, by Ian Bicking (the author of Webware), and it seems to work pretty well. (It's pretty simple so it doesn't do everything, but it's extensible.)
I'd love to know what you think of PyDO2, the ORM in Skunkweb? How does it compare to Ruby on Rails' ORM, ActiveRecord?
At first glance at the sample code you provided, I noticed that it uses a non-standard variant of XML syntax. That is a big show-stopper problem, which means you can't develop your templates with any off-the-shelf XML editors, and you can't take advantage of any of the standard XML tools to process, generate and validate templates. If you're not going to use standard XML syntax, then why bother making it look anything like XML at all, since you've forsaken the entire universe of XML tools.
If you're going to invent your own markup language, then you'd better have the resources of IBM and 30 years to invest in reinventing the wheel. Otherwise, the benefits of sticking with standard XML syntax far outweigh any upside of bastardizing it with your own special syntax enhancements.
-Don
Take a look and feel free: http://www.PieMenu.com
I'd include Python-"on-rails"; Django.. it's even been /.'d before: 5 1258&from=rss
http://it.slashdot.org/article.pl?sid=05/08/02/00
It isnt about programming language that affect speed it is about how good IDE i have. Even if python or Ruby has fewer characters or lines it doesnt matter since eclipse autogenerates almost anything in java. Speed is all about IDE .. and since you can use a complex language with the speed of a script language you get more control since it has strong typing and better support for object orientation which make large applications less errorprone.
I really enjoyed learning about Ruby, but it seems to me the documentation is lacking and the websites are less navigable than other languages. Compared to perl/python/php, it really seems lacking. Also, there seems to be a million different sources for everything, without a single, definitive, complete place to find answers.
If you point me to a few places where I can find information about how to use RoR or ruby gems or various libraries, I'll give it another shot.
Social scientists are inspired by theories; scientists are humbled by facts.
It's obvious that most programmer have failed to really internalize any of the current programming models we've got, so what's the point of coming up with new ones that everybody's going to spend more time arguing about on messageboards than actually bothering to learn?
Question... how the f is this better than:
<table>
<? foreach ($foo.Users.GetSome() as $user) { ?>
<tr> <td> <?=$user.username?> </td> </tr>
<? } ?>
</table>
?? Please enlighten me?
This is what I hate about all these half assed attempts at templating languages. Before long, they all end up trying to reinvent asp/jsp/php.
Stop blaming the language and start blaming the bad developers!!
More properly, Lisp macros operate on the program structure itself. Macros for languages like C and C++ operate on text. I believe this is the why most programmers don't immediately comprehend why Lisp macros are so much more powerful and useful. They are used to macro systems which are useful for for putting CONSTANT_VALUE instead of a hard-coded number in the program text, but quickly become a bear to use when it is time to do something more sophisticated.
(Of course Forth lets you define words with any punctuation, even unbalanced parens, like "<BUILDS" and "DOES>", but the punctuation doesn't mean anything other than being a character in a token.)
-Don
Take a look and feel free: http://www.PieMenu.com
PLEASE don't point me to any of those ridiculous javascript widget libraries. They are an absolute joke. They are all slow and ugly.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
RIA (Rich Internet Applications) is a marketing term Macromedia (Flash, Cold Fusion) conjured up as a way to get people looking at their development products. Even googling on the term only points you back to one vendor. Not exactly what I would call a model...
Wow, that's pretty impressive. A templating language. That hasn't ever been done before. Oh, except by Coldfusion, ASP, JSP, Velocity, NVelocity, any number of Perl modules, a bunch of stuff I've never heard of, and almost anyone who's ever written a webpage before.
How is this +5?
I'm guessing that the future of programming lies within languages in which you can easily define a domain specific language to solve your problem. Good languages to write DSLs: Lisp dialects, Ruby, Factor, Smalltalk. When code is data, you have a really powerful language. That's where the future lies IMO.
Even mainstream Python won't have macros any time soon. Check out the section "Gotchas for Lisp Programmers in Python" number 12 on the Python for Lisp Programmers guide by Peter Norvig.
What's funny is that the guide is supposed to be an introduction for Lisp programmers to learn Python. But to me, it is damming evidence of why Python is so much less powerful than Common Lisp. Instead of making me want to learn Python, I wanted to learn CL even more!
I think the most promising thick-client app development model is the Model-View-Controller paradigm, as seen in such well-designed app frameworks as Cocoa for OS X, and of course Ruby on Rails, and although I see Skunkworks improving the "typical" drudgery of web-app dev, I would wonder what it provides in the way of code management when it comes time to test your controller without worrying about how the view renders it or the model stores it.
And I know this is a personal preference and all, but... Python's significant whitespace? Yuck... I hope you don't copy/paste much, you might forget a tab somewhere (not to mention, copying from webpages is an adventure in itself...) To me this is like drinking cider instead of beer. Why would anyone consider such a thing worthwhile? Just to avoid some begin/ends or curly braces?
Python does have a more complete library but I am pretty sure Ruby and friends are catching up (and of course, no real word on Parrot yet...) Ruby also just seems to do the whole object-oriented thing nicer (abbreviated getter/setters, everything is an object, no self-referential hacks or whatever...)
There isn't enough time to do it right the first time, but there's time to do it four or five times.
One of the coolest parts of the Java tool chain is ant, which uses XML instead of make's ridiculous syntax.
Ant has its limitations because it doesn't provide an actual scripting language. That's one of the problems that Jelly is attempting to address.
Another approach to programming with XML that works well is embedding a traditional programming language like JavaScript in XML text content, and expressions in XML attributes, like OpenLaszlo.
-Don
Brad Paisley
Make a Mistake
Written by - Brad Paisley
From - Mud On the Tires
You over think things
You say what if we're not meant to be
Well you know what so what
Make a mistake with me
Nobody goes through this life and does
Everything perfectly
We're all gonna fail so you might as well
Make a mistake with me
Sometimes, baby, when we take
A chance that has this much at stake
We look back and in hindsight
What seemed wrong looks more like right
So I say worst case we'll be left with
Lots of good memories
This chance we have well it's worth that
So make a mistake with me
I'm tellin' you the right thing to do
Is make a mistake
Make a mistake
Make a mistake with me
Take a look and feel free: http://www.PieMenu.com
-Don
Take a look and feel free: http://www.PieMenu.com
Some of you may be interested in dependent types. This is where simple types (what Java, C etc.) are extended so that types can be dependent on values. For example, your list type can include the size of the list as part of the type. So, the empty list would be type List(0), the list containing 3 things would be List(3). This allows you to do very powerful and useful analysis of the code at compile time. For instance, if you call removeLastItem on a list of type List(1), you know it will return List(0) (and not just List type in most languages). If you then add the constraint that removeLastItem can only be called with List(n), where n is greater than 0, to your code, you can catch out of bounds array accesses at compile time. This not only makes you code more robust, but you can also optimise out range checking code so it is efficient too. See this paper for examples: http://www.cs.bu.edu/~hwxi/academic/papers/pldi98. pdf
I suspect functioanl programming will dominate right through to 1988 and maybe even 1991.
IMHO Zope is pythons only hope for web dominance. And those guys really don't have it together yet.
Religion is a gateway psychosis. -- Dave Foley
You forgot:
- an attitude. (ST)
Or you can define your tags in Java (JSP), or use PHP, ASP ...
Stop me when you see the pattern. The problem is getting tougher.
In modern times ('90s), recently, we've...
Umm. We're starting to pick low-hanging fruit if you ask me. We will not proceed farther until we address what we sweat over working on:
And of course....
We have not abstracted out everything not necessary to accurately determine the minimum amount needed to convey a functional output from input.
Until 90% of the programming is essentially a library of "compiler hints" that get some code to work in the proper balance of optimisation, we have no choice but to spew an endless surf of compiler-required arbitrary drool-proof-paper decisions that we can barely keep in our skulls.
In sum.. we need to automate the hard parts of programming without errors. That's all. (Hint: we're not done yet.)
Nietzsche is dead - God
I like both Lisp and XML, and the way I use XML is deeply influences by Lisp. I'd rather be using Lisp, but XML (and JavaScript and Flash) are ubiquitous and well supported, so I'd be a fool to try to reinvent those wheels instead of learning to live with what we have and improving on it.
There's an interesting discussion of Lisp -vs- XML. Some people think Xml is a good copy Of Lisp S-Expressions, and other people think Xml is a poor copy Of Lisp S-Expressions.
"Think of XML as Lisp for COBOL programmers." (Tony-A on slashdot)
"S-expressions are a representation, XML is a career path." -- WardCunningham (oopsla '03)
The ExtensibleMarkupLanguage is a poor copy of EssExpressions.
XML made the worst part of sexprs worse, by introducing lousy syntax. Then it failed to really capture the strengths of sexprs. Less for more cost, what a deal.
See http://xmlsucks.org/ or http://xmlsucks.org/but_you_have_to_use_it_anyway/
-Don
Take a look and feel free: http://www.PieMenu.com
Indian
As one of my coworkers said, "Coldfusion is the only language that made me question whether I had errors in my code or whether the implementation itself was broken."
Badass Resumes
Did anybody else get as wound up as I did about the soundtrack advertising Macromerdia products?
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Here's all my ruby bookmarks: http://otierney.net/ruby_bookmarks.html
- tristan
I'd heard that ST doesn't have a multiple inheritance mechanism. Is this correct, and if so doesn't it pose a problem?
I once read a paper written by Cristina Videira Lopes, a pioneer of aspect oriented programming, in it she stated that AOP is a significant breakthroug, but that the next step is to include elements of natural language in programming languages.
She says that natural language is not suited to write computer programs, but it has powerful elements that can be useful in transferring ideas more closely to the way we think. An example of such elements are temporal references such as before and after.
You can read the abstract to one of her papers here. Very interesting stuff.
This is a old technology that I guess no one thinks is cool anymore... but at my present job I've been using Liveconnect to route messages from a server to javascript in the browser with excellent results. The java piece of it is pretty simple, it's more or less a message conduit between a javascript libary and the backend server. Also, considering how well Javascript interacts with CSS elements now, I've pulled off some pretty good interactivity using this method.
Blender And Linux Fan
OCaml is my primary language and I wish more people would turn on to it
... but this is not the point: I want to use OCaml to write apps for Windows, so pointing to (say) cd-boot distros that include OCaml do me no good.
I'd love to, but Windows is my primary dev environment, and Windows support for OCaml is kinda marginal. (Oh, sure, you can do basic stuff with it, but most of the interesting libraries are very Linux-oriented... if a Windows version exists, it's got a painful build process associated with it.)
I know, I know, I can just learn Linux... it's easy and free, right?
I know, I know (#2)... it's all open-source, so I can just bring the Windows version up to snuff myself, right? Yeah, in theory... if only I had the time.
I know, I know (#3)... I'm asking for a free lunch here. ("Damn you for offering an excellent, free language on my OS of choice! The nerve!") All I'm trying to say is that IMHO OCaml would be a much more interesting language if the Windows implementation had better parity with the Linux versions...
There's no doubt that the preferred form of application distribution is the browser - and pretty much here to stay.
And frankly I don't see nice rich clients becoming ubiquitious unless either Avalon comes to Mozilla or some Mozilla technology gets into IE (unlikely).
Microsoft gave us XmlHTTPRequest which has spurred the big AJAX hype. It would be nice if they would open up some of their upcoming web technologies for everybody to use, but I'm not holding my breath.
I guess the only other hope is for Mozilla-based browsers to get enough of the market share to force Microsoft into complying - as they did with javascript.
I hate web apps. Even with AJAX they still suck. I'm eagerly anticipating the day when we can all have a rich client experience in the browser.
These will be more important than any programming language. The way Java or .NET handle components should be an eye opener. What you want is code you can control, what does what you expect it to do.
.NET framework)
.NET C++, C#, VB7 and J#). You end up learning all of them (see MSDN). Mixing with languages that use other programming paradigms could be usefull though.
On the runtime part:
- plugins (see Eclipse and OSGi technology)
- assemblies/libraries (see
- VM support (garbage collection, overflow handling, exception handling, bounds checking etc.)
- runtime information (reflection)
- supporting components (application servers, message services)
On the IDE part:
- parsing editors (see Eclipse)
- code analyzers (PMD)
- semantic links from code to design tools (needs a parsing editor to function best)
- unit testing
I see a mayor shift towards runtime technologies coming up ahead. I can see more flexibility coming up in how programs are run and objects are used. Compilers are already running in the background to use Java both as script and as compile time language, for instance. Java may be to strict on some issues however.
For programs, components, OO and the imperative model will probably be here to stay. Other languages will be used for their respective domains, but the language wars seem to be over for now (as each programming language looks more and more like its siblings). Lets focus on the runtime and supportive technologies. And getting the things running reliably, for crying out loud.
I don't think using multiple languages that try to accomplish the same thing is such a good idea (see
And yes, this is also an opinion piece, as is the parent.
Basically:
1 0/lop/
1. Lots of things would be better expressed in DSL (domain-specific languages), but...
2. DSLs are hard enough to create, but DAMN it's a pain to maintain any product developed in one!
So LOP's goal is to make it easy to develop tools (refactoring IDEs and debugging facilities) for DSLs. Then you create the solution in the DSL.
For a great discussion of its possibilities, I recommend the article describing it by the founder of JetBrains:
http://www.onboard.jetbrains.com/is1/articles/04/
JetBrains is getting into this area with a new product called Meta Programming System, a beta of which is available through their Early Access Program. Find out more about it here:
http://www.jetbrains.com/mps/
What a mouthful huh?
We have secure, distributed programming languages, and we have multi-paradigm, distributed programming languages.
Next stop: secure, multi-paradigm, distributed programming [1],[2].
[1] The Oz-E project
[2] SCOLL: A Language for Safe Capability Based Collaboration
Higher Logics: where programming meets science.
... a long time ago. Sure, its a commercial platform, but being able to leverage C/C++, Java, and .NET and of course AJAX and Flash through simple, tag-based markup, really speeds things up. It can run on any major platform too.
body massage!
<:import foo:>
<table>
<:for `foo.Users.getSome()` u:>
<tr><td><:val `u.username`:></td></tr>
<:/for:>
</table>
And just like virtually every other templating language, it makes the same mistake of putting flow control seperate from the html (Not to mention escaping into complex python expressions when it really isn't needed), which leads to a complete mess in anything more complex than a simple repeat example.
Now TAL on the other hand
<table>
<tr tal:repeat="user foo/Users">
<td tal:content="user/username">
</tr>
</table>
Much cleaner- you don't have to constantly 'escape' into another language.
I absolutely hate this style of templating- it makes it incredibly difficult to debug. I like to be able to skim through an entire html page at once. Flow control in a template to, say, repeat over a dataset is NOT business logic and doesn't need to be seperated. If you're using something like TAL this becomes much simpler-
-Don
Take a look and feel free: http://www.PieMenu.com
at a quick glance, knowing none of the languages involved (except for extremely basic HTML), I find the GP's code much more immediately comprehensible. Now, immediate comprehension is not the beall and endall of a good programming language, but it can be quite important, especially when dealing with code someone else has written.
SIGSEGV caught, terminating
wait... not that kind of sig.
Declarative Programming is like Functional Programming, only it goes one step beyond: it converts a functional algorithm to an imperative one, by identifying at compile time which data can be safely updated.
In Declarative Programming, there are no references or objects; there are only values, even if these values are composite ones like a Window or a database object model. A DP program is a recipie of value transformations: a set of values is transformed to another set of values through I/O and computations.
DP programs can also act as formal specifications, since they manipulate sets of values and specify the transformations between them using the lambda calculus.
DP saves the programmer from having to manually insert destructive updates in a program. Updating of a variable is just an optimization anyway...if we had infinite computers, we wouldn't reuse the same variables, but instead act on copies of them. The whole problem is referential transparency, of course, which FP solves, and DP optimizes.
Another promise of DP is algebraic types...i.e. types that their properties are defined by algebra. This covers all possible type categories, like enumerations, classes, etc
There is no concrete mathematical theory yet developed, but there is evidence that any functional algorithm can be converted to the equivalent imperative one. For example, the functional quicksort algorithm can be converted to the in-place quicksort algorithm. Check out this link for further information.
The problem wasn't just the parenthsis. Actually, a LISP program for your sentence would be (more confusingly):
(if (needed I (to-look (at LISP) (day all)))
(would-stab I (eyeballs my) out))
That doesn't quite roll off the tongue so easily...
Me Tarzan, you Jane.
Me hungry.
Me want...COOKIES!
Avalon will be a system for declaratively defining a rich ui. The design will presumably allow for what is called a RIA here, but isn't limited to that. More analogous is Microsoft's Atlas, which will probably be released much sooner, and be more cross-platform.
The central point of the linked article is, that Lisp is the "highest Language" around - Could somebody comment on this? Sureley there must be a higher, even more experimental language somewhere, no?
Smalltalk is one of many image-based environments out there. A problem with all of them is that they tend not to play well with file-based toolsets, like source control.
Now it is true that you can build a set of tools in Smalltalk to do what you can do with a filesystem. However you've just guaranteed that to become productive with Smalltalk you need to master this entire custom toolset. And if you want to become productive with another image-based environment then you need to master another toolset. And since the Smalltalk community is smaller than the Unix community, odds are that there are some good ideas in the standard file-based toolset which just haven't yet made their way into Smalltalk.
This is one reason why I personally prefer Ruby. It has many of the benefits of Smalltalk, but it is filebased so people don't have to throw away their existing development toolkit.
BEPL
The Kruger Dunning explains most post on
Every time RoR is mentioned on slashdot RoR's hundered or so door-knockers get their code references, suits and start jamming their version of salvation down our throats.
So I tried RoR, and found two things:
1. It has a few really talented people heading a community of zero-talent idiots
2. It's another framework, with all the bullshit frameworks involve
None of the above should have been surprising. RoR promises to be easy but in reality frameworks are there for noobs to avoid the very basic step of learning OOP programming on their own.
If you thought you might be interested in Ruby on Rails, I suggest two courses of action:
1. Learn to use OOP in the language you've used until now.
2. Build your own framework. After all since in the end a framework is only an agreed coding style, the framework might as well be based around YOUR coding style.
I recently started teaching PHP (most fun thing I've ever done actually) and I've found a good use for frameworks. One of my class projects is for each student to develop their own. This is because the most effective framework for any one programmer is one they wrote. End of story.
I was project lead on 2 projects using Smalltalk between 1990 and 1994. Commercial in-house projects with >10 developers, so not small stuff - I think I know what I'm talking about.
Never mind syntax, it died for very good reasons:
1. It's too big. Because it abstracts the machine so much, a ST installation is an all or nothing proposition. You've either got enough memory or you haven't. In 1995, for example, I was working on yet another site which had a ST project going for their salespeople (I wasn't involved with that one) to go out and visit customers in their homes.
Everything went fine until they tried to deploy it - IBM Visual Age didn't support 64M Ram allocation. Ouch, but IBM fixed that.
Then the order for the laptops went in - all the way up to the CIO (this was a large company). He canned the project as it was too expensive.
2. It's too slow. Have you ever seen a ST application? You know what I mean.
At that time, Java came out of nowhere and killed it off. All the advantages of ST - dynamic, GG, yada, yada - and you could size it to fit the problem, and - while slow at first - the promises of speed were met.
ST is dead, get over it.
That is, if I am only going to learn one, which should it be? Python!
Jesus = communism = Karl Rove = treason.
If it was by "thinking" that you arrived at that, then please don't. Anywhere. Thank you.
Back in the day, there was once a lot of talk about how programmers would someday be obsolete. I figured the ultimate goal would be to be the one programmer that eliminated all others. But programmers have proved resilient by changing the rules every few years.
;)
First it was the third generation language which allowed us to code in things resembling words. Then the fourth generation languages which integrated database access with the language. Then came the GUI with a new set of challenges all it's own. When that came close to being solved, then came the web and "markup languages" which made GUI programming again require a language. But dropping the 4GL concept now introduced the widespread adoption of SQL which means that I have RAD code in Delphi generating both HTML, SQL and, in some cases XML. And for job security, I can use MS Visual Studio to program in more languages than you know.
I think the end game will involve a graphically rich version of integrated circuits - much in the manner of flowcharts. Perhaps in an RPC model, or maybe open "source". Think black boxes, like IC's but more accessible and that don't smoke when you provide the wrong inputs. Let me connect them by clicking and dragging. Let me encapsulate them into larger black boxes.
Yes. You got it in one.
In the data base world it means this:
The pointers are carried in the tuples. These are of the following variety (ObjectClass,Version,Release[->table] [&ObjectID] : relationshipNameOrAdverb : ObjectClass,Version,Release[->table] [&ObjectID]). This meane that they are unaffected by changes in, of, or to the individual objects.
Its a DB table containing only the ObjectIDs and therefore the pointer to an object existing in a DB table containing them.
This means that the objects themselves are not affected by any change and that, since the information contained in those tuples is all meta information it is inherently stable.
The change is an addition to the standard SQL table definition protocol by the addition of Relationships to define Connections.
In addition these connections may themselves be 'valued' when an object itself may be defined but its existence is totally defined by the connection. Also additionally a Relationship, and by extension the Connections which instantiate it, may re between an Object and a Relationship.
Its might seem obscure and useless but it does have its uses and it means that the implementation is actually simpler by the implied recursiveness of the definition.
Its all overseen by a schema which is a repository for the Objects (but not their instances) their Class (instantiation) and instance methods (what makes the instances do what they do) and the Relationships (but not their instances.)
In the programming world world it means this:
You are now dealing with a large pool of objects, all unique, and a large pool of connections all of which respond to a simple set of messages.
Relationships respond to "find:[object, [version[release]]]" and "create: [contextObjects]"
ConnectionSets respond to "first, next, prior, last and count"
and Connections respond to "delete" (which may cascade depending on the schema.)
Objects have an added method "delete" (which may cascade depending on the schema.)
It impacts far beyong this to enable a post-VonNeuman architecture. Think 'Occam' with some finesse.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Could the person who modded this 'flamebait' get the fuck out of our polite, technical disscusion, and die? Thank you.
The little playing around I did with Ruby on Rails was very impressive, I understand why it's getting hyped.
Going totally OT, in my part of the world 'on rails' is an euphemism for 'on coke'. Is this widespread, or just local to my area (BC)
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
for 25 years but I only realized it, or make that formalized it, three years ago.
There is no real performance problem since you only deal with the relationships and connections that are relevant, and you safely ignore the rest.
Its is also a good solution to a caching and cache invalidation problem that vexed me about fifteen or twenty years ago (man I've been at this crap a lo-ong time.)
Send me your email address and we can discuss this further. My email address is charles@artdogs.org
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
I said the exact same thing when I learned Python instead of Ruby. Then in the interest of completeness I decided to see if Ruby was any better. BOY AM I GLAD I DID. Everything I hated about Python, Ruby did 100 times better. Don't let the project count scare you away. There are probably 10 times more VB apps than Python apps. Does that make VB a better language?
- tristan
I see you are familiar. Thats the strange duality of the Zope devs. Very rich platform missing basic features (like searching in zope3. YOU CAN'T SEARCH FOR SHIT EXCEPT IN THE MOST BASIC OF WAYS).
Religion is a gateway psychosis. -- Dave Foley
Language developers need to decide what well structured programs look like. (When I say structured, I don't mean "Structured Programming.")
Once the rules for how to structure logic has been determined (to the best of ones ability) then a language that formalizes those constructs should be created.
We have plenty of languages that are great for defining logic, but none for structuring it.
So how do we do this? I suggest looking to the universe for answers.
In the hardware world, there is no need for garbage collectors. The laws of the universe restrict hardware engineers and so they must decide which hardware device is going to exclusively own a resister or a capacitor.
The reason for garbage collection is because of the unrestricted nature of the state-of-the-art languages. Any old object can point to any other object.
If hardware was designed like software, then a circuit board plugged into you motherboard would share a resister or two with the circuit board on you hard drive. It wouldn't take a genius to see that this is a bad idea. But in software it's done all the time.
There are many other such problems that garbage collection causes like breaking encapsulation, causing memory leaks (i.e. objects aren't collected because some object incorrectly is still referencing it), slowing down your program, indeterministic destruction of objects, etc.
There are many other problems with programming that need to be solved, e.g. how to easily develop multithreaded programming without little or no extra coding. (I've personally developed such a model, one that also gives the developer the speed of manual allocation of objects with the automatic deallocation of a garbage collector with no extra CPU cycles wasted AND deterministic destruction of objects.)
Also, imagine only needing a single collection class instead of dozens. (I've also achieved this.)
With proper models, we can achieve such things.
We need to reconsider everything to innovate. Nothing is sacred. Everything should be up for a redesign.
Unfortunately, all we seem to do is evolve languages to add a special flavor of a loop construct.
I see a pattern of shifting back and forth between data-oriented techniques and behavior-oriented techniques. I personally prefer data-oriented techniques, and enjoy "collection-oriented programming" using concepts from the likes of relational and APL's step-children languages.
OOP is perhaps the pennicle of behavior-oriented in that interfaces tend to be thought of as behaviors applies to things. It is about time we swing back to the data side for a while.
I would also like to see more exploration of "separate meaning from presentation" such that syntax or views of logic can be customized to the developer and/or a particular need. Microsoft's CLR (or is it CRL?) is a baby step in that direction because it allows multiple syntaxes on top of more or less the same interpreter.
Table-ized A.I.
I'm not entirely sure what you're referring to.
On the one hand, you might be referring to the controller, in which case I'd respond that fetching a list of users from a database is most certainly not presentation, especially if you're doing anything more complex than "get me all of them."
On the other, you might be referring to the call to "render_colleciton_of_partials", in which case I went to lengths to point out that it's optional, that you can "repeat over a dataset" right in the page content if you like, and that the render_collection... function is usually only used in situations where the presentation of each member of the dataset is hairy and obnoxious. In which case, it's probably much easier dealt with in its own file.
So, um... what's your point?
I think what you mean by specification is "declarative" programming. This is not new. Html/XML is declarative. The programmer gives the WHAT to do, not the HOW. That would be imperative programming. Most popular languages such as Java/C#/C++ are imperative. Keep an eye out for Microsoft's XAML. They try to push things more toward the declarative model.
Most higher level languages rely on raising the level of abstraction. Unfortunately with those kind of constraints, there's not much you can do. There's not enough computing power to effectively abstract away the lower level details and still maintain acceptable performance. just one of the things you trade off for lower cost of hardware.
Smalltalk died because it solved the problem with elegance instead of practicality. It's the same reason why BSD is being killed by Linux (ie /bin, /usr/bin, /usr/local/bin, etc ad nuseum scheme makes sense but isn't practical as just dumping everything in /usr/bin).
Sure, the Smalltalk language fits on a postcard and is mostly self-consistent, but only zealots actually care about that because people are perfectly capable of using complex syntax if it's more practical. For example, operator precedence was invented way before computer languages, and it was invented for a reason -- it helps people understand the equations. In each decade the languages derived from algol and simula syntax (C, C++, Java) have dominated everything but scripting because they appeal to how we think even though they are most certainly not {elegant;}!
Another elegant but not practical solution is to make everything an object. Just making a few non-object types makes interpreted Java faster than highly optimized, JIT'd Smalltalk. Smalltalk can't be used for significant numerical work whereas Java isn't a great choice but is rarely over 30% slower (vs typically 4-20 times slower for the fastest Smalltalks).
And finally, the third major nail for Smalltalk is that the whole system is changable. This is the elegant solution since you can solve some large problems by making just a few minor tweaks. But the industrial revolution replaced customized individual parts with completely interchangable parts. You don't custom engineer the bolts in a suspension bridge to make them just so, you slap in the cheapest pre-designed ones that have the qualities you need. In Java you can't change a system object or really even patch any object if you don't have the source, but this is far more practical because there are no surprises. You don't have to know the entire class library to know how redefining Object's equals method is going to affect some obscure part (that maybe you aren't even using in your software... yet).
And it's not like Java doesn't also suffer from this... C# delegates are a crappy idea in terms of elegance or 'good OO' (they are essentially function pointers)... Java's inner classes actually make sense, but they just aren't as practical as delegates.
You are talking about zealots. The problem with side effects is the mess they bring when you try to prove things about your program, which isn't exactly zealotry.
Now, that was an impressively stupid comment.
[or something like that]
What this sounds like is some academic catching up to state of the art and codifying it in immaterial footnotes. Dimes to doughnuts that any "new models" will be obsolete (or at least extremely old hat) before they're noticed in the Grooves of Acka Deme. Work gets done before it notices it has a name. I once passed arguments to another program using spawnle and got (very, very wrongly) praised for "inventing a new technology" -- nobody in the shop I was working for actually knew what was in ANSI Standard C!
``Tension, apprehension & dissension have begun!'' - Duffy Wyg&, in Alfred Bester's _The Demolished Man_
Please No More programming models!!
www.boznz.com Simple solutions to complex problems.
Frans,
g uage.html.
you are right about the hype. For some heavy-duty train-regulation & aeronautics stuff, however, I have been using IOA, a specification-based language:
http://larch-www.lcs.mit.edu:8001/~garland/ioaLan
You may find this interesting.
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
"users respond better to RIA". Crap. I disable javascript and flash. I respond by not visiting such sites. I want plain HTML and a form. With all the detail on one page. No "next next finish idiocy". Flash: a disaster, not a new model.
Running computationally complete stuff written by an anonymous author on your own PC using a massive, poorly debugged application is just asking for trouble: It raises the barrier to entry for new user side systems which lack said massive, poorly debugged system infrastructure, makes life a joy for people who want to break into your system, and generally ceedes control over your own infrastructure.
so why bother typing out it's name?
xml: <ol><li>1</li><li>2</li></ol>
lsp: (ol (li 1) (li 2))
forth is a language which allows you to define itself on the fly.
i did a uni project on extensible languages and covered this a little. it looked very interesting, although i can't say i learnt much about it, since i was writing my own application which could load an extensible language definition and compile applications to Java. (geez, anyone got some money for a patent? btw this is the second time today i've asked this question if anyone wants to employ me... hahaha)
i think languages that let you create new language constructs are the way of the future, since as i proved for my project - it is the best way to maximise the ratio of functionality VS code written.
maybe i missed the boat and someone is already working on such a thing.
as far as internet languages - what's the go? it's just another regular language with a different system environment isn't it?
people thought that distributed programming was the new 'programming model' until they realised they were writing the same code in a different environment (IMHO one that will overcomplicate all but the largest project).
'language model'.... guess i probably should RTFA, but if you really mean the next level in grammars for directing computers i don't think either of these things qualify.
It's OK Bender, there's no such thing as 2.
Despite the prevailing "wisdom" of those who have become impatient with the Perl 6 project, it is meant for the long term and I suspect its strong linguistic roots might enable us to start looking for meaning in text, and that might be a reasonable candidate as a future disruptive application technology.
Presumably that scenario would require a stronger mix of automated and by hand programming, which Perl 6's macros should facilitate.
-- Our systemic servants do not good masters make.
Not that these stats are everything. Clearly, in the professional world, VB is more common / popular. Mostly, though, I want to keep up on my skills, and use a language that I'm able to find other people who know (more resources, people to hire or work with, etc.) I want to make sure that the libraries are there, and other resources (like books) are there.
Maybe I'll check into Ruby a little further. Ruby does have the "Ruby on Rails" momentum going for it. (Reminds me of when Java came out - and a lot of non-tech people heard about it from Sun's marketing. It got "popular" in part because it was a buzzword of the Internet. Perhaps Ruby on Rails will cause the same thing to happen for Ruby.
These are all functional languages, or can be used functionally.
That line really got to me too. I was going to reply but then you already said everything much better than I could. Excellent.
Arbitrary sig
There's always the balance between "getting it done" and "getting it done right". If "getting it done" is the highest priority, as it often is in the real world, sometimes it's best to do whatever you need to do to get it done. Including using your prototype code in v.1 of production.
www.clarke.ca
mao che minh=tusixoh=trollllllll
-Don
Take a look and feel free: http://www.PieMenu.com
Decisions about tools, lifecycle models, and thin vs. thick client are all best thought of in terms of the needs of the project and questions used to identify those basic needs:
1. How much can I expect to control the deployment environment? Not much - then I probably want to do my heavy crunching on the server (example is a banking application), otherwise I can get away with offloading a good chunk of processing (example is a video game). This can be anything from http browsers specifications, CPU speeds/throughput, expected memory limitations, peripheral devices differences (AGP vs PCI video adapters and specific types of adapters etc.), to other communications and security standards etc... (an endless list of things to consider - that you need to whittle down to something manageable based on your experience building applications)
2. How efficient must the code be? If I expect to be doing teraflops worth of processing - maybe I better write it in C and assembly code for the bottlenecks - maybe this needs to run on a high-end server. Otherwise, maybe I can use Python - maybe it will run fine on an old 386 with 32 mb ram.
3. What is my due date for the project? This will constrain the amount of complexity allowed and will impact the choice of tools and network and lifecycle models. To paraphrase a common observance, "Have it fast, have it good, have it cheap - pick any two"
In a perfect world we would be able to ask these questions and be on our way. Of course politics and business practices play a big role in limiting what we can do and how we can do it.
In my mind there is no one right way to do every project - and I recognize what works for me might not work for someone else.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
With this topic, I expected discussions on such technologies as MDSD, MDA, or AOP yet there is no mention of these here. Does everyone here consider them to be DOA?
URBI is a new programming language devoted to robotics until now, but people are wondering whether it could not be useful in other domains, especially for multicore processor programming. Indeed URBI proposes new programming models and features that makes it suitable for this: * easy parallel/serial commands execution * native event based programming * native support for several mutex policies (blend modes) The URBI Kernel is GNU GPL. You might want to have a look, it's there: http://www.urbiforge.com/. Feedback welcome, Jean-Christophe Baillie
Maybe Common Lisp source is clean and elegant or maybe it has all the charm of porridge with finger nail clippings, but all that misses the point.
,name (,vector ,@parameter-list) ,(mapcar ,@(mapcar #'second defining-equations))))))
...) works.
Here is an example from this afternoon's coding. I'm trying to turn the Lorenz model into a musical instrument. My text book gives the differential equations as
.
x = p(y-x)
.
y = rx - xz -y
.
z = xy -bz
where p,r, and b are parameters and x,y, and z are variables, coordinates in a 3 dimensional space.
It is easy enough to code up these equations
(defun lorenz (x y z p r b)
(vector (* p (- y x))
(- (* r x)
(* x z)
y)
(- (* x y)
(* b z))))
is a function of 6 variables that returns a vector of three elements.
However that is not really what I want. I want to pass in a vector (x,y,z) with my variables bundled together. So I decide that x will be component 0, y will be component 1, and z will be component 2 and code:
(defun lorenz (v p r b)
(vector (* p (- (aref v 1)(aref v 0)))
(- (* r (aref v 0))
(* (aref v 0)(aref v 2))
(aref v 1))
(- (* (aref v 0)(aref v 1))
(* b (aref v 2)))))
Well that is crap in two different ways. First, I'm repeating myself. (aref v 0) would be OK if I only typed it once, but repetition is bad. Second, the connection to the page in my text book is lost. I really want to be copying the equation out of my text book. I can cope with infix to prefix translation, but I don't want to lose my symbolic names. Fortunately it is easy to fix
(defun lorenz (v p r b)
(let ((x (aref v 0))
(y (aref v 1))
(z (aref v 2)))
(vector (* p (- y x))
(- (* r x)
(* x z)
y)
(- (* x y)
(* b z)))))
At this point one says: the three lines with aref in them are just boiler plate, make them go away!
One wants to be able to code a function that is passed a vector, is written using component names, and returns a vector, like this
(defvecfun lorenz (p r b)
(x (* p (- y x)))
(y (- (* r x)
(* x z)
y))
(z (- (* x y)
(* b z))))
No repetition, no boiler plate, clear relationship to the equations in the book.
Common Lisp doesn't have a defvecfun command, so I add it by defining a macro
(defmacro defvecfun (name parameter-list &rest defining-equations)
(let ((vector (make-symbol "V"))
(variables (mapcar #'car defining-equations)))
`(defun
(let
(lambda (var)
(list var
(list 'aref
vector
(position var
variables))))
variables)
(vector
Now my ideal code (defvecfun lorenz (p r b)
Rather than manually translate the equations in my paper book to meet the syntax requirements of my programming language, I type the equations from the book into my source file without regard for the fact that I want x,y and z to be components of a vector. Then I write a bit of code, my macro, to automatica
Lisp-phobia is actually displaced homophobia. The first thing a homophobic latent homosexual thinks when they hear the word "lisp" is "gay", so it triggers their automatic defensive reaction (inexplicable violent emotional repulsion, taking the offensive against Lisp as a symbol of homosexuality and an affront to their manhood). So they never realize why they really hate Lisp, since it's all a subconsious chain reaction. They justify it by claiming it's because of the parentheses, but it's something much deeper.
Perl naturally appeals to a homophobic's need to reinforce and prop up their facade of manhood. They love the fact that it's hard to learn and difficult to use, because that makes them feel studly and virile, without actually having to come into contact with people of the opposite sex. Elegant, easy to use languages like Lisp are for fags.