Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Announcing Opa: Making Web Programming Transparent

timothy posted more than 2 years ago | from the opalong-nothing-to-see-here dept.

Cloud 253

phy_si_kal writes "Opa, a new open source programming language aiming to make web development transparent, has been publicly launched. Opa automatically generates client-side JavaScript, and handles communication and session control. The ultimate goal of this project is to allow writing distributed web applications using a single programming language to code application logic, database queries and user interfaces. Among existing applications already developed in Opa, some are worth a look. Best place to start is the project homepage which contains extensive documentation, while the code of the technology is on GitHub. A programming challenge ends October 17th."

cancel ×

253 comments

Sorry! There are no comments related to the filter you selected.

very expensive to implement (4, Funny)

Tumbleweed (3706) | more than 2 years ago | (#37230650)

Every time you do something in Opa that is successful, you have to break a plate. Opa simply isn't economical to scale.

Re:very expensive to implement (1)

Anonymous Coward | more than 2 years ago | (#37230686)

Every time you do something in Opa that is successful, you have to break a plate. Opa simply isn't economical to scale.

and then there's the Ouzo. No beer or single malts for Opa programmers!

I welcome our Greek inspired programming overlords!

Re:very expensive to implement (1)

Trepidity (597) | more than 2 years ago | (#37230942)

ti les re; den apogoreuetai oi mpura!

malista, einai upoxrewtiko to ouzo, alla den eimaste fanatikoi k'olas

Re:very expensive to implement (1)

St.Creed (853824) | more than 2 years ago | (#37230944)

Hehehe... and in Dutch, it means "grandfather".

"Yeah, I wrote this program in grandfather and..." (voice trails off under whithering stare of boss)

This is why commercial entities do a namecheck before choosing names :)

Re:very expensive to implement (2, Interesting)

Anonymous Coward | more than 2 years ago | (#37231060)

In German too. So Germany, Austria, half of Switzerland and Luxemburg are already going WTF or laughing before they even check if itâ(TM)s useful.

(It's not. There is a reason there are different languages: The right tool for the right job. Trying to auto-translate e.g. JavaScript into SQL or regular expressions, is bound to result in a horrible frankenstein monster [which luckily is as slow as a glacier]. And for those languages where itâ(TM)s easy, like PHP, Python, Java, C++, it's not worth it since they are so easy that if you know one, you can learn the other one in a single day.
The real problem are the different libraries. Those are the ones that need unification. [But there should still be at least 3 competing unified libraries, so no monopoly or duopoly can ever happen.] Provided they don't ignore the language differences.)

Re:very expensive to implement (1)

CastrTroy (595695) | more than 2 years ago | (#37231650)

I agree. This makes me think of stuff like Linq. SQL is a much nicer language for representing this stuff. Now, they could have added support for some kind of inline sql that could work on objects. Instead, they tried to shoehorn the functionality of SQL into C#/VB.Net syntax, creating something that is just more difficult to use. It's not that hard to learn 3 languages to do web development. Most web developers already know at least 3, languages such as SQL, PHP, and Javascript. Most serious web developers probably know SQL, Javascript, and 3 or 4 different server side languages. Languages are easy once you have the concepts down.

Re:very expensive to implement (2)

Tumbleweed (3706) | more than 2 years ago | (#37231108)

This is why commercial entities do a namecheck before choosing names :)

aka The Chevy Nova Effect

Re:very expensive to implement (1)

Jaxoreth (208176) | more than 2 years ago | (#37231260)

aka The Chevy Nova Effect

Whereby it's assumed that speakers of other languages are stupid? Would you refuse to buy a Notable-brand dining room furniture set on the belief that it didn't in fact include a table?

Then again, Apple's second lineup of iMacs came in five 'flavors' (grape, blueberry, strawberry, tangerine, and lime) -- one for each color of the (old) Apple logo except yellow. I guess they didn't want to be selling a lemon. :-P

Re:very expensive to implement (1)

Anonymous Coward | more than 2 years ago | (#37231382)

aka The Mythical Chevy Nova Effect

FTFY!

http://www.snopes.com/business/misxlate/nova.asp [snopes.com]

Re:very expensive to implement (0)

Anonymous Coward | more than 2 years ago | (#37231122)

Cool!

Maybe as a joke to the rest of the World (computer languages seem to all come from the US), a programming language name that translates to "Fuck You" in another spoken language. So, when the boss asks, "What language are you implementing this in?" you can respond in all seriousness, "Fuck You boss. Why do you ask?"

Re:very expensive to implement (2)

Jaxoreth (208176) | more than 2 years ago | (#37231186)

Hehehe... and in Dutch, it means "grandfather".

"Yeah, I wrote this program in grandfather and..." (voice trails off under whithering stare of boss)

This is why commercial entities do a namecheck before choosing names :)

But if the name was chosen before the checking policy was instituted, then they get to keep it. I think there's even a word for this practice...

Re:very expensive to implement (1)

Guillermito (187510) | more than 2 years ago | (#37231232)

And in (south american) Spanish it means "stupid", "idiot".

Re:very expensive to implement (-1)

Anonymous Coward | more than 2 years ago | (#37231204)

Hehe, I love Greek.

Women just don't seem to understand that a man can find just as much pleasure in the warm confines of a well- muscled ass as they can in the satin embrace of a well-wetted cunt. Maybe we men have conditioned them too well to ignoring one hole for the other: nonetheless, every man I've talked to about it loves Greek and every woman who I've talked to about it has been less than enthusiastic. So imagine my surprise last weekend when Kathleen treated me to the joys of anal sex in what must be the first time in five or six years.

The night started our strangely. Kathleen had just finished re- arranging her large library and was exhausted. As suits my biological clock, I was just coming awake at 10 PM when she was turning in. She invited me to bed and I politely declined: I was horny as usual and told her I'd keep her awake. After a couple of more requests from her, I stripped and crawled in beside her. Kathleen loves to snuggle and wasted no time in curling her small body up next to mine. I turned and kissed her. She was oddly responsive for her tired state, and teased me with a hint of tongue in her kisses. I reached down to feel her muff and found it just beginning to rev as her right hand slipped down her belly to her clit.

I took up what has become my customary position between her legs - kneeling and using my cock as a sex toy to tickle her lower labia and the entrance to her cunt. But this time I let my aim wander lower to the wonderful curve where ass, crotch, and leg meet. I rubbed my cock against this soft crescent and expanded the stroke to brush against the entrance to her ass. I noticed that every time that my prick touched her rosebud, her strokes on her clit quickened. It wasn't long before I was pressing the tip of my cock against her asshole.

Surprise! My cock slipped easily into her ass until the entire head was buried inside, and just as I was about to pull out and apoligize, she handed me a bottle of sex lubricant and said "What the fuck? Why not?". I pulled back and poured the lubricant on my hard cock and noticed her pussy was swollen and very wet. I worked my cock back into its previous nest. It was so easy. I could feel her ass muscles relaxing and opening for me. I eased ever so slowly deeper. Such heaven! Like a warm, wet hand gripping all around my prick - so much tighter than pussy, and delightful in an entirely different way. I could feel her hips grind against me as I worked the last of my seven-plus inches into her back door. Realizing where I was and how long it had been since I'd known this pleasure, I had to fight to pull the reigns in on my orgasm.

It seemed like forever - my slow rocking pulling my cock almost full-length out of her ass before easing it back in until my balls rested against her firm buns. Her right hand furiously massaged her clit and her left hand played at the entrance of her cunt, pressing on the full length of her labia. And all the while my cock was enveloped in a firm net of gripping muscles that wrestled to bring the cum from me. "It's so weird," she said as she searched for the grip on her own orgasm. Suddenly, it was upon her. I felt her ass open up like a mouth that was just to blow up a ballon. "Are you close?" she hissed. "No," I grunted. She was close, tho'. Too close to stop. I felt her stiffen and lurch under me. "Uuhhhh! Come on you bastard! Fill my ass!" she yelled as she dug her nails into my back. Amazing what a little dirty talk will do - from that special nowhere where good men hide their orgasms until their lovers are ready, my load bolted from my crotch to my brain and back to my flushed balls. I gripped the pillow with my teeth and jerked my neck back and forth and tried not to deafen Kathleen when my cum blasted out of my cock like water from a firehose. The rush of jism racing up my tube seemed to last for stroke after stroke until sweaty Kathleen gasped, grunted, and pushed me from on top of her. Since I have a little anal experience myself, I knew the sudden discomfort of having something in your ass after you've orgasmed. I considerately slipped out of her despite not having finsihed my own orgasm to my complete satisfaction.

I kissed her and thanked her for her special gift, but she pushed me away. "Go wash off and fuck my pussy," she said " I feel like something's undone." So after a quick and thourough shower, I returned to the futon where her dripping, swollen twat waited for my not-quite-recovered cock.

And that's another story...

Re:very expensive to implement (0)

Anonymous Coward | more than 2 years ago | (#37231620)

mcgrew, is that you?

needs time (1)

danbuter (2019760) | more than 2 years ago | (#37230676)

Let me know if it's still around in five years. I hope it works for these guys, but there are so many options already around, they are running uphill.

Five years? Ruby on Rails barely lasted that long. (0)

Anonymous Coward | more than 2 years ago | (#37231038)

Even Ruby on Rails, which was first released during the summer of 2004, barely lasted that long. As anyone who does even the slightest bit of web development knows, RoR was hyped, hyped, and then hyped some more for years. It got a huge amount of attention, more so than basically every other web framework out there.

However, by the end of 2010 it was on its way out. People found out that the hype wasn't deserved. Rails apps performed horribly, they were unmaintainable, they couldn't scale well, and the community had some pretty serious misogynistic tendencies. The few good Rails users fled, and it has thus stagnated. Today, we hear very little hype about Rails, and nobody who knows what they're doing uses it for new projects.

Sure, it's still around, but it's a ghost town. It's looking like there won't even be a 10th anniversary at this point. Or if there is, it'll be a pretty sad affair. More like a funeral, if anything.

Re:Five years? Ruby on Rails barely lasted that lo (1)

danbuter (2019760) | more than 2 years ago | (#37231188)

That's why I said 5 years. It takes that long for people to figure out if the thing will actually work over time. As you so aptly said, Rails wasn't worth the hype.

Re:Five years? Ruby on Rails barely lasted that lo (1)

anomaly256 (1243020) | more than 2 years ago | (#37231310)

If this were even remotely close to being true, I'd be out of a job right now. And I'm not, so it isn't. :)

Clearly this is an attempted troll post..

Re:Five years? Ruby on Rails barely lasted that lo (0)

Anonymous Coward | more than 2 years ago | (#37231978)

Clearly this is an attempted troll post..

Rails = COBOL. It's dead tech. You need to get your head back in the game and switch to ASP.Net

Now this is a troll post, bitch.

Re:Five years? Ruby on Rails barely lasted that lo (1)

taxman_10m (41083) | more than 2 years ago | (#37231698)

I'm a newbie and slowly learning RoR right now, so I'm interested to learn that it is on it's way out. What has replaced it? What do you suggest learning for web development currently?

Re:Five years? Ruby on Rails barely lasted that lo (1)

modmans2ndcoming (929661) | more than 2 years ago | (#37231824)

if you want to be in the web dev game, you need to know everything. RoR, Some PHP frameworks, some Python ones, Catalyst for perl would be good, Javascript (the good parts) JQuery, HTML 5, XHTML.

The Web Dev world is very complex and sucks.

Re:Five years? Ruby on Rails barely lasted that lo (1)

Kagetsuki (1620613) | more than 2 years ago | (#37231958)

Uh, what? I'm guessing you posted as AC because you didn't want to get modded down for posting flaming bullshit. Let me guess, you're a Perl developer who's still pissed Perl* doesn't offer a comparable framework and still won't accept the fact that Perl 6 will likely take another 5 years and all the shiny new functionality has been available in Ruby since you first heard about it. Rails is still very alive and well and is used in quite a lot of major sites. Rails 3.1 has some really nice improvements as well. As for speed I'd bet on a Rails app over something like Drupal any day.

Twitter still heavily uses Rails by the way. If I'm not mistaken they are the ones who did all the work to combine Rails and Unicorn - and now you can bind your Rails app to unicorn with about one line of code.

*I very much like Perl - it does many things very well and it has it's place. For plain CGI scripts, shell scripts, and a variety of other tasks it's great. Though I really wish Perl 6 was out 5 years ago so we could stop fussing with this Perl 5 object modoki BS.

Re:needs time (1)

modmans2ndcoming (929661) | more than 2 years ago | (#37231804)

Is there any reason that a language like Java, C#, C++, Python, Perl or Ruby, or with the appropriate framework and compiler couldn't do the same thing that Opa is aiming to do?

On Hanselminutes, Scott Hanselman interviewed a guy who made the statement "Javascript is the machine language of the Internet", alluding to the fact that it is better from a productivity and performance perspective to develop in a lot of other languages (C# in this case) and have compilers that know how to create optimized, minimized, and cross browser javascript.

Re:needs time (2, Informative)

Anonymous Brave Guy (457657) | more than 2 years ago | (#37231970)

The developers are strongly backing a particularly virulent licence, Affero GPL. That requires that not only are the Opa tools open source, but any software you write using Opa is infected as well [opalang.org] .

The claimed alternative is to buy a commercial licence for Opa, which lifts the open source conditions, but costs an as-yet-unconfirmed amount of money.

To my knowledge, there is no programming language that is even moderately successful today that does not have a good quality, free-as-in-beer, no-strings-attached tool chain readily available.

I suspect Opa is about to become a textbook example of a project that was be stillborn because its developers were too greedy; they're just demanding too much control over other people's work instead of too much cash.

Re:needs time (1)

jbolden (176878) | more than 2 years ago | (#37232154)

Seems to me QT and GCC were both successful with that sort of licensing.

How is it different from, say, Wicket or ZK? (3, Interesting)

Cyberax (705495) | more than 2 years ago | (#37230694)

How is it different from, say, Wicket or ZK, or even GWT?

I can write complete AJAX-y webapps in Wicket or ZK, including database. They both store state of pages on server side, so AJAX becomes trivial (just rerender the page and send the difference in DOM trees using JSON).

Then there's GWT which compiles static Java code into JavaScript.

Re:How is it different from, say, Wicket or ZK? (2)

icebraining (1313345) | more than 2 years ago | (#37230996)

How is it different from, say, Wicket or ZK, or even GWT?

Not having to use Java?

Re:How is it different from, say, Wicket or ZK? (1)

Kagetsuki (1620613) | more than 2 years ago | (#37231968)

Check the documentation, Opa runs on Java....

Re:How is it different from, say, Wicket or ZK? (1)

Kagetsuki (1620613) | more than 2 years ago | (#37231972)

*I understand you were talking about the language, just pointing out we're not free form the clutches of Java on this one.

Re:How is it different from, say, Wicket or ZK? (2)

Seferino (837142) | more than 2 years ago | (#37232246)

Nope, it doesn't (note: I'm the architect-in-chief for Opa). Java is used only in the compilation process to run the Google Closure Compiler as a sanity check on our JavaScript libraries. Thanks for the great work by the Google team, by the way, this saved us literally months of JS debugging.

Re:How is it different from, say, Wicket or ZK? (1)

mellon (7048) | more than 2 years ago | (#37231392)

It's an integrated solution. You write one piece of code, and the compiler manages the AJAX interface. So you don't have to write your app in two languages and deal with communication between the server side and client side: the language hides that.

It seems like a good deal in a number of ways, and I think for a new application it might be a good choice. However, there are some problems—they have chosen to define a new language, rather than extending an existing language, so you have to learn and be current in another language. They require that you use their database, so if you already have your data in another database, you have to migrate. And of course you still have to know HTML and CSS, so really you're still programming in three different languages. But 34, so I guess it's a start.

Re:How is it different from, say, Wicket or ZK? (1)

mellon (7048) | more than 2 years ago | (#37231400)

That was 3 < 4, not Rule 34, in case anyone was wondering...

CGI.pm (1)

Aighearach (97333) | more than 2 years ago | (#37231554)

You write one piece of code, and the compiler manages the AJAX interface. So you don't have to write your app in two languages

Sounds like CGI.pm to me! I never went for that. With a code generator you have to be thinking about what it generates all the time, or else restrict yourself to the lowest common denominator... on every feature. And still have a brittle result.

Template systems for the dynamic parts win for a reason. And it isn't because of any shortcoming of Perl, Ruby, or that Aelfinn one.

Re:CGI.pm (1)

moonbender (547943) | more than 2 years ago | (#37231570)

Sounds like CGI.pm to me!

Huh? How so? It doesn't seem to be at all like CGI.

Re:CGI.pm (1)

Seferino (837142) | more than 2 years ago | (#37232260)

I confirm, no relation to CGI.pm that I can see (and I'm the architect-in-chief for Opa). That and we offer quite a nice templating system [opalang.org] , too.

Re:How is it different from, say, Wicket or ZK? (1)

shutdown -p now (807394) | more than 2 years ago | (#37231568)

It's different in that network communication is more or less transparent - you write a single program, not two clearly separated client and server parts (and then those in different languages).

Simply put, it's a lot like Volta [wikipedia.org] , except that, apparently, didn't get anywhere - even though the CTP was neat (it even let you do integrated debugging, like "step in" on client and it would get you into the corresponding server entrypoint). I think there's something like that for Java also. So this isn't exactly new, but they may be the first one to ship a production version of such a tool.

Why yet another language, though, I don't understand. We already have plenty that could be readily used for something like that (C# 5 with "async" feature would be very handy, for example), or you could take one and add some minor extensions.

yes! (1)

Anonymous Coward | more than 2 years ago | (#37230700)

I was just thinking: this is exactly what we need! Yet another programming language. And even more "web apps". Yay!

Re:yes! (1)

interval1066 (668936) | more than 2 years ago | (#37231024)

I was just thinking: this is exactly what we need! Yet another programming language. And even more "web apps". Yay!

You're not getting it. Don't think of web apps as some separate application layer, think "web". This is where its going, its already there to be honest. If you're not prepared for that simple fact you're in for a bumpy ride as its only going to get more "webby" in the future. And a new language that ties all that in a more comprehensive way is going to be a good thing.

Re:yes! (1)

aztracker1 (702135) | more than 2 years ago | (#37231146)

We already have a language that ties it all together in a comprehensive way... Front end (HTML+CSS+JS), Middle tier (Node+Express+JS), Backend (MongoDB+JS) ...

Re:yes! (4, Insightful)

mellon (7048) | more than 2 years ago | (#37231410)

Yes, and if Javascript weren't so bloody limited, that would be a great solution. Why, oh why, couldn't they just have embedded Scheme, which has all the wins of Javascript, and none of the limitations? Sigh.

I don't like the look of them colons (2)

mfearby (1653) | more than 2 years ago | (#37230710)

I don't know about you but I've never really liked the look of programming languages that use colons. Semi-colons are OK but two dots, one on top of the other? That's just craziness! And "do" statements remind me of BASIC... yuck.

Re:I don't like the look of them colons (1)

deniable (76198) | more than 2 years ago | (#37232036)

Actually, the colons give me a Pascal vibe. The indents remind me of Python. So, I've got a language that looks a bit like Pascal and Python, runs in Java and generates HTML + JavaScript. The documentation must be a fun read.

Obigtory..... (3, Insightful)

Anonymous Coward | more than 2 years ago | (#37230714)

This [xkcd.com] seems to be getting some use lately.....

Re:Obigtory..... (0)

Anonymous Coward | more than 2 years ago | (#37230820)

First thing I thought of as well!

Opa? (0, Informative)

Anonymous Coward | more than 2 years ago | (#37230724)

Well, i assume for sure that these guys know that 'opa' means 'grandfather' in German ?

Which open-source license? (2)

93 Escort Wagon (326346) | more than 2 years ago | (#37230732)

If I write a web application using Opa, and the server end accesses a database - am I required to release the sql username and password?

Re:Which open-source license? (3, Informative)

ludwigf (1208730) | more than 2 years ago | (#37230862)

AGPL 3

Probably the most important implication of AGPL is that it requires you to provide a way for your users to download the sources of the application. In fact Opa facilitates that by automatically enriching the server (in release mode) to serve the source code of the application at a special /_internal_/src_code URL.

But this is not the end of the story. We believe in free software (hence the AGPL license) but we also understand that it may not be very suitable for commercial users of Opa. Such users will be able to obtain a private license (paid). This will allow them to keep their sources closed if they wish to do so and will provide us with funds to further develop and improve Opa — win-win situation :). If you are interested in more details about obtaining such a license, do not hesitate to contact sales@mlstate.com, where we will try to answer all your questions (including pricing).

http://blog.opalang.org/2011/08/opa-license-contributions.html [opalang.org]

Re:Which open-source license? (-1, Troll)

tomhudson (43916) | more than 2 years ago | (#37231200)

So in other words, yes, you have to release the user name and password, since it's part of the source and compiled into the binary, and the AGPLv3 requires that it all be released.

The GNUstapo strikes again. Last week it was FUD to try to get people to encourage Linux to move to the AGPLv3 [fsf.org] , which would kill Android on mobile devices, and now this. No thanks. Keep chipping away at the various freedoms - you just end up making the *BSDs look better and better.

Re:Which open-source license? (0)

Anonymous Coward | more than 2 years ago | (#37231378)

So in other words, yes, you have to release the user name and password, since it's part of the source and compiled into the binary

Someone's never heard of configuration files!

Re:Which open-source license? (1)

tomhudson (43916) | more than 2 years ago | (#37231606)

You might want to look at the original post, and RTFA (a href=http://opalang.org/#slides=1>in particular, this slide). The "application" is a single executable, containing everything needed to run, including the data store. An additional problem is that the resulting application is itself a server, not code called by a server, so each instance of your app needs to have it's own port. Not very useful at all compared to today's setups:

http://opalang.org/resources/book/index.html#_setting_up_storage [opalang.org]

The following command line distributes 6 instances of Hello, chat on albertson, with user jeff. Each instance will be listening to a port between 7000 et 7005 included.

opa-cloud --host jeff@albertson:7000,6 hello_chat.exe

So unless you control the physical server, including the right to run stand-alone executable content as well as use ports outside of the standard ones, forget it.

Re:Which open-source license? (1)

mellon (7048) | more than 2 years ago | (#37231420)

Oh please, you're just being difficult. If you want an entirely closed-source application, you can pay them the licensing fee. If you want to go the open source route, but don't want to reveal your passwords, don't put them in the source code: store them in the database.

Re:Which open-source license? (1)

tomhudson (43916) | more than 2 years ago | (#37231544)

Oh please, you're just being difficult. If you want an entirely closed-source application, you can pay them the licensing fee. If you want to go the open source route, but don't want to reveal your passwords, don't put them in the source code: store them in the database.

And how, pray tell, are you supposed to get the password out of the database without the password?

Re:Which open-source license? (1)

deniable (76198) | more than 2 years ago | (#37232048)

You want me to keep the key to the safe inside the safe?

Re:Which open-source license? (1)

93 Escort Wagon (326346) | more than 2 years ago | (#37231320)

Probably the most important implication of AGPL is that it requires you to provide a way for your users to download the sources of the application. In fact Opa facilitates that by automatically enriching the server (in release mode) to serve the source code of the application at a special /_internal_/src_code URL. ... We believe in free software (hence the AGPL license) but we also understand that it may not be very suitable for commercial users of Opa.

Whether I'm a commercial user or not... why would I - or anyone - ever want web visitors to be able to grab the SQL username and password I'm using in the back end?

Re:Which open-source license? (1)

a_n_d_e_r_s (136412) | more than 2 years ago | (#37231584)

Whether I'm a commercial user or not... why would I - or anyone - ever want web visitors to be able to grab the SQL username and password I'm using in the back end?

Are saying that people actually write username and password in the source code ?

Thats a no no.

Use a configuration file containing secret information so you can protect it. Don't hardcode parameters that might change.
Put the SQL information needed in a configuration file that you read before opening the database. Then its easy to change
database, username and password if you need to.

Re:Which open-source license? (1)

Seferino (837142) | more than 2 years ago | (#37232274)

Whether I'm a commercial user or not... why would I - or anyone - ever want web visitors to be able to grab the SQL username and password I'm using in the back end?

Well, that's an awful practice, regardless of the language.

In Opa, since the binary automatically generates the database, scheme, etc. the first time it is run, the way we generally handle this is to have the binary generate random username/password and somehow display it to the console, where only the administrator can see it. There are other schemes, of course, but this one has served us nicely so far.

Using a simplified tool for a complex problem... (1)

blippo (158203) | more than 2 years ago | (#37230770)

I thought that it was proven that languages with less complexity will make simple problems simpler, and the rest of the problems impossible.

Re:Using a simplified tool for a complex problem.. (1)

blippo (158203) | more than 2 years ago | (#37230792)

Or maybe this *is* a complicated language, and I should just go back to idle.

 

For me as a German (5, Funny)

Anonymous Coward | more than 2 years ago | (#37230816)

this language seems to be obsolete from the beginning.

Re:For me as a German (2)

St.Creed (853824) | more than 2 years ago | (#37230956)

It was grandfathered in with an older browser :P

Re:For me as a German (0)

Anonymous Coward | more than 2 years ago | (#37231714)

I know that being /. there's an anti-windows ideology for all sorts of reasons aiming from a hatred of capitalism to wanting openness from others on demand to the security issues (in spite of being brought about by the ease of development for business applications) - but how can they even be remotely serious about deploying this when there is no Windows version around? They include Apple and Ubuntu, I suppose there is something to be said for catering to the least talented of all developers - and non-developers - for the sake of cheap labor - but not for serious development work - guess I'm sticking to LAMP for all my AJAX needs.

Javascript as assembly (1)

SharpFang (651121) | more than 2 years ago | (#37230866)

Am I the only one scared by the new trend of "languages that compile to Javascript"?

Coffeescript, Opa, there were some more.

I understand first compiling to Asembler and only then to machine code. I understand early C++ compiling to C. Various languages to bytecode...
But really, while I love Javascript for many features it provides, creating yet another layer of indirection on top of it seems to serve only one purpose: boost sales of faster hardware...

Re:Javascript as assembly (0)

Anonymous Coward | more than 2 years ago | (#37230946)

My own solution to this issue was actually to learn JavaScript, but this is apparently too difficult for some.

Re:Javascript as assembly (-1)

Anonymous Coward | more than 2 years ago | (#37231088)

JavaScript is actually a very difficult language to learn, especially for people who know one or more real programming languages.

We have to throw out years, if not decades, of knowledge and experience with doing things properly. We have to revert to JavaScript's absolutely pathetic level of stupidity with regards to every aspect of the language and runtime. For those of us who are good programmers, this is very difficult to do.

Even the most basic comparison operations are severely broken. That's how bad the situation is. No other language, aside from PHP, fucks up so badly something that is actually quite simple. Of course, JavaScript manages to make it get worse from there. It doesn't even do prototype-based OO properly, for example.

Those of us who are good programmers have a hard time intentionally doing idiotic things. That's why we find JavaScript difficult to learn and use.

Re:Javascript as assembly (1)

tomhudson (43916) | more than 2 years ago | (#37231246)

No other language, aside from PHP, fucks up so badly

perl?

Re:Javascript as assembly (1)

shutdown -p now (807394) | more than 2 years ago | (#37231558)

Perl at least compensates for its ugliness with a wealth of useful features, and the ability to write terse code.

Re:Javascript as assembly (1)

WillKemp (1338605) | more than 2 years ago | (#37231466)

[......] For those of us who are good programmers, this is very difficult to do.

Perhaps you're not as good a programmer as you think you are then.

Re:Javascript as assembly (0)

Anonymous Coward | more than 2 years ago | (#37231556)

Hyperbole is the WORST thing in the entire world.

Re:Javascript as assembly (1)

Herkum01 (592704) | more than 2 years ago | (#37230966)

There are guys doing this at my company, and the reasoning for it is that web developers know JavaScript. They don't necessarily know the back end language that is used to generate web pages (Perl, Java, PHP, etc...).

Rather than have web developers spend time learning the back end, they display a blank div and use AJAX to request the data that they want. Then they can create the web page in JavaScript. I am not sure that this will be good way to go, but I do understand why the business wants to explore the idea.

Re:Javascript as assembly (1)

TD-Linux (1295697) | more than 2 years ago | (#37231098)

I think you missed what the parent was talking about. He didn't mean implementing more things in Javascript, he meant allowing developers to use non-Javascript languages to generate Javascript. It's so people don't have to use Javascript or learn it, not the other way around.

What you mention, the pattern of generating pages using AJAX, is still fairly new. I use it a lot for data that is updated in real time, and some websites are using it for static data as well. I very much like it for cleanly separating the presentation from the backend server side code, even though some NoScript using purists hate it.

Re:Javascript as assembly (1)

aztracker1 (702135) | more than 2 years ago | (#37231166)

I think you have thisbackwards... This is another language that generates JS, rather than JS being leveraged more... For that, Node + Mongo are a great pair of options.

Re:Javascript as assembly (1)

icebraining (1313345) | more than 2 years ago | (#37230980)

It depends on how cleanly it maps to Javascript's concepts. I don't really see almost anything in the core Opa language [opalang.org] that doesn't map reasonably well to JS. It shouldn't be particularly slower than JS by itself.

Re:Javascript as assembly (1)

qxcv (2422318) | more than 2 years ago | (#37231170)

I'm more scared of libraries that try and force class-based OO into Javascript, but the mere existence of such libraries does show that people have a LOT of trouble efficiently getting around OO problems in Javascript. I don't mind Coffescript, etc because they make Javascript what it should have/could have been. There are so many neat little things that could make Javascript less tiresome, but almost none of them have been pushed out into the real world yet. Think array comprehensions, getElementsBySelector (if we had this a decade ago it could have saved insane amounts of money and bandwidth), default arguments (Javascript arguments are HORRIBLE), a less braindead DOM model, etc.
 
Opa OTOH is a different kettle of fish. In 98% of cases tying your frontend to your backend is a Bad Thing (tm). There is a very real difference between the client and the server, and I'm not sure what transparent environments are trying to achieve by ignoring it.

Re:Javascript as assembly (1)

Anonymous Coward | more than 2 years ago | (#37231366)

What you essentially want is Lua embedded in web browsers.

Obligatory (0)

Anonymous Coward | more than 2 years ago | (#37230922)

http://imgs.xkcd.com/comics/standards.png

Re:Obligatory (1)

deniable (76198) | more than 2 years ago | (#37232068)

And now we have one more competing post pointing to that XKCD strip.

Hierarchical database??? (0)

Anonymous Coward | more than 2 years ago | (#37230948)

They lost me at "A hierarchical database and web server are integrated with the language." Hierarchical? Really? I thought, outside of LDAP, that hierarchical databases had already suffered a much deserved death.

Re:Hierarchical database??? (1)

Tablizer (95088) | more than 2 years ago | (#37231888)

Every 5 years it gets reinvented with a new name

Why a new language and not an existing one? (0)

Anonymous Coward | more than 2 years ago | (#37230964)

Compiling an existing language into JS cuts down the learning curve and makes more tools available. For example Java to JS using GWT

Documentation = Weird (1)

platypusfriend (1956218) | more than 2 years ago | (#37230986)

Reading the documentation and how-to's on the Opa website reminds me of talking to the Orz in Star Control II / Ur-Quan Masters.

Integrating everything into one thing? (2)

lattyware (934246) | more than 2 years ago | (#37231026)

Integrating everything into one thing seems like a poor idea. Sure, it makes it a little easier for the dev, but in the end, you are just learning 5 times the amount of Opa when you could learn each thing. Not only that, but can one thing really do all those tasks the other things do, and do it as well? Even if it can, it's harder to keep all of those on a level, you can't replace those parts if you find something better. It just seems to me that splitting things down into the parts seems like something we should be doing, not reversing. I also really don't like the whole compiling to JavaScript behaviour. Maybe just because I don't like JavaScript.

Re:Integrating everything into one thing? (1)

MeddlesomeKids (537431) | more than 2 years ago | (#37231752)

>> Sure, it makes it a little easier for the dev, but in the end, you are just learning 5 times the amount of Opa when you could learn each thing.

I see it the other way round. When you are dealing with all the languages and formats we have now there is a huge amount of wasted duplication. Look at how you concatenate strings in Javascript versus PHP. Or calculate a random number. Or iterate an array. obj->method() or obj.method() or obj->val or obj.val ? How about encode a non-ascii character in a URI, or in XML, or in HTML? Which characters are reserved in HTML or XML or JSON or a URI or SQL or a regular expression? How do you walk a DOM in Javascript versus PHP (versus Ruby/JSP/NET/etc.) ? Frankly, I have better things to do with my limited time on this planet that memorize all these little conventions over and over again slightly differently each time.

If I can learn and use Opa and not have to meddle with the others, then it's a win. But if I have to use Opa to perform string concatenation to construct javascript or SQL. then it's a loss. I can live with having to concatenate HTML and CSS (but I'd rather not).

Re:Integrating everything into one thing? (3, Interesting)

Seferino (837142) | more than 2 years ago | (#37232294)

Integrating everything into one thing seems like a poor idea. Sure, it makes it a little easier for the dev, but in the end, you are just learning 5 times the amount of Opa when you could learn each thing.

Well, that's not quite true. Having the same language for database manipulation and for in-memory manipulation is a huge time-saver. Having the same language (indeed, the same piece of code) for server-side validation and for client-side validation is more efficient and less bug-prone. And you have only learnt one thing.

Not only that, but can one thing really do all those tasks the other things do, and do it as well? Even if it can, it's harder to keep all of those on a level, you can't replace those parts if you find something better. It just seems to me that splitting things down into the parts seems like something we should be doing, not reversing.

Ok, on this, you may have a point.

I also really don't like the whole compiling to JavaScript behaviour. Maybe just because I don't like JavaScript.

Well, that's part of the point: with Opa, you do not need to write any JavaScript.

Caveat I'm part of the Opa team. Well, worse than that, I'm the architect-in-chief.

So here's some example code (3, Informative)

moonbender (547943) | more than 2 years ago | (#37231036)

No idea whether it's viable long-term, but I thought it's really interesting. It does way more than GWT does, for example. It's also statically typed, yay.

Here's some example code from the tutorial [opalang.org] . This is a chat room [opalang.org] . Apart from CSS, this is the entire soure code required to create the chat room server. Yikes. Had to get rid of the comments to appease the spam filter, unfortunately.

type message = {author: string /**The name of the author (arbitrary string)*/
              ; text: string /**Content entered by the user*/}
 
@publish room = Network.cloud("room"): Network.network(message)
 
user_update(x: message) =
  line = <div class="line">
            <div class="user">{x.author}:</div>
            <div class="message">{x.text}</div>
        </div>
  do Dom.transform([#conversation +<- line ])
  Dom.scroll_to_bottom(#conversation)
 
broadcast(author) =
  do Network.broadcast({~author text=Dom.get_value(#entry)}, room)
  Dom.clear_value(#entry)
 
start() =
  author = Random.string(8)
  <div id=#header><div id=#logo></div></div>
  <div id=#conversation onready={_ -> Network.add_callback(user_update, room)}></div>
  <div id=#footer>
        <input id=#entry onnewline={_ -> broadcast(author)}/>
        <div class="button" onclick={_ -> broadcast(author)}>Post</div>
  </div>
 
/* Main entry point. */
server = Server.one_page_bundle("Chat",
      [@static_resource_directory("resources")],
      ["resources/css.css"], start)

Working at such a high level (0)

Anonymous Coward | more than 2 years ago | (#37231054)

IMHO, anything that works at such a high level is going to have problems. For example, quoting their doc page, "As for deciding which html version to use, Opa handles this behind-the-scenes".

Now what happens when browser X handles HTML 5 just fine, but browser Y doesn't?

It still works fine if the "behind the scenes" thingy has a fantastic knowledge base of all the browser variations. That's a big "if".

Aside from that, looking at their examples it reminds of MFC, where it was really easy to roll applications if you wanted to do it their way. As soon as you got an idea that didn't conform to what they had in mind, you were in a world of hurt.

Finally, I think web services are fine as a library in a langauge, but integrated at the language level? OK fine, but you can't call it a general purpose language anymore. Then it becomes a DSL. I'd rather have a general pupose language with a well documented API into a library that handles the doman than a DSL.

Re:Working at such a high level (1)

aztracker1 (702135) | more than 2 years ago | (#37231184)

The biggest issue here is integrating with a legacy system... I can't see this as anything but painful...

In argentinian spanish... (1)

buanzo (542591) | more than 2 years ago | (#37231176)

.... opa means 'idiot'. Yes, offtopic. Now onto some ontopic stuff: It definitely sounds good for security at least. I'm giving it a try.

Standards (0)

Anonymous Coward | more than 2 years ago | (#37231278)

http://xkcd.com/927/

Wt (3, Interesting)

paugq (443696) | more than 2 years ago | (#37231288)

Why is a new programming language required to "make web development transparent"?

Opa automatically generates client-side Javascript and handles communication and session control. The ultimate goal of this project is to allow writing distributed web applications using a single programming language to code application logics, database queries and user interfaces

Wt [webtoolkit.eu] does exactly the same but in C++. You develop webapps like desktop apps: widgets, ORM, etc. No need to care about Javascript, HTML, etc. Compilers available on all platforms. The result is a single binary which includes an embedded HTTP(S) server.

While I agree with what Opa wants to achieve, inventing a new programming language for that end is unnecessary and, in fact, will become a burden: they will need to maintain both the language and the library. But actually the value lies in the library, which is the one that needs to deal with HTTP, Javascript, AJAX, etc

Re:Wt (1)

MeddlesomeKids (537431) | more than 2 years ago | (#37231708)

Wt is cool, but compare the listings for the Wt chat application versus that of Opa. How many orders of magnitude are there between the lengths of the two listings? 1? 2? The Opa listing would fit on a t-shirt. So I think that is at least a partial answer to your question of "why a new programming language required". Personally, I also find that most new language announcements are unnecessary. There are already many great languages available, could not a tool or library accomplish the same thing? However, in this particular space I'm less opposed to the introduction of a new language. The whole web app thing is already a rotten stinking soup of languages, protocols and formats (SQL, PHP/JSP/NET/Ruby/Python, HTML, CSS, XML, Javascript etc etc etc) and I am very sympathetic to any one-language-to-rule-them-all solution. If I can worry about one instead of legion I'll be better off. However, though I have not yet used Opa or Wt yet, looking through their example code listings I see HTML strings being constructed in the Opa listing, and Javascript code being concatenated in Wt. And for both CSS files seem to also be BYO. That isn't necessarily unreasonable, but you can see the slope we are on. So now I'm using Opa/Wt to write HTML (or Javascript) and I have to provide the CSS myself. Am I really ahead of the curve, or wearing mittens? How is this different than (gulp) PHP? What about the database? Does my Opa/Wt code need to construct SQL query strings? If I, or my designer, wants to add some new jQuery plugin that will be announced tomorrow, how is that approached? I've been fairly impressed with Opa from what I've read on its site. I'm hoping to get some time to actually play with it and maybe get to the bottom of some of these questions.

Re:Wt (1)

Lord_Naikon (1837226) | more than 2 years ago | (#37231840)

Thank you for that link, Wt seems really useful.

I don't know about this. (0)

Anonymous Coward | more than 2 years ago | (#37231334)

It sounds like a mechanic throwing out his toolbox in favor of a Swiss army knife.

i don't get it (0)

Anonymous Coward | more than 2 years ago | (#37231734)

i get this, we are going to a lot of folks try and improve the client/server side programming of distributed web application -- and that's a good thing -- but this one will need to significantly evolve to be a game-changer

Epic fail (1)

pongo000 (97357) | more than 2 years ago | (#37231902)

Opa automatically generates client-side JavaScript

Just what we need, more sites spewing out poorly-designed client-side script badly rendered by any number of JS browser implementations. Like many others, I do everything possible to block JS...why does anyone think the future lies in more client-side code?

Are you sure? (1)

xyourfacekillerx (939258) | more than 2 years ago | (#37232002)

Just what we need, more sites spewing out poorly-designed client-side script badly rendered by any number of JS browser implementations. Like many others, I do everything possible to block JS...why does anyone think the future lies in more client-side code?

While I agree that client-side code is not the proper direction for web focus (it amounts to circumventing doc structure standards with a scripting standard to do things neither standard planned for, the habit of doing this is REALLY why we have "Web Development Language/System of the Day") ... I don't know how Opa determines its JS output, and though my glance through the documentation turned up nothing, I imagine its claim to being transparent means there might be some control to what quality of JS is output.

While I am currently merrily digging into its grammar and the more technical details of the language itself, I don't really want to mess around with this language platform, though, because its "integration" of database, server, and client side means a nightmare for development when you traditionally have database team, design team, server-side team, etc. this puts all the eggs into one basket, how do you manage that? This sounds like it'd requiere a whole change in the development methodologies and programming practices, or would only be adopted by cowboy programmers working for small outfits. Our brains can only hold so much information, and getting familiar to this "language" would displace more practical knowledge. Where are the white papers, case studies, best practices, cost analysis, migration analysis... ? The things that would motivate the business minded to adopt, you know?

A new programming language (0)

Anonymous Coward | more than 2 years ago | (#37232004)

"... a new programming language ..."

Oh for chrissakes. Kill it with fire now.

Dear Creators of Opa... (3, Insightful)

drgroove (631550) | more than 2 years ago | (#37232110)

Dear Creators of Opa - Honestly, what were you thinking? Opa is basically another crack at the same approach that ColdFusion tried years ago, and failed at. Opa isn't Object Oriented, meaning that developers working in an OOP language (Java, .NET, Python, PHP, Ruby, Perl, etc) will have a tougher time making the transition - it also means that Opa can't implement or support standard Design Patterns, which is a huge mistake IMnsHO. The sample code on the Opa site shows a mix of Opa functions, database interaction, markup language, CSS, Javascript... what a mess. Haven't we all learned that clean separation of functional application concerns is the only way to write scalable, enterprise-class programs yet? Opa doesn't appear to support any database beyond it's own build-in, slightly obfuscated one, meaning it will gain no enterprise/business traction. As much as I like to see new programming languages succeed, I have to agree w/ a lot of the other posters on /. - Opa is dead on arrival.

Nice Idea, but... (1)

davesque (1911272) | more than 2 years ago | (#37232296)

I like the idea behind this: that web programming should become less like the herculean task of juggling several syntactically different languages. But why did they need to use that word "transparent"?? This is one of those silly buzz words that means very little (like cloud this and that) and smacks of sales talk.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>