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?"
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?
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.
1. Come up with a great idea.
2. Write a bunch of spaghetti code.
3. Properly format my @*#$& HTML.
4. ???
5. Profit!
Reminder: Apple owns 1/255th of the internet.
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 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.
You know what I'm talking about, yeah, you do.
You are not alone. This is not normal. None of this is normal.
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
1. Come up with great idea
2. Write a bunch of spaghetti code that only you can read
3. ???
4. Job security!!!!!
I got nothin'
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.
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.
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.
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
Sounds like the mindset of the place I used to work. It went something like this.
"Hey! If we write a whole bunch of spaghetti code that only we can read, and that breaks a lot, then people will see us doing stuff all the time and we will have job security."
The sad part is that it seems to have worked in that company instead of them getting fired for incompetence.
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.
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.
When my bose asks for the documentation i point to my work load and ask him which one he wants done.
he always response "get the other stuff done first, and stay away from beer trucks"
'...if only "Jumping to a Conclusion" was an event in the Olympics.'
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
Next programming model is right here
-Don
Take a look and feel free: http://www.PieMenu.com
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.
What's funny is that this is the first post and it has been labeled redundant.
What is your penile percentile?
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. --
-Don
Take a look and feel free: http://www.PieMenu.com
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.
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.
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
I started on BASIC, then learned PASCAL. Moved on to C, then C++. At some point I did scheme, Java, korn shell scripting, bash scripting, Perl, PHP, jsp, javascript, etc. Many of those languages are not alike.
This is not about similarity. This is about an *aweful* syntax. Just plain bad IMHO.
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
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.
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
-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/
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
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
What's wrong with parenthesis? If you hate parenthesis, then do you hate XML twice as much as Lisp?
Lisp syntax is excellent because it's simple and consistent, and that's the reason Lisp macros are so powerful. Perl syntax is absolutely awful, and that's the reason Perl will never have macros like Lisp.
-Don
Take a look and feel free: http://www.PieMenu.com
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))
I love the way he wants to get away from decade old programming models to Ruby on Rails, which uses the same programming model found in NeXT's WebObjects in...1995.
I am TheRaven on Soylent News
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 ==
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.
Is it about "*aweful*" syntax, or awful spelling? Or are you full of awe?
What's wrong with parenthesis? If you hate parenthesis...
What's wrong with it is that you spelled parentheses wrong. One parenthesis, multiple parentheses. But at least you're consistent in your misspellings.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
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.
PWNED!
Okay, a slight mis-spelling. I accept that. Fine.
And yes, FWIW I hate XML as well. Did I make any indication that I felt otherwise about XML? Did I even mention XML? Why do you care so much about XML?
I also don't recall saying that I hated parenthesis. I've got nothing against them per se. I dislike LISP and Scheme and the like because of their syntax. If you didn't like "C" because of its syntax, I wouldn't assume you dislike curly-braces.
The only thing that actually makes XML slightly better to deal with is that it's a document format, not a programming language.
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
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...
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
Why would he hate XML because of parentheses? It has none as far as I know.
Unless of course you are using super-dooper edition..
Arguing in favor of both LISP _and_ XML? Jesus man, get a hold of yourself! cold water in face!
-Don
Take a look and feel free: http://www.PieMenu.com
-Don
Take a look and feel free: http://www.PieMenu.com
Ok, there we go again. Write one hundred times:
- Lisp is a programming language
- XML is a data description language
If you haven't learned by then, follow up by writing one hundred times:
- Lisp is created mostly by humans
- XML is created mostly by computers
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
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.
Lisp is a programming language and also a data description language. Lisp programs are exactly the same stuff as lisp data, so Lisp macros operate directly on lisp programs as well as any kind of Lisp data (S-Expressions), which makes them extremely powerful, in ways that C-preprocessor-like text substitution based macros and type system based C++ templates simply can't approach. Lisp is the original floor wax that's also a desert topping, that both shines well and tastes great.
XML is a data description language, which has programming language applications, and many other applications having nothing to do with programmign languages. That is to say: There are many XML based programming languages, which are all applications of XML, not XML itself.
If you take the parenthetical arguments against Lisp seriously, then you have to dismiss XML and all of its many applications on the same grounds.
-Don
Take a look and feel free: http://www.PieMenu.com
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?
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.
That is, if I am only going to learn one, which should it be? Python!
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.
Don, that's bullshit, and worse, you know that. Lisp has deeper structure than sexprs. Arbitrary sexprs are not the same as Lisp syntax. The next time you have a macro that accidentally feeds a procedure in the first-arg place instead of a symbol, you can give me some Slashdot karma. Or when you screw up the levels of parens for a cond. Your penance is a RELAX-NG schema for a Lisp-disgustingly-expressed-in-XML system.
While I share your amusement at XML conquering the non-Lisp barbarians (by way of hypocrisy), you should not be overselling Lisp. Instead, you should be explaining how manipulation of XML as a real tree will avoid the soul-scouring horror of cross-site scripting vulnerabilities and SQL injection attacks. There's a lot of money to be made there. Please take it so I don't have to.
- C is a programming language
- Lisp is a data description language
- XML is crippled Lisp with no semantics.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
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.
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?
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.
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
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.
This is more about the image-centric construction of Smalltalk.
;-)
I agree that modularisation of Ruby is a lot better, but an image can help debugging (and continuing) programs that take a long time to run or debug.
For me, the modularisation of Ruby is not good enough yet. But it is a good start.
The question was about what programming model should become the future. And for me it is certainly something that is close to smalltalk (or Ruby).
Answering the question "What are the next programming models",
it is not really interesting whether the language is hybrid (Java, C++) or abstract.
What is interesting that we have used programming models in Smalltalk, that we see appearing slowly in other languages too..
That means any future programming model (not language), will certainly be close to what we see in smalltalk.
That is why Smalltalk is always coming back in some way.
The main syntax problem of C are not the curly braces. The main syntax problem is the terrible declaration syntax.
The Tao of math: The numbers you can count are not the real numbers.
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
The only thing that actually makes XML slightly better to deal with is that it's a document format, not a programming language.
Erm, XML and S-expressions are both data formats. It so happens that S-expressions are used to express programs in a number of programming languages in the Lisp family, but this doesn't stop them being a data format. You're very confused.
Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
Fine. I concede. Jebus, will you List/Scheme folks stop bitching about XML now? I never even mentioned it. Lisp sucks, it'll never come back. Thank $DIETY it's dead. I'm done here.
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
Well, those who don't learn advanced programming languages are doomed to reinvent them -- badly.
Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
"Is it about "*aweful*" syntax, or awful spelling? Or are you full of awe?" It is misspelled but weirdly enough, "awful" does come from "full of awe".
Is it about "*aweful*" syntax, or awful spelling? Or are you full of awe?
Well as long as you're playing dress-up with your daddy's grammar cop outfit, let me show you how the safety on that gun works. Awful means "filled with awe." God is awful. Awful does not mean bad, and awe does not mean good. "God is awful" means "omg god is scary."
That's why when you say "huhu i hate when people say awful smart" educated people within earshot sigh and shake their heads.
Lisp syntax is excellent because it's simple and consistent, and that's the reason Lisp macros are so powerful. Perl syntax is absolutely awful, and that's the reason Perl will never have macros like Lisp.
Yeah, and that's why LISP killed Perl.
Don't bother calling me a Perl fanatic; I barely use it. I'm just a pragmatist. You guys can swear by a syntax you're just used to until you're blue in the face; LISP has a bad syntax whether you like it or not. It's simple, consistent, bulky, hard to read, and so famously a source of parse bugs based on a visual hanoi's tower of brackets that there's in fact an entire class of jokes revolving around its baditude.
Next, tell me how simple and elegant your double bucky keyboard is, or how you didn't have to go through X-Ray machines to use the ornithopters growing up. Or how lunch cost a nickel and how walking uphill both ways in bare feet builds character. If LISP is so simple, elegant and powerful, and since it's one of the very first programming languages, since it's had a free implementation since about two days before it was invented, then riddle me this, quiz master: why is it so dead?
There's nothing worse than listening to velociraptors opine the importance of the 140-foot-tall predator. Move on, Jurassic Jim. The rest of the world is tired of calling your museum number.
StoneCypher is Full of BS
-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
So do you agree that you should reject XML for the same reason you reject Lisp: too many parentheses? Or do you claim that it's easier to read twice as many XML angled brackets with repeated tag names, than Lisp parenthesis? If so, then why's that?
-Don
Take a look and feel free: http://www.PieMenu.com