OCaml For the Masses 338
CowboyRobot writes "Yaron Minsky of Jane Street argues that the time has come for statically-typed functional languages like OCaml and Haskell. He cites many reasons and illustrates what he says is the most important, concision: 'The importance of concision is clear: other things being equal, shorter code is easier to read, easier to write, and easier to maintain.'"
haskell for the masses? sure, but only... (Score:5, Insightful)
Re: (Score:2, Interesting)
Yeah, every now and then I've known someone who firmly believed we should all be writing in Haskell and the like.
Mostly it seems like they're suggesting it because they're geeky people who like some of the features they claim the language has, and because this meets some level of mathematical elegance that resonates with them.
My recollection of functional programming from university was that it was kind cute, seemed to be geared to solving a problem domain I never found a use for, but that ultimately I hate
Re: (Score:2)
Functional languages ... Err code editors perhaps (emacs) ? Games (jak & daxter) ?
Re: (Score:3, Funny)
See, as an old school user of vi, emacs doesn't make the case for a functional language being useful.
In fact, quite the opposite. :-P
Re: (Score:3)
Lisp is used for just about everything possible. Compilers, editors, games, window systems, etc. Lisp isn't really in the same category as pure functional languages like Haskell. But pure functional languages have been used to do a whole lot of larger applications as well, editors, compilers, etc.
The big problem is that in a lot of programs you need more than just the pure functions; you need I/O and other side-effects. Functional languages have these but they often feel like odd bits tacked on that cor
Re: (Score:2, Offtopic)
See, a computer language without IO is generally something which doesn't do anything useful. If all they are is something which is elegant and pretty, it's hard not to write them off as something that academics crow over but which have no actual value.
Obviously, that's a gross overstatement, but usually I get the impression that people fawn over it because it's pretty and plays into
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
It's not a pure functional language, but most pragmatic FP languages aren't pure. OCaml is not pure, either.
I'll grant you that F#'s object model (taken wholesale from .NET) is less suitable for this type of language than OCaml's one, but aside from that, what are the irritating constraints?
Re: (Score:2)
Modern imperative languages are constantly adding elements from functional languages. For example, take C++ templates - template metaprogramming is a pure functional style of programming. C++ 1x has added lambdas. Also things like STL algorithms such as accumulate and for_each or boost::bind - are essentially functional programming. C++ 1x was to have concepts which was removed but will hopefully return in the next standard. C# has added async and await. So your "masses" cannot avoid functional programming
Re:haskell for the masses? sure, but only... (Score:4, Insightful)
You misunderstand thing. General purpose languages, such as the C or Algol family (which includes, among others Java, Python, and Ruby) do, indeed, include concepts from functional languages. But they don't RESTRICT you to those concepts. It's the insistence that everything be unchanging that is the weakness in the purely functional languages. The Scheme family is the only group of that to have any measurable use. (Note that Lisp is NOT a functional language, even though the concept originated via a subset of Lisp.)
There's much to be said for having the ability to have invariant elements in functions. There's very little in having the requirement that everything be that way. Note that many existing languages that have invariant strings ALSO have mutable strings. Java to name just the most popular example. So by all means allow functions to declare their values invariant. This allows lots of different kinds of optimization. But don't insist that all functions do so. And definitely don't insist that everything be invariant.
Re: (Score:2)
Re: (Score:2)
I've been programming Prolog quite a lot (a bit CLP too), but still don't get monads, so I just shrug off your snobbish nonsense.
Re: (Score:2, Insightful)
I've been programming Prolog quite a lot (a bit CLP too), but still don't get monads, so I just shrug off your snobbish nonsense.
Me either; I don't even think that the higher order concept like monads or arrows are even relevant to most programming. Also, I find actual maths easier to read than Haskell or lisp - it's not just a question of not 'getting' the language; it's not very gettable.
(I hope no-one from lambda-the-ultimate comes across this comment thread or they'll be irritated.)
Re: (Score:2)
(I hope no-one from lambda-the-ultimate comes across this comment thread or they'll be irritated.)
I'm sure they're already here... in numbers. ;)
Re: (Score:3)
Re: (Score:2)
I get monads. But Prolog? I never learned to do more than asking what color is the ball in the third hut? Can you actually make real programs with that?
Re: (Score:2)
Well, Prolog is like Lisp with syntax and backtracking, so if a problem is suitable for Lisp, then it's suitable for Prolog as well. So it's good for domain specific languages (and you get additional goodies custom operator precedence, custom prefix, postfix, infix operators etc.)
Also, all Prolog implementations come with a few Constraint Logic Programming libraries, so if you have logistics/scheduling problems it's pretty good for that too. Also CLP(R) libraries also feature various optimization algortihm
Re: (Score:2)
Also, I get how Lisp handles IO as a separate type that indicates that those operation is "dirty" and order matters, what I don't get what's inside the arrow operator, as it's syntactic sugar for a series of primitive operations. Honestly, I have spent a weekend figureing it out, and all I got was headache. I just don't like when there's too much magic happening behind the scenes. Also, Oz seemed much easier to understand, and I just thought I know enough exotic languages to warrant my geek card, so I just
Re: (Score:2)
"Also, I get how Haskell handles IO "
"get what's inside the arrow operator" or is it "DO" operator? I don't really remember.
Re: (Score:2)
It took me a while to grasp why monads use is so widespread in Haskell. But that's not primarily because of their inherent complexity (one understood, they're a rather simple Abstract Data Type) but because the uncountable monad tutorials make a terrible work at explaining their context, why they're useful for, and in which cases you should use them. These tutorials usually introduce monads with super-abstract metaphors and mathematical descriptions, that aren't useful for someone with a background in progr
Re: (Score:3)
So if it's simple in an imperative approach but difficult in a functional one- why the fuck are you using a functional one to begin with?
That's why no functional language has ever been successful. It's a beautiful model that just doesn't work. And no number of epicycles like monads will ever fix the problem that you're off on your base assumptions.
Re: (Score:2)
Re: (Score:2)
I guess you meant DCG (Definite Clause Grammar). ...
DCG is not a distinct conept in Prolog, just a syntactic sugar for
foo1(In1,Out1),foo2(Out1,Out2),foo3(Out2,Out3)
Re: (Score:2)
That definitely depends on what you're doing. Every time I've looked at a functional language I've bounced. Usually over random access read-write files. IIRC, even doing ordinary IO in Haskell (or possibly it was OCaML) required dropping into C. (Monads have no state, or some such.)
If I were to choose a functional language it would be one of the Scheme family...unless there's something that I really don't understand about Haskell or OCaML. But I have a hard time mapping Scheme variables into byte layou
Re: (Score:2)
"C, even doing ordinary IO in Haskell (or possibly it was OCaML) required dropping into C. (Monads have no state, or some such.)"
I'm not a Haskell programmer, but I'm sure you can do IO in Haskell, but the idea is that Haskell maintains information which function does IO and which doesn't, and does all kind of optimizations/rearranging/paralellization on non-IO functions. So if your function calls an IO function, your function becomes an IO function as well, so this property spreads to the caller.
Remember P
Re: (Score:2)
Do you have a reference for this? As far as I've ever heard, the idea was to use "function" for computations which return a value and "procedure" for computations which don't return a value (equivalent to void functions in C), and the distinction wasn't intended to have anything to do w
Re: (Score:2)
Now just imagine having a complex expression involving several function calls, where the functions have side effects ...
"No, functions and procedures were treated differently by Pascal compilers. Procedure calls, since they did not return a value, could not be used where a value was expected, and function calls, which did return a value, could only be used where a value (specifically, an rvalue) was expected."
That's just nitpicking.
Re: (Score:3)
I'm sorry to say that you're mistaken. Please read up some more on how and for what people use Haskell, before saying such things (without proof).
If I enter "Haskell" in Monsterboard, I get zero results. You probably refer to academic work, but where in the commercial world is Haskell used?
Re: (Score:3)
Yup, Haskell shops don't post job openings, they head hunt.
Re: (Score:3)
I'm sorry to say that you're mistaken. Please read up some more on how and for what people use Haskell, before saying such things (without proof).
Oh please no - that proof ... it doesn't have to be written in Haskell, does it?
They're not equal though... (Score:5, Insightful)
All other things are not equal though, are they? Procedural programming is easier for humans to understand: most of us do no not think in a way that maps easily to functional programming.
Re: (Score:3, Insightful)
Or most of us didn't learn to program in a functional language, so our brains are used to thinking imperatively. Or were you born understanding code?
Re:They're not equal though... (Score:4, Insightful)
Or most of us didn't learn to program in a functional language, so our brains are used to thinking imperatively. Or were you born understanding code?
Our brains think imperatively because life is imperative.
Imperative languages dominate computing because the real world is imperative.
Re:They're not equal though... (Score:4, Insightful)
god no, why do you asset that life is imperative?
Because each of us exists as one location in 4-dimensional spacetime. Our existence is a single thread moving uniformly forward through time, attending to one task at a time. Almost nothing in the real wold is stateless or immutable. Our brains evolved to deal with this reality.
but apart, remember programming isn't something natural of the human, is learned.
When I looked at the first BASIC program listing I encountered almost 40 years ago, I immediately understood what it meant. I didn't have to learn anything to relate to it. It's a list of steps to take, just like we do every day in the physical world.
Most CS students struggle for a long time just to get a grasp on recursion, much less the various high-powered concepts from functional languages.
Re: (Score:2)
Re: (Score:2)
All other things are not equal though, are they? Procedural programming is easier for humans to understand: most of us do no not think in a way that maps easily to functional programming.
Quite the opposite actually, and that's the real advantage of functional programming; I don't think "do this to the first item in the list, then do it to the second, then...", I think "do this to every item in the list". Procedural was popular because it corresponded to what the computer was doing, and in the early days knowing exactly what the computer was doing was very important, but functional maps much more closely to human reasoning.
Re: (Score:2)
I think procedural programming is easier for humans who have spent prior time studying procedural and/or imperative programming to understand. I'm not convinced its any easier to understand starting from scratch, though.
Ah Haskell (Score:2)
I remember using it during my uni times and finding it very cool.
However it is less useful than Iteratative or OOP languages unless you NEED to use mathematics and recursion all the time, in which case its easier.
I disagree, it'll always be a niche language which isn't for 'the masses'.
Re: (Score:2)
Part of the problem there is in the teaching of it though; my university taught Standard ML and almost went out of their way to avoid teaching us how to write anything in it that would be useful in the real world. There are some quite practical real-world software packages written in ML / OCaml / Haskell. Plus I find functional-style constructs incredibly useful to sprinkle in Python code I write.
Another functional programming fan (Score:2)
OK, somebody posted their resume.
Python is similarly terse, and isn't statically typed. So this isn't about static typing. It's another functional programming fan.
Functional programming is a good fit to a certain class of algorithms. For the 65 programmers of a trading house, it makes sense.
Functional programming has its downsides. It tends to result in heavily nested code. It's hard to fan out results, so programs tend to be trees with a single result. Persistent state and I/O don't fit well with th
Re: (Score:2)
The nice thing with OCaml is that it has all the good old imperative goodness - it even has while and for loops. It's just that immutability is default, and you have to sprinkle "mutable" in your data structures where you actually need it.
One thing that I personally find awesome about OCaml, though, is not so much its FP side, but rather it's 100% structural OOP approach. This lets them do pervasive type inference, even for operations such as method calls. And yet their object model is very powerful - it ha
Re: (Score:2)
It's just that immutability is default, and you have to sprinkle "mutable" in your data structures where you actually need it.
That's a related idea to functional programming - single-assignment languages. [c2.com] The idea is that all (or at least most) names are "const" - they can only be assigned a value once. This works a lot like functional programming, but there's not so much nesting, and most things have names, rather than being anonymous within some nested expression.
Pure functional languages force programs into a tree form, with one output. A single assignment language forces programs into directed acyclic graph form, with multi
Re:Another functional programming fan (Score:5, Interesting)
My favorite code to read is OOP stuff written by coders who understand and make use of functional programming concepts. They know how to write things that are stateless when that makes sense, and use state in an appropriate manner when that makes sense.
And yes, by all means use it when appropriate. But don't think that Lisp is always the right language for scripting your text editor (dodges blow from Emacs partisan).
Re: (Score:2)
Agreed that Python is similarly terse, that's one reason I like it. But static typing does eliminate a whole class of errors if done properly. The ML family and Haskell languages do have an amazing static type system, which provides guarantees that I don't have when I program in Python. It's more powerful than the type systems of other statically typed languages whilst being not verbose.
To a large extent, for some functions, when something got through the ML typechecker correctly I generally found most o
Two line summary of TFA (Score:2)
I have the perfect hammer.
Everything should be a nail.
Re: (Score:2, Informative)
I have the perfect hammer.
Would that be the C family of languages used all over the place?
Re: (Score:2)
No, no no. It should be:
I have the perfect hammer.
Everything is a nail.
Re: (Score:2)
With C/C++, everything can be!
Practicality drives use (Score:3, Interesting)
'The importance of concision is clear: other things being equal, shorter code is easier to read, easier to write, and easier to maintain.'
But there's the rub. Other things are not equal. Functional languages require the developer to approach problems with an entirely different mindset. There is a steep learning curve to really understand how they work. And I'm not talking about just the syntax. Functional languages are fundamentally different than procedural languages. Truly understanding how they work requires a lot more brainpower than procedural languages.
While it's admirable to espouse what you see to be a more elegant and "better" solution, you need to be pragmatic. Getting the millions of software developers in the world to put the effort to completely change their way of thinking just isn't going to happen. The cost/benefit ratio is questionable at best, given that a lot of people could train for a long time and still have difficulty with the basic concepts of functional languages.
Procedural languages are the norm because they're a lot simpler. Procedural languages (including "C with classes" and the like that masquerade for OOP/OOD) are useful to many more people simply because there is less to understand about how they work. It's easier for people to approach problem solution in a procedural way than it is for them to think about it functionally. And that's why functional languages, no matter how elegant or "great" they may be, will never really break into the mainstream.
Re:Practicality drives use (Score:5, Insightful)
'The importance of concision is clear: other things being equal, shorter code is easier to read, easier to write, and easier to maintain.'
That was the idea behind APL. You could do amazing things in one line of code. I never, however, knew anyone who used it who thought it was easier to read, easier to write or easier to maintain.
Re: (Score:2)
Agreed. In fact, just about everywhere I work has a coding standard that says you shouldn't cram a whole lot of stuff into one line of code specifically because it's hard to write correctly, not to mention difficult to read and maintain. Perhaps that's a symptom of the chosen languages but I suspect it goes deeper than that. It's been my experience that one needs to be able to strike a balance between complexity/elegance and readability. I've been known to write code so clever and elegant I have no idea
Re: (Score:2)
Sounds to me like you're in a situation where a language like that is a viable tool with which to implement a solution. But only because the nature of the problem lends itself to being solved with that specific tool. And when it's the right tool to use, I'm sure it's a fantastic language. But that's just it. How often are people working on problems where it's the best tool? I don't often run into situations where a functional language is the best choice. I'm glad I have it in my tool box along with so
Re: (Score:2)
Sure. But I can do that in a procedural language too. In fact, that's one of the points of OOD. You abstract away your layers with a proper design and your code is small and concise. Of course, it's rare to find that type of design done well but it's possible.
Ahem (Score:2)
"Procedural languages are the norm because they're a lot simpler"
Maybe you haven't seen Scheme.
Procedural programming isn't simpler. Its popularity and mindshare (like that of say, Windows) is accidental, and needs to end for the industry to move forward. Minsky's not the first or last to point this out.
Re: (Score:2)
I have, and my point still stands. A minimalist Lisp language may have a simpler syntax but that's not what I'm referring to when I call the languages simpler. The point is that the concepts behind building software with procedural languages are far more simple than using functional languages. The average office worker can cobble together enough thought process to write basic macros in a spreadsheet. Try getting those same people to use a functional language to do the same thing and then tell me how "sim
Re: (Score:2)
Maybe you haven't seen Scheme.
Or maybe he has like all other people who took programming languages in their (CS undergrad (and (completely '(hated it))))
Re: (Score:2)
We didn't cover Scheme in my CS class. We did straight LISP (Lost (In (Superfluous (Parenthesis)))).
Re: (Score:2)
I don't know if you've ever tried teaching functional languages to novices with no math background. To say it's not easy is a colossal understatement. What is far easier is getting them up and running with procedural languages. The concepts are just far easier for the average layman to grasp than the concepts of functional languages. Protest all you want but that's just the way it is.
Re: (Score:2)
To me, functional languages are actually more intuitive.
I know a lot of academic types for whom that is the case. But I've met far more people who have enough trouble understanding basic procedural language concepts. I don't even want to think of trying to teach them a language that requires a solid understanding of advanced math just to be able to use.
And that's my point. Functional languages have their place, but they will never reach the mainstream because the mainstream just doesn't have the desire (or ability in many cases) to understand the underlying t
OCaml vs Javascript (Score:2)
Place your bets.
Concision? (Score:3)
Functional languages and RDBMS? (Score:2)
I'm no developer, and only a novice with programming and databases, so this may be a naive question.
I remember reading about Object-relational impedance mismatch [wikimedia.org]. I thought, if object oriented programming is a poor fit, conceptually, with the relational database model, perhaps functional programming would be a better fit: the code leaves the management of state to the database, which is its specialty.
Does that make any sense?
Re: (Score:2)
Re: (Score:2)
I can see that sort of mismatch as a serious problem.
However, the Wikipedia article I reference was definitely discussing a difference in design philosophies between OOP and RDBMS, which I understood to be essentially that objects are understood to be both function and data structure, but databases are concerned only with data structures, which complicates moving data back and forth.
Re: (Score:2)
what type would you use for a 32-bit integer in Oracle?
Umm... INTEGER? (or maybe PLS_INTEGER if you want to be Oracle specific).
In any case, I really don't think the mapping of datatypes has anything to do with OR impedance mismatch. It has to do with how data structures are represented in code vs how data is stored in an RDBMS (OOD vs relational tables). For instance, the concept of inheritance does not exist in an RDBMS. While tables can be constructed to implement the concept, it's generally a bit of a kludge, a kludge that ORM middleware was invented to ma
Déjà vu (Score:2)
All the fear and uncertainty coming from those who've never tried functional languages here sound just like the mobs in 1965 insisting 'compiled languages will never catch on'.
Smell the coffee. Learn something. The industry needs to change. [loper-os.org]
Any studies to back up the "small code" thesis (Score:3)
Are there any studies to back up the "smaller code is better" thesis? My own experience and that of many others leads us to diasgree; but our anecdote and/or sentiment is no better than theirs.
1. Quantify terseness.
2. Assign terseness value to language.
3. Quantify qualities of interest (maintainability, etc.).
4. ???
5. Science!
Data vs algorithm (Score:2)
Functional languages are good for inplementing algorithms and imperative languages are good for handling data. It happens that in most real-life situations we need the latter.
Real-life Experience with functional programming? (Score:2)
I have no experience in functional programming languages, so I'm curious to hear from those who have developed real applications. How does functional programming do when having to create UIs? Or reading/writing to a database and dealing with transactions? Or creating a web-service? Or enforcing business logic?
Functional programming seems ideal for writing algorithms, but does it have any drawbacks?
After VBA anything seems like deliverance (Score:2)
The guy started his career writing in VBA and moved to OCaml via Java. Is it any wonder he finds OCaml so great?
Re: (Score:2, Informative)
Re: (Score:2, Informative)
You mean like right now? Haskell's pretty mature, and it's been able to compile to native code for years. It's pretty straight forward to talk to C (the universal ABI) with Haskell (well, as straight forward as anything is in Haskell).
OCaml has been mature for nearly a decade, by the way. Without the success it's had, languages such as Haskell and F# wouldn't be around. It also can compile to native code, and has been able to since inception.
PS, the .NET VM isn't really decrepit, it's much more performant t
Re: (Score:2)
Re: (Score:2)
Request granted [inria.fr] (at least for calling C). SML has an even nicer FFI [mlton.org] and most certainly builds native executables.
Adhering to the platform ABI makes little sense -- the "platform" ABI on e.g. UNIX is meant for C programs and is not expressive enough for other languages (keep in mind the only types in C are bytes, half-words, words, double words, ...).
Re: (Score:2)
Huh? No it isn't. The API may most often be expressed in C, but the ABI is language agnostic.
Huh? The C standard doesn't define anything in terms of "bytes", "half-words" or "double words". In fact those terms are largely meaningless in the context of C: the standard offers very few guarantees about the width and endianess of it's native types. C didn't even gain portable fixed
Re: (Score:2)
The ABI defines how data is represented at the machine level, how functions are called, etc. The C ABI is insufficient for representing languages like Common Lisp, OCaml, Haskell, ... for a number of reasons. One is that the calling convention is not powerful enough for them, another is that it is difficult to express types from these languages in terms of the C ABI. It could probably be done, but then you'd need a lot of run time support and it would be really difficult for a human to actually call things
Re: (Score:2)
The common ABI of all platforms in wide use today were designed only with C in mind (extended slightly, in an incompatible manner, to support C++). If even C++ cannot link directly with C, why would Ocaml et al have to? These things have their own internal binary interfaces and so I don't see what the problem is. The lack of a shared library format?
Re: (Score:3)
Re: (Score:3)
Glascow Haskell Compiler [haskell.org]:
GHC compiles Haskell code either directly to native code or using LLVM as a back-end. GHC can also generate C code as an intermediate target for porting to new platforms. The interactive environment compiles Haskell to bytecode, and supports execution of mixed bytecode/compiled programs.
Re: (Score:2)
Take a look at Scala collections.
Scala lists look and feel immutable, but under the covers they are really mutable to remain more performant.
No way (Score:2)
Are you aware that there is a State object in the Haskell library just to represent mutable objects? There's nothing in functional languages preventing you to handle state, not even in the purest ones, at least since the application of monads to programming [wikipedia.org].
With monads you can create sequences of pseudo-imperative actions ("do blocks") that behave like a language with mutable states, but where the only possible side-effects are the ones you have previously embedded in the monad declaration; every other side
Re: (Score:2)
Yup, I know about monads. A clear step forward particularly in terms of reasoning about state in an immutable language, but still a bit of a kludge.
By the way, observe that functional language != immutable language. People often confuse the two.
Re: (Score:2)
which comes particularly handy when trying to debug a stateful complex program.
To that I concur. Trying to handle two different states by boxing/unboxing data with monad transformers is a pain.
Yup, that's why I added a remark about the "purest ones", which use immutable descriptions to represent mutable obj
Re: (Score:3, Interesting)
This is why I think Scala will succeed.
Scala has all the advantages that the article mentions AND you can integrate and reuse your old Java or .NET code and libraries.
It's there. The tooling doesn't suck half bad anymore. The world just needs to find out.
I personally think that Scala will win over the 10% best Java programmers as soon as the tooling is comparable to Javas.
And that might happen within the next 1-2 years.
Use F# (Score:3, Interesting)
F# is essentially OCaml for .Net, so you get the full access to the .Net library. Also the best thing about F#, in my opinion, is since it is a .Net language, you can mix and match it with C#. So you can use functional approach for most part of your program, yet drop to C# when you require.
Re: (Score:2)
F# is an OCaml variant built to run in .NET. While not 100% compatible with OCaml, many programs can be cross-compiled.
F# includes features such as units of measure (numeric parameters) and computation expressions. It has many more, those are just the ones I like most.
Re: (Score:2, Interesting)
Ah, and I forgot, F# 3 will have type providers, which gives you a hook into the compiler to provide types however you please. It is mostly used to create statically-typed elements from a dynamic resource such as a cloud database.
Good news! (Score:3, Interesting)
We have found the problem with the software business.
Bad news: It's you and your 100,000,000 ignorant & unwilling to learn clones.
Re: (Score:2)
The Unison file synchronizer is written in OCaml.
Re: (Score:2)
So, if I find a programmer making more money than TFA author, his language of choice is perforce better than OCaml and Haskell?
Re: (Score:2)
(wait, no, even better: at editing time, because you're IDE/Emacs/whatever *should* be able to compile even an impartial AST and tell you immediately that you got your types wrong).
I would like to agree with this (long ago I even work with an 'Interactive Incremental Compiler' for FORTRAN that did the syntax checking on a line by line basis as you typed). But there is a major problem - the editor basically has to include a complete, correct copy of the language compiler/interpreter in its own logic. Since most languages these days are built based on various token-tools, perhaps it would be possible to base the checking on the input definitions to those tools (sorry I can't remember
Re:Shorter code? (Score:5, Insightful)
If shorter, more concise code was always better, we'd have switched to APL years ago.
We didn't.
Re: (Score:2, Insightful)
True, so on one end you have bloated, verbose languages like Java and Cobol and on the other end you have terse, unreadable languages like Perl and APL. So the key is finding the right balance. Ideally you want a language which is both readable and expressible. One that encourages reduction of repetitious code. One that allows you to build the abstractions to best express your intent as a programmer in a maintainable way.
I'm of the opinion that C syntax is not best suited for this. Lisp is better, but every
Re: (Score:2)
APL FTW! :D Occasionally described as the first 'Write-only language'. But it was remarkably good at describing the pure problem efficiently, without all the syntactic fiddling most languages require. Cross-product was just 'cross-product' - no nested for loops. But the programmer had to think completely in terms of the abstract problem being solved, not piecewise refinement of all the fiddly details.
Wrong question: (Score:2)
Re: (Score:2)
My only problem with non-determinism and Prolog was that it was really hard to find where unnecessary choicepoints are. (e.g. you get the same results multiple times) Prolog could definitely use better debugging tools.
Re: (Score:2)
Well, if a thousand unbelievably crappy, unstable, and resource-inefficient erlang programs hit the streets in a couple of years, I'll know it wasn't actually the Java language that was the problem after all, it was the Java programmers. Which is what I suspect, frankly.
Re: (Score:3)