Language:
switch to room list switch to menu My folders
Go to page: First ... 41 42 43 44 [45] 46 47 48 49 ... Last
[#] Thu Dec 17 2009 10:10:44 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Although I have no interest in Google bashing, I don't particularly see any value in this particular language either.

But, that's what happens on the Internet.  Research projects like Go end up getting sent out into the world whether they have any usefulness or not -- and then when journalists and bloggers see a big name like Google attached to it, they turn it into a big thing whether it was intended to be or not.



[#] Thu Dec 17 2009 14:26:49 EST from davew @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Wed Dec 16 2009 01:22:01 PM EST from fleeb @ Uncensored

If I've read it right, Google came up with a language named 'Go', but someone else has a language (that predates Google's Go) named 'Go!'.

Let the confusion continue.

Yeh, I had recolections of something like that and then you posted so I googled.

Seems google ignores the ! and just returns all the stuff for google go.

Only way I could get to anything about Go! was via a link on the Google Go page in Wikipedia

 



[#] Thu Dec 17 2009 23:07:18 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


OK, if I see the phrase "as an alternative..." one more time in the SpringSource documentation, I am going to scream. Have we learned nothing from Perl's mistakes?

[#] Fri Dec 18 2009 16:10:28 EST from Spell Binder @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I've heard a bit about "functional programming" lately, and the Haskell language, in particular, so I've been doing some reading lately, and Haskell has a really powerful, albeit uncommon, approach to programming.

I'm not sure I can see it as "the answer to everything," but it definitely does have a lot of features that make it ideal for lots of mathematical and data processing applications.

A number of the features also seem very similar to the "generic programming" techniques that fleeb has oft described in C++. I think he could really get into Haskell.
Haskell Binder

[#] Fri Dec 18 2009 16:54:03 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I haven't really wrapped my mind around the 'functional programming' technique yet.

[#] Fri Dec 18 2009 19:25:47 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


OK. Imagine if all your variables had to be declared CONST.

Then, every variable is essentially equivalent to the expression that computed it, and all variables are essentially the same thing as functions. the compiler can theoretic ally make smarter decisions about what order to do things, because functions aren't allowed to have side-effects, so as long as their inputs are available, they can be computed in any order.

It can also make your program's structure easier to analyze. Even when I'm workign in a non-purely-functional language, I do find myself taking steps to write in a more functional style if possible: whenever I find myself modifying a particular variable a number of times or in a loop, that's a hint that that section of code needs to be its own function, with side effects removed, if possible.

Haskell is purely functional, which apparently pleases the purists.

Scheme, LISP, and ML (and ML dialects such as OCaml and Microsoft F#) have more procedural features while still providing a rich set of tools to write in a functional style. Scheme probably has the richest set of these three, with its support for closures and first-class continuations.

But Scheme and LISP have that damn fully parenthesized syntax. Which has been hard for me to get my head wrapped around, in the limited time I've spent looking at it. For that reason alone, F# looks promising. It's nice that it's hosted on the .NET CLR, which provides decent support for functional programming languages, but does NOT yet support all of the requirements for Scheme. Scheme asks a lot of its runtime.

[#] Fri Dec 18 2009 19:28:18 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

A number of the features also seem very similar to the "generic
programming" techniques that fleeb has oft described in C++. I think

he could really get into Haskell.
Haskell Binder

take any loosely typed language that has support for closures, and you already have most of what you need to do generic programmming. (Well, you don't have strong typing. But languages based on type-inference are interesting in this regard.)

[#] Fri Dec 18 2009 19:35:26 EST from IO ERROR @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

On a totally different note: Ford, my nice Core i7 compiles all of Citadel in just under a second.

real 0m0.863s
user 0m3.116s
sys 0m0.888s

But configure still takes forever. Isn't there anything better than GNU autoconf yet?


[#] Sat Dec 19 2009 09:44:42 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

But configure still takes forever. Isn't there anything better than
GNU autoconf yet?

Yes, not using GNU autoconf.

Thats insane. Very cool machine there.


[#] Sat Dec 19 2009 09:49:33 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

As for functional programming (and what I remember of lisp, and that whole every variable is a function thing) that may be all well and good for the compiler, but who cares about the compiler, it only runs once
It's runtime performance that really matters and the language should at least somewhat be suited to your application implementation, because lets face it, deep down, it gets compiled to a binary, so what you want a language to do is match your application type.

I dunno what the rest of you do, but I've been writing server daemons and front end web applications mostly lately
I don't need a language that lets me easily do matrix multiplication if what I really want to do is listen on a socket.

Which makes me wonder about Go! or Go, whichever it is.

They're keen on compiler speed, I totally don't get that, that's intel's problem.
And easy to write serversoftware. Okay, cool, I can get into that, but if they have a function "bindlistenaccept()" what happens if I want to control the details of the listen, or the bind more tightly.
I've not looked at it, so I can't say, but berekely sockets implements just what you need to control what you need to.
Making it any simpler or more complex is either taking away functionality or making it unneccesarily cumbersome.

[#] Sat Dec 19 2009 12:23:46 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Have you given boost::asio a shot, Ford?



[#] Sat Dec 19 2009 17:44:46 EST from IO ERROR @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Sockets really should have been in the standard C++ library. That's such a glaring omission that's caused no end of trouble over the decades.

[#] Sat Dec 19 2009 19:17:04 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

It's runtime performance that really matters and the language should

at least somewhat be suited to your application implementation, because

lets face it, deep down, it gets compiled to a binary, so what you want

a language to do is match your application type.

Some would say that runtime performance doesn't matter so much as long as you're Turing-complete and you have the ability to write algorithms that scale properly -- and, perhaps, link to lower level native code when and where you need to. 10-20 years ago people were saying, "gee, once computers get faster, everyone will be running Lisp and Smalltalk." And they were wrong on both counts. Except that now, computers ARE faster, and people ARE running .NET and Java. Which aren't functional, but ARE quasi-interpreted and feature the same sort of VM underpinnings - dynamically modifiable environment, dynamically loadable and compilable code, and garbage collection - as lisp and smalltalk.

[#] Mon Dec 21 2009 16:49:34 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Have you given boost::asio a shot, Ford?

No. Mostly because I haven't really written much c++ lately. Since you often
speak of it so highly I was going to, but never had a need yet.

But then i think of roguewave and it seems to me, it can't be that different...

[#] Mon Dec 21 2009 16:50:32 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Some would say that runtime performance doesn't matter so much as long

as you're Turing-complete and you have the ability to write algorithms

that scale properly -- and, perhaps, link to lower level native code

Yea, well those people are acedemics and arein R&D and don't actually have to build robust real time systems. I find it very easy to discount what they say.

[#] Mon Dec 21 2009 16:50:52 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

computers ARE faster, and people ARE running .NET and Java. Which

Sad, isn't it.

[#] Mon Dec 21 2009 18:44:42 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Yea, well those people are acedemics and arein R&D and don't actually

have to build robust real time systems. I find it very easy to discount

what they say.

No, you don't build a real realtime system (in the strict sense of the term) in Java... or any other GC'd language. But for you're typical web app it's one of the best things going.

[#] Mon Dec 21 2009 18:45:03 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Sad, isn't it.

Now you're just being negative.

[#] Mon Dec 21 2009 19:37:30 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Now you're just being negative.

I'm being neutral, the world is negative.

[#] Mon Dec 21 2009 20:13:43 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Mon Dec 21 2009 16:49:34 EST from Ford II @ Uncensored
Have you given boost::asio a shot, Ford?

No. Mostly because I haven't really written much c++ lately. Since you often speak of it so highly I was going to, but never had a need yet.

But then i think of roguewave and it seems to me, it can't be that different...

Did RogueWave have network socket tools with asynchronous i/o?  I don't recall seeing that.



Go to page: First ... 41 42 43 44 [45] 46 47 48 49 ... Last