Linked by snydeq on Sun 11th Dec 2011 01:35 UTC
General Development Fatal Exception's Neil McAllister writes in favor of new programming languages given the difficulty of upgrading existing, popular languages. 'Whenever a new programming language is announced, a certain segment of the developer population always rolls its eyes and groans that we have quite enough to choose from already,' McAllister writes. 'But once a language reaches a certain tipping point of popularity, overhauling it to include support for new features, paradigms, and patterns is easier said than done.' PHP 6, Perl 6, Python 3, ECMAScript 4 -- 'the lesson from all of these examples is clear: Programming languages move slowly, and the more popular a language is, the slower it moves. It is far, far easier to create a new language from whole cloth than it is to convince the existing user base of a popular language to accept radical changes.'
Order by: Score:
Do I agree or not?
by Alfman on Sun 11th Dec 2011 02:25 UTC
Alfman
Member since:
2011-01-28

I find myself agreeing with all this author's supporting evidence, and yet I'm leaning away from his conclusion. No, I don't think we need yet another new language syntax.

Personally I'd rather work on a way to make existing languages more interoperable to make the choice of languages less restrictive.

Reply Score: 5

RE: Do I agree or not?
by WorknMan on Sun 11th Dec 2011 03:55 UTC in reply to "Do I agree or not?"
WorknMan Member since:
2005-11-13

I find myself agreeing with all this author's supporting evidence, and yet I'm leaning away from his conclusion.


Yeah, me too. He does a good job outlining the problem, but I can't agree with the solution he proposes. I don't know if I have a solution myself, except to say that for me personally, the biggest pain in the ass part about learning a new language is learning the APIs/framework behind it. For example, C# is not a hard language to learn, but the .NET framework is a monster.

Thus, I think we should work towards standardizing the APIs/frameworks, then there could be 3,000 different programming languages, and you could hop from one to the other with relative ease.

Reply Score: 4

RE[2]: Do I agree or not?
by JAlexoid on Sun 11th Dec 2011 04:25 UTC in reply to "RE: Do I agree or not?"
JAlexoid Member since:
2009-05-19

The ironic part is that without the standard libraries modern languages are useless. Any language is pretty much of the same effectiveness, when all standard libraries are removed from comparison.

Reply Score: 2

RE[3]: Do I agree or not?
by snowbender on Sun 11th Dec 2011 09:55 UTC in reply to "RE[2]: Do I agree or not?"
snowbender Member since:
2006-05-04

The ironic part is that without the standard libraries modern languages are useless.

Don't completely agree, but standard libraries are definitely very important these days.

Any language is pretty much of the same effectiveness, when all standard libraries are removed from comparison.


I definitely don't agree with this. Any object-oriented language is pretty much of the same effectiveness, that I can live with. But, still, support for for example closures makes a big difference in effectiveness for particular problems. Functional or declarative languages are also more effective solutions for particular problems.

Even if you don't consider standard libraries, there are very good reasons for chosing different languages for different types of problems.

Reply Score: 4

RE[4]: Do I agree or not?
by JAlexoid on Sun 11th Dec 2011 16:14 UTC in reply to "RE[3]: Do I agree or not?"
JAlexoid Member since:
2009-05-19

When coding will be 80% of the time a developer spends during software development, then I will agree.
But currently coding is 20% of the time, unless you are inexperienced developer that likes to make his on mistakes.

Reply Score: 2

RE[5]: Do I agree or not?
by snowbender on Sun 11th Dec 2011 20:38 UTC in reply to "RE[4]: Do I agree or not?"
snowbender Member since:
2006-05-04

When coding will be 80% of the time a developer spends during software development, then I will agree.
But currently coding is 20% of the time, unless you are inexperienced developer that likes to make his on mistakes.


Hmm.. if an experienced developer only spends 20% of the time on coding, then what does he do the remaining 80% of the time?

Reply Score: 2

RE[6]: Do I agree or not?
by tchristney on Sun 11th Dec 2011 23:06 UTC in reply to "RE[5]: Do I agree or not?"
tchristney Member since:
2005-09-21

Keeping the inexperienced developers from marching the project towards disaster.

Reply Score: 1

RE[7]: Do I agree or not?
by snowbender on Sun 11th Dec 2011 23:49 UTC in reply to "RE[6]: Do I agree or not?"
snowbender Member since:
2006-05-04

Hmm... either you have way too many inexperienced developers on your team, or either you need to replace those inexperienced developers with better inexperienced developers.

Reply Score: 2

RE[6]: Do I agree or not?
by theosib on Mon 12th Dec 2011 16:20 UTC in reply to "RE[5]: Do I agree or not?"
theosib Member since:
2006-03-02

Let's seeā€¦

Architecting
Thinking about a good way to go about coding
Testing
Debugging

Reply Score: 2

RE: Do I agree or not?
by jessta on Sun 11th Dec 2011 07:50 UTC in reply to "Do I agree or not?"
jessta Member since:
2005-08-17

No, I don't think we need yet another new language syntax.


New syntax isn't important. If the differences between programming languages were just syntax then it would be very easy to convert between them and have them interoperate.

We need languages with different semantics.

Reply Score: 5

Browser languages
by yourpalal on Sun 11th Dec 2011 02:33 UTC
yourpalal
Member since:
2011-04-15

This is exactly why we need something JVM-ish in the browser. It doesn't have to be a JVM, maybe even a restricted subset of ECMAScript that can be heavily optimized, which would act as a compile target for other languages. As it stands, updates to JS take too long, and will be unsupported on older browsers.. what's the point?

Any programmer worth his salt knows that you pick the tools based on the job you're doing, and right now, the only choice for web development is JS. While JS works fine for some tasks, it isn't well suited for every single thing you might want to run in a browser, and it never will be.

Reply Score: 2

RE: Browser languages
by Alfman on Sun 11th Dec 2011 03:05 UTC in reply to "Browser languages"
Alfman Member since:
2011-01-28

yourpalal,

"Any programmer worth his salt knows that you pick the tools based on the job you're doing, and right now, the only choice for web development is JS. While JS works fine for some tasks, it isn't well suited for every single thing you might want to run in a browser, and it never will be."

Yes I agree. I often wish we could write code that could run equally well between the server and browser, and even as a native app on the desktop. It sucks having to write code in multiple languages between a client and server to handle web pages. I've even contemplated using javascript on the server to avoid logic duplication.

JVM-like technologies benefit from native performance and the same code can be used on the server, client, desktop, anywhere. It would open up new possibilities, such as freezing an application on the desktop, serialising it, and transferring it to run natively on a tablet. Javascript just isn't up to the task and never will be.

Of course, this kind of power under end user control would scare the crap out of companies promoting walled gardens. So we're probably stuck with less powerful javascript for a while longer.

Reply Score: 3

RE: Browser languages
by Shannara on Sun 11th Dec 2011 03:10 UTC in reply to "Browser languages"
Shannara Member since:
2005-07-06

"Any programmer worth his salt knows that you pick the tools based on the job you're doing, and right now, the only choice for web development is JS. While JS works fine for some tasks, it isn't well suited for every single thing you might want to run in a browser, and it never will be."

Uhh.. Unless you mean something else other then what you type. This simply is not true. I could name at least 5 other languages that you can use for web development that is much more common then JS.

Reply Score: 1

RE[2]: Browser languages
by Alfman on Sun 11th Dec 2011 03:24 UTC in reply to "RE: Browser languages"
Alfman Member since:
2011-01-28

Shannara,

It was pretty clear to me he meant in the browser, where the choice of built in languages is indeed limited to javascript.

Edit: Although, now that I think about it, many years ago IE did support vbscript too.

Edited 2011-12-11 03:26 UTC

Reply Score: 2

RE[2]: Browser languages
by JAlexoid on Sun 11th Dec 2011 04:26 UTC in reply to "RE: Browser languages"
JAlexoid Member since:
2009-05-19

For a browser?

Reply Score: 2

RE[2]: Browser languages
by yourpalal on Wed 14th Dec 2011 23:19 UTC in reply to "RE: Browser languages"
yourpalal Member since:
2011-04-15

Uhh.. Unless you mean something else other then what you type. This simply is not true. I could name at least 5 other languages that you can use for web development that is much more common then JS.


I'd love to be proven wrong, what 5 languages are used client side more than JS? I'll accept languages that compile to JS in your list too.

I know Python can be compiled to JS, and Java through GWT, but I'm pretty sure that straight-up JS is still the #1 client-side language.

Reply Score: 1

RE: Browser languages
by snowbender on Sun 11th Dec 2011 10:12 UTC in reply to "Browser languages"
snowbender Member since:
2006-05-04

I like what you say. Browsers should natively support the execution of a certain type of bytecode, and come with a standard library. Instead of specifying that a browser support this version of JavaScript, we would just say that it supports this version of the bytecode, and this version of a standard library.

That way, anyone is free to write a compiler from his favorite language to bytecode that is supported on a browser.

The thing that bothers me, is that JavaScript is a language that is very hard to execute efficiently. And in the beginning when JavaScript was used for very simple stuff, that was fine. Nowadays, people try to build full-blown desktop applications in the browser, and the result is that so much time and energy is put into trying to execute JavaScript efficiently.

Can you imagine where we would be right now, if in the beginning one would have supported a specific bytecode set instead of JavaScript? In a way, nowadays we actually do use "JavaScript" as some kind of intermediate code (not really bytecode, but close) with for example GWT that just compiles Java code into JavaScript code: going from a language that as of today can be executed very efficiently into something that is hard to execute efficiently, and then trying to optimise the hard-to-optimise JavaScript.

Reply Score: 3

"Better" vs. Better
by Brendan on Sun 11th Dec 2011 04:50 UTC
Brendan
Member since:
2005-11-16

Hi,

Just because something is "better" doesn't mean it justifies the costs involved with changing from existing working solutions (developing new tools, retraining programmers, remembering a wide variety of different languages just to be able to maintain old code, etc).

To actually be better (rather than just "better"), something needs to be so much better that the costs of change is justified.

Existing languages aren't perfect, but they are "good enough". Slightly better is possible, but so much better that it's worth changing is (almost?) impossible.

Basically, new languages are advocated by (and adopted by) short-sighted morons - people who only see "better" and fail to recognise or account for the costs of change they inflict on their peers and the industry as a whole. These people need to be hunted down and forced to pay for what they have done. ;)

- Brendan

Reply Score: 3

RE: "Better" vs. Better
by lucas_maximus on Sun 11th Dec 2011 11:54 UTC in reply to ""Better" vs. Better"
lucas_maximus Member since:
2009-08-18

Totally agree, You should never do a rewrite on a piece of software because you instantly lose years worth of effort.

Reply Score: 2

RE[2]: "Better" vs. Better
by ilovebeer on Sun 11th Dec 2011 17:54 UTC in reply to "RE: "Better" vs. Better"
ilovebeer Member since:
2011-08-08

Totally agree, You should never do a rewrite on a piece of software because you instantly lose years worth of effort.

If all those years of effort took the software in the wrong direction and wound up crippling it more than helping it for future expansion, then yes, a complete rewrite is certainly the better option.

There's one constant that you should always consider as much as possible -- progression. If you want your language to survive the test of time, it not only needs to be good, it needs to be expandable/extendable. That is a key element in it's basic design. If you ignore it, you will pay the price later.

Reply Score: 1

RE[3]: "Better" vs. Better
by Delgarde on Sun 11th Dec 2011 21:51 UTC in reply to "RE[2]: "Better" vs. Better"
Delgarde Member since:
2008-08-19

"Totally agree, You should never do a rewrite on a piece of software because you instantly lose years worth of effort.

If all those years of effort took the software in the wrong direction and wound up crippling it more than helping it for future expansion, then yes, a complete rewrite is certainly the better option.
"


Even so, rewrites kill companies. No matter how painful it is to stick with the existing version, that's the version that's paying the bills.

It's all very well assigning developers to do the complete rewrite that in five years time will make everything better. But if you're spending all the effort on the rewrite instead of on keeping the old product going, well... you probably won't still be around in five years time.

Reply Score: 2

RE[4]: "Better" vs. Better
by ilovebeer on Mon 12th Dec 2011 04:19 UTC in reply to "RE[3]: "Better" vs. Better"
ilovebeer Member since:
2011-08-08

Even so, rewrites kill companies. No matter how painful it is to stick with the existing version, that's the version that's paying the bills.

It's all very well assigning developers to do the complete rewrite that in five years time will make everything better. But if you're spending all the effort on the rewrite instead of on keeping the old product going, well... you probably won't still be around in five years time.

That makes some big assumptions:

-that the software actually is paying the bills
-that it will take substantial time to do a working rewrite
-that the current troubled version is still usable and meeting the required needs

If all of that is true, I would tend to agree. If any of them are false, I can't say the same.

Reply Score: 1

RE[3]: "Better" vs. Better
by lucas_maximus on Mon 12th Dec 2011 11:02 UTC in reply to "RE[2]: "Better" vs. Better"
lucas_maximus Member since:
2009-08-18

I worked at one company where they decided they were going to rewrite the old product from scratch. 1 year later they had a product that they couldn't sell to anyone, while the old product with all of it problems the clients still wanted.

The old product is still going and has been bought by new customers and is still paying the bills. If the amount of effort for the rewrite had been spent refactoring the product ... It would probably would have none of the performance problems it currently has.

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that's kind of gross if it's not made out of all new material?

Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

http://www.joelonsoftware.com/articles/fog0000000069.html

Edited 2011-12-12 11:08 UTC

Reply Score: 2

RE[4]: "Better" vs. Better
by ilovebeer on Mon 12th Dec 2011 17:22 UTC in reply to "RE[3]: "Better" vs. Better"
ilovebeer Member since:
2011-08-08

I worked at one company where they decided they were going to rewrite the old product from scratch. 1 year later they had a product that they couldn't sell to anyone, while the old product with all of it problems the clients still wanted.

The old product is still going and has been bought by new customers and is still paying the bills. If the amount of effort for the rewrite had been spent refactoring the product ... It would probably would have none of the performance problems it currently has.

The only thing that proves is that the rewrite was poorly handled. For every case where a rewrite was a disaster, you have a case where it was a great success and the old version was treated with good riddance.

If you create a new piece of crap, all you have is a new piece of crap. The problem isn't that you made something new, it's that you made it a piece of crap.

Reply Score: 1

RE[5]: "Better" vs. Better
by lucas_maximus on Mon 12th Dec 2011 19:12 UTC in reply to "RE[4]: "Better" vs. Better"
lucas_maximus Member since:
2009-08-18

The only thing that proves is that the rewrite was poorly handled. For every case where a rewrite was a disaster, you have a case where it was a great success and the old version was treated with good riddance.


If you have something working, it is ridiculous to do a full rewrite. The only time I can see it making sense if the current platform is going to be depreciated, or fundamental core changes need to be made.

Re-factoring and rewriting modules is fine. Slowly changing the architecture is okay as well. It is pretty easy to do this after a few iterations.

If you create a new piece of crap, all you have is a new piece of crap. The problem isn't that you made something new, it's that you made it a piece of crap.


Agreed, but that doesn't mean that rewriting a working application is a good idea because it might be better in the future.

Many of the weird logic the applications have are there for very good reasons.

Reply Score: 2

RE[6]: "Better" vs. Better
by ilovebeer on Tue 13th Dec 2011 10:30 UTC in reply to "RE[5]: "Better" vs. Better"
ilovebeer Member since:
2011-08-08

If you have something working, it is ridiculous to do a full rewrite. The only time I can see it making sense if the current platform is going to be depreciated, or fundamental core changes need to be made.

I'm not talking about doing rewrites when there's no need for it. When you have poorly designed software that's in a constant state of maintenance, you can reach a point where maintaining it and dealing with the poor design is no longer the best option -- when too much time and too many resources are being committed just to keep it working. In these cases a proper rewrite can easily be the best solution if the end result is relieving the time & resources being spent.

The people who are saying that a rewrite is never a good choice and believe that there are never any circumstances which call for it, are completely nuts. They're either not coders, not good coders, never had to deal with resource management, or aren't good at it.

Reply Score: 1

RE[7]: "Better" vs. Better
by JAlexoid on Tue 13th Dec 2011 17:40 UTC in reply to "RE[6]: "Better" vs. Better"
JAlexoid Member since:
2009-05-19

I have a good example of a well written application that requires a total rewrite - lack of documentation leads to weird things happening in production.
In addition, rewrite will easily remove 80% of code from custom domain. It is not so much a rewrite, as it is distilling the application to the business features and letting the custom code be replaced by COTS or opensource code.

Reply Score: 2

RE[7]: "Better" vs. Better
by lucas_maximus on Tue 13th Dec 2011 18:18 UTC in reply to "RE[6]: "Better" vs. Better"
lucas_maximus Member since:
2009-08-18

When you have poorly designed software that's in a constant state of maintenance, you can reach a point where maintaining it and dealing with the poor design is no longer the best option[q]

Well I think that comes under core design changes ... such as what happened with Win9x vs WinNT.

[q]The people who are saying that a rewrite is never a good choice and believe that there are never any circumstances which call for it, are completely nuts. They're either not coders, not good coders, never had to deal with resource management, or aren't good at it


I not saying "NEVER EVER EVER" rewrite ... but in the vast number of cases I think it is better just to get the original requirements (if any) or map the behaviours and rewrite that particular module (i.e. Method in OOP) from scratch.

Reply Score: 2

RE[4]: "Better" vs. Better
by Neolander on Mon 12th Dec 2011 17:52 UTC in reply to "RE[3]: "Better" vs. Better"
Neolander Member since:
2010-03-08

I believe that "Do it right the first time" should become some kind of mantra for computer science.

Good code ages well and is easy to fix. It doesn't require rewrites.

The thing is, it takes a lot of mental discipline to actively apply this philosophy every day, including the worst ones, where you're lacking sleep and must ship something that is currently barely finished in one week.

Edited 2011-12-12 17:53 UTC

Reply Score: 1

RE[5]: "Better" vs. Better
by dnebdal on Mon 12th Dec 2011 17:56 UTC in reply to "RE[4]: "Better" vs. Better"
dnebdal Member since:
2008-08-27

I believe that "Do it right the first time" should become some kind of mantra for computer science.

Good code ages well and is easy to fix. It doesn't require rewrites.

The thing is, it takes a lot of mental discipline to actively apply this philosophy every day, including the worst ones, where you're lacking sleep and must ship something that is currently barely finished in one week.


The largest problem with this is the way good enough is sometimes best - a working but horribly coded project now has some benefits over a well-coded one later.

Reply Score: 1

RE[6]: "Better" vs. Better
by lucas_maximus on Mon 12th Dec 2011 19:16 UTC in reply to "RE[5]: "Better" vs. Better"
lucas_maximus Member since:
2009-08-18

I have written last minute hacks that have stood the test of time. Something working is a lot more convincing than vapourware that does work.

Edited 2011-12-12 19:19 UTC

Reply Score: 2

RE[5]: "Better" vs. Better
by lucas_maximus on Mon 12th Dec 2011 19:22 UTC in reply to "RE[4]: "Better" vs. Better"
lucas_maximus Member since:
2009-08-18

I believe that "Do it right the first time" should become some kind of mantra for computer science.


Oh comon, this is ridiculous. You can do sensible things the first time, but doing it "right" first time is a completely different matter.

I wrote a C# library the other day, a nice bit of OO programming. Very clean and encapsulated, today I found out a way to make it even cleaner ... While my first attempt was sensible ... tomorrow it will be perfect.

Reply Score: 2

RE[6]: "Better" vs. Better
by Neolander on Tue 13th Dec 2011 06:15 UTC in reply to "RE[5]: "Better" vs. Better"
Neolander Member since:
2010-03-08

It's not about writing perfectly clean code the first time you put your hands on a keyboard, it's about shipping perfectly clean code in the end ;)

Of course, if you have lots of time, you can experiment with low quality code before writing the real thing, and the more time you have the larger-scale these experiments can go (things like GSoC projects come to mind). However, everything that is released has fallen into a vicious circle that makes it much harder to fix unless it is very well coded to begin with.

TL;DR : Hackish cost is fast to write and a powerful research and testing tool, it should just not make its way to the final product IMHO.

Edited 2011-12-13 06:19 UTC

Reply Score: 1

RE[7]: "Better" vs. Better
by lucas_maximus on Tue 13th Dec 2011 11:35 UTC in reply to "RE[6]: "Better" vs. Better"
lucas_maximus Member since:
2009-08-18

TL;DR : Hackish cost is fast to write and a powerful research and testing tool, it should just not make its way to the final product IMHO.


No I agree, but you will always find better ways of doing something down the line.

Reply Score: 2

RE[4]: "Better" vs. Better
by Bill Shooter of Bul on Mon 12th Dec 2011 20:43 UTC in reply to "RE[3]: "Better" vs. Better"
Bill Shooter of Bul Member since:
2006-07-14

Absolutely agree. Refactor first, Rewrite in different language, only if everything else fails, or if its just a fun hobby.

Reply Score: 2

RE: "Better" vs. Better
by juzzlin on Mon 12th Dec 2011 12:18 UTC in reply to ""Better" vs. Better"
juzzlin Member since:
2011-05-06

Just because something is "better" doesn't mean it justifies the costs involved with changing from existing working solutions (developing new tools, retraining programmers, remembering a wide variety of different languages just to be able to maintain old code, etc).


I can't agree more ;) There are also a number of great application frameworks build on top of certain widely-used languages.

Reply Score: 1

Comment by OSbunny
by OSbunny on Sun 11th Dec 2011 07:47 UTC
OSbunny
Member since:
2009-05-23

Doesn't matter whether we need more languages or not. We are sure to get them! As the first comment to that article points out, making a language is easy and it can be a money making venture. So you are sure to see lots of new languages fighting for developers' attention. And developers also have to keep up with the skills arms race and learn whatever newfangled language/framework/API becomes popular.

Reply Score: 1

on the hardware/parallel side
by transputer_guy on Sun 11th Dec 2011 07:56 UTC
transputer_guy
Member since:
2005-07-08

I also believe that we are in need of newer languages for specific domains, but at the same time they need to be able to work with the current infrastructure so that the new language doesn't have to reinvent all the plumbing that current languages already do well. The new language can then be built quickly by adding a preprocessor or interpretive module to the tool mix just as the early C++ preproc did.

One example is to do math in Fortran and use F2C to merge the math code within a C system. Same with Matlab and others.

One weak area has always been concurrent programming of communicating processes over many processors or within hardware. When you model really large parallel systems, they look just like nested blocks of hardware logic where the processes might be software or hardware cells communicating with wires (hdl) or channels (occam/csp).

We can kind of hack around this with C++ classes like in System C which makes designing hardware really ugly. In the hardware field we already have Verilog and VHDL, for designing massively parallel systems but they don't really work well with C and cost big $ to use. The System C guys came along and said, you hardware guys can just use our C++ classes to model wires, events and so the hardware code would run in a free C simulation environment. What was not free was the tools to convert the SystemC description back to Verilog to make the hardware, money ruins it all.

I ended up writing my own primitive Verilog subset V2C that allows hardware logic to be written in almost pure Verilog and compile to C for cycle simulation and the same code could then go through normal hardware synthesis tools usually free for FPGAs, no $ at all.

Even to this day I don't think you can get this type of utility with out big bucks. I would like to have taken this further by combining subsets of Verilog and C+ to produce a smaller united language. In the Verilog syntax you describe the parallelism of logic blocks and signals and in the C syntax you write behavioral C functions to validate those blocks.

The first hardware description language I ever learnt for processor design was APL from the 60s and yet many old timers will know that was used for business software and likely just as incomprehensible.

Perhaps Go might be a useful tool for hardware guys since it has a far more natural syntax for describing block modules with multiple I/Os, still have to finish the tutorial.

just blabbering on

Reply Score: 3

RE: on the hardware/parallel side
by moondevil on Sun 11th Dec 2011 14:19 UTC in reply to "on the hardware/parallel side"
moondevil Member since:
2005-07-08

We can kind of hack around this with C++ classes like in System C which makes designing hardware really ugly. In the hardware field we already have Verilog and VHDL, for designing massively parallel systems but they don't really work well with C and cost big $ to use. The System C guys came along and said, you hardware guys can just use our C++ classes to model wires, events and so the hardware code would run in a free C simulation environment. What was not free was the tools to convert the SystemC description back to Verilog to make the hardware, money ruins it all.


Well, people do have to live from something.

Reply Score: 2

improve current languages
by fran on Sun 11th Dec 2011 15:07 UTC
fran
Member since:
2010-08-06

As someone that recently gotten interested in programming and doing a lot of reading on it, these influenced my decision.

Programming is hard to master. You got to have tutorial material, documentation, cookbooks ect.

Better to be real good in one or two relevant languages than mediocre in a lot.

Compilers and platform support.

Are there people who are going to be able to fix your code?

Are the enterprise going to have difficulty finding coders for that language?

Frameworks and IDE's

A publishing house for instance will be more interested in writing a PHP6 book than a new one obscure language.

I also expect a new version of a current language to be much easier to master than a totally new one.

My vote lends towards the improvement of the current languages. Although new language are very interesting.

Reply Score: 2

RE: improve current languages
by Neolander on Sun 11th Dec 2011 15:32 UTC in reply to "improve current languages"
Neolander Member since:
2010-03-08

And what would you think of in-depth redesigns of existing languages that keep similar concepts (may compile in the same object files or bytecode), but strongly rework syntax ?

Reply Score: 1

RE[2]: improve current languages
by fran on Sun 11th Dec 2011 15:55 UTC in reply to "RE: improve current languages"
fran Member since:
2010-08-06

Lots of frustration:-)
But there will probably be books and examples on it farly quickly compared to a totally new language.
But every single established language where brand new at one stage.

Reply Score: 2

RE[3]: improve current languages
by moondevil on Sun 11th Dec 2011 16:26 UTC in reply to "RE[2]: improve current languages"
moondevil Member since:
2005-07-08

If you have a proper computer science background you'll be able to pick new languages/concepts in no time.

The proper way is to master the concepts not the tools.

EDIT: missing word

Edited 2011-12-11 16:26 UTC

Reply Score: 2

RE[4]: improve current languages
by juzzlin on Mon 12th Dec 2011 12:23 UTC in reply to "RE[3]: improve current languages"
juzzlin Member since:
2011-05-06

If you have a proper computer science background you'll be able to pick new languages/concepts in no time.

The proper way is to master the concepts not the tools.



That's not the problem. As I see it, the problem is that you usually have a lot of re-usable code, classes, frameworks and engines written in some language and you'd have to re-write or port that code into the new language. And it would be a huge and wasted effort.

Reply Score: 1

RE: improve current languages
by l3v1 on Mon 12th Dec 2011 11:30 UTC in reply to "improve current languages"
l3v1 Member since:
2005-07-06

Better to be real good in one or two relevant languages than mediocre in a lot.


If you know what you're doing, the language doesn't really matter ***. As also said above, frameworks and libraries matter a lot more than the language itself. I can spend my time better than learning all language references by heart. If you can be good in a few, then it's ok to be superficial in others. And sometimes it's quite good to be at least superficially knowledgeable in a few others than your chosen ones, gives you insight and good ideas.

Edit: I'm correcting myself:
*** Except when it does, since there are situations where it's imperative to choose one language over the other.

Edited 2011-12-12 11:31 UTC

Reply Score: 2

Comment by pepper
by pepper on Sun 11th Dec 2011 21:36 UTC
pepper
Member since:
2007-09-18

"once a language reaches a certain tipping point of popularity, overhauling it to include support for new features, paradigms, and patterns is easier said than done"

Hm...what about Lisp style languages? The core is very simple and generic, and it is easy and efficiently extensible to support all the features of modern programming languages. And the result can be as fast as C/C++. From what I can see, Lisp is the king of DSLs, and there is no need to redesign everything all the time, just copy and improve macros to meet your current requirements.

Where other languages are build like a cathedral, monolithic and extensible only in ways that look distinctively different from the core language, Lisp is a bazaar where you can add and remove language capabilities as needed.

Reply Score: 1

RE: Comment by pepper
by JAlexoid on Tue 13th Dec 2011 17:45 UTC in reply to "Comment by pepper"
JAlexoid Member since:
2009-05-19

(((((((((((((((((Yes(I(agree)))))))))))))))))))

Reply Score: 2

Baggage
by torbenm on Mon 12th Dec 2011 09:58 UTC
torbenm
Member since:
2007-04-23

Old languages carry around a lot of baggage, and it is very difficult to get rid of this with language updates -- you can usually add features, but it is extremely hard to get users to accept that you remove any. Even minor syntactic changes can be hard to do. This gets worse as a language have more users.

A new language can be designed cleanly without having to worry about backwards compatibility, so you often get a cleaner design with fewer surprising corner cases. Also, you can avoid the cases where the new features interact badly with the old features.

I agree with the previous poster that libraries are important -- it is often a lot more work to write extensive libraries than it is to design and implement the language itself. But I also think libraries are in as much need of revision as languages. Languages tend to accumulate libraries and it is very difficult to get rid of the badly designed libraries once they are in widespread use. And it often isn't enough to rewrite the implementation of these, as it may be the APIs themselves that are badly designed.

Also, when libraries become too big, they hurt performance. The result is that a simple web application equivalent to a HTML form compiles to 2MB of code and requires 80MB to run.

Extensive libraries also makes programmers lazy: They would rather use a library that is a poor fit to their problem than coding a solution that is better suited, even if this would only need 20 lines of code. In fact, many so-called programmers aren't: They can't program, they can only string library calls together.

This is also why I think Java and its ilk are badly suited for teaching programming: In most cases your program is 90% library calls and 10% real programming, so students come to believe that programming is stringing library calls together. This is why CMU have dropped OO languages from the first year of their CS programme -- instead the students use Standard ML and a (fairly clean) C subset, both with fairly limited libraries.

Reply Score: 2

Several Reasons
by umlcat on Mon 12th Dec 2011 17:26 UTC
umlcat
Member since:
2011-12-12

I believe, there are several reasons why programming languages change. They are like people, born, mature, learn new things (add new features), and sometimes die.

I made a programming language designer tool, for my Graduate Thesis. Sort of user friendly, with pascal syntax, "Lex" alternative. Open Source Flex didn't exist, or existed, but, wasn't mainstream, yet.

It was in the middle 90's, Object Oriented Programming Languages where on the raise, 4GL's style like PowerBuiler and XBase where starting to leave the scene.

I have to defend to my thesis "judges" why my tool was need it, since there where already many programming languages (same topic that this post).

I arguee several things, but, the main idea was that technologies evolve, and change, and where not constant. That was before Browser Scripting Languages, and Functional Languages.

Reply Score: 2