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?
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 have heard marvels of Embryo Enlightenment version of SMALL
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
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.
It's not a programming model, it's a delivery model. As near as I can make out they're just web apps that rudely offload processing onto the client. The actual programming model stays the same whether it's a desktop application, webapp or RIA.
Don't blame me, I didn't vote for either of them!
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.
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.
I'm increasingly finding that web programers ( and their managers ) can be like that. Meaning that they're increasingly trying to find ways to make "HTML-server based application with some client interaction" sound new and exciting.
Not that using advanced Javascript||.NET||Java||C||Objective-C||Python||wh atever on the client to communicate to a server running Perl||C||Python||Java||.NET||Ruby||Objective-C||wh atever using XML( or whatever ) isn't interesting or useful, it's just... like calling a personal log-format web page a 'weblog'; it's not really something new in the abstract, it's a new way of doing something that's been done before. In other words, it's marketing hype to make you think you're seeing something truly new. At least in general, the implementations are new, not the ideas.
Functional programming and continuations. One present day example is the UnCommon Web, which is a web application framework implemented with continuations.
I totally agree with you. I won't get into details about why I think the FA was referring to the latter (or even better -- how naive programmers don't even know the difference). Instead, I will mention two ideas that I think will keep nibbling on the edge of expanding our understanding of programming.
1) Generative programming. OOD is a relative good technique for representing the design of an a program. Especially combined with some of the recent (in the last 15 years, say) understanding of OO design patterns. However, OOP does not allow effective reuse of code without compromising the flexibility of the design. Enter generative programming. Essentially you write computer programs that can generate the code you need in different circumstances. A simple example of generative programming is using C++ templates to generate a sorting algorithm for various different types of objects.
2) I know some work is being done in this next area, but I don't know what it's commonly called. Basically allowing the programmer to manipulate the code based on the AST using a refactoring browser. This is essentially a literate programming technique. The "source code" is merely the output of the program that the programmer can use to read the program. However, all interaction with the code is done using a refactoring browser.
So why do I think these are new programming techniques rather than just technological gimmicks? First, I think it is important to distinguish between design techniques (such as design patterns, or OOD) and programming techniques. Programming techniques are how we use technical tools to solve our problems (e.g., using a virtual function table to give us polymorphism).
I would like to also make a distinction between programming techniques and technical tools. For instance, a class library is merely a technical tool. It might reduce my work, but it doesn't give me flexibility to use a language to express different ideas than are in the library. Using templates (or generics) is a programming technique that allows me to do some generative programming (i.e. represent my ideas in a more efficient form), while an "event" in C# is merely a tool that saves me from having to implement the observer pattern.
One can see that a language designed around generative programming ideas, as well as a language that is designed to be manipulated using a refactoring browser can lead to a difference in the way I think about programming. It will change the way I communicate with the computer and my fellow programmers. RIA appears to me to be just a set of tools that might save me time. But perhaps I just don't understand what the FA was talking about.
-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?"
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
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").
That's why I'm advocating a formal approach - done correctly, the idea would be that you COULD NOT SPECIFY a problem properly without giving the database the ability to determine whether it has been done or not. You still need intelligent people to specify the requirements, but the idea would be that once you DO fully specify them it would be immediately clear what exists, courtesy of the searchable central archive.
That's one of the problems that needs to be attacked - too many problems have been solved only in old code, or an obscure library, or only in one language. We need to make programming solutions both general and searchable, which requires a rigorous system.
Now I agree that it might sometimes be faster to just code the darn thing than learn to use such a system (probably quite often, really), BUT. Once learned, it would make all future tasks both easier and FAR more robust.
It's the same old problem - it takes effort to learn an app/language/system, and people will always take the shortest path, generally speaking. What I'm saying is that we should use organization, education in schools/college, and formal methods to make a system so powerful and robust it will be wasteful and expensive to use anything ELSE. Do it Right once and build off of it. Most of the work in an application design is designing the solution - most of the pieces, logically speaking, should already exist. So once you know WHAT you want (I know, that can change, but if you're going to do it you've got to have some idea) the actual DOING of it should reuse proven, solid parts. Creating that system will be really, really hard but would allow us to build much more powerful software - think about it as using steel beams and architects to create a skyscraper instead of knocking together a wood hut to keep the rain off. The skyscraper requires a heck of a lot more supporting industry and design, but look at what it achieves.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
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.
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
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
These have been around for ages, but mainly for scientific computing. For example Fortran 90 and later versions, but there are also variants of C++ and others. Usually they take advantage of obvious parallelity in the data, for example matrix multiplication, and make the processors handle the separate bits without bothering the programmer with threads etc. It's also the kind of computation that takes place in graphics cards with their multiple pipelines.
I don't see any easy way to do the same for general programming. For example, separate threads for user interface and the actual processing is a good idea, but a very high-level one, not the kind of thing that would be done automatically by a compiler.
I hope that the existing parallel programming languages would be more widely used for the computationally intensive parts. It seems so silly that home computers have focused on pushing single processor performance for all this time, while 'real computer science' has been reaping the benefits of parallel processing for years.
Escher was the first MC and Giger invented the HR department.
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
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.
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
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.
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 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.
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.
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.
BEPL
The Kruger Dunning explains most post on
With other languages, a compiler 'parses' your code into an Abstract syntax tree, in Lisp, your code is that tree.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
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.
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?