The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Why aren't you using advanced programming languages?

Most of the users on this bulletin board write languages in language like C#, C++, or Java. I bet no one here writes code for pay in Haskell, Lisp, Scala, Clean, OCaml, or any of the other experimental programming languages you can find out there.

I wonder: are there any sufficient conditions under which someone mostly familiar with imperative languages would be willing to use unpopular languages in a project?

What if the following held:

- Good brevity and productivity; advanced features that led to fewer bugs and happier programmers.
- Tractable learning curve: you could initially use the language very much like one you were already familiar with and gradually adopt functional programming idioms at your own pace.
- Seamless integration with target platform. No FFI code, no shenanigans; effortless use of any Java/.Net/whatever library, thereby sidestepping the problem of lack of libraries in new advanced languages. In fact you could even extend classes written in the new language in your old one.
- Integration with popular IDEs and toolchains. You could still use the build tools, IDEs/editors, etc. that you use now (e.g., for Java, you could use it seamlessly with Maven/Ant, Eclipse, JUnit, etc etc).
- Deployability. Suppose the language could work with the target platform easily; either native code with a small portable runtime or the bytecodes of Java/.Net; in the case of Java, say, you could deploy it as a WAR with all the stuff for the language included so you could use it on a server that didn't have the language installed.

Suppose all the usual objections to functional programming were taken care of, and all that really remained was fear of the unknown and/or unwillingness to learn new things. (I think one of the languages I mentioned in the beginning meets the above criteria and more, but that's not so relevant to the discussion). Basically what I want to get at is the root causes for why developers don't want to use advanced programming languages, even in greenfield projects, and even languages that only take a week or so to learn well.
Warren Send private email
Wednesday, January 31, 2007
 
 
Err, that should be "code in languages like".
Warren Send private email
Wednesday, January 31, 2007
 
 
I think the premise of your question answers it:

* even in greenfield projects

>99% of projects are not greenfield projects.  Greenfield projects are exceedingly rare at big companies; you're more likely to find them at startups, which fewer people work at.

* languages that only take a week or so to learn well

Most programmers can't learn a language in a week.  Most programmers still don't understand how C pointer syntax works, even those who program in C full time.

* You equate "advanced" and presumably "good" with "functional".

I am personally a fan of functional programming.  I program in Python full time and while it's not a functional language, it has more support for a functional style than any language that's more popular than it (C, C++, Java, C#, VB, etc.)

But this is a totally flawed presumption.  The best programmers I know are not functional programming advocates, unfortunately.

I think the winds are blowing and functional programming will have its heyday, with increasingly complex and parallel programs, but it's not there yet.  If you have this attitude that functional programming is the most advanced, I don't think you're going to convince a lot of people to try whatever it is you want to them try.

But the rest of the things you list are definitely obstacles as well.  I think there are more than you think though.
Moosebumps Send private email
Wednesday, January 31, 2007
 
 
"...any of the other experimental programming languages..."

Nobody should code for pay in "experimental" languages.  The thing is, if the features are good they included in the mainstream languages.  The reason C/C++ have been around for so long is backwards compatibility -- you just can't toss away everything that came before.  Java looks like C++ for similar reasons.

C++ isn't just object-oriented, it's multi-paradigm.  It has meta-programming, functional elements, etc.  C# is adding more functional stuff all the time.

It's for that reason that experimental languages remain experimental.  If those languages had all the conditions that made people use them, they'd be a lot more like the languages we already use.
Almost H. Anonymous Send private email
Wednesday, January 31, 2007
 
 
You see, right now I am trying to solve a puzzle. My code works most of the time. For the session management, I have three options: file, memory and database. The database is my "production" setup, because it can handle thousands to millions of session ids. Before I got to the session management issue, I resolved a similar issue in another library, which would cause exceptions in the database access during concurrent connections. But now I am stuck with the same problem in my session management, and the past four hours or so have been spent on this issue already.

My point? Just at times like this I wish I could use another language like Erlang, because it seems to be more suitable to this than a combination of "native thread, green thread, C and Ruby" that I use. :-) But guess what? I think any language has its own trade-offs, though. The good news is that once the abstractions are in place, even aberrations of programs/languages don't look so bad. That is, the infrastructure being in place, one can focus on high level requirements. Maybe more folks don't use the unpopular languages because they still lack in infrastructure. BTW, to create the infrastructure seems to be a very brute-force process, which can take several years, hence the popularity helps in the adoption languages, and the familiarity of the languages can only help their popularity. For instance, all the struggle of Microsoft in creating the VB.NET port has paid off somewhat, even though it's largely similar to what C# can do. Myself, I dislike the VB.NET syntax, because it's very unfamiliar to me.
Lostacular
Wednesday, January 31, 2007
 
 
Well I used to mess with Smalltalk, but you know what, you can not write a modern desktop application in Smalltalk. some goes for lisp etc. The things you mention just aren't present, getting it working is too hard, etc. C++ works and is fast and there are libraries.

That said, Objective C is pretty awesome and is a true object oriented language. Lots of people are writing very productively in it, it's got smalltalk like messaging, it's cool and fun, it's as fast as C, it links with C libraries, it and it's way way cooler than C#, Lisp, Haskel, Python and all the rest of the elitist languages.

Unfortunately, Objective C is practical. Because of this, the language elitists stay far away from it.
Scott
Wednesday, January 31, 2007
 
 
Oh and while I'm ranting, I'll say that after I saw it mentioned on this board, I started working with D a bit and it's pretty nice is well. It belongs to the family of object code compatible post-C languages.

I've also messed with Lua a bit and it's quite good at being a low-overhead embedded scripting language.
Scott
Wednesday, January 31, 2007
 
 
And Haskell and Lisp both SUCK.

So there.
Scott
Wednesday, January 31, 2007
 
 
How do you process Windows messages in Lisp? How do you create, let alone clear a new Window using Haskell, and blit a few bitmaps and put up some buttons?

Oh wait, you can't? Well that explains why nobody uses it.
John
Wednesday, January 31, 2007
 
 
One of the coolest things I ever heard of is how Ritchie and Kerighan wanted to play this lunar lander game, so they invented the C language and the Unix operating system specifically for the purpose of being able to portably write this game for different machines.

After that, I was most impressed by this story from last year:

"Joel, functional programming languages are so cool. Check out these closures!"

"Closures are nifty."

"Joel, let's write FogBugz in Haskell! Wouldn't that be cool!"

"Mmm, I don't think I want someone translating the codebase to Haskell from VBScript. But I see your point about cool languages. Let's compromise. Why don't you redesign the VBScript language to be functional and support closures and write a compiler for that?"

"That's cool! I'll get on it right away!"

(one month passes)

"Hurray! It works!"

"Joel, is it true you guys invented your own function programming language based on VBScript? How is that even possible?"

"It's easy, man. I just give 6 weeks vacation and a gym membership and we had these union guys come in and put in these 45 degree angle walls and paint them a hip shade of  wasabi green. Ever since then, the top talent in the world has been coming here and working for standard wages just because we don't treat them like slaves and everyone else does. So yeah, I got guys working here that can just go off and create some new language only for shits and giggles and bragging rights, and we can be using that language in production the next day."

"What are you going to call this new language?"

"Ah," (looks around) "... I guess we'll call it Wasabi."

People have slammed these guys for doing this, but hey, they are writing production code in a functional language. Ha ha language bigots! Ha ha!
Scott
Thursday, February 01, 2007
 
 
Yahoooo! :-)

I just found a solution to my problem: I used a mutex which in Ruby is rather easy:

      def setup
        @semaphore = Mutex.new
        request_db{|db|
          @clean_sql = %Q|delete from #{db.prefix}session where sess_expiration_time < ?|
          @delete_sql = %Q|delete from #{db.prefix}session where sess_session_id = ?|
          @exist_sql = %Q|select sess_id from #{db.prefix}session where sess_session_id = ?|
          @select_sql = %Q|select sess_session_data, sess_expiration_time from #{db.prefix}session where sess_session_id = ?|
        }
      end

      def request_db &b
        @semaphore.synchronize{
          db = DBModel::Model.new(@conf[:db])
          begin
            b[db]
            db.commit
          ensure
            db.e :pool_return
          end
        }
      end


I found a deadlock when I used this mutex as well. This is an easy solution, because I just tested it with these parameters:

Concurrency Level:      100
Time taken for tests:  46.457444 seconds
Complete requests:      1000
Failed requests:        0
Write errors:          0
Total transferred:      546000 bytes
HTML transferred:      324000 bytes
Requests per second:    21.53 [#/sec] (mean)

Not bad at all. Hopefully this was it! Now I can retire on this. hehe
Lostacular
Thursday, February 01, 2007
 
 
I've been learning Ruby the last few weeks so I can add Ruby language support to my IDE product for the next release. I have to say it is a very interesting language and is way more OO than the C++ world I live in. I'd love to find some time to write a Ruby (web) app, but that isn't going to happen any time soon. And for Desktop apps Ruby isn't well suited, especially as there isn't a compiler yet. But that is changing, so I'll definitely be keeping an eye on Ruby.
Neville Franks Send private email
Thursday, February 01, 2007
 
 
John,

Franz and LispWorks have been in business for decades.  There are extremely high quality commercial implementations available for Common Lisp.  (And yes, they let you create desktop applications).

Here is some output from a common lisp application (not mine though):  http://www.izware.com
I program in Common Lisp full-time.
Thursday, February 01, 2007
 
 
I was the first employee on my current company and my boss asked me: Can you do web apps? Since at the time I knew PHP, I said yes. Six months later we decide to hire someone else, so he should also know PHP and we can have a single codebase / knowledge sharing. Add a couple employees here and there and we're a PHP shop now.

Switching is too expensive. I code the company products in PHP because I've coded them in PHP. Perhaps I've started wrong :p My preferred language is Python, the servers scripts and small things scattered all around are made in Python. But there's 5 years of written code in a language that we can't just throw away.

Why don't I go work somewhere else where I can use Python? Well, the programming language we use is really a minor thing in the grand scheme of things. Yesterday we were without net access so my boss got some cards and we spent the afternoon playing. He takes us every couple month to fancy restaurants. I get to work late today, just like yesterday. I have the office door keys and the security system password and secret word. We make a lot of money already. I go to meeting with clients. I make the sales pitch, I can call some of our clients right now and ask how their weekend was. I am surfing Reddit, went to JoS forums, read your message, now I am spending 15 minutes on the new message form.

There are far more important things than what programming language I use. Typing is really a small part of the whole thing anyway, >90% of the time is spent with other things. Thinking, talking, making specs, designing.

Yeah, all these cool things are independent of PHP. I could have started with Lisp five years ago. Web apps can be done in any language anyway. The monstrous sites are done in C-C++/Java/Python/.NET/PHP/Own scripting language. As long as you don't choose Cobol you're fine :p
Julio Nobrega
Thursday, February 01, 2007
 
 
I am. We are writing increasingly large portions of our production code in Lua. I find it painful whenever I have to do some application-level programming (usually in the form of maintaining old code) in C++: how did I ever live without closures, coroutines, multiple return values, and most important of all, the ability to modify and inspect the state of the system while it's running?
Assen
Thursday, February 01, 2007
 
 
> I've been learning Ruby the last few weeks so I can add
> Ruby language support to my IDE product for the next
> release

Why would an IDE need Ruby support?
wha
Thursday, February 01, 2007
 
 
I'm sorry, but I can never understand how someone can even seriously ask a question like this.

For most of us, writing software is about creating products that fill a need and can be sold for a profit. It's not about what's the coolest or sexiest programming language.

Go and ask a carpenter why he doesn't use the latest titanium, laser guided hammer when the old one works just fine.
Bruce Rennie
Thursday, February 01, 2007
 
 
No, the question is more like asking him why isn't he using an electric drill, but still insists using his old manual drill.
Assen
Thursday, February 01, 2007
 
 
"No, the question is more like asking him why isn't he using an electric drill, but still insists using his old manual drill."

When I was in china about 4 years ago, all the carpenters were still using manual drills and saws. Even the ones working on the high rise apartments in Beijing were using manual tools.

The consequence is it takes far more people to build the same structures than in the US and the workmanship looks crappier too. Except for old stone buildings and structures, almost everything in China has a cheap, shoddy feel to it.

And yes, the situation does strike me as similar to software shops who find the upfront expense and learning curve of new tools unacceptably high. They continue clinging to old fashioned ways of doing things, while the better shops look to use increasingly advanced tools and techniques.
ronk!
Thursday, February 01, 2007
 
 
I think this mostly comes from them not applying to the problem.  Several of the "not so cool" languages are specifically focused on producing Windows Forms or web applications.  In most cases, those languages have frameworks written for the production of those specific types of programs.  In some cases, those languages have extensive IDE support for the production of those types of programs. 

I doubt that you can build a web application as fast in Haskell or OCaml as you can in Python (Django, Turbogears) or Ruby (Rails).  Since people are interested in making money, the faster they can produce the code they are going to sell (or rent!) the more money they can make.  Even if you could build a web application in Haskell, OCaml or Lisp as fast as in Python or Ruby, when you business grows, it will be much harder to find people who program in those languages, and they will probably cost more to employ.  Why would a sane business person choose to write their application in one of the functional languages right now?  What benefits does it give the business?
Joshua Volz Send private email
Thursday, February 01, 2007
 
 
+1 for Bruce Rennie. If more programmers spent as much time understanding their business domain as they spend fantasizing about the latest language fad, we might not have so many software atrocities. I really think you'd have a hard time making a case that Haskell is to Java (for example) as an electric drill is to a hand drill.

By the way, I went to a talk about China a while ago and I noticed how all the buildings looked like the inside of public washrooms, eg. covered in crappy looking tile.
Greg Send private email
Thursday, February 01, 2007
 
 
To answer the original question: Because many people don't like functional programming.  Deal with it! ;-) Your argument is based on the assumption that the above languages are inherently superior to the languages currently in use.

Five years ago python would have been an advanced language that would be considered risky, and probably even a year ago ruby would have been.  I can't remember exactly when the Rails hype kicked in.  But the hackers and early adopters just used them anyway, and created enough stuff for those languages to gain critical mass.  For whatever reason that hasn't really happened with functional languages, even if it theoretically should have due to their alleged superiority.  To repeat, even the early adopters and hackers aren't picking those languages, even though they could if they wanted to.  Even the Elvis' are discarding Haskell, not just the Morts.

That being said, I've been using OCaml at home, and it seems to be hitting the sweet spot with 60-70% the flexibility of python and 80-90% the speed of C.  I'll probably find an excuse to use either that or F# on something at work this year.
Grant Send private email
Thursday, February 01, 2007
 
 
For desktop apps, especially, the "advanced" programming languages don't have available and polished sets of components and frameworks.  The idea of using an "advanced" language and writing everything you need from scratch is ludicrous.

I will say that it seems to me like .NET (and maybe Java) may be an opportunity for "advanced" languages to gain market acceptance.  I'm thinking of IronPython and Eiffel.  I expect IronPython may gain traction as it matures.  The .NET version of Eiffel could also if it were marketed better and weren't priced too high.  The ability of .NET languages to seamlessly use components and libraries written in other .NET could give "advanced" languages a foothold to grow from.
Herbert Sitz Send private email
Thursday, February 01, 2007
 
 
I find functional programming to be fascinating, and I definitely think that everyone should learn it and at least play with it a little bit for its educational value.  It will make you a better programmer regardless of what language you end up writing production code in.

That being said, I have this sneaking suspicion that functional programming is like RISC: an idea that looks great on paper but isn't really catching on in the marketplace for reasons that we don't quite understand yet.  We're starting to understand why RISC (I mean real RISC, not CISCish RISC) didn't really go mainstream.  Most CPUs are memory starved and RISC is no better and frequently worse when it comes to code bloat and memory traffic.  Secondly, pipelines and advanced instruction decoders made CISC perform as well or better in the CPU as RISC.

There just has to be some reason it's not catching on.  I don't buy the inertia thing... if this were true Ruby would never have caught on.  If a language really is great, hackers will gradually pick it up and start using it and it'll get its big break (e.g. Rails).  Where is Haskell's killer app?  OCaml?  LISP?

I suspect that the future will look like this:

- For systems programming, we'll continue to use C and C++.

- For application and webapp programming, we'll use languages like Python and Ruby.  These languages have closures and other features that give us some of the power of functional programming while still having moderate learning curves and dealing with all the edge cases (e.g. messy I/O, interfacing with legacy code) that FP has trouble with.
Adam Ierymenko Send private email
Thursday, February 01, 2007
 
 
Back to the original question.

I suppose because changing languages is like switching to new hardware, you need a 10x improvement to go to the bother.  If a new grammar buys you just a little bit, or if the value is hard to quantify, why take the chance?

It's sort of like why cubicles exist.  You can argue that people might get more work done in an office w/doors, but it's pretty hard to set a value to it.  On the other hand, you can prove how much cheaper and more malleable a cube sea can be.
old.fart Send private email
Thursday, February 01, 2007
 
 
Why would I bet my business on something that is not proven, may not be supported, may not be around in 2 years (and if it is may not be compatible with my existing code base), and is known by only a small percentage of the developer community? The business world likes to mitigate risk as much as possible and everything in my first sentence is a risk. The cutting edge may be fun to play on but it can also be a dangerous place to be. The bleeding edge... well.... you get the point.
A. Nonymous
Thursday, February 01, 2007
 
 
No one? Does Ruby count as advanced? If not, I use some Ocaml and emacs lisp (hey, it's a lisp). But not as much as I'd like. The library support for Ocaml sucks.

OT: RISC is far better than CISC, and it's not even close. For a given cost (including design cost and process development costs), RISC processors far outperform CISC processors.

The reason x86 is killing everything else is beacuse the giant legacy user base allows Intel to amortize its design and process development costs over more sales, which lets them devote far more manpower than anyone else can. Even now, Itanium* kills x86 in FP performance despite burning less die area on logic in an equivalent process, using smaller design teams, and not being on Intel's bleeding edge process technology all the time.

Maybe this isn't so OT after all, if you think of process technology as tools/libraries.

*to be pedantic, it's VLIW, but it has easy to decode instructions that are fixed length (modulo bundling) and simple addressing modes, like all RISC processors.
28/w
Thursday, February 01, 2007
 
 
"why developers don't want to use advanced programming languages..."

In my case, because no-one will pay me to do it. My wants have nothing to do with it.
Mike S Send private email
Thursday, February 01, 2007
 
 
Windows, the internal combustion engine, and Java have a lot in common: they're all ubiquitous, all somewhat unpleasant to use, and all do the job well enough that it's difficult to persuade people to invest in alternatives.

Maybe in an ideal world we'd all use Macs, drive electric cars, and program in Haskell or Ruby, but here and now we have to accept that it usually _doesn't_ make sense to look too far ahead; potential efficiency savings five years down the line, when all the programmers are trained, will not be much good if the company has gone bust in the meantime!
Iago
Thursday, February 01, 2007
 
 
It's damn hard to write useful applications in any of those experimental languages (except, of course, for Lisp, which is intimately tied to an uber-useful application: emacs). If you disagree, get back to us when you've written a simple text editor (full screen editing, search and replace, auto indent, etc.) in Haskell or ML.

While this may sound like a flippant reply, it really isn't: 1) the task of writting useful applications requires more than a capable language, it requires all sorts of libraries that the cool, experimental languages usually don't have (that's why they're still cool and experimental), and 2) the task of writting such an application in one of these languages serves as a kind of proof that the language is more than just an academic toy. Until a language has been used to write a substantial program in any given programming domain, it doesn't deserve to be taken seriously by most practitioners in that domain.

If you really think that other people should be using one or another of these cool, experimental languages for production coding then put your money where your mouth is: eat your own dogfood and try producing a real application in your favorite language-du-jour. Until you've done such a thing, you're just spouting hot air.
Jeff Dutky Send private email
Thursday, February 01, 2007
 
 
I wonder how many of the script kiddies that use these newer languages have any enterprise level development experience.

When I look at some of the new langages, one can see they are good for simple problems.  But when I see a language thats imbedded with <%@ and other such rubbish I think, excessive cognetive load and time wasting.
Andy Send private email
Thursday, February 01, 2007
 
 
>Go and ask a carpenter why he doesn't use the latest titanium, laser guided hammer when the old one works just fine.

He's very likely using a nail gun! And an electric screwdriver.
frustrated
Thursday, February 01, 2007
 
 
Jeff Dutky asks where the Haskell-based editors are. The answer is that they already exist. Yi is a text editor written in Haskell (with terminal and GUI interfaces), and hIDE is, well, an IDE written in Haskell.

So while your caution to eat one's own dogfood is appreciated, i would caution in return that you do some research before dismissing such things as cavalierly as you did.
John Melesky Send private email
Thursday, February 01, 2007
 
 
> When I look at some of the new langages, one can see they are good for simple problems.  But when I see a language thats imbedded with <%@ and other such rubbish I think, excessive cognetive load and time wasting.

Have you seen Erubis of Ruby? Check it out:
http://www.kuwata-lab.com/erubis/

It "compiles" the source to Ruby code, which is faster than the ERuby C interpreter, even. After the source is loaded one time, I cache it in memory for faster reuse. And I support both Ruby embedded in HTML with Erubis and pure Ruby files which are transformed into runtime code for faster reuse when cached.

Anyway, this part seems to be solved already in Ruby, and there are several alternatives, with some that generate the HTML for you, with some that support XML, etc. Pick your poison.
Lostacular
Thursday, February 01, 2007
 
 
To all people living in denial:

1) You can write GUI code in functional languages (Haskell, OCaml, Scheme, Common Lisp),

2) Ocaml, SML, some Schemes, some Lisp yield very fast numerical code/or code that you can compare to C.

3) Common Lisp has an object system that wacks the hell out of C++/Java

4) People write real apps in Smalltalk. The fact that you are a Java monkey does not mean the Smalltalk market doesn't exist.

5) You can write desktop apps in Smalltalk, as F-Script on Mac OS X proves. People actually run business with Squeak.

6) You can write a video game in Clean (a functional language.)

7) Erlang is here, baby. Telecomm uses it. eJabber uses it. Yaws is better than Apache.

8) People write somme heavy shit in Common Lisp. You would not believe it: military, telecomm, bioinformatics, financial, medical, etc. The fact that you do not qualify for such jobs shows how unqualified you are.

9) The industry deploys the languages _you_ know widely so they can pay _you_ lower wages, because you job does not demmand very specialized knowledge/talent. After all, you are all replaceable people.
Anti-Moron Send private email
Friday, February 02, 2007
 
 
To all the people saying "I would no run a business on something that's not proven, blah, blah, blah": please explain how Perl < 5 was not naive and stupid and experimental, or how _good_ PHP was when you picked it up, or how Ruby is not experimental, or how you can stand Guido Van Rossum's mood swings in Python?

The fact is, when you have to think different, you shit on your pants.

The languages some of you are dissing have - _all_ of them - a 20 years headstart in advanced topics.

One day, you will get around to them. Already, Microsoft Research has brought Ocaml to .Net (F#). You'll come around to the fact that you are primitives.
Anti-Moron Send private email
Friday, February 02, 2007
 
 
See how stupid you are: you revel in Ruby, when it isn't 30% of Smalltalk, does not even solve namespaces (PHP, too). Squeak does full multimedia (look up the Scratch programming language for kids - it's made with Squeak), yet you have no reservations about Ruby. You think Python is cool, but Python is very, very limited, and with badly implemented syntax (set is =). Perl 6 has come around to something modern, because Larry Wall has a learning brain (yet you think Perl is in decline and Python rulez). BTW, remeber that Perl 6 is implemented in Haskell? Oh, my, there goes my theory of the uselessness of functional languages. You sit and watch while C# gurus keep learning from the functional community and implement changes in it. Etc. All you do is wait. You have not even the skills to start a bad project like those scripting languages, yet you think you are so smart. The majority of you do not even qualify for compilers 101.
Anti-Moron Send private email
Friday, February 02, 2007
 
 
Wow, a lot of animosity and negativity here.

Quite a few responses were of the form "the libraries are bad/I can't do what I need to do" which I explicitly assumed to have been dealt with; when someone says "assume x" and you reply "but what if you assume not(x)?" it's kind of pointless. You can sidestep the library problem altogether by targeting a platform that has good libraries, anyway.

"Why take a risk on something that's not proven?" (asked in comically lousy English) If the language has been used on multiple 2+ million LOC projects over the course of the last 10-15 years the way Erlang has, for instance, what is there to prove?

I will not dignify with a response the ridiculous idea of not taking the notion of function seriously in computing.

It sounds like a lot of the people who responded use bad tools to write boring software and you're bitter about wasting your lives on things no one cares about. But, if masochism pays the bills, more power to you. May your days be filled with buffer overflows and XML situps.
Warren Send private email
Friday, February 02, 2007
 
 
Well, I don't think the grass is greener for you. Enjoy your 10 thousand functional languages, and enjoy using C# once it gets functional enough to you as well. :-) Not gonna happen? Oh, too bad.

Wake me up when you have rewritten everything that's in C and C++ that's important in your darling language. I really want to see how it all will end up, with those millions of lines of code reduce to several thousands of cryptic lines of code. :-) I want to see a Flash replacement as soon as possible. And a .NET replacement. And a JVM replacement. And a PostgreSQL replacement. And so on... I want to see how you are going to make all the functional languages talk together, in your functional "Web Services" or something. Ocaml that calls Erlang that calls Haskell that calls Factor that calls Cat... that runs from the dog. :-)
Lostacular
Friday, February 02, 2007
 
 
> Quite a few responses were of the form "the libraries are bad/I can't do what I need to do" which I explicitly assumed to have been dealt with; when someone says "assume x" and you reply "but what if you assume not(x)?" it's kind of pointless.

You: What if energy were free and there was no gravity? Would you visit the moon? Answer honestly because I am booking flights and you'll need to make a trip deposit soon.

Me: Um, energy isn't free and gravity exists. Currently travel to the moon is expensive and kind of pointless since there is not much on the moon worth visiting.

You: You stupid man! I say to assume no gravity! You not smart enough to travel to moon, stupid dumb dumb!
Scott
Friday, February 02, 2007
 
 
Never discuss politics or religion in polite company.

Friday, February 02, 2007
 
 
Hijack!!!

"We're starting to understand why RISC (I mean real RISC, not CISCish RISC) didn't really go mainstream.  Most CPUs are memory starved and RISC is no better and frequently worse when it comes to code bloat and memory traffic.  Secondly, pipelines and advanced instruction decoders made CISC perform as well or better in the CPU as RISC."

I'm not a chip designer, but will throw out a couple of opinions.

1) There were a couple of responses to memory traffic issues.  Big-ass caches, separate code and data paths, clock rates.
2) I sort of agree with your point on CISC and pipelines and decoders, but there were RISC parts with equally nasty (if not more so) front ends (PowerPC?...that is, the IBM versions).
3) Hey, they've got to do something with the extra space on the chip, it might as well be translating stuff.  Now that these multi-core things are starting to be available on x86, I hope that is where the effort and space goes.
4) RISC vs. CISC doesn't mean a heckuva lot.  There are RISC parts loaded up with 'multimedia' instruction sets, ones that are loaded up with oddities (ARM variants), etc. It (RISC) has tended to come to mean one size fits all instruction lengths.  Big deal.
4a) Heck, if you're a purist about it, I seem to remember AMD 29k parts with no multiply.

My take is more that the parts are all being optimized to suit programming languages.  Pipelines aren't exposed (I guess) so that assembly programmers didn't have to worry about sticking instructions into available slots or salting code with no-ops.  VLIW and vector stuff never happened because 'C"/Pascal/etc. is just a single stream of consciousness from the programmer.  Loads of features have been added to some CPUs to suit things like structures, subroutines, local variables, and the like (plus the needs of classic OSs). 

The whole world has become 'C' / Unix uber alles.  From a Martian's standpoint, there's zero difference between that and WinNT.  It's sort of sad, since my guess is that to have a radically new approach to software, you'll have to redesign the hardware to get acceptable performance.
old.fart Send private email
Friday, February 02, 2007
 
 
JavaScript is already an extremely popular functional language. You can use it for client side desktop apps (.NET/CLR) and server side web apps. The questions is whether or not programmers use and understand the advanced features (closures, monads, etc) and if not, why not?
rod Send private email
Friday, February 02, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz