As a summary, and in the hope of not dragging this discussion further off topic, I created Brendan's Law Of Language Adoption.brain wrote:Brendan, what about forks and extensions of languages, for example the many dialects of basic? Each solves a specific set of problems right but isn't strictly a new language, whereas there are very few 'dialects' of c if you include objective c, c# etc as dialects...
Unfortunately it was unclear to me your post was meant satirically. I have had the unpleasant experience of meeting people who happen to genuinely have the view expressed in your post about purely theoretical research, and (luckily mistakenly) believed you fit into that same category.Brendan wrote:Hi,
That would depend if the reader understands important key concepts or not.davidv1992 wrote:Brendan, you're last post just gives the idea that you're completely oblivious to the gains of fundamental research (most of what you write can be transposed one to one to every other field of fundamental research out there) combined with a complete lack of respect.
I agree with you that in a perfect world the natural solution (or definition) is the best one to write, and that languages have to strive to make that as easily expressable as possible. However, the current state of affairs is that it is in a lot of cases impossible if one want's any type of performance. The argument I tried to make in my previous post is that because of the limitations it imposes, for certain classes of problems functional programming languages allow the programmer to jot down the natural solution (or sometimes even the mathematical definition) and get away with it without performance problems, whereas in languages with mutable state, due to the CURRENT state of affairs in analyzing code for optimizations like memoization they cannot be done.Brendan wrote: Let's be honest here - programming (the task) is harder than it should be, and programming (the career) is worse.
Why is programming (the task) is harder than it should be?
The task is hard because natural solutions are often not the best solutions due to restrictions. Consider your LCS example. If you had a group of 100 children (all without any programming experiences at all) and asked each child how they would solve the problem, you'll find that almost all of them would start by searching the string for the first character of the substring, and each time they found the first character of the substring they'd count to see how many characters at that starting position match. This is the natural solution. In C, it might look like this:
Of course this is the natural way of doing it with only one thread. The natural way of doing it with multiple threads is relatively simple (it's "embarrassingly parallel") - determine how many CPUs/children you've got and get each of them to scan part of the main string, then determine which result is the best result at the end.Code: Select all
int lcs(char *a, char *b) { int pos; int length; int bestPos = 0; int bestLength = 0; char first; first = b[0]; for(pos = 0; a[pos] != 0; pos++) { if(a[pos] == first) { length = 1; while( (a[pos + length] != 0) && (a[pos + length] == b[length]) ) { length++; } if(length > bestLength) { bestPos = pos; bestLength = length; } } } return bestPos;
Restrictions that prevent the natural solution from being the best solution include performance and language features. For performance, in this case the natural solution is likely to perform well (nice predictable pattern of accesses for the prefetcher to deal with, good cache locality even for the multi-threaded version, etc). However, if the language you're using doesn't have arrays, or doesn't let you use variables to remember what the "best length so far" is, then you're screwed.
When you can't use the natural solution, you have to use an unnatural solution. This makes programming awkward and means that how a piece of code works isn't how people expect the code to work.
Here I do not agree. Again, different problems have different requirements, but there are (big) classes of problems which still can be "naturaly" formulated in functional programming languages. Furthermore, for these problems, the fact that the language is functional might enable the compiler to actually deduce a fast way of computing the requested answer, where it might not be able to do so in languages that support mutable state.Brendan wrote: For language design, restrictions that prevent the natural solution from being used must be avoided, and any language that forces programmers to use unnatural solutions is a failure. For compiler design, the goal is to find ways to optimise the natural solution into the fastest solution, in an attempt to remove restrictions that prevent the natural solution from being the best solution.
For language design, functional languages are a complete failure because they don't allow the programmer to express the natural solution in many cases. For compiler design, research into functional languages is important, because it can lead to better ways of converting the natural solution into the fastest solution. It's important not to confuse these things - normal programmers should never need to care about functional languages unless they're designing code optimisers.
I agree that there are too many frameworks for programming, and that there may be too many languages. I do, however, not agree on the stated cause for this problem. Most of the programming languages you have worked with, are not the result of language research, with the exception of python. Most are either the result of a professor thinking he needs a new language to be able to properly teach a programming concept, or individual programmers making something that they percieve solves a problem. This is where the core of the problem is. Different people have different expectations of what a programming language should do for them. This might be shaped by their education, but also comes from their personal preferences. Your proposed solution would require not just putting language researchers into that room, but almost every IT manager in the world, as it are these people who in their infinite wisdom decide that their company needs a new framework because the ones currently existing are not up to the spefic requirements their company has.Brendan wrote: Why is programming (the career) harder than it should be?
Let's start with some quotes!
brain wrote:Lol someone's got an axe to grind against some academicsGuess who's right?davidv1992 wrote:That said brendan, your posts in this thread do not give the impression that you have spend any decent ammount of time with languages other than C/C++. Whilst this is your choice, it might be refreshing to try and use some other languages, i would suggest something like haskell or lisp, and something like scheme or erlang. These are languages structured in radically different ways to C/C++ type languages, and working with them might teach new methods of approaching problems. If you've tried them and you felt they didn't work for you that's fine, but at the moment you give the impression that you haven't used them at all.
Up until a few years ago I'd learnt several dialects of BASIC (Commodore 64 BASIC, QuickBASIC, VisualBASIC), several assembly languages (6502, 80x86) and C. I learnt some more obscure languages (e.g. "ladder diagrams" used by electricians to program industrial controllers, some BASH scripting, etc). I also picked up small pieces of other languages along the way (a little Pascal and a little C++, etc).
However, more recently I've been doing a "Bacheler of IT" course. In the last 18 months or so I've been taught (which isn't quite the same as "I've learnt") Alice, PHP, Phython, Perl, Java, Javascript and SQL.
I just want to write software, but over the last 18 months I haven't really been able to. Instead I've been faced with churn - learning languages for the sake of learning languages (although to be fair it's not just languages, it's the libraries and frameworks too). I've been getting more and more frustrated because I can't find enough time.
What have I learnt? Mostly what I've learnt is that the single biggest problem for programmers today is the proliferation of different languages (and the libraries, tools, code documentation systems, etc. that go with them). It's futile and unproductive and has a massive cost on the I.T. industry as a whole - retraining, retooling, rewriting and the "Tower of Babel" effect. As a test, go to stackoverflow and see how many of the questions you can answer (for any experienced programmer, I can almost guarantee that it will be less than 25% of them).
What we need is to limit the number of languages to one per field (e.g. one for low level programming, one for high level programming and scripting, one for databases, etc). What we need is some sort of conference for academics and language researchers (to get them all in the same place at the same time) and a special educational tool (a baseball bat with nails/spikes) that can be applied to these people until they get the message.
Cheers,
Brendan
For a lot of things, people think the same way unless they're specifically trained not to. Even when they are trained to think in certain ways they often (for a brief moment) start from the natural solution.berkus wrote:That is the key and the essence. Everybody thinks differently and so many different languages exist.
But language is for communication. Sure you can teach that one child a different language so that it could express its thought patterns better, but no-one would be able to communicate with the poor fellow...berkus wrote:You deliberately excluded that one child who dared think like no other did.
Actually, they did. In February.JamesM wrote:Guys, fun as this is, can't we stop now and agree that all of our penises are equal size and cease waving them in each others' faces?
gravaera wrote:Given that I just lost about 40% of my brain; mass debating on facebook with two women, I do believe Sundays have the power of lycanthropy for the retarded.
).
