PDA

View Full Version : D language?



Pages : [1] 2

swgh
08-09-2007, 09:07 AM
As we know, C evolved from the B language, and C++ evolved from C and C# evoloved from C++ ( sort of )

My theroy is a new 'D' language may arrive soon... to continue the trend so to speak.. proberly never happen but I thought it was worth mentioning as a possiblilty for any future language developers...

laserlight
08-09-2007, 09:12 AM
I believe there is a D programming language exactly along the lines you speak of, but it does not seem very popular.

Mario F.
08-09-2007, 09:42 AM
http://en.wikipedia.org/wiki/D_programming_language

For one it doesn't try to be "backward" compatible with C++. I tried D a little while ago. Nothing much bad to say about it. Not when my C++ knowledge is so limited anyways. However, I don't see the point of D. Much of what it offers is offered by C++ through libraries. It tries to address the shortcomming of C++ probably ignoring the fact C++, for the most part, doesn't really have those shortcommings (design by contract, unit testing, dynamic and associative arrays, nested functions, heck even automated memory management).

QuestionC
08-09-2007, 12:47 PM
Please.

The next big thing's gonna be C<<1

Salem
08-09-2007, 01:15 PM
What about C*=1
Oh wait, that's just C
Nevermind....

@nthony
08-10-2007, 01:40 AM
Well, according to the rules, its I before E except after C, so really the next two languages should be "E" and "I".

dwks
08-10-2007, 04:33 PM
Rearrange E=mc^2 and you get c=sqrt(E/m), so maybe it'd be "E" and then "m". ;)

There was actually some controversy about this a while ago, since C was based on B and BCPL. Would the next language be D as in A, B, C... or P as in BCPL? Anyway, D got invented, but if someone else actually created another language based on C and they wanted a one-letter name, they'd probably go with P.

zacs7
08-10-2007, 05:01 PM
I wouldn't say it's based on C? Rather inspired by it. It looks more like C# to me :|

robwhit
08-10-2007, 05:09 PM
I don't think P would be a good name choice.

IMHO :p

DavidP
08-11-2007, 12:52 AM
Yeah...just think if someone said, "I like to program with P" or "I love P" or "P is as slow as crap" :)

maxorator
08-11-2007, 11:03 AM
I would never wish there would be another programming language made. As far as I know, all new languages are slow, ugly and obfuscated.

prog-bman
08-11-2007, 06:47 PM
Yah, who needs to progress. Let's just keep programming in the same languages!

OnionKnight
08-11-2007, 09:17 PM
D would've been more interesting if it had first-class functions and type inference.

maxorator
08-12-2007, 12:15 AM
Yah, who needs to progress. Let's just keep programming in the same languages!
We have everything we need - Assembly for performance, C for saving time, C++ for complexity.

whiteflags
08-12-2007, 12:40 AM
We have everything we need - Assembly for performance, C for saving time, C++ for complexity.

Real men don't need languages. They compile everything in their mind, and the program works.

pheres
08-12-2007, 01:00 AM
Yah, who needs to progress. Let's just keep programming in the same languages!New Programming languages with 3 or 4 nice new features doesn't got us anything so far. It doesn't solve the problems software development suffers from all the time, like, the demand for more complex software systems, lack of a software engineering method working for all types of software, ignoring education in software design/implementation in computer science, or a design method what is verifiable/executable. There is just no need for another programming language working in a similar way as the 3 zillion already existing. because the limiting faktors in software development today are the things mentioned above.

whiteflags
08-12-2007, 01:36 AM
Hyperbole doesn't make an argument correct or sound smarter. We're not even talking about a particular language anymore so what is your real problem with practically everthing?

You could be expecting some sort of rigourous miracle language to come along that is quick to master and solves all your problems. You could have had a bad experience with a different paradigm. You could simply have no idea what you are taking about, too.

I can't make up my mind which, so pick one. They're all stupid.

pheres
08-12-2007, 01:51 AM
I just said that D nor E nor F will be the progress what software development really needs. There do you see the stupidity/hyperbole exactly? I do not expect a miracle, nor did I've bad experiences (ok, I had them, but not worse than everyone else I guess). Maybe I (and all researchers actually looking for better software development methods) are stupid and don't know what they are talking about.
so you expect new programming languages to solve the actually problems not solved by all programming languages before. I do not. Thats a difference in opinions and should be normal in social life. no reason to bite round you :)

whiteflags
08-12-2007, 02:09 AM
so you expect new programming languages to solve the actually problems not solved by all programming languages before. I do not. Thats a difference in opinions and should be normal in social life. no reason to bite round you :)


No, that's what you stated I think. Are you that positive that there are no languages that execute in a matter-of-fact way, are capable of building complex systems, or make it easier to study software engineering that came into being after the 70s? Your statement that the "3 zillian" languages all fail massively in all of these areas is quite an exaggeration.

prog-bman was being sarcastic, in case you never noticed, btw. And now I'm just completely confused, because you took that seriously and said all new languages suck, and now want to convince me that new languages don't suck or old languages suck less, or something. And it doesn't even matter at this point.

pheres
08-12-2007, 02:21 AM
you seem to get me intentionally wrong. Newer languages are better, no question. but they are not suited to handle the complexity of huge software projects. They get expensive, they overrun their time frame, they are buggy (to be exact they are buggy in a constant manner: after a while updates does not lower the absolute count of bugs), they are hard to maintain and they fail.
my statement was: a new language will not solve that problems.
now please criticize that statement and not some constructed things I never said.

zacs7
08-12-2007, 03:16 AM
you seem to get me intentionally wrong. Newer languages are better, no question. but they are not suited to handle the complexity of huge software projects.

Not that I care much, but where are you pulling these "facts" from? It also depends which software model your talking about (ie how the language is designed to be used, RAD, agile etc).

You never said anything about new languages not solving problems, you said they just suck. I suppose we better all go back to B then, or even before B - no point using C, after all it was a new language and therefore must suck.

pheres
08-12-2007, 06:24 AM
Not that I care much, but where are you pulling these "facts" from? It also depends which software model your talking about (ie how the language is designed to be used, RAD, agile etc).Turning on your tv should be enough. At least here in german we have 2 very actual examples: toll collect system and a new software to manage unemployment. both suffer from exact the problems I mentioned. If you say developers over here are just incapable, well what may be true, but others are just not better. if you are really interested in (which i doubt of) I can get you some references to scientific papers investigating the problems of software engineering today.
I'm actually pretty surprised to see my statements so heavily criticized. Until today I was convinced that these things are common sense.


You never said anything about new languages not solving problems, you said they just suck. I suppose we better all go back to B then, or even before B - no point using C, after all it was a new language and therefore must suck.Where do I say they suck? Ok I try it one more time: Newer languages are nice, because the abstracting away things what in former languages had to be done by hand or introduce pretty new features like tmp and so on. But, they are just the wrong tool to solve the class of problems todays software projects suffer from in the first place. D may be a great language, but the main problems will stay the same. And thats why nearly nobody will switch, the costs of switching to D are just greater than the return (return in the sense of solving actual software engineering problems)

Rashakil Fol
08-12-2007, 07:25 AM
I would never wish there would be another programming language made. As far as I know, all new languages are slow, ugly and obfuscated.


We have everything we need - Assembly for performance, C for saving time, C++ for complexity.

You are joking, right?

Right?







Right?

laserlight
08-12-2007, 07:59 AM
And D for Donkey?

cboard_member
08-12-2007, 08:28 AM
Eee-haaaw!
I am so listening to music right now.

whiteflags
08-12-2007, 03:38 PM
Can I at least get you to admit that you stated this, pheres?


[A new language] doesn't solve the problems software development suffers from all the time, like, the demand for more complex software systems, lack of a software engineering method working for all types of software, ignoring education in software design/implementation in computer science, or a design method what is verifiable/executable. There is just no need for another programming language working in a similar way as the 3 zillion already existing. because the limiting faktors in software development today are the things mentioned above.


And this is the reason why I find statements similar to yours - "Newer languages are better but don't get the job done" - very paradoxical. They do get the job done. It is merely that your evaluation of what makes a good language is entirely unfair. I doubt that in a near future a single programming paradigm, or a single language is going to solve all the problems that you mention. (And don't really attempt to pin down with some sort of evidence - I still think that you're relying on umbrella statements purposefully so that they can't be meaningfully applied to anything.) It's unreasonable to expect this kind of breakthrough out of one particular thing. That's why I said you have no idea what you're talking about.



At least here in german we have 2 very actual examples: toll collect system and a new software to manage unemployment. both suffer from exact the problems I mentioned.

Newer languages are nice, because the abstracting away things what in former languages had to be done by hand or introduce pretty new features like tmp and so on.But, they are just the wrong tool to solve the class of problems todays software projects suffer from in the first place.


Not being from Germany, I find it hard to understand the examples that you have provided, because I feel like even if I had visited there, I still wouldn't have the ability to make an evaluation of the software these systems use. However I don't think that a new language sucks just because it is applied wrongly to a class of problems.

Your computer is a complex system that runs many programs written in different languages to solve problems. It is how complex things should be designed. Why should any complex system depend on one umbrella language that will never exist? Why do you expect that kind of breakthrough out of research? It is already possible now to design complex systems using a class of, or several languages.

Do we understand each other now.

pheres
08-12-2007, 05:06 PM
Ok i think I know why we are arguing: No, I do not expect to see any super programming language that solves software engineering problems. The power of programming languages is stagnating for years now, while demands/complexity of systems is increasing all the time. Instead of creating new languages we should think of new methods to reliable create software and in fact there are people who do that - without much success so far as it seems. today a spec is build from requirements and a programmer _somehow_ (Do you have universities that teach methods how exactly? I don't know not one over here) creates a design and hacks the code. If he is good he will get it done. unfortunately nobody knows if he is good enough until the end of the project. Even if he is good and the software works as it should with a low count of bugs the chances are good that the design spec has not much to do with the code anymore. The project is nearly unmanageable now. _That_ sucks, not the languages. But new language can't improve that situation. We need for example straight forward methods to create a design. We need a way to have designs that are verifiable and even indirect executable. And we need better education of software engineers, not the kind of people coming out of university today knowing how to draw 13 uml diagrams out of their head but have hard times to get a hello world app compiled.
So nothing against D or some else language you prefer. but they will not help us much looking at the big picture

whiteflags
08-12-2007, 06:44 PM
I think I understand that you're measuring the effectiveness of a language based on how monolithic the code can become. I agree that there are some toy languages that simply reimplement features available in other places and don't make the code any less of a headache than before. These are the languages that also aren't being used for anything. But this doesn't mean that new languages aren't a part of a better future in software. After all, there are new languages that are useful.

Read on.

> But new language can't improve that situation. We need for example straight forward methods to create a design.

Yes they can. Languages don't require a great deal of applications like C or C++ have in order to be what they are. There is nothing wrong with implementing a whole new language to solve a new class of problems (as mathmatica does for equations and other math things, for instance). I hope you realize that a new language can be all that you need to get an expressive design. If you don't understand that, then perhaps you need to re-evaluate your definition of what a programming language is, or read SICP, or something.

Rashakil Fol
08-12-2007, 07:02 PM
No, I do not expect to see any super programming language that solves software engineering problems.

I'm reminded of an anecdote by one guy who started a software company, where a project manager at another company told him his company must have excellently fine-tuned project management, because they were keeping up with a schedule that was deliberately made too accelerated. The guy had trouble keeping a straight face, because his company had no project management at all! He was using ML at the time.

There's a language I'm a fan of, where I can write code, fix its syntax errors until it compiles, and it works. No bugs. Or they rarely/never appear. Really!

Of course, there are always some software engineering problems. But programming languages and programming language features can fix software engineering problems -- all languages do, and they do so in modest and less-than-modest fashions. Take strong typing, for example. That solves a software engineering problem. What about static typing? There's another. How about lexical scoping, or namespaces? Solves another one. Garbage collection? There's another one solved.* A serious module system (instead of #include barfage)? There goes another. The const keyword? There's another. Or better yet, pick a language where it would be redundant. Restrictions on naming that differentiate between values and types? There's more refinement to the namespacing problem. Isolation of side effects? Solves another one. I think that's coming to C# soon, in a primitive way. Type system-based descriptions of side effects? Ooooh. Statically typed software transactional memory? ~drool~.

* Edit: the biggest one of them all -- since named functions and variables were invented. Hey, I forgot to list the invention of subroutines!

OnionKnight
08-12-2007, 07:23 PM
Language is not really the issue here, people can't design because they're never taught to, and that is not because there is no method of doing it. We call this abstraction, and it comes in many different flavors.
SICP is a great read, it teaches programming instead of a programming language. The programming courses I've taken in high school all took programming in the wrong direction. For example a whole week could be spent on explaining how to make something as painfully simple as a Fahrenheit to Celsius converter by taking lengths explaining things like how integer math can't produce fractions. This stuff was all low-level and spends no time on abstraction and understanding what's going on at the upper level and how it all translates into the components you just built.

maxorator
08-13-2007, 03:45 AM
Of course, there are always some software engineering problems. But programming languages and programming language features can fix software engineering problems -- all languages do, and they do so in modest and less-than-modest fashions. Take strong typing, for example. That solves a software engineering problem. What about static typing? There's another. How about lexical scoping, or namespaces? Solves another one. Garbage collection? There's another one solved.* A serious module system (instead of #include barfage)? There goes another. The const keyword? There's another. Or better yet, pick a language where it would be redundant. Restrictions on naming that differentiate between values and types? There's more refinement to the namespacing problem. Isolation of side effects? Solves another one. I think that's coming to C# soon, in a primitive way. Type system-based descriptions of side effects? Ooooh. Statically typed software transactional memory? ~drool~.

* Edit: the biggest one of them all -- since named functions and variables were invented. Hey, I forgot to list the invention of subroutines!
Namespaces - what do they solve? I don't think you'll have so many functions that you run out of letter combinations for a function.
Garbage collection - Yikes... never heard of freeing memory? When you allocate memory for an object, structure or buffer, why not free that memory when you don't use it anymore? It's as simple as that. Garbage collection is an "alibi" to do careless programming.
Const keyword - the most useless thing on earth. If I want a value not to be changed, why not use macros? And who would be that stupid to accidentally modify a variable which is not supposed to be modified.

Most of the stuff you mentioned doesn't give any real advantages. They just teach us bad habits like always giving the functions the same names in libraries, not freeing memory, making stupid mistakes etc.

What's ruining the art of programming is that people are taught to do what would otherwise be mistakes and software has to hunt&kill them. Why not write good code? Nowadays most performance goes to runtime environments or CRT checking if you have made stupid mistakes. Why not spend performance for the reason that the application was designed for?

When disassembling some programs programmed in high-level languages, I can clearly see that the code that the application actually was meant to do makes a small portion of the code that runs for every function. Visual Basic even adds "jo xxxxx" (if calculation overflow, then jump to exception handler, it triggers when doing unsigned INT_MAX+1, which results in 0) after almost every other assembly instruction. And MSVC++ compiled executables call a complex checking in the beginning and in the end of every function, not mentioning that it calls the checker many-many more times during the function depending on what it does.

Anyone care to do MD5 benchmarking for example in C# and then compare it with C and Assembly? You'll be surprised.

pheres
08-13-2007, 04:01 AM
Of course, there are always some software engineering problems. But programming languages and programming language features can fix software engineering problems -- all languages do, and they do so in modest and less-than-modest fashions. Take strong typing, for example. That solves a software engineering problem. What about static typing? There's another. How about lexical scoping, or namespaces? Solves another one. Garbage collection? There's another one solved.* A serious module system (instead of #include barfage)? There goes another. The const keyword? There's another. Or better yet, pick a language where it would be redundant. Restrictions on naming that differentiate between values and types? There's more refinement to the namespacing problem. Isolation of side effects? Solves another one. I think that's coming to C# soon, in a primitive way. Type system-based descriptions of side effects? Ooooh. Statically typed software transactional memory?
That are not the class of software engineering problems Im talking of. I would rather call them programming problems. And I disagree with maxorator: Im convinced they must be solved, too. But they help not much with the problems building todays complex software projects I mentioned in my former post. Garbage collection or namespaces does nothing to verify a design for example or to transform a design straight forward into something executable nor does it help to get changes from the executable back to the design/spec and so on.

maxorator
08-13-2007, 04:39 AM
I just haven't seen any actually useful features in new languages. Of course it's possible to create really useful features, but I haven't heard of such yet. But there are too many new languages coming without any improvements, there should only be another language if it really solves problems of programming, not problems of lazyness.

C++ was one good step to resolve problems related to extremely complex applications, but the new programming languages use the same features, add unnecessary features and slow the thing down. I haven't seen ANY progress since C++.

Mad_guy
08-13-2007, 07:32 AM
Garbage collection - Yikes... never heard of freeing memory? When you allocate memory for an object, structure or buffer, why not free that memory when you don't use it anymore? It's as simple as that. Garbage collection is an "alibi" to do careless programming.
You have no idea what you are talking about. Garbage collection is there to alleviate the pains of programming; memory management is one of those things.

You talk as if you program flawlessly (which, I can assure you of something: you don't,) and talk of other people as if they don't.
If it's so simple, why are you not leading the revolution in software design? So far, your solution looks like nothing more than just "dealing with what we have now, because it's the best solution to the problem and always will be." This is one of the most asinine things I have heard in a very long time.

Truly, if this is the way to reason about software, you will be famous for pointing it out for a very long time.

Sadly, I can assure you you're wrong.


Most of the stuff you mentioned doesn't give any real advantages. They just teach us bad habits like always giving the functions the same names in libraries, not freeing memory, making stupid mistakes etc.
Now I'm quite certain you have absolutely no idea what you're talking about. Did you even read his post or, if you did, did you understand any of it (especially relating to types and transactional memory)? He listed plenty of good examples that help write software.

Want a really, really good example? A very strong type system as seen in a language like Haskell or ML. This can help reduce the number of bugs in your programs to such an extent, you would be amazed.

Case example: I am currently writing an IRC bot in haskell that has the advantage that you can write a plugin for it (in haskell,) and the plugin will be dynamically loaded into the system on startup. Generally, you could consider plugins a point of failure because they are prone to have errors (NULL pointer anyone?) You have to reason about them carefully since in an extensible system offering this functionality, you're asking bugs to creep in through user-provided plugins.

On the contrary: the plugins system works so well that I've already moved almost every bot command into a plugin of it's own which has resulted in reduced complexity and boilerplate, at the expense of a little refactoring. What happens if a plugin is wrong or there's something incorrect about it? It doesn't load, because the compiler will catch the type errors at compile time and alert you about it. What happens when it does load? It works almost flawlessly upon the first activation. Every single expression has a very strict type, and unless all the types in the program fit together in a sound manner, they won't compile.

This is not to say the plugins never have errors; indeed, the bot can fail for example if you try to take the head element from an empty list (and this isn't something you cannot reason about at compile-time, since it may very well depend on an external state.) However, the type system makes reasoning about them and how they should execute *a lot* easier, and it also ensures my plugins are at the very least, safe.

I would also bet that if I wrote the equivilant bot in C, the amount of bugs would have been much higher than the haskell alternative.
The silly thing is, I'd say ~95&#37; of those bugs would have been caught at compile-time in haskell, because they would manifest at the type level.

Conclusion: a strong type system reduces program bugs by an incredibly effective amount. This is a pretty big 'real advantage,' no matter what way you look at it.

Here's another really good example: Software Transactional Memory. This solves the problem of synchronization and locking based solutions in multi-threaded programming. The solutions we use now such as mutexes and locks are archaic and while proven to work [sometimes], are still quite error prone. STM solves this problem very elegantly, and indeed, this is a very important topic, considering multi-core programming is not an option, but is more of a requirement these days if we wish to increase our performance and thoroughput.

Conclusion: STM solves a lot of issues with multi-threaded programming (and additionally removes much complexity) and allows more composable, reliable concurrent software. This is a 'real advantage.'


What's ruining the art of programming is that people are taught to do what would otherwise be mistakes and software has to hunt&kill them. Why not write good code?
Because humans aren't flawless and we make errors. Stop speaking of yourself as omnipotent or something. You're far from the perfect programmer, I hate to inform you.


Nowadays most performance goes to runtime environments or CRT checking if you have made stupid mistakes. Why not spend performance for the reason that the application was designed for?
Why make your life harder and waste your time bug hunting, when a simple runtime or type system can automatically give you guarantees and make your life easier?

I think you're under some [very] misguided assumption that to be a programmer, you should do everything yourself. Trusting any sort of abstraction just means you aren't a programmer, and you're ruining programming entirely. I think you should look at one of the greats of computing on this note:

"Being abstract is something profoundly different from being vague... The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise." - E. Dijkstra



When disassembling some programs programmed in high-level languages, I can clearly see that the code that the application actually was meant to do makes a small portion of the code that runs for every function. Visual Basic even adds "jo xxxxx" (if calculation overflow, then jump to exception handler, it triggers when doing unsigned INT_MAX+1, which results in 0) after almost every other assembly instruction. And MSVC++ compiled executables call a complex checking in the beginning and in the end of every function, not mentioning that it calls the checker many-many more times during the function depending on what it does.

Anyone care to do MD5 benchmarking for example in C# and then compare it with C and Assembly? You'll be surprised.

This has nothing to do with anything you've said above. It doesn't even prove a point. I am quite convinced you have no idea what you're talking about; if you were a programmer working for me, I can almost assure you you'd be out of a job pretty quickly. I'd want programmers who embrace new things, not ones who arrogantly disregard all that is not perfect as deemed by them. If you didn't read or understand anything else I said, at least ponder on that note for a little while.

jwenting
08-13-2007, 07:44 AM
Given that F# already exists, someone seems to have forgotten E and using D is way outdated :)
Of course J# also exists, and actually predates F#.

maxorator
08-13-2007, 08:02 AM
You talk as if you program flawlessly (which, I can assure you of something: you don't,) and talk of other people as if they don't.
If it's so simple, why are you not leading the revolution in software design? So far, your solution looks like nothing more than just "dealing with what we have now, because it's the best solution to the problem and always will be." This is one of the most asinine things I have heard in a very long time.
Debuggers need to do the same job once what a run-time environment does every time you run the application.

Mad_guy
08-13-2007, 08:45 AM
Debuggers need to do the same job once what a run-time environment does every time you run the application.

The fact of the matter is, a runtime environment encapsulates a lot more than what a debugger does; they're completely different things. You have to be aware of a bug to put a debugger to any use (given this context.)
If you, for example, have a program written in C that has a bug, say, it writes to an array one element out of bounds, it might not manifest itself in any meaningful way given a certain range of inputs while with others, it very well may. With a runtime doing your checking, you are guaranteed it will always catch the invalid memory access, regardless of the input, regardless if it's 'visible' as far as you're concerned, as long as it happens. It still gets caught. The runtime just made sure something very bad like arbitrary code execution didn't happen.

You're doing nothing more than completely avoiding the point under the garb of 'efficiency.' These arguments do not work, and personally, I would rather have the runtime throw me an array out of bounds exception than simply have the bug go unnoticed and/or have it manifest in some arcane or possibly volatile and destructive way. I would also much rather be correct and have it take a little more time, than be flawed and have it go fast.

maxorator
08-13-2007, 08:59 AM
Trying to write to the code section should trigger a general protection fault. Trying to write to an unallocated memory will certainly fail too. And data is usually in the data section, which is after the code section.

The example you brought is a serious mistake. I usually double-check the allowed ranges when dealing with arrays.

Mad_guy
08-13-2007, 10:05 AM
Trying to write to the code section should trigger a general protection fault. Trying to write to an unallocated memory will certainly fail too. And data is usually in the data section, which is after the code section.
What you said does not apply to local variables that're allocated on the stack (which is where my example fits in.) In this case, writing to a variable outside of bounds is perfectly 'legal' and will it will cause undefined behavior (of which an access violation is certainly a possibility. Writing to an array outside it's bounds is a common programming error and vulnerability.)

Example:


[austin@continuum ~]$ cat > test.c
int main() {
int test[5];
test[7] = 1;
return 0;
}
[austin@continuum ~]$ gcc-3.4 test.c
[austin@continuum ~]$ ./a.out
[austin@continuum ~]$ echo $?
0
[austin@continuum ~]$
(Note, I'm using gcc-3.4 here because my gcc (4.2.1) on this system is currently broken (most likely a binutils incompatability I need to work out,) not because it just suits my case in point or anything.)

This is what I'm talking about. I think you need to refresh yourself on how things like memory layout are typically done in a C-written program (and probably more about binary executable formats in general, too.)


The example you brought is a serious mistake. I usually double-check the allowed ranges when dealing with arrays.
Yes, that's good for you. But no matter what you say, the runtime can do a better job of making sure your memory writes are *inside* array bounds than you can when dealing with this sort of stuff manually, I can guarantee you (why? Because that's its job. It has far more intimate knowledge about how the memory is managed internally than you do, so don't fool yourself into thinking you could really do a better job manually than it does automatically. The people who designed these types of environments are not stupid, no matter what you'd like to think.)

maxorator
08-13-2007, 10:28 AM
This is what I'm talking about. I think you need to refresh yourself on how things like memory layout are typically done in a C-written program (and probably more about binary executable formats in general, too.)
I know what you're talking about. And as a reverse engineer I have quite a good idea how the memory layout works. Though I didn't assume you were talking about local variables, because it is not a good idea to allocate large arrays as local variables and with smaller arrays it's not likely to make a mistake like this.

Yes, that's good for you. But no matter what you say, the runtime can do a better job of making sure your memory writes are *inside* array bounds than you can when dealing with this sort of stuff manually, I can guarantee you (why? Because that's its job. It has far more intimate knowledge about how the memory is managed internally than you do, so don't fool yourself into thinking you could really do a better job manually than it does automatically. The people who designed these types of environments are not stupid, no matter what you'd like to think.)
Of course they knew what they were doing when they designed the run-time environment. But if most of the bugs could be detected on compile-time, then why do we need the run-time environment to deal with the rest 5&#37;? If a programmer learns from his mistakes then he will very soon learn to avoid these mistakes. There aren't very much different common mistakes.

Critical bugs should be caught while testing the program. Using a run-time environment is like publishing a debug version of the program.

laserlight
08-13-2007, 10:43 AM
Namespaces - what do they solve? I don't think you'll have so many functions that you run out of letter combinations for a function.
They allow one to use names appropriate for the domain model, even when the name is already in use, without always having to resort to some (library) prefix, assuming appropriate use of using declarations and directives.


They just teach us bad habits like always giving the functions the same names in libraries
I do not see how naming appropriately is a bad habit. Convoluted naming, on the other hand (letter combinations?), is a bad habit.


Const keyword - the most useless thing on earth. If I want a value not to be changed, why not use macros?
It looks like you are overlooking the fact that const is not just used to declare constants, but also as a design mechanism to inform users of a function that an argument passed by reference will not be changed, or to enforce no changes to an argument passed by value. Macros do not respect scope and are not typesafe.


And who would be that stupid to accidentally modify a variable which is not supposed to be modified.
A future maintainer of the code, which may well include yourself coming back to maintain your own code.

Mad_guy
08-13-2007, 11:36 AM
Of course they knew what they were doing when they designed the run-time environment. But if most of the bugs could be detected on compile-time, then why do we need the run-time environment to deal with the rest 5&#37;?

See above:

The fact of the matter is, a runtime environment encapsulates a lot more than what a debugger does...
This includes things like thread management (in the case of green threads,) resource utilization, profiling and garbage collection.


Look, my point isn't that you "catch all bugs," the point of my previous (long) post was that we catch a substantial amount with them with an addition like a strong type system. You said in Rashakil's post he didn't really outline anything that was 'useful,' when in fact, he did. He pointed out a few of REALLY useful things. And even this isn't my overall point, see below.



Critical bugs should be caught while testing the program. Using a run-time environment is like publishing a debug version of the program.
This comparison makes absolutely no sense, you're simply refusing to get the point of what I'm telling you: that these additions do make writing software easier and they do solve some problems with software development.

Do they solve them all? No. There is no silver bullet.

Do they help? Most certainly. That is my overall point, and you are simply stinting progress by saying things like this do not help and they're just a way to justify "careless" programming, and it's obvious you will never understand that until you have first hand experiance with it.

All you're advocating that programmers "don't need help, they just need to suck less." This is the completely wrong approach to the whole situation, since there are more factors to it than your software "being written."
Development time, safety, scalability, code quality, reusability, functionality, expressiveness. If we want to acheive these things, we have to make progress and move forward and adopt new ideas, rather than just be stubborn and 'hardcore' by using outdated, unsuited, unreliable and, to be honest, stupid development tools (note that I'm not pointing fingers here, I'm merely speaking in general.) No matter what way you paint it, a pig wearing lipstick is still a pig. You are doing nothing other than halting progress by saying these things, which, fyi, do make writing software easier "aren't needed." If there is a better textbook definition of "halting progress" than this, please, point it out to me.



Software development is hard. It always will be hard, and there probably won't ever be a clean cut solution to the whole deal. But we can be smart and adopt new ideas and techniques to make the process easier and the quality better overall. That's called progress.

Would you also advocate the use of wood to build skyscrapers and say that steel isn't needed, people just need to learn how to "build things better"?
Didn't think so.

Rashakil Fol
08-13-2007, 02:52 PM
Garbage collection is an "alibi" to do careless programming.

Garbage collection lets you turn subroutines into functions.


Most of the stuff you mentioned doesn't give any real advantages.

Any nontrivial non-real-time problem can be solved in 1/5 the time by me using Haskell than by me or you using C.

robwhit
08-13-2007, 03:06 PM
Garbage collection lets you turn subroutines into functions.C doesn't have garbage collection and it has functions.

what do you think the difference is between a subroutine and a function?

Rashakil Fol
08-13-2007, 03:14 PM
C doesn't have garbage collection and it has functions.

what do you think the difference is between a subroutine and a function?

I'm not using C terminology. I mean you can write functions and use them as functions (in the mathematical sense) instead of using them like subroutines.

maxorator
08-13-2007, 03:17 PM
I just typed www.dprogramming.com into my address bar and guess what I got - the D programming language!


Would you also advocate the use of wood to build skyscrapers and say that steel isn't needed, people just need to learn how to "build things better"?
Didn't think so.
Those extra features doesn't make the program "stronger", I think performance is close to stronger than "repairing the skyscraper every day". Anyway, let's cut the crap - we just have different opinions and that won't change anyway. Let's concentrate to the meaning of this thread - enterntainment. ;)

Mad_guy
08-14-2007, 03:53 AM
Those extra features doesn't make the program "stronger", I think performance is close to stronger than "repairing the skyscraper every day".
So... You'd rather run really fast and do it in a shakey, non-reliable manner (you might not even get to the finish line, mind you) than go somewhat slower and be correct? Be composable and extendable? I fail to see how being wrong helps anybody, regardless how fast you come to the conclusion. I'd rather have my program spend an extra 5 seconds doing something internally with the runtime (GC, proper thread synchronization using STM, etc) than just leak memory, have a deadlock or just crash. I'm pretty sure the people who use my program would feel the same way.

I'll agree to disagree at this point, but I still wonder why you would rather go fast than be a little slower but be more composable, reliable and modular. Speed is not the same as strength.

maxorator
08-20-2007, 04:20 AM
So... You'd rather run really fast and do it in a shakey, non-reliable manner (you might not even get to the finish line, mind you) than go somewhat slower and be correct? Be composable and extendable? I fail to see how being wrong helps anybody, regardless how fast you come to the conclusion. I'd rather have my program spend an extra 5 seconds doing something internally with the runtime (GC, proper thread synchronization using STM, etc) than just leak memory, have a deadlock or just crash. I'm pretty sure the people who use my program would feel the same way.
First debugging... then testing... then testing again... then releasing beta version. Just a hint. ;) I know what you're going to say (that it still may have some mistakes AND/OR that some time of developing could be saved not doing those things) and then you know what I will say (that a long process like that will definitely catch every critical bug AND/OR though it runs, the bugs will probably cause the program to behave not the way it should). Why? I mean why bother saying that? We know what the other will say, we know what are our opinions. Let's just enjoy ourself and have fun. :)

Any comments about the D language? :D

Mario F.
08-20-2007, 08:49 AM
I found it useless for my needs.

indigo0086
08-20-2007, 09:01 AM
wow, you're ususally insatiable.