Dart Is Not the Language You Think It Is

An anonymous reader writes "Seth Ladd has an excellent write-up of Dart: 'When Dart was originally launched, many developers mistook it for some sort of Java clone. In truth, Dart is inspired by a range of languages such as Smalltalk, Strongtalk, Erlang, C#, and JavaScript. Get past the semicolons and curly braces, and you'll see a terse language without ceremony. ... Dart understands that sometimes you just don’t feel like appeasing a ceremonial type checker. Dart’s inclusion of an optional type system means you can use type annotations when you want, or use dynamic when that’s easier. For example, you can explore a new idea without having to first think about type hierarchies. Just experiment and use var for your types. Once the idea is tested and you’re comfortable with the design, you can add type annotations."

Comments

There are two kinds of programming languages....

[Anonymous Coward]

Those people always bitch about and those no one uses.

Since I have yet to hear any complaints about Dart, I can only assume it's in the latter category and no one cares.

Sounds like

[Anonymous Coward]

the D

Re:Sounds like

[Anonymous Coward]

How tenacious.

Unadvantages!

[Shaiku]

Once the idea is tested and youâ(TM)re comfortable with the design, you can add type annotations.

I've been doing this with comments since 1999 and it works great! Of course I still haven't gotten around to that final step of going back and adding all those comments but I love the flexibility!

Unless you like bugs, type-checking is a good thing. Lack of type enforcement encourages what -- lack of forethought?

Re:Unadvantages!

[Anonymous Coward]

I get the same feeling, sounds good for just testing something quickly, but anytime it gets bigger it will turn into an ugly mess.

Re:Unadvantages!

[H0p313ss]

Once the idea is tested and youâ(TM)re comfortable with the design, you can add type annotations.

I've been doing this with comments since 1999 and it works great! Of course I still haven't gotten around to that final step of going back and adding all those comments but I love the flexibility!

Unless you like bugs, type-checking is a good thing. Lack of type enforcement encourages what -- lack of forethought?

Exactly, this is one of the things that crippled large smalltalk projects back in the day; it was almost impossible to figure out how to call someone elses code without invoking the wrath of doesNotUnderstand.

Re:Unadvantages!

[Nerdfest]

It lets you throw something together quickly for a proof of concept. After you throw in the type annotations the compiler, lets you know how sloppy you are and why you should use static typing. (YMMV, but generally not in a system of any serious complexity)

Re:Unadvantages!

[farble1670]

It lets you throw something together quickly for a proof of concept

the thing about type safety ... even if you use a non-type safe language, you still have to get it right or your crap will crash, or worse, run and do something unexpected. you still need to be type safe, it's just that you have to find all your bugs at runtime in stead of compile time. do we need to discuss why it's better to catch bugs at compile time?

Re:Unadvantages!

[Longjmp]

Unless you like bugs, type-checking is a good thing. Lack of type enforcement encourages what -- lack of forethought?

My thoughts exactly. Any language that makes you believe you can leave the "thinking" to the compiler is the wrong approach.
Might as well program the next Mars rover in PHP.

(not that PHP is bad as such, it just makes lazy programmers more lazy)

Re:Unadvantages!

[lennier]

Might as well program the next Mars rover in PHP.

Now that's just silly. Of course something mission-critical like a space probe won't be running PHP.

It'll be running jQuery on node.js.

what do you mean the latency from our data center on Pluto is lousy? look at the cost savings we get from the free cooling!

Re:Unadvantages!

[angel'o'sphere]

Well, fact is some people can live without type checking.

Some can't. (I'm more the second variant)

However analyzing the problem comes down to the point that I'm either a bad typer or a bad reader or both. Words like print, prnt, pirnt, even pront, prant, pfrint etc. look at the first glance the same for me. Ofc they all mean

print. However in a language like Smaltalk, Groovy or Python a statement like:
    a.pront("hey!")
will compile.
It will run even (to a certain point).
However, the problem above is not a "type problem". The runtime system knows that the method "pront" is not defined and will raise an error. The language etc. is still type save. Unlike the bad things you can do in C or C++ (like casting const away on a reference on the stack ... the thing I like most about programming is "casting". (Angel O'Sphere casts "fire ball" at the dragon. The dragon evaporats into smitheren! Muhuhuhaaaaa!)
Well, other people don't have my problem. they see a word as a word like a word and if the word seems odd they see their typo. Hence: they have no problme in programming in Lisp, Python or Groovy or Smalltalk.
Your idea about how types/typecheking work is a little bit wrong ...

Re:Unadvantages!

[angel'o'sphere]

How many not type safe languages do you know?

Re:Unadvantages!

[Nerdfest]

That's exactly what the latter part of my post was saying, although my sense of humour is apparently lacking. I have seen some nice work done in dynamically typed languages, but in general you need to unit test the living crap out of it (which you really should do anyway), and you can generally do the same thing with interfaces if you design well (single responsibility principle & interface segregation).

Re:Unadvantages!

[dreadway]

IMO the thing which crippled large Smalltalk projects was the corporate IT market embracing programming technologies which looked more like C. You had to fight hard to make Smalltalk code look like a procedural language, which a larger body of programmers were already used to. Java, C++, and C# look more like C, so I guess they have that going for them.

Smalltalk is a strongly-typed, late-binding language. Smalltalk's Object>>#doesNotUnderstand behavior is a hindrance for production-quality code only to the extent that your programmers are unwilling or unable to read and use someone else's API. Oh, and maybe your system design should not suck, no matter what programming technology is involved.

I worked for years as a Smalltalk programmer on big, corporate IT systems involving hundreds of programmers and handling hundreds of millions of $$$ per day in production, but corporate IT has had a mood swing and now our systems mostly use the early-binding programming technologies. I like being gainfully employed, but am not persuaded the tradeoffs of the extra code, convoluted syntax constructions, and tool paradigms actually represent any improvements. And finally, believe it or not, but the less senior programmers apparently have difficulty reading and understanding the code (even with its early-binding features) written by far more experienced programmers than myself, which in turn results in numerous and varied production defects. Who would have thunk it, eh?

Re:Unadvantages!

[narcc]

There are tons of them. Do a google search.

Re:Unadvantages!

[Waffle Iron]

How many not type safe languages do you know?

If you exclude assembly languages they're not very common, but examples include FORTH and BCPL.

Re:Unadvantages!

[angel'o'sphere]

You could easily add C :D (And even C++)

Re:Unadvantages!

[Laxori666]

The best is when you don't need to annotate the types, but you have type safety anyway, like Haskell. Unfortunately you can't have perfect type inference and subtyping in the same type system... The advantage of not having static types, though, is that it is a heck of a lot faster to program, as well as much easier to extend. You just have to be able to keep the design in your head.

Re:Unadvantages!

[Anonymous Coward]

not that PHP is bad as such, it just makes lazy programmers more lazy

I don't think you've programmed much in PHP. It is bad.

Re:Unadvantages!

[Anonymous Coward]

14

Re:Unadvantages!

[Anonymous Coward]

I don't understand why people say this. C has simple, strong type safety. But you can _explicitly_ subvert type safety by casting or using void pointers. Good C code rarely, if ever, should explicitly cast; and aside from malloc and free, void pointers are used sparingly.

There are issues with integer conversions, but most other supposedly "strongly-typed" languages also do implicit integer conversions. It's just that C has a much more rich and flexible native integer set, necessitated by needing to elegantly abstract machine types.

And you can't categorize memory and array bugs under type safety. That's a run-time issue, and there are C implementations that can detect those errors just as in any other language--e.g. using fat pointers.

Given that one of the very purposes of C is to manipulate raw data from all manner of sources and load it into typed objects, I'd say it does a fine job. Loading and parsing data in most other languages, especially strongly typed languages, is one of the most frustrating experiences a programmer could have. Usually you must use an API which part of the language implementation itself, which means there's no generic mechanism for loading and unloading untyped, external data.

Re:Unadvantages!

[Anonymous Coward]

In my experience, there is no such thing as a proof of concept or a prototype or whatever qualifier you have for something that isn't done, unless you only put it in front of other developers.

The moment you put a proof of concept in front of a PHB or other similar, their brain immediatly melts and the only though they can form is "oh look, it's already done!".

Never, ever count on being able to "go back later and _really_ implement it".

Of course, this is only a problem in poorly run organizations. Unfortunately, this in 99% of organizations.

Re:Unadvantages!

[alannon]

they have no problme in programming

Nope. No problme at all, I'm sure they'll see their typo.

Re:Unadvantages!

[stenvar]

Unless you like bugs, type-checking is a good thing. Lack of type enforcement encourages what -- lack of forethought?

Unless you like bugs, you actually test your code. Most dynamically typed languages have strong type checking. And with testing, that type checking ends up being pretty much as strict as static type checking.

JavaScript's problem is that it is weakly typed (or has badly defined default operators), not that it doesn't force you to annotate or declare your types.

Re:Unadvantages!

[Anonymous Coward]

However in a language like Smaltalk, Groovy or Python a statement like:

    a.pront("hey!")
will compile.
It will run even (to a certain point).

In a modern Smalltalk environment you actually will receive a warning if you try to accept code which uses something undefined. The problem is if "pront" is actually defined somewhere else....
Anyway in my experience tests are your only hope to manage whatever software large project, no matter the programming language. With type safety the big advantage is the ability to easily implement many safe refactorings which are much more complex otherwise.

Re:Unadvantages!

[Phillip2]

The problem with type checking is that sooner or later you want to do something that is very hard to type check. So, then you have to reinvent and extend the type system. If you look, for example, at Java which had a nice simple type system, but one that was too simple; now we have upper bound, wild card types in the generics, which I still don't fully understand and have to look up every time I want to use. Complicated.

It also tends to complicate the development process, so that you spend a significant amount of time declaring types, often ones which do essentially very similar things. Again, using a Java example, there is no straight-forward way to iterate over all the methods of a class (you have to use reflection). One of the other hand, with Javascript, a class is just a hash with first class functions. And hashes provide iterators because it is the sort of thing hashes do.

Finally, type checking tends to add syntax; Java, again, is an extreme example, Scala much less so. If you want to build a DSL, for example, then the added syntax of types is significant. What ends up happening is the developer produces a config file which the application parses. With a simpler syntax for the language, you can just use the language instead.

Type checking is a good thing, but it is one that comes at a cost. As with many areas of programming, it is a question of weighing the gains and the losses.

Re:Unadvantages!

[aiht]

they have no problme in programming

Nope. No problme at all, I'm sure they'll see their typo.

You do realise that GP was specifically pointing out that they personally do have this problem... right?

Re:Unadvantages!

[Xest]

"The advantage of not having static types, though, is that it is a heck of a lot faster to program, as well as much easier to extend. You just have to be able to keep the design in your head."

This is a myth, even if it were faster to type code you end up having to spend more time debugging because you're having to manually track down more awkward bugs. It's not faster to type code though because what you save in not declaring types, you lose in having to explicitly deal with conversion. For every int you don't type you have 10 more === you need to remember to type instead of == and so on.

Beyond that more bugs inevitably slip through, because things a compiler would've caught in a statically typed language only appear in edge cases at run time with dynamically typed languages.

It all gets worse the larger the project is too, the larger the project the more these sorts of issues arise and the greater the cost such that on large projects the gap between static vs. dynamic typing is massive and using a dynamically typed language will cost you dear.

I worked on such a 2 year project about a year back using PHP, it wasn't mine from the outset but I took it over about 18 months in and I had 5 very talented, very experienced contractors working on the project. We completed it on time and with a healthy profit margin but it could've been done so much sooner with such a larger profit margin if we'd been doing it using C# or Java - I wont pretend it's all because of dynamic typing, much of it was because PHP is shit and you have to implement hacks to work around it's lack of decent threading support and such but it was certainly a factor. I have absolutely no doubt that that project could've been done in 15 to 18 months using C# or Java and would've been of much higher quality. I'd argue that the higher levels of testing and longer we had to spend debugging cost us at least 1 month of that over using a statically typed language. Our 56% profit margin could've easily been a 70%+ profit margin.

Dynamically typed languages are okay for toy projects, or for internal quickly hacked together pieces of code for automation and so forth, and can also be good for scripting inside part of a larger application and that sort of thing but for full system development their worth rapidly diminishes for anything that's going to take more than a month or two to build.

Re:Unadvantages!

[sproketboy]

Nope. Smalltalk died because projects written in it were unmaintainable. Simple as that.

Re:Unadvantages!

[Anonymous Coward]

There are type assertion statements if you're into that kind of kinky stuff

Re:Unadvantages!

[Anonymous Coward]

Ruby

What is type "safety" anyways? I've done both post- and preconditions in Ruby even though it's not promoted as a "type safe" language. If you need real safety, it can be done, the language itself can be changed to accomodate most requirements and allow for much flexibility for the truly gifted (as well as promises of chaos created by the overintellectual).

It all depends on the project: how many are going to deal with the code and each member's level of expertise.
"Type safe" languages is really just a cruch for weak programmers and messy projects. Unfortunately, this is the "normal" in the business world.

For hobby projects, my best experience so far is with Ruby, ActiveRecord (not Rails, that's taking dynamicity too far IMHO) and Postgresql. No types, everything defined in-code, rapid development and minimum change and maintenance overhead. Last but not least, a very rare quality: It's both beautiful and pragmatic!

For my needs, I didn't need any "unit testing". Mostly because the code structure, names and control code abbreviations was in itself self-documenting. When the defaults are non-surprising and sane and superflous code kept to a minimum, bugs tend to be superficial compile errors, easy to locate and the serious ones, more high-level errors rather than code-rot needing de-bugging.

When you just want something done, this is the best bet I've found so far. Of course, you wouldn't want to extend this to larger projects without putting the proper policies and best pratices in place. However, for surprisingly many tasks, automation by scripting return the best ROI, provided you don't abuse the flexibility but plan ahead.

Re:Unadvantages!

[Anonymous Coward]

C has simple, strong type safety.

No. Try to put this in one file:

double f(double x) { return x*x; }

and this in another

#include <stdio.h>
 
int f(int x);
 
int main()
{
  printf("%i\n", f(1));
}

Then compile with C and link both files together. The compiler will not complain. The linker will not complain. That's not type safety.

Re:Unadvantages!

[Waffle Iron]

Ruby

What is type "safety" anyways?

It's apparent that you don't know the answer to that question.

Ruby is a safely typed language. It happens to use *dynamic* typing, but it checks those types at runtime nonetheless. Static-typed languages try to do the same thing at compile time.

Type-unsafe languages, such as FORTH, do not check types at all before operating on them. If you provide the wrong type of operand to a call, you get garbage output, but no error is raised unless you cause a CPU-generated segfault.

Re:Unadvantages!

[Anonymous Coward]

The difference is that the later you find the bug, the more effort you need to fix it. With static checking, you'll get the error at the next compile, likely long before you have anything sufficiently complete that you can run your tests on. Moreover, you get it usually at the right place, namely exactly where you made the error, instead of somewhere deep down in the call hierarchy.

Re:Unadvantages!

[DuckDodgers]

Sometimes you're trying to use a concept and the type system just gets in the way. Half - or more - of the famous Design Patterns for Java are not necessary in languages like LISP, Python, Ruby, or Perl because you don't need to work around the static type system the same way. A Design Pattern gives you flexibility at the cost of more adding a layer of abstraction, and in the enterprise applications I've seen the abstraction layers are so deep that you can't see what the hell is going on from any single point in the program.

There was a financial company that switched a flagship application with one million lines of Java code to Clojure. Clojure is an offshoot of LISP that runs on the JVM. They reimplemented the complete feature set available in the Java application in less than 100,000 lines of Clojure. I don't care how smart you are, understanding 100,000 lines of a weakly typed programming language has to be less work than understanding a million lines of a strongly typed one - and if you can understand it, you can maintain it better.

Re:Unadvantages!

[Anonymous Coward]

Yes, because everyone is great about "Going Back" to "fix up" things.. Without types the mediocre(at best) programmers I work with would bring total devastation to our product.

Re:Unadvantages!

[Anonymous Coward]

I don't understand your comment. Modern C/C++ programs leave most of the thinking to the compiler in how to generate their program; optimization, memory layout, data-alignment.. you only care about these things when they matter AND the compiler isn't doing the best possible job. Otherwise your relying on the compiler to translate your code into good machine language.

Re:Unadvantages!

[nitehawk214]

Once the idea is tested and youâ(TM)re comfortable with the design, you can add type annotations.

I've been doing this with comments since 1999 and it works great! Of course I still haven't gotten around to that final step of going back and adding all those comments but I love the flexibility!

Unless you like bugs, type-checking is a good thing. Lack of type enforcement encourages what -- lack of forethought?

When you go to hell, your punishment will be to go back and add comments to every bit of code you have ever written.

I am pretty sure I would rather stab myself in the eye then go back and look at code I wrote in 1999.

Re:Unadvantages!

[jkauzlar]

I've been writing a lot of clojure (for no profitable purpose) and actually find it very difficult to maintain. Common refactorings like moving functions from one package to another can be a headache and keeping track of types and keyword names in my head can also make a project's complexity get quickly out of hand. Mind you, I'm still a beginner to lisp (maybe 1-2 yrs experience), but with a statically-typed language and a good IDE, I'm a much faster developer and can easily do major refactorings to code I'm not all that familiar with.

That said, I'd still take a pay cut if I could develop in clojure all day )

Re:Unadvantages!

[DuckDodgers]

I'm not even that far along, so I'll defer to your experience somewhat. :) I just had to write a one-off program for work to dump a few database tables to disk, link and rejigger the data between them, and put it back into the database. I've done it before in Java, but Clojure let me get the job done in about the same length of time for the work (and I'm really new to Clojure) and just 90 lines.

Re:Unadvantages!

[DuckDodgers]

Oh, and before anyone says anything: no, this was a complicated enough manipulation between different tables changing their foreign key relationships that it couldn't be done easily with regular expressions and database stored procedures.

Re:Unadvantages!

[Pherdnut]

You know what the weird thing is? I came up in JavaScript but what really pisses me off in all the C# and Java I've been working with lately is the spectacular amounts of code that gets heaped on the problem of not having dynamic types. Completely pointless interfaces, generics, and lists of objects are absolutely everywhere in our code base. I actually find it easier to just rely on my use of OOP to keep the branching of data flow to a minimum and bring methods to my data structures rather than pass the data around constantly, putting 20 different sets of hands on them often re-validating and repackaging redundantly for every process, because you really might as well just call it a global var at that point. Handling thing's better with OOP actually makes it easier for me to use simpler data structures and not have to constantly cast things from one type to another or slap generics on absolutely everything (which is a phenomenon anybody writing in a statically typed language should take as a smelly symptom of lousy OOD).

So yeah, that's me, your JavaScript guy in the C#/Java dev authored codebase actually using single-typed arrays or lists of primitives in a sea of excess IOC and generics when there's no reason not to, because why complicate things needlessly? Is it better to make it generic "just in case" or is it better to know what type this thing is going to be right here and now where you're looking at the code? It's an even easier question to answer when you have one point of entry where it gets packaged and validated one time and then changes are all made internally as the object interacts with other objects and responds to events. You can do that sort of thing when you understand that vanilla getters/setters don't actually do anything for you and you might as well expose the property as public. Try encapsulating for realz. It's more challenging than beans/DTOs handed around like the cheap OOP-murdering data whores that they are because it makes you think critically and that's something modern software devs need to do a lot more of. Don't "maintain" contracts, check them at the door of a given problem domain. It's okay if the internals of a class get longer than 2-3 lines, I promise.

The dynamic kids who know what they are doing can work in your favorite statically typed language and produce results in less code than mediocre authors using that language can because we know how to write code. If we didn't, we'd be making the very messes static-only devs are afraid of making because it's never occurred to them that what static types protect them from is a mediocre dev's lack of ability to manage data flow, keep dependencies to a minimum, and actually leverage plain vanilla OOD - rather than just wrap procedural function-only code in classes - to write cleaner, easier to read, easier to maintain code. Catching a goof at compile time is nice. Catching 20 breaks at compile time when you made a simple change is a problem you shouldn't be having. When competent devs are in the room, static vs. dynamic types are a code quantity to performance tradeoff and that is all. To any static-only purists out there, I would recommend both writing and studying something something non-trivial written in a dynamic language and I guarantee that whether you are competent or misinformed, you will learn something that will benefit you in whatever languages are your bread and butter now just as I've learned stuff from branching out into C# and Java that I could take back to JavaScript to actually leverage what it's good at even better.

There are things I would not write in JavaScript exclusively (fortunately Node makes it really easy to leverage C or C++ for more calculation intensive stuff) but I think the widespread success of Django, particularly in the no-longer-just-print journalism sector has already dispelled the myth that dynamic languages can't handle complexity or scale. And the fact that JS maintained its position as the best tool for the job of normalizing umpteen variations on the DOM API in, particularly I

Re:Unadvantages!

[Pherdnut]

It helps to never ever pretty-up the UI for POCs. As the UI dev, I've never understood why people do this. The point is to prove what is within grasp for possible implementation. Finished-looking UI makes them think it's mostly-done.

Re:Unadvantages!

[Pherdnut]

A language design closer to a LISP-variant, which have traditionally been popular for AI work for glue and C/C++ bindings for the calculation-intensive and embedded system stuff under the hood with concurrency basically auto-handled by C threading routed to an event-loop and events driven by JS's blocking function calls? Give me that, what I know of JS and 5 kick-ass C/C++ guys and I would take on a 20-100 Java dev team in a rover contest any day.

jQuery btw is just a function that spits out decorator/adapter wrappers for DOM objects on the client-side web. It's in no way tied to core JavaScript and serves no purpose in Node. If it's all you see or all that you're using on the client-side, you're not doing anything very complicated on the client-side or you're doing it badly since it is in no way an aide to architecture beyond reducing DOM API cruft. It is, however, a very good example of how to write an adapter/decorator factory in JavaScript.

Since I think nothing of Dart

[Spy Handler]

not having heard of it, and thus never having any thoughts about it, and since you say it's NOT what I think it is (nothing), I guess Dart *is* something!

Re:Since I think nothing of Dart

[Anonymous Coward]

Never heard of it either. Google Evangelist evangelizing.

Re:Since I think nothing of Dart

[c0lo]

Meanwhile, in a galaxy far-far away:
Sith Ladd has an excellent write-up of Darth

Re: Since I think nothing of Dart

[Anonymous Coward]

Of course Dart still is something:
It's a US trucking company!
Bunch of nerds and still can't figure that out! Duh.

Welcome to the chopping block

[Anonymous Coward]

It sounds like somebody's language is on the chopping block at google. Dart has had a long, quiet run and Google seems to be allergic to that these days.

Re:Welcome to the chopping block

[larry bagina]

Being killed off is better than the alternative -- forced integration with google+. Will they require you to login to google+ to run the javascript transpiler? Will they auto-post your error log to your google+ page? Will they remove the "+" operator (like they did with search)? Who knows!

So, like Lisp

[Jmc23]

but more restrictions and unnecessary syntax. Great.

Can't wait' for the day when all languages 'evolve' back to Lisp.

Re:So, like Lisp

[Aguazul2]

No, nothing like Lisp.

Re:So, like Lisp

[kwerle]

Turing complete?

Re:So, like Lisp

[ebno-10db]

more restrictions and unnecessary syntax

I like syntax. It helps human beings read code. It was never intended for anything else.

BTW, what language is going to evolve back to Lisp and be usable for writing OS kernels, drivers and other such primitives?

Re:So, like Lisp

[ChunderDownunder]

I was going to say BitC but that language evolved away from s-expressions to something more Haskelly.

Re:So, like Lisp

[Waffle Iron]

but more restrictions and unnecessary syntax

(so (that (can (understand (non dweebs) (your program)))) (is (necessary syntax)))

Re:So, like Lisp

[ebno-10db]

I use to write Lisp, but I wore out the parentheses keys.

Re:So, like Lisp

[Anonymous Coward]

My zero and nine keys went mysteriously missing a few days after I picked up Lisp. Then I switched editors and ctrl, shift, and alt tabs vanished. Later I realized I'd just worn off the symbols on the keys, and was speaking in a thrange way.

Re:So, like Lisp

[ebno-10db]

I switched editors and ctrl, shift, and alt tabs vanished. Later I realized I'd just worn off the symbols on the keys

As a long time user, I can tell you that a real Emacs man can find those keys in the dark.

Re:So, like Lisp

[Jmc23]

That looks like a stupid person trying to make a joke, not anything like Lisp.

Re:So, like Lisp

[Jmc23]

umm, lisp? It's really good at twiddling bits.

As for readability, pretty much any non-programmer would disagree with you, and lots of programmers as well! I think it was never for readability but for those with lesser minds who can't hold too much information in their head and for those who write functions hundreds of lines long.

Re:So, like Lisp

[Waffle Iron]

It's perfectly valid Lisp code. So it looks exactly like Lisp.

Re:So, like Lisp

[angel'o'sphere]

I can confirm that. The keys are still where they ment to be. However if you use Emacs you are likely assuming that this is a nice editor. Well, as far as I can tell it is a nice operating system, but it lacks a decent editor. Honestly you should give vi or vim a try.
No offense, only a full hearted wish for your future!

Re:So, like Lisp

[Anonymous Coward]

Your sig: Don't complain about syntax, grammar, or spelling. There is no.hell like input on android.

Get SwiftKey 3. Not perfect but far from hell, and it learns as you use it.

Re:So, like Lisp

[ebno-10db]

lisp? It's really good at twiddling bits

How fast? What support environment is required? What happens when the GC kicks in?

As for readability, pretty much any non-programmer would disagree with you

Non-programmers would look at either and say "gibberish".

and lots of programmers as well!

The only programmers I've ever met who disagreed were Lisp programmers.

I think it was never for readability but for those with lesser minds who can't hold too much information in their head and for those who write functions hundreds of lines long.

Complaining about people who can't hold too much information in their heads and then those who write functions hundreds of lines long is a curious contradiction.

I don't know whether you're playing or really are one of those Lisp evangelists with a funny look in their eyes (probably from looking at too many parentheses). Either way, have a good night. Maybe I'll go back to making Lisp jokes in the morning. In the meantime rms@gnu.org may be holding an evangelists meeting.

Re:So, like Lisp

[ebno-10db]

you should give vi or vim a try

A curse on you and a whole bunch of stuff associated with you (whatever makes this more insulting). They say language wars are vicious, but editor wars are worse! With a little effort we can make the Wars of the Reformation look tame.

Re:So, like Lisp

[angel'o'sphere]

did you say: look tame?
or did you rather mean: look lame?

I only ask because the small but significant differences between emacs and vi (or vim if that matters) are lame, too!

However vi is easy to tame and I believe emacs is a beast!

Re:So, like Lisp

[Jmc23]

People write long functions because they think procedurally and can't hold several abstractions in their head at once.

Drivers should be functional, nothing to collect. As for syntax, why do you think different languages have different syntax? Some just think the others are gibberish. I prefer a language where i can make my own syntax if i need it, or not.

I've got a funny look in my eyes, but not from looking at parentheses! does a driver constantly look at the shoulders or what's in the middle of the road?

Re:So, like Lisp

[Mirar]

Wait, lisp *and* be usable for writing OS kernels?

Unless you're talking about these
https://en.wikipedia.org/wiki/Lisp_machine
I find it hard that that type of language (high level, functional) will ever be useful for writing kernels.

Re:So, like Lisp

[goose-incarnated]

I've got the code that NSA uses to break SHA-5 and all the current tough encryption used worldwide. The code is written in lisp, and as proof that I have the encryption breaker and un-hasher, I post the last 5 lines of it below:

))
))
))
))
))
Damn filter error! Doesn't let me post this comment, so ignore this sentence; treat it like an IBM manual with "this page intentionally left blank" written on it

Re:So, like Lisp

[Anonymous Coward]

Drivers should be functional, nothing to collect.

... Said the fool who has clearly never written one.

Why don't you try that first? Devices have state engines, often multiple state engines that interact and change independently, sometimes resulting in a combined configuration that the hardware engineer didn't intend that needs to be "fixed in post" by the driver. The driver needs to track the device's states and change them as needed to get stuff done, you can't just fling data at the device and forget about it. Packet queuing, reordering and rescheduling for devices slower than the system, aborting and resetting the device when it glitches out in the middle of an operation (which a lot of them do) then trying to resume operation from where you were, managing device power states which slow, stop or crash active operations, fighting the internal clocking by having to push writes at certain intervals with microsecond sleeps in between, and cleaning up residual invalid state values after a process completes which then get in the way of the next pending task, all of which needs to be thread-safe on top, practically ensures that drivers are almost always some of the most ugly code you will ever have to write.

Re:So, like Lisp

[Anonymous Coward]

Even Prolog has been used to write kernels.

Re:So, like Lisp

[Anonymous Coward]

D has picked up some lispish ideas, and can talk the C ABI, leading to the possibility of a mixed C/D microkernel or D modules in a C program. However development is really moving away from these primatives and into runtime platforms.

Re:So, like Lisp

[Anonymous Coward]

It's a valid s-expression, weather it's actually code depends on the enviroment you attempt to evaluate it in.

Re:So, like Lisp

[Anonymous Coward]

(if (properly-abract? program) (map increase (list 'understandibilty 'succinctness 'tweakability 'robustness)) (set! brain 'fucked))

The advantage of not haveing an arbitrary fixed syntax is that becomes much easier to abstract anything neccessary to build your language up to the probelm domain, instead of only being able to subdivide the problem until you reac the language's domain.

Re:So, like Lisp

[JesseMcDonald]

(so (that (can (understand (non dweebs) (your program)))) (is (necessary syntax)))

Here's the equivalent C/C++/Java code:

so(that(can(understand(non(dweebs), your(program)))), is(necessary(syntax)));

Was that any easier to read?

Understanding Dart's goals

[Necroman]

I've been following Dart on and off since it's announcement. I'm still a little skeptical of the language, but I'm a fan of what they want to do. Here are their basic goals:

• Create a class based (OOP) language for doing browser heavy apps (like GMail).
• Allow it to inter-op with today's browsers (hence compiling to Javascript)
• Create a DartVM so the code can run faster than there javascript counter-parts. This also allows for server-side, but this much lower on their priorities.
• Make the language easy for Java/C++/C# developers to learn.
• Only work with "the modern web". meaning IE9 and higher.

There is a lot more to it than this, but it's sort of a beginning. The language still hasn't hit 1.0, so no one is seriously using it (as the language itself was seeing large changes up until recently). Google has not talked about anyone outside of the Dart team itself that is using Dart within Google (they are doing it, it's just not being talked about yet).

Since 1.0 is expected this summer, you probably won't see many people using it until that milestone is hit. Once 1.0 is hit, people will be more willing to create real products with it, so you can expect to see more about Dart after that. As well, once the DartVM makes its way into Chrome (which will happen sometime after 1.0), you'll probably see a lot of press about the first Google App that is written in Dart.

It's still early in Dart's life. The only people really seriously using it are people that like learning new languages. Companies and most developers won't touch an in-progress programming language out of fear that syntax and behavior changes will screw them up.

Re:Understanding Dart's goals

[fisted]

If modern web means IE9 or higher, then thanks, but no, thanks.

Re:Understanding Dart's goals

[Nerdfest]

"Not JavaScript" is a pretty bug feature if you like having maintainable code. JavaScript is a very flexible language and all, but there are *way* too many bad/flaky things about it. I'm hoping it's an open language (more open than Java at least), but I'm assuming it is as it's from Google. It would be nice to have a single language that could replace Java and JavaScript, and a handful of other languages.

Re:Understanding Dart's goals

[Anonymous Coward]

That's flatly untrue for modern Javascript. The problem is that the only people who care to implement Harmony/Ecmascript 6 right now are.. Mozilla. Google would rather SAY they're doing it, and instead focus their efforts on their own spin-off of ES6 named.. Dart. MS is also lagging badly. It makes JS look bad just so alternatives can be marketed that will ultimately fail to get any traction.

That's the real shame here. Google has a massive problem with not-invented-here that leads them to develop their own tech. When Mozilla asked them to add APNG support to Chrome, they basically said "nope, NIH." Jpeg2000? Nope. JpegXR? Nyet. We're going to replace ALL image formats with our own monolithic, moving-target of a format called WebP!

Same goes with Dart. Google's got a lot of great minds, but when it comes to making choices for the broader web, they're always right and everyone else's solutions are ignored until Google makes their own more exciting version-twos of them.

Re:Understanding Dart's goals

[Kal Zekdor]

I actually have taken a liking to TypeScript for that purpose. It is rather fancy. I never touch "raw" js any more, I just treat it as a compiled blackbox.

Re:Understanding Dart's goals

[atchijov]

if I remember correctly, Dart was announced end of 2011 and become available to "play with" almost immediately. Since couple month after announcement, I have not seen anyone mentioning it ever. In 'internet years', 2011 is ancient history - so I am not sure if "it's still early in Dart's life" apply. I can see Google pushing it into Chrome, but I can not see Google replacing JS with it and I do not see any other browser except Chrome adopting it. Dart solves problem which no one has.

Re:Understanding Dart's goals

[siride]

I think that's IE9, IE10, Chrome, Safari, Firefox.

Re:Understanding Dart's goals

[larry bagina]

The Dart source code is BSD licensed, available on Google Code (hmm... I wonder when Google Code will get shut down...)

One of the contention points in the WebKit/Blink split was support for non-JS languages. Chrome (and Opera, Google's bitch) will, I suppose, support it, but Firefox, Safari and IE? Then again, IE used to support VBScript and PerlScript back in the day, so maybe Google could do an IE/Dart plugin.

Re:Understanding Dart's goals

[angel'o'sphere]

Well,

don't get me wrong. However knowing what a class is and knowing what a function is and knowing what a procedure is and knowing what a script is ans knowing what a program is .... it hurts me (physically!!) that a class in JavaScript is defined/introduced with the keyword "function". Sorry, a function is not a class. That is computer science first year. The guy who invented that should be shot. (Interesting however is that there are likely more Javascript developers on the world than Java or C# or C++ developers, and they seem to have no problem with this)

Re:Understanding Dart's goals

[narcc]

that a class in JavaScript is

Fail.

Re:Understanding Dart's goals

[AuMatar]

That sounds like a maintenance nightmare. The code you're writing and debugging is not the code actually running, making debugging require you to know a second language and be able to figure out where the bug is in both. No thanks, that sounds like a great way to waste lots of time. I hate Javascript, but until something else is native in the browser there is no alternative.

Re:Understanding Dart's goals

[shutdown -p now]

That sounds like a maintenance nightmare. The code you're writing and debugging is not the code actually running

When you're writing native desktop apps, the code that's actually running is also not the same as what you're writing and debugging - the former is assembly, the latter is C or C++.

Re:Understanding Dart's goals

[Laxori666]

narcc is of course referring to the fact that JavaScript does not have classes. That there are so many frameworks that attempt to mimic classes in JavaScript certainly doesn't make this an easier to understand fact.

Re: Understanding Dart's goals

[Kal Zekdor]

Welcome to compiled languages. Still, people continue to use C/C++, so it can't be that problematic.

Re: Understanding Dart's goals

[AuMatar]

There's a much smaller chain there- C++->machine code. Here we're talking about Language X->Javascript, then interpreting that Javascript in a VM in your browser. Oh, and add a possible JIT step in between. And factor in that there's multiple VMs (each browser has its own).

Re:Understanding Dart's goals

[Necroman]

You are correct. But they wanted to get Dart out to the world very early so that they could start getting feedback from the community. They actually listen to the community quite a bit and have taken a number of patches and features from external committers as well.

Their goal was to show that they were going to be open about the design of the language, but I think they ended up presenting that wrongly when the language launched, so they caught a lot of flack.

So Which is Faster?

[LifesABeach]

GWT, or DART?

Re:So Which is Faster?

[viperidaenz]

They're two different things to solve the same problem.
One is a framework with a limited java->javascript compiler, one is a language.

ps: problem = Javascript's prototype based objects are not tool-friendly, hence no decent Javascript IDE's.
Google has decided its easier to use a different language and compile it to Javascript than to write good IDE support for Javascript.
Java is perfect for building tools for it - hence GWT uses a subset of Java (reflection is one missing part). Dart is designed to be cross compiled and be easy to write tools for.

Re:So Which is Faster?

[MetalOne]

There is also AngularJS. The third thing to solve the same problem.

Re:So Which is Faster?

[viperidaenz]

No, AngularJS is a Javascript framework. It has nothing to do with Javascript tool support

Re:There are two kinds of programming languages...

[stormboy]

Get ready to hear some bitching about Dart on this thread, then review your assumption.

Re:There are two kinds of programming languages...

[Anonymous Coward]

I vote for no one cares.

I for one never encountered a situation where I thought "gee, if only I could prototype without types!". Types matter. When solving even the most basic data processing problem there's "input" and "output". Specifications are very clear on the formatting and types. What happens in between is dictated by those types.

Typeless programming in shorthand for lazy markup.

Yet Another Language -- what good is it?

[l0ungeb0y]

Or so that was my first thought. Then I got to the end of the article

Dart compiles to JavaScript and runs across the modern web

And suddenly I find it potentially very useful. I have a NodeJS project to develop a Streaming Service later this week. While I was planning on writing it in Coffeescript, the classic OO nature of Dart with Type Checking and Interfaces(!) seems like a potentially better match since the NodeJS app will be a clustered streaming service -- just the sort of application whose architecture could greatly benefit from these language features. If that succeeds, I know of a large retailer wanting to create a NodeJS middleware as a REST API to legacy systems, who might find Dart as compelling as I do.

Re:Yet Another Language -- what good is it?

[Anonymous Coward]

The problem I have often faced with writing in a language that compiles to another language is that debugging is a BITCH

Re:Yet Another Language -- what good is it?

[Jesus_666]

Note that Dart isn't stable yet (1.0 is expected this summer, though) and the language may still undergo breaking changes on the way to 1.0. If you're interested it's certainly a good idea to start looking into Dart but I wouldn't recommend using it for a production system yet. At the very least be prepared for a rewrite soon.

Re:Yet Another Language -- what good is it?

[Anonymous Coward]

That... and what exactly your code ACTUALLY does is somewhat of a mystery. I had the unfortunate experience to work in ColdFusion for a period of time... Arrays passed by value (wtf?), a single function call equating to a dozen lines of java and the creation of several objects (50 us overhead on FN call)... just ridiculous.

Wish it had better JS interop

[kwerle]

I fooled around with Dart a few months ago. I like the language. But I really want to be able to use it AND all the javascript libraries that do lots of work for me. It's my opinion that it will be hard for Dart to get traction if all those libraries have to be rewritten.

Re:Wish it had better JS interop

[Kielistic]

You're in luck. Dart can access javascript without too much trouble.

Re:Wish it had better JS interop

[kwerle]

Can you supply a pointer to how one would do that?

Re:Wish it had better JS interop

[Anonymous Coward]

This shows ahttp://www.youtube.com/watch?v=QFuCFUd2Zsw

Re:Wish it had better JS interop

[Kielistic]

Here is the article on it: js dart interop

Re:Wish it had better JS interop

[Anonymous Coward]

http://www.dartlang.org/articles/js-dart-interop/

Type Checker

[mdmkolbe]

Dart understands that sometimes you just don’t feel like appeasing a ceremonial type checker.

Given that in Dard, the type checker is only ceremonial as far as I can tell, this is an interesting choice of words. The purpose of a true type checker like you find in Haskell, Agda, ML, ATS, etc. isn't just ceremonial. It guarentees certain properties of the resulting program (e.g., that variables of a certain type actually contain an object of that type, that you can never apply an invalid operation to an object, etc.). That is far from ceremonial.

Re:Type Checker

[Anonymous Coward]

Provable correctness is for un-agile dweebs. You want to review your code? Psssh. Just ship it! bugs@disruptinnovation.io is our code review!

Re:Type Checker

[stenvar]

Languages like Smalltalk, Python, and Lisp have "true type checkers" as well, and they are strong, they just happen to be dynamic type checkers.

Big fat waste of effort.

[Anonymous Coward]

Why they recreated Ecmascript 6 is beyond me. Seems a huge waste of effort when they could have focused on implemented Harmony more quickly in Chrome/Blink/Webkit, and evangelizing that instead.

Re:Big fat waste of effort.

[walterbyrd]

> Why they recreated Ecmascript 6 is beyond me.

Because of inherent limitations in Ecmascript, that cannot be fixed. I believe Google has explained all this.

YASL

[ebno-10db]

Yet another scripting language. Oh boy, because Perl, Python, Ruby, Lua, and probably a hundred others I've never heard of just don't give you enough chaos (oops, I mean choice). Or there is some reason that Dart is the scripting language to end all scripting languages. Or it's an optimal combination of the best features of 47 other languages. Whatever.

Re:YASL

[Anonymous Coward]

Not a strict comment, but I think you'll see the point.

http://xkcd.com/927/

Just experiment and use var for your types....

[randomErr]

Isn't that just Visual Basic 6, VBScript, JScript, ActionScript, Real Basic, Jabaco, or JavaScript/ECMAScript? There are languages out there and even C# has the dreaded 'var' in it as well. I just don't see Dart's use outside of Google products.

Re:Just experiment and use var for your types....

[ebno-10db]

I just don't see Dart's use outside of Google products.

So? It's Google! By definition everything they do is wonderful, brilliant and the future. But their greatest product of all is hype, and they ship it in volume.

Re:Just experiment and use var for your types....

[Tablizer]

So? It's Google! By definition everything they do is wonderful, brilliant and the future. But their greatest product of all is hype, and they ship it in volume.

Microsoft is suing for Prior Art

Re:Just experiment and use var for your types....

[siride]

C#'s var has nothing to do with JavaScript's var.

Re:Just experiment and use var for your types....

[AlphaBro]

In C#, var is used to declare implicitly typed variables. They're still strongly typed.

Re:Just experiment and use var for your types....

[Anonymous Coward]

Isn't that just Visual Basic 6, VBScript, JScript, ActionScript, Real Basic, Jabaco, or JavaScript/ECMAScript? There are languages out there and even C# has the dreaded 'var' in it as well. I just don't see Dart's use outside of Google products.

I don't believe 'var' in C# is what you think it is.
'dynamic' or 'object' is probably what you meant.

I believe C#'s 'var' is closer to C++11's 'auto' than to JavaScript's 'var'

Re:Just experiment and use var for your types....

[Anonymous Coward]

var in C# is TOTALLY different from the others! Don't be so quick to judge, there are very good reasons for it too. What you're thinking of (in C#) is rather dynamic. var just tells the compiler to figure it out for you (type inference), it's still statically checked and all. Basically, if you write:
var xyz = new SomeClassOrAnother();
it's pretty easy for it to figure out that xyz is a SomeClassOrAnother object, it's just quicker to read and less redundant than :
SomeClassOrAnother var xyz = new SomeClassOrAnother();
but the end result is the exact same. It's also extremely useful for LINQ queries when the exact return type is unknown (like an IEnumerable of an anonymous class)

As for the dynamic type which you loathe, it's used with the dynamic language runtime, it enables writing dynamic languages like ironpython, and it's very useful for COM interop. So even then it's not a mechanism for sloppy programming or whatever, unlike those scripting languages which you listed. It's a feature that is sometimes the least bad option in some specific cases.

Re:Just experiment and use var for your types....

[Anonymous Coward]

Sure it does. At the base of things, its used to declare a variable. C# just happens to use type inference from it upon assignment.

The new COBOL

[Anonymous Coward]

Apparently the real reason to include Big Integers was to make it an attractive language for dollars and cents... for instance this commit came from financeCoding/master.

Exciting stuff...

Lol what?

[Anonymous Coward]

"Just experiment and use var for your types. Once the idea is tested and you’re comfortable with the design, you can add type annotations." Riiiight, because all developers you know do that. It's never about "just do something that works and then move onto something else"... Nope, doing things properly always happens. And it especially happens on the projects that matter.

The proliferation of computer languages

[Taco Cowboy]

I haven't used DART yet, so I will not comment on the strength or the weakness of it

But, all through the decades that I've been in the scene, there have been so many programming languages invented, but so few of them being used

Some of the more widely used programming languages like C, for instance, are not perfect, but they are being used partly because of legacy, partly because of momentum, and partly because of the laziness of programmers to learn new, more useful languages

Talking about legacy, the other day there was a piece on Cobol, and that IBM is trying to extend Cobol to the cloudsphere

As for the languages that are not so-widely used, some of them are downright weird, but then, there are gems among them. The only downside for those few gems is that the ecology is not there to enable those few gems to become more widespread

I guess it's kinda Darwinian game plan --- not all surviving/thriving species are perfect, and not all the extinct species are bad, either

Re:The proliferation of computer languages

[Anonymous Coward]

laziness of programmers to learn new, more useful languages

What can't you do in C? I know that if it can't do something easily, you can create a library in it so that you can do it easily. Even create interpreters to make more useful languages. How's that again?

Re:The proliferation of computer languages

[Anonymous Coward]

What can't you do in C?

Use functional duck-typed garbage collection monads, of course. You are you supposed to build a RESTful API for your grocery list webapp without them?

Re:The proliferation of computer languages

[Joce640k]

What can't you do in C? I know that if it can't do something easily, you can create a library in it so that you can do it easily.

Throw an exception? Stack unwinding? RAII? Object construction/destruction?

I'd like to see a library that does all those easily/automatically.

A C++ compiler OTOH...now you're talking!

Re:The proliferation of computer languages

[angel'o'sphere]

C++ implements all this with C features called setjmp and longjmp.

http://en.wikipedia.org/wiki/Setjmp.h

Re:The proliferation of computer languages

[siride]

setjmp()/longjmp() were good enough for my dad and daggone it, they're good enough for me!

Re:The proliferation of computer languages

[Pseudonym]

What can't you do in C?

Write a robust system that has a sufficiently complex job to do, on time and on budget.

In particular, if you find yourself having to write an interpreter first, you probably should have used another language. (Unless, of course, the interpreter is the job.)

Re:The proliferation of computer languages

[Anonymous Coward]

Not looked at setjmp and longjmp for a long time, but I don't think those do stack unwinding.

Re:The proliferation of computer languages

[Pseudonym]

setjmp and longjmp do many useful things, but stack unwinding is not one of them, and it's far from "easily and automatically". If you're trying to do the same thing as a real exception system, setjmp/longjmp imposes a large maintenance overhead (and significant run-time overhead, but the maintenance overhead is arguably much more important) on your program, even if you never raise an exception.

Incidentally, I do have a few quibbles with the list you responded to. C programmers do object creation and destruction just fine, it's only exception raising and stack unwinding which requires the manual effort. And RAII is a means, not an end in itself.

Re:The proliferation of computer languages

[Anonymous Coward]

Vala. Compiles all those things to C, then you compile the C. And it's also very clean C, not the clusterfuck that GObject/GLib is - except for the portions that use GLib of course.

Re:The proliferation of computer languages

[mevets]

You only have to unwind the stack frames that matter, and merely keep a chain of what needs to be destroyed.
It is not cheap, but C++ exception handling is not cheap either.
It is also a poor way to implement things, but at least you will be remembered.
C++ amortizes overhead more evenly than C, so inefficiencies of a particular mechanism are not as glaring. Would you take the roof racks off an SUV to save gas?

Re:The proliferation of computer languages

[Anonymous Coward]

I haven't used DART yet

Why do you think it's "DART"? If you visit dartlang.org, you'll notice it's "Dart".

Re:The proliferation of computer languages

[bmk67]

What can't you do in C? Not a hell of a lot, sure - but the level of effort is often not worth it. I've spent 20 years doing development primarily in C, and it's often not the right tool for the job.

Re:The proliferation of computer languages

[Ghaoth]

Program in binary. There are no limitations except the processor and time....a very, very lot of time.

Re:The proliferation of computer languages

[Pseudonym]

C++ exception handling is extremely cheap if memory is not tight (storing EH records isn't hideous, but isn't free either) and you never throw an exception. If you never throw, the speed difference is unmeasurable most of the time.

Re:The proliferation of computer languages

[Pseudonym]

Please ask Google what "stack unwinding" means. It doesn't mean resetting the stack pointer.

Re:The proliferation of computer languages

[Anonymous Coward]

I program in hexidecimal. It's 4 times as efficient as binary.

Re:The proliferation of computer languages

[chris.alex.thomas]

as languages go, you might want to practice english a bit more first :) /troll hahahahah

Re:The proliferation of computer languages

[Anonymous Coward]

This comment is my favourite kind of stupid. It is condescending, it is entirely true and it completely misses the point.

Re:The proliferation of computer languages

[Anonymous Coward]

> Program in binary

Nonsense. Put your binary code in a buffer, and set your program counter (aka instruction pointer) to the address of the buffer.

It takes specific circumstances for this to work, but this is in fact how some operating systems gain exclusive control of the CPU.

Re:The proliferation of computer languages

[ultrasawblade]

I like the way you thunk.

Re:The proliferation of computer languages

[Anonymous Coward]

What can't you do in C?

What can't you do in assembly language?

Oh, BTW, I can tell you what you can't do in C: Switch an x86 processor into protected mode!

Re:The proliferation of computer languages

[angel'o'sphere]

Yes it does. Even if the term got ninja-ed and misplaced. I guess you talk about C++ where unwinding the stack means that destructores need to be called ;D
Do you know how C++ implements this? With longjmp. A list of setjmp adresses for try/catches and returns is "unwinded".

Re:The proliferation of computer languages

[Anonymous Coward]

You could say the same thing about assembly or object code, that it's possible but not easy unless you slap something onto it. Or that you can write interpreters in them. But that misses the point.

Re:The proliferation of computer languages

[Anonymous Coward]

How do you reset your program counter in C? AFAIK you need to use inline assembly to do that.

Re:The proliferation of computer languages

[Pseudonym]

Actually, that's not just what I'm talking about. Destructors and RAII are C++'s implementation of stack unwinding, but it's not the first example and not necessarily the best example.

If you think of a program or language as implementing a virtual machine which satisfies certain axioms, an "undesired event" (UE for short; this is the term that Parnas and Wurges used in the original paper on exceptions from 1976) may cause some of those axioms to no longer hold. The job of UE handling is, then, to restore the virtual machine from an "impossible" or "defective" state (where the axioms don't hold) to a "valid" state (where they do).

IIRC, Lisp's unwind-protect operation predated setjmp/longjmp in C.

Do you know how C++ implements this? With longjmp.

C++ is a language, not an implementation. Cfront used longjmp, but pretty much every implementation since uses a native implementation because longjmp imposes far too much overhead if you never throw an exception.

Besides, even if this point were true, it would be irrelevant. Consider the analogous argument: Do you know how C implements longjmp? With assembler.

Re:The proliferation of computer languages

[ultranova]

Write a robust system that has a sufficiently complex job to do, on time and on budget.

This is true of any imaginable language.

Re:There are two kinds of programming languages...

[Anonymous Coward]

They are like Pop tunes. All vaguely the same but different. Empty and useless. Without purpose other than to be Yet Another Language.

ActionScript + Python + Ruby

[RedHackTea]

That's what I think. ActionScript allows the same static/dynamic switch:

for(var i:int = 0; i < 0; ++i) { }
for(var i = 0; i < 0; ++i) { }

But, in strict mode, it will give you warnings for the 2nd.

Re:ActionScript + Python + Ruby

[Longjmp]

Actually, a compiler would give you the same results for both concerning "for( i = 0; i < 0;)"

In Assembler: NOOP ;)

Re:ActionScript + Python + Ruby

[Mashdar]

Thank you for incrementing before the return in your for loop!

Re:ActionScript + Python + Ruby

[Anonymous Coward]

Yes, can anyone tell me why people do this? Is it more aesthetic to increment before the result is thrown away?

Re:ActionScript + Python + Ruby

[Nbrevu]

I don't know about the others, but for me, it's like muscle memory after a few years of C++.

First, you have to take into account that not everything that accepts "++" is a number. It may be anything, and in particular it may be an iterator, which is very common.

Now, you have to consider that "++variable" is not the same as "variable++"; they are two distinct operations with their own behaviour. So, "++variable" increments in-place, but "variable++" returns an anonymous copy of "variable" and then increments "variable". It doesn't seem like a big deal when you're doing a standalone increment (i.e., not assigning "++variable" or "variable++" to a result, which has different behaviours because the result won't be incremented in the second case), and indeed the result is the same, but the preincrement doesn't create a copy, while the postincrement does. So, preincrement is more efficient (especially if the copy is not trivial, if it's inside a loop, or both. The second case is the most frequent). It's a micro-optimization (which means that you won't speed up your code by 200% by doing this) and many compilers will probably do the fastest thing if you use postincrement and do not assign the result, but it doesn't have any downside. And, like I said in the first sentence, it becomes muscle memory quickly. I've ended up doing it in all C-like languages, but I'm not sure if there are differences in anything that isn't C++. I certainly hope there isn't any downside.

Re:There are two kinds of programming languages...

[Anonymous Coward]

And then there's Python.

Dart has some important fans

[93 Escort Wagon]

I know Tom Magliozzi used to wax rhapsodical about his old Dodge Dart from the 1960s; and recently Dodge resurrected the brand.

So yeah - there are people that care deeply about Dart.

Re:Dart has some important fans

[ebno-10db]

I think the car was named after the Delta Dart, which is way cooler than any car or programming language.

Re:Dart has some important fans

[larry bagina]

It's actually Google Fart. Another casualty of autocorrect.

Dart feels your pain

[Anonymous Coward]

Dart knows that you don't have time for strict typing. Unless you do. For example, Dart allows you to write code. And that's just one example. Once your code is done, you can add more code that doesn't do anything. Unlike other languages, Dart allows you to define functions and libraries, not just classes. Go ahead, write free functions and import them into your programs. See if Dart cares. Unlike any language in history, Dart also has anonymous functions. What's that function's name? Dart doesn't have to tell you.

As long as it kills Javascript

[OhANameWhatName]

I'll support it. Javascript is a thoroughly horrible language with anachronistic syntax that requires specialised skills to understand. If Dart has the potential to rid my life of Javascript, please Google .. get it out there!!

Re:As long as it kills Javascript

[MrBandersnatch]

On that front I will agree however Dart really doesnt solve my major complaint with the "web" languages - its still "slow" when compared with Java/C++, although it is of course early days. Personally all I want is a language (Dartish/Rubyish) thats as fast as Java....but that ISN'T Java (or Javascript). Seriously considering investing some time in Scala with the Play framework....

Re:As long as it kills Javascript

[Anonymous Coward]

Um, Dart is basically an inferior Ecmascript 6. All Google is doing is holding back modern Javascript by not focusing on it and evangelizing their own inferior products.

Re:As long as it kills Javascript

[Anonymous Coward]

Seriously considering investing some time in Scala with the Play framework....

I've invested lots of time into Scala and it's thoroughly horrible. If you want FP use Haskell, F#, an ML or Clojure. Scala is just a mess...

Re:As long as it kills Javascript

[Anonymous Coward]

Seriously considering investing some time in Scala with the Play framework....

Yup, been there done that. All I can say about it is that, yep, it's another web framework. Unfortunately the Play2 documentation isn't good enough if you ever need to do anything "advanced" -- which you will do often for any non-trivial app since the core framework remains incomplete and there still are not many plugins.

Re:As long as it kills Javascript

[cb88]

What about LuaJit? http://luajit.org/ I don't see any reason why this couldn't be integrated into browsers and in addition to that it is extremely fast.

Re:As long as it kills Javascript

[walterbyrd]

> Dart is basically an inferior Ecmascript 6.

No it is not.

10 reasons why Dart is cooler than JavaScript
http://www.grobmeier.de/10-reasons-why-dart-is-cooler-than-javascript-03012012.html#.UZzaoaARiXk

Re:As long as it kills Javascript

[Anonymous Coward]

Why use "java" and "fast" in the same sentence ?

What you whant was called "juice" (developed by one post doc student of michael franz i think) a very fast, strong typed, safe, object oriented, incremental profiled and compiled, run time on netscape plug-in form, for an oberon2 dialect (with interface verification and restriction, on load of the bytecode intermediate representation... only succesfully audited modules, that can also by admin policy be aspect restricted, finally where compiled, profiled and monitored on run

Re:There are two kinds of programming languages...

[dreamchaser]

I'm not sure why you were modded Troll. I tend to agree. Types are no good if they are not enforced. Either use a language that doesn't enforce typing or use one that does. This in between approach is indeed lazy.

There are problems with new languages

[angel'o'sphere]

One Problem is teaching.

One problem is "compatibility" or "easy to learn". E.G. regarding keywords.

C has a keyword: static.
C++ has the same keyword: static.
As Java aimed to be similar to C++ and "easy to learn" it also has a keyword static.

While the meaning of the "keyword" in Java and C++ is the same, it differs from C. (Oh! and this already is not true as you can use 'static' in C++ similar to C if you just use it for free functions and data).

So what does 'static' mean?

http://dictionary.reference.com/browse/static
http://www.thefreedictionary.com/static
http://www.merriam-webster.com/dictionary/static
http://oxforddictionaries.com/definition/english/static

Unfortunately 'static' in a programming language has no meaning at all. Why is the "starting method" in Java called "static void main(String[] args) {}"? Yeah, because in C and C++ it is called main(). Pascal has not that problem.

What do you think a non native english (oh, well what about the english?) considers if he hears the word 'static'?

Good, now lets bash Python and Groovy. What is a "def"? Oh? A definition? Are you certain you can distinguish what the difference between a definition and a declaration is?

So "methods" are now "declared" (or is it defined?) by the introducing keyword "def"? Oh, for fuck sake, I got it wrong again.

Oki, in Python you declare, oh no!!!! you define methods with the keyword "def". In Groovy you define variables (oh! no!!!!! you declare!!!) with the keyword "def".

Yeah, I could rant forever ...

All new languages we see here and there are only languages for programmers that already can program.

But, what is about expressing your mind?

What about teaching programming? Imho Java is one of the most difficult languages to teach. Why? Because you need to know already so much about programming to grasp it!!!!! (Same for C# ofc).

However: modern times show: you don't need to understand Java/C# (just a replacement for most modern languages) because the programing tasks a modern developer has (especially compared to the tools he has at hand) is so mondane. C++ on the other hand only shows how super smart and knowing you need to be to use the language, or not to shoot into your foot.

So where are we?

New languages should use new keywords, that describe precisely what they mean. No void, no static, no final or for that matter finally, no fucking def, var or func. Did I forget one? I certainly did. And they should have reasonable defaults. I hate Java meanwhile, "public void doit() {}", "private boolean done = false". Then we get to "static final String DID_WE_DO_IT = "yes we did";" What is so hard in having methods be PUBLIC by DEFAULT and attributes PRIVATE by DEFAULT?
Writing code is still possible, even if it hurts my hands and my eyes. But reading? I simply don't want to read code anymore ... neither C++ nor Java nor C#. The redundancy hurts me literally.
In a typical Eclipse window I would estimate 30% of all characters/words are simply superfluous. And the fact that they all have a different colour emphasizes this.

How would a real world language look to you if it was written like this: "I want (that is me the guy writing) that we (that is us, you who are listening, and me who is talking) that we (well, dont be mistaken, I only want it, it is not an order) that we (yes, I invite you to participate) go to the beach (and want does not mean it is super important ... it is kinda void)? (And all words in () above in a different colour? Like pink (ARRRRGGG!!!!) light green ( /*facepalm*/), dark and light blue, emphazised(bold) full

Re:There are problems with new languages

[Anonymous Coward]

>However: how the fuck do you explain someone who starts programming what "static void main(String[] args) { ... }" is supposed to mean?

Generally? They start with "this is the way you do it" and explain later.

If you program twice as well as you argue, you should have stopped 28 years ago. Pascal is dead* and good riddance.

* In that only a moron would write new code in it. Much like COBOL, legacy code is here to stay.

Re:There are problems with new languages

[Kielistic]

If you think all those words are superfluous you probably don't have much knowledge of compilers or IDEs. The static keyword has very well defined meaning in every language it is used in. As do all those other keywords you seem to hate. Should we kill modern programming languages and go back to what, a stripped down functional paradigm because you deem all this stuff superfluous and hard to teach to beginners?

Programming is about precision. I should never have to guess at what the compiler is going to do with my code; programming is not a natural language. You are damn right I want a void return type. I want OO static members. I want all the information that can be put into method/function/variable definitions so I can take a quick glance and see what it does, takes and returns. So that my IDE, if I'm using one, can auto-complete most of the code for me. So that the (JIT-)?compiler or interpreter can understand all kinds of fancy syntax that lets me do more and write less.

Those five things you mention have nothing to do with C or C++. They are programming concepts and pretty basic ones at that. Obviously you have to understand the basics before you can move on to intermediate.

Re:There are problems with new languages

[vux984]

The static keyword has very well defined meaning in every language it is used in.

I think his point was that that static doesn't map semantically very well. They could have just made the keyword "ketchup" and defined it the same way and it would be no better or worse.

You are damn right I want a void return type

But why call it "void" and why call it a "function" if it doesn't return something?

To be honest, I kind of see his point.

Re:There are problems with new languages

[Ateocinico]

I absolutely agree with you. But until someone young with a new paradigm for translating human intentions to machine code comes around, we must stick to all that context free grammar stuff. That's the origin of all the mess. We need a fresh start in programming languages.

Re:There are problems with new languages

[Kielistic]

It is called static because it is statically allocated. It is a compiler concept which became an OO concept due to being somewhat similar. It is static; it is the same when I access it here as it is when I access it there. It is not arbitrary any more than any word is arbitrary. Why make up new words now when we have an established lexicon? Nothing maps semantically well into English because it is a natural language with all kinds of context involved. Programming languages have to be context free which is why we class them as context free languages.

Few OO languages call it a function. It is called void because it returns nothing. It is so the compiler knows where the return type ends and where the method/function name begins. It keeps things consistent and consistency is good. A few languages do leave it out now because some people think that removing redundancy is more important than consistency. These quirks are present in older languages because lexical analysis is a complicated task and it was simpler and more effective to leave the heavy lifting up to the human that found it easy.

Re:There are problems with new languages

[narcc]

But why call it "void" and why call it a "function" if it doesn't return something?

This is something VB got right: distinguishing functions from subroutines. I don't know that it was ultimately helpful beyond the obvious pedagogical benefits, but it the distinction is valid and reasonable.

To be honest, I kind of see his point.

Even a blind squirrel gets a nut once in a while. Try as he might, he can't be wrong all the time.

Re:There are problems with new languages

[angel'o'sphere]

Pfft, you stopped reading after 10 sentences?

I know what all that bullshit means. If you reread my post and scroll down you see.

Did you follow any link I posted?

So "static" in C means "pertaining to or characterized by a fixed or stationary condition"? No it does not.

So it means "showing little or no change: a static concept; a static relationship"? No it does not.

So it means: "lacking movement, development, or vitality: The novel was marred by static characterizations, especially in its central figures."? No it does not.

So it means: "Electricity . pertaining to or noting static electricity."? No it does not!

Static in C means: the function or variable is INVISIBLE outside of the compilation unit. (I hope you know what a compilation unit is, I don't want to teach you, Padawan)

In C++ this means the same for global functions / variables outside of classes.

Now INSIDE of classes it means something DIFFERENT.

It means it is a so called "class variable" or "class method" (the term member function, introduced by Stroustrup only emphasizes my rant. Why could he not use well established terms?).

Surely you want a void return type. But void does not mean void. If your flight is canceled your ticket is void. You get a new one for the replacement flight. A function can return nothing, that is fine. Other programming languages however call such a function a procedure. I rather have a function that returns "nothing" instead of "void". Because this I can explain my 6 year old child. "Oh this function is void!" "What do you mean daddy? It does nothing? It makes no sense to call it? Well, if so, what is it actually doing?"
Imagine you had a cooking recipe.
void makeCake() {}
Obviously no cake comes out as result. Where is the cake then?
C++ tried to reuse C keywords, like static (hence you fail to comprehend my post)

And other languages just picked up those keywords. Many languages just picked up keywords of other languages. My examples are static, void, func, def, var etc.

Sorry, many people believe that programming is about mastering the machine. The iron that runs your programs. This particular asm instruction will save me 2 cycles. And now I modify my stack to jump back 3 subroutine calls (because I know where I am, who I am and what I am and how many I am) .... so smart! So only a super hacker can do this, you are my hero, you are so smart!

Programming is not about mastering a particular machine. That idea should be over after 2 or 3 years of "programming". After that comes DEVELOPING. Developing a solution for a paying customer. Developing means to think in terms of the customer. Requirements engineering etc. Business. "What" is it what he wants? And "how" would I implement this. Stacks and Assembly and Opcodes are irrelevant.

Those five things you mention have nothing to do with C or C++. They are programming concepts and pretty basic ones at that. Obviously you have to understand the basics before you can move on to intermediate

Yepp, and here you are completely wrong.

All the programming concepts I touched have a human comprehensible name.

They are called: class variables/methods versus instance variables/methods. Hint: no static here.
They are called: subroutines that return a value or donet return anything. Hint: no void here. And in Assembly, the former pushes a return value onto the stack before returning, and the later .... surprise surprise: does not. What exactly has that to do with "void" as in "your passport is void, get a new one"? Nothing, exactly, that is my point.
Now "main" as in "main argument" ... sure I can understand if you are in a language like C that someone comes to the idea that a function called "main" is an easy solution.
But why repeat this in Java or C#? Hu?
In C the function main can have basically any signature, e.g. you can omit the "char** args" (and the less known "char** env"). In Java an

Re:There are problems with new languages

[vux984]

It is called static because it is statically allocated

That's a circular argument. What does statically allocated mean? Is it called "static" because its kind of the opposite of dynamic? I checked two thesaurus that don't make that connection... they suggested 'fixed' or 'stable' or 'permanent'. Those make at least as much sense as 'static'.

. It is a compiler concept which became an OO concept due to being somewhat similar.

Even you have got to realize that is pretty weak. Could have just as easily called them shared, or something more directly applicable.

It is called void because it returns nothing

So void is nothing, and its not to be confused with a void* which is a pointer to absolutely anything, right?

But ultimately the issue is that a variety of decisions were made back when C was written, and there is absolutely a sort of logic to it all, but if you don't know C they don't make a lot of sense, especially when you encounter them in quasi "somewhat similar" roles in modern languages.

Like why are they in dart? Nothing is statically allocated in a language that compiles to javascript to run in a browser. And there are any number of ways of writing function/method declarations to communicate return values or lack thereof without invoking the 'ghost of C' void keyword.

hell simply

method_name [return type] (params)...

or perhaps the more verbose:

method_name (params) returns (return type|nothing)

I mean, if you are designing a new language... the advantage to re-using old keywords from C is that it makes it easier for people coming to the language from C and its descendants. But its needless complexity and confusion for new programmers.

Re:There are problems with new languages

[angel'o'sphere]

Exactly.
We need a fresh start in programming languages.

I consider to write a blog, perhaps I allow myself to use this sentence as a headline. Credits granted, definitely.

You coined it to the point.

Re:There are problems with new languages

[angel'o'sphere]

A static method is static allocated?

A static member variable is static allocated? (Perhaps, it makes half sense).

Ofc it is arbitrary. As it does not explain what it is.

In C something static is not "static allocated" ... C++ and Java just captured the keyword and gave it a new meaning.

My point is not, that you don't know what it means. You know it, no problem. I know it as well. We all know it. But if you teach someone a language, especially a programming language, he also knows what static means.

Unfortunately his knowledge about what static means is wrong as it means something completely different (and close to incomprehendable) in the programming language. The clash between programming and natural language is huge.

Well, my point is simple.

New languages should not reuse "static" again, but rather use a new keyword that makes clear for the layman what we are talking about.

Class variables and class methods are not static. In other words everywhere where C++ uses const imho static would make more sense.

And please ... we are talking here about a Gedankenexperiment. No one of us is right or wrong or needs to prove the other side wrong.

I like to play with language, natural or artificial ... thats all.

Re:There are problems with new languages

[mbkennel]

Actually there is a fairly-well used programming language, with a substantial user base, highly optimizing compilers, and a large set of libraries which comes closer to meeting the poster's objections (which I agree with 100%).

It's called Fortran. Modern Fortran (95 through 2008) makes fairly reasonable use of words to express important semantics instead of bizarre combinations of some legacy subset of wordlets and punctuation. Fortran uses additional words when it adds additional concepts.

REAL, POINTER :: a(:)
REAL, ALLOCATABLE, TARGET :: b(:,:)

b is a two dimensional array of 'real' (single precision float), which is dynamically allocatable, and a potential target of a pointer.
a is a pointer to a one dimensional array of reals.

What do these look like in all the 'web-scale' programming languages?

And yes, the difference between FUNCTION and SUBROUTINE is there. VB just swiped it.

Re:There are problems with new languages

[mbkennel]

No we don't. Designing good languages takes lots of experience.

We need a fresh start in human cognitive ergonomics as applied to programming. No, actually we don't---there's been plenty of research already.

What we need is for people to actually care about these things, which means appreciation of non-trivial academic knowledge and experience of older people who've been there before. It means appreciating that good syntax, as it relates to underlying semantics, is essential for human performance even if various choices are equivalent to a compiler.

Re:There are problems with new languages

[Kielistic]

That's a circular argument.

Exactly, they're words. They needed to name it something and they chose static. Definitions always come down to circular logic. Why is the thing attached to my arm a hand and not a foot? Because it's a hand and a foot is something different.

Could have just as easily called them shared

Yes they could have called them anything but they chose static members because it fit and because the compiler was deciding what to allocate at compile-time and not at run time.

So void is nothing, and its not to be confused with a void* which is a pointer to absolutely anything, right?

Precisely. They needed a way to tell the lexer nothing gets returned from this and they wanted it to be concise. Asterisk represents a pointer so yes it is different

Like why are they in dart? Nothing is statically allocated in a language that compiles to javascript to run in a browser. And there are any number of ways of writing function/method declarations to communicate return values or lack thereof without invoking the 'ghost of C' void keyword.

Static members are an OO concept and Dart is an OO language. Makes sense to me it would support static members. Dart does not require the void keyword. If you omit a return type it assumes a return type of dynamic (you can return anything or nothing just like in JS). So you can write it how ever your preferred style would dictate. They used a similar syntax because why mess with something that clearly works quite well?

Re:There are problems with new languages

[Laxori666]

Non-superfluous doesn't necessarily mean not precise or not well-defined. It means using context clues more than explicit declarations where the context gives you everything you need to know.
For example, 'var' in C# was brilliant, IMO, and I am upset that Java doesn't have one. `var x = ...` gives you 100% of the information you need to know what the type of `x` is, because the language is statically typed so the right-hand side has a statically determinable type. It also saves a ton of needless typing. Which looks better:

var intNames = new HashMap();

or:

HashMap intNames = new HashMap();

Is the former any less precise than the latter?

Speaking of superfluous, having to insert <br> in my post here is superfluous. Stackoverflow does a brilliant job of formatting my question, answer, or comment well without needing such markup. And it's not any less precise. It's just more concise.

Re:There are problems with new languages

[Laxori666]

Gordamnit. That should have read:

HashMap<Integer, String> intNames = new HashMap<Integer, String>();

The &lt; is another example of something superfluous.

Re:There are problems with new languages

[Anonymous Coward]

DISCLAIMER: I program since 30 years,

Hi, you speak excellent English, and this common transliteration error is the only way I was able to tell you were not a native speaker.

The most common way to phrase this is, "I have been programming for 30 years". Slightly less common (and slightly more awkward), yet also valid, would be to say, "I have been programming since 30 years ago". One could also say, "I started programming 30 years ago," but that doesn't communicate the connotation of continually programming for the whole time.

Like I said, just a minor nitpick; most English speakers can understand what you are attempting to communicate but it sticks out.

Re:There are problems with new languages

[angel'o'sphere]

Lots of experience is plenty available on this planet.

However a new language should be 'void' of marketing interests and compatibility issues.

Otherwise we remain 'static' in what we already have.

Frankly, if I go to the wikipedia page of Dart and follow the links to other referenced languages I always the same old wine in new bottles. (Sorry, to lazy to dig out the proper english term of this biblic saying :) )

Re:There are problems with new languages

[Kielistic]

So "static" in C means "pertaining to or characterized by a fixed or stationary condition"? No it does not.

That is actually the definition that they were probably going for. It is fixed and stationary at compile time. It does not move in and out of memory.

Because this I can explain my 6 year old child.

I don't think you should plan a programming language on what would be easy to explain to a 6 year old. Few 6 year old children would even have the conceptual understanding to get the return vs. doesn't return concept.

Your cake example doesn't make a lot of sense. Is it a program to instruct a robot to make a cake? If that is the case then it would make sense for it to not return a value. Is it supposed to return a cake and just doesn't because it was written sloppily? I don't know but I can't think that there are too many occasions that a make a cake method is written.

Erm ... for what exactly was the "String[]" part for?

You know what it's for: the arguments. The devs decided it was better to always require it than to have a bunch of special cases. You think it is harder to explain to a novice "it needs to be done this way" than it is to say "it can take this set of arguments, or this set, or none... figure it out"?

They all use main for exactly the reason you state. Why change it when it makes sense and works? The main method is the main method.

So calling me an "intermediate" is a bit ... hm, insulting?

I actually meant in relation to teaching new people. As in you have to teach them the basics before moving on to the intermediate. Sorry if I came across as insulting.

please google what "functional paradigm" is.

You seem to dislike keywords; functional languages tend to use less.

What dod you want to say with tis statement?

You seemed to be saying the compiler should figure things out from context (you don't like definition keywords). I would rather specifically tell it what I want instead of guess at what it thinks I mean. Either way I have to learn the idiosyncrasies of how it interprets the language into machine code and I'd rather do that with an explicit language.

Re:There are problems with new languages

[Anonymous Coward]

angel'o'sphere is a long-time troll. Don't feed the trolls. He gets off on this kind of stuff.

Re:There are problems with new languages

[Anonymous Coward]

So here's the solution for you. Go take some more meth* and stay up for 2 weeks straight and implement the perfect language.

* Half of the posts in this thread are your long rants. I have to assume meth is involved somehow.

Re:There are problems with new languages

[Anonymous Coward]

I agree with Fortran being very readable. I only used Fortran-77, but it always looked pretty close to BASIC to me...

You could write the program

            Print *, "Hello World"

And it would compile in gcc and run just fine, even without mentioning "main program" and "end"
That would be pretty easy to explain to a non-programmer, and go from there...

Re:There are problems with new languages

[MrBandersnatch]

I encountered a company still writing software in VB this week. The new version of their software was crashing so they sent us a debug version which said it would copy any error information to the clipboard and write a log file with any error messages.......it crashed when attempting to write the error message to the clipboard and so never wrote a logfile.

VB DID NOT GET **ANYTHING** RIGHT! ;)

Re:There are problems with new languages

[goose-incarnated]

Sounds like you need lisp

Re:There are problems with new languages

[goose-incarnated]

It is called void because it returns nothing. It is so the compiler knows where the return type ends and where the method/function name begins.

Are you listening to yourself? This is specifically what his rant is about - designing the language for the compiler to understand, and only secondarily for the human to understand. You've kinda re-emphasised his point - too much in the language is due to the inability of the compiler to understand what we are trying to express. We need smarter compilers that can understand smarter languages, not more complex languages to feed to still-quite-dumb parsers.

As an example, consider a composite method invocation foo.bar (a1, a2, bar.baz (b1, b2), a4);

There is no need for the semi-colon - we know exactly where the expression ends.

There is no need for commas between arguments - it's obvious from the brackets where the second invocation starts and ends and thus obvious where all the arguments go and in what order

And that's just off of the top of my head - gimme some time and I'll point out a whole slew of other stupidities forced upon the human programmer by the computer language that makes reading code a real pain in the rear. Sure, static is needed - but why is it needed for hello world? Same goes for void - if the method/function returns nothing, just leave it blank (oh, but we can't do that because then the compiler becomes difficult to write!!!).

Re:There are problems with new languages

[vux984]

Precisely. They needed a way to tell the lexer nothing gets returned from this and they wanted it to be concise. Asterisk represents a pointer so yes it is different

That was a rhetorical question. I could probably draw the C syntax tree in my sleep. The point was the lack of consistent meaning for 'void'.

Makes sense to me it would support static members.

It makes sense it would support what we call static members in C++. Its a lot less clear that it makes sense to call them "static" except to be consistent with C++

That's all I'm saying.

Re:There are problems with new languages

[serviscope_minor]

But until someone young with a new paradigm for translating human intentions to machine code comes around, we must stick to all that context free grammar stuff.

So, C++ is the new paradigm? :)

(yes I like C++ and yes I concede it's grammar is not the nicesest out there)

Re:There are problems with new languages

[Anonymous Coward]

Programming languages have to be context free which is why we class them as context free languages.

Er, what? Roughly speaking, if a language is context free you can parse the structure of an entire program without keeping track of what the identifiers refer to. In other words, you don't need to retain any context. Standard Pascal is context free but in C and C++ the parser needs to know if an identifier is a typedef or not to determine the correct parse so C and C++ are not context free. Pascal, C and C++ are, however, all programming languages.

Re:There are problems with new languages

[Anonymous Coward]

u 'spergin, scrote?

Re:There are problems with new languages

[Anonymous Coward]

A language from the lisp family might address all of these problems. I suggest Common Lisp or Scheme.

Re:There are problems with new languages

[Anonymous Coward]

I get your points, that is why I mod you insightful.

But what you do not get is that words make only sense in the social context. For example, in Germany we all speak German, but there are new words in north Germany and south Germany and different meanings of the same words in north/south. Some English words have different meaning in different English speaking countries. Although some words keep their meaning over 1000s of years (like for example, the word water), many words have different meaning in time and geo-location and in different context (for example the word gay).

So while it should make more sense to use different words for "static" or "void" it is now established meaning that almost all programmers can agree to. That "void" means no return, or no type, and "static" means it's global (global variable or method). Of course the meaning will differ with the language used, just like any natural language change the meaning of words in time, space and context.

So if a novice is asking "What is the meaning of void foo()?" Then he or she just needs to grasp the difference of the English word "void" and the word "void" in the context of the programming language. Just like a novice lawyer needs to craps the difference between the English word "prejudice" and the lawyers term "prejudice"

Re:There are problems with new languages

[narcc]

I wouldn't say that. Neither would Linus Torvalds, as it turns out.

Not that it didn't have it's share of problems. (Of course, I would say the same for any language.) It certainly wasn't broken in some fundamental way. It's apparently fun to bash, but you'll find that most criticisms are either empty or pitifully shallow.

The REAL problem people have with VB is that it was absurdly easy to learn and use. This caused two problems:

  1) A Lot of crummy amateur code was produced that needed to be maintained by more experienced staff. That's not the fault of the language. Being easy to use is a good thing, after all! Of course, dealing with all that crummy code didn't exactly inspire a lot of good will from those who had to clean up the mess.

  2) As it was so simple that an absolute beginner could learn the basics of computer programming near instantly (and produce real, working, programs) it became a real threat to a large and vocal group of insecure developers. Believe it or not, some people actually believe that the ability to write computer programs requires a "special mind"! Having that skill makes them feel special, smart, and important. Having no other skills, they rightly felt threatened by VB. Never mind that half of Slashdot taught themselves to program between the ages of 8-12. (Hell, back in the 80's, computer programming as a hobby among pre-teens was so popular that there were tons of children's books that included type-in programs. Some, like the Magic Micro series, were targeted at early readers. Other books had type-ins that the reader had to modify or debug to solve the protagonist's problem and progress the story. There were many others aimed at teaching computer programming directly to the 8-12 set.) They've got a lot of their ego wrapped up in a skill that the average child can learn on their own VB, aimed at professionals, threatened more than their jobs; it threatened their ego. Can you really blame them for spreading FUD?

The remaining hate seems to come from the same kind of people who believe GOTO to be inherently evil. They don't really know why VB was horrible, only that "everyone" says that it is. It's an easy meme to put out there as they're likely to get a good bit of praise for their comments and unlikely to get much (if any) criticism for restating their borrowed opinion. It makes them feel like part of the community. It also makes them feel smart for holding the majority opinion, even though they didn't form it on their own.

Re:There are problems with new languages

[bruce_the_loon]

The point was the lack of consistent meaning for 'void'.

ANY pointer, be it int*, char*, void* or object* is a pointer to absolutely anything. Allowing a pointer to be of type void makes sense for defining functions that accept a pointer to several data structures that will be cast into the right form in the function.

Re:There are problems with new languages

[The_Noid]

HashMap intNames = new FancyDoodle();

You can't express that with just the var keyword, but it is a very important distinction.

Re:There are problems with new languages

[angel'o'sphere]

That is actually the definition that they were probably going for. It is fixed and stationary at compile time. It does not move in and out of memory.

No, this is not the case. As this is also true for all other C variables. They are permanent and don't go away ...

As I said in my post a few posts back: static variables or functions in C are invisible to the outside world. In C# or Java that would correspondent to "private".

The problem in C is the linking. You have two files, where one file is referring to a function or variable in the other file:

fileA.c:
int my_counter = 0; // a variable that is never going away and "permanent", but not static
static int something;

int doit() {} // a function

fileB.c
main() {
doit(); // call a function in a different compilation unit (in this case fileA.c
}

static int my_counter; // this counter is different from the one in fileA.c and as it is static no other C file can refer to it.

Well, C is a little bit more complex as you usually would explicitly "export" a variable that should be refered in other files.

So you might write: "export int myVar;" This indicates to the compiler that "somewhere else" a variable called myVar exists.

Anyway: we use the keyword static in Java and C# only for one reason: C# is modeled after Java, Java is modeled after C++, C++ did not want to invent new keywords (as for quite a while C++ aimed to be a better C and to be able to compile any C code, a new keyword bares the risk to clash with a funny variable or function in some legacy C code) and C had a keyword that seemed appropriated: static.

Your english looks very good to me, so I would asume you are a native english speaker.

So: what is so hard in understanding that if you invent a new language that you obviously don't use the ancient keyword "static" for class variables or class methods but rather use "class_scope" or something similar?

A house is static, a bus does move a variable is either mutable or const/final but "static"? Hu? A variable is static? So if it is, the opposite is then? Volatile?

The best programming language imho was and will be: Pascal.

It is the only language that explains on 3 pages of paper how computers work and what the relevant constructs of a programming language are.

All other languages, and that includes Python, can in my eyes only be effective taught or learned if you already can program. Note the word effective. Sure, everyone learns a programming language in university. And 80% of the people say: wow, I ever thought programming is so complicated. Why do they say that? Because of the mental clash of words that they use in daily communication with the meaning of that word in the programming language.

(Especially if you are french or german and the programming language is english based)

You are a good example for it, as you did not know or understand from my first post/example what "static" means in C. Your assumption what it means was wrong. It is pretty hard to have "no assumptions". Your mind jumps to assumptions and conclusions automatically. Pushing this back and realizing: "oh, I don't know it, I have to look it up!" is pretty hard.

If I say "look at this blatonga!" your mind stops and tells you: "erm, a blatonga? What is that? I have no concept or association to this 'symbol'" so you stop and you ask. If I say: "look the problem is is simple, that there is static but it should not be" your mind does not stop, as "static" is a known word, however did you comprehend the meaning of my sentence? Are you sure you did? Frankly: you only think about this now because I asked you. If I would say a sentence like above you would not consider it a second though if you

Re:There are problems with new languages

[Kielistic]

We need smarter compilers that can understand smarter languages, not more complex languages to feed to still-quite-dumb parsers.

No, we don't. People make these claims every once in a while but they are never well thought out. A compiler will never understand natural language for the simple fact that not even humans can understand natural language anywhere close to 100% of the time. Natural is not designed for that . Programming languages are and that is why they are different.

There is no need for the semi-colon - we know exactly where the expression ends.

Do you? always? In a powerful language it will never leave ambiguities? Many languages do get rid of semi-colons for probably the reason you state. JavaScript will "inject" them if it find a place you probably wanted one. Some people like that and some don't but almost all the big players use them. Perhaps get rid of periods in English because you should be able to figure out where the clause ends.

There is no need for commas between arguments

Even English uses commas to separate a list. The commas are there to be more like natural language and be easier to read for both computer and human. Or should we ditch the comma in English too because we can probably figure it out from context?

The two examples of what we should get rid of in programming languages to make it more natural for a human are examples of things from human language. Most of the top 10 list of spoken languages use periods to signify end of sentence. C derivatives use a semi-colon but it's the same concept: separate things to avoid ambiguity.

(oh, but we can't do that because then the compiler becomes difficult to write!!!).

Several languages do that very thing.

Re:There are problems with new languages

[Laxori666]

True. Subtyping makes it less straightforward. If you really need to have the variable typed as the superclass, then you can specify it explicitly. But when you don't then it saves a lot of time - both thinking, typing, and reading - to have `var`, I think.

Re:There are problems with new languages

[Anonymous Coward]

There is no need for commas between arguments - it's obvious from the brackets where the second invocation starts and ends and thus obvious where all the arguments go and in what order

OK, take

foo.bar(1, -2)

Here, if you omit the comma, then you'll suddenly have one argument (one minus two) instead of two arguments (one, and minus two). You'd have to write an extra parenthesis,

foo.bar(1 (-2))

to get two parameters in a comma-free argument list. That's hardly more intuitive than the comma version.

The commas are not there for the compiler (it would be trivial to write a parser which just starts a new argument whenever the next character cannot be parsed as part of the current argument's expression). They are there for the humans. When reading the code, it's much easier to tell the arguments apart if there's a comma in between, and it also reduces the number of bugs introduced while editing code, e.g. without commas, changing foo.bar(2 2) to foo.bar(2 -2) instead of foo.bar(2 (-2)) when you want to reverse the sign of the second argument would be an easy to do mistake.

Re:There are problems with new languages

[Kielistic]

New languages should not reuse "static" again, but rather use a new keyword that makes clear for the layman what we are talking about.

You cannot make programming clear to the layman. The layman does not understand programming nor its concepts. Changing the keywords does not affect that. One way or another they need to learn it. If you call static members shared what happens when something else is "shared" but in a different way? What happens now when they work in an established language (which most of the world will still be using) and now they need to understand what "static" means anyway. Why change how we've been using it for years?

Re:There are problems with new languages

[angel'o'sphere]

Hm, seems you are slow in catching up with those many posts on this thread.

Originally in C static "members" where not shared it is the opposite, they where private only visible inside the compilation unit where they where defined..

So why do you suggest "shared" as a replacement of "static"?

Also in Java or C# static does not mean shared, so why do you suggest this word?

Obviously you either don't want to read long posts or you simply don't understand/comprehend what I say.

There was once a series of conferences called HOPL. I think there are 3 books available covering the conference lectures: History of Programming Languages. I suggest to read at least one of them.

Re:There are problems with new languages

[Anonymous Coward]

New languages often have words with different meanings. Which part of "new language" don't you get? Some languages are harder to learn or use than others.

That's not all. Here are another bunch of words to learn:
http://en.wikipedia.org/wiki/Software_design_pattern#Classification_and_list

If you learn them you can communicate certain programming concepts more concisely and precisely with someone/something who also knows them.

Is a language or jargon is worth learning? Depends...

Re:There are problems with new languages

[Anonymous Coward]

Yes. When I later write:

intNames = new LinkedList()

I almost certainly want that flagged by the compiler, because I don't want to try and debug whatever stupid result ends up being computed by the surrounding code based on that assignment.

Re:There are problems with new languages

[Kielistic]

C does not have static members, static members are an OO thing. In C the "static" bit had nothing to do with where they were visible but to do with how they were placed into memory.

Also in Java or C# static does not mean shared, so why do you suggest this word?

Yes it does. That one reference is shared amongst all instances of that class. Do you see now why natural language isn't a good match for programming? I don't suggest that word; I'm happy with static because it has a clear and defined meaning in the context of OO programming (I'm pretty sure at least VB uses shared for this meaning already though). You wanted a new word but no words seem to be good enough for you.

Re:There are problems with new languages

[SlowMeDown]

I share your frustration. I have been programming, and have taught, in various languages for about 30 years. (Getting old) I started on a TI-99 writing a word processor in Basic. Each language that I mastered left me thinking that there has to be something better. With each progression of languages I have seen improvements and mistakes. Languages that use different definitions of the same keyword are a good example of a mistake. The elimination of the GOTO statement was an improvement. (The elimination of the GOTO is largely due to the teaching proper programming technique.)

My teaching career was about 4 years long. It was all part-time at night, to help pay the bills. My first thought was that I could teach anyone to code. It is easy. And it is, when you start with a language that is designed for teaching. Pascal is one of those languages. (Pascal was originally never meant to be used in a production environment.) What I learned was that you have to teach the intent of programming before teaching the language. (Remove the mundane task from the end user.) Your example of 5 things first example brought back memories of the first day of class for new students of C/C++/Java. I just resolved that the first day would be this: explain the each piece of “Hello World.”, send them to the lab to do it themselves, and be available to answer questions of the students that really did want to learn a language.

In the end, each language has three parts, a way to store, a way to compare, and a way to get really loopy.

Re:There are problems with new languages

[vux984]

Allowing a pointer to be of type void makes sense for defining functions that accept a pointer to several data structures that will be cast into the right form in the function.

Does it really? Why not have an indeterminate type keyword... "unknown", "anything" or just a keyword "pointer"? Why does it make sense to reuse the void keyword which literally means "nothing"?

It is not a pointer to void. There is something there.

Look, I get that it 'works'. In the sense that its not broken, and that there even is a perverse logic to it. But you can't possibly really think it is the clearest way imaginable to express a pointer to 'something' is to call it a pointer to 'nothing'.

Re:There are problems with new languages

[goose-incarnated]

We need smarter compilers that can understand smarter languages, not more complex languages to feed to still-quite-dumb parsers.

No, we don't. People make these claims every once in a while but they are never well thought out.

Just because you don't understand the deficiencies doesn't mean that they don't exist

A compiler will never understand natural language for the simple fact that not even humans can understand natural language anywhere close to 100% of the time.

But that is not what was argued - we aren't arguing for a natural language programming language; we're asking for one that's simpler to read, even if harder to implement. What we have are harder-to-read-but-easier-to-implement languages (and yes, I've implemented a few in my time).

Natural is not designed for that . Programming languages are and that is why they are different.

Incorrect. Programming languages are they way they are due to ease of implementation, not ease of programmability.

There is no need for the semi-colon - we know exactly where the expression ends.

Do you? always? In a powerful language it will never leave ambiguities?

Yes. See lisp.

Many languages do get rid of semi-colons for probably the reason you state.

And some languages never had them.

JavaScript will "inject" them if it find a place you probably wanted one. Some people like that and some don't but almost all the big players use them. Perhaps get rid of periods in English because you should be able to figure out where the clause ends.

There is no need for commas between arguments

Even English uses commas to separate a list.

What makes you think arguments/parameters are a list?

The commas are there to be more like natural language and be easier to read for both computer and human. Or should we ditch the comma in English too because we can probably figure it out from context?

You are making strawmen arguments: No one proposes to replace commas because we can "probably" figure it out, we propose to replace them where they can always be figured out. In much the same way, I never proposed that natural language is a replacement for computer programming languages, only that current computer programming languages are descended from languages that are easy for a computer but hard for a human, hence there are many things that are superfluous.

I suppose you might think differently after you get some experience under your belt. I thought pretty much the same way when I was a newbie at programming too.

Re:There are problems with new languages

[Common Joe]

You have some very interesting things to say. I'm going to comment on a couple of them.

What is so hard in having methods be PUBLIC by DEFAULT and attributes PRIVATE by DEFAULT?

Agreed. As a matter of fact, I'm tempted to go one step further. Why not have settings on the compiler decide some of this so there is no doubt? Or (my personal preference) require the words public and private when coding.

It does not mean it needs a keyword "static", nor "func"

I like the word "static" in the Java language. I think it has a good purpose and I'm not sure I can come up with a better descriptor word for its purpose.

func and void are interesting ideas. I'm mulling over whether or not we (as programmers) should do away with the notion of functions entirely. They are redundant and can be covered by "methods" (or by my preferred word "subroutines"). Methods can have in/out variables meaning they can return one or more variables at a time unlike a function. The only advantage a function has is that a programmer can define a variable while calling a function: string someVariable = foo(). I don't see why we can't define it earlier in the program or define it in while calling the method. I'm entirely convinced my idea is a good one, but I think it could work.

As far as your opinion about static void main(String[] args) { ... } and how confusing it is to a student, that is easily overcome. Just tell the student "Don't worry about what all of that means right now. It will make sense within a couple of semesters. Treat it like magic. It's required to make the magic work." It's that simple. Of course, if you have moron professors (like I did), then they just treat everything as magic and never really teach you how to program. It took me 3 semesters to understand what the concept of an object was... and I had been doing procedural programming as a hobby for years. (This was back in 1998.) The issues of a programming language can be masked until it is time to reveal how the magic works if you have a good teacher. If you have a bad teacher then no programming language (no matter how good it is) can help.

how the fuck do you explain someone who starts programming what "static void main(String[] args) { ... }" is supposed to mean?

In Pascal this is just: "BEGIN .... END." // note the period

From what I recall of Pascal, that is because it is a procedural language vs the object oriented nature of Java or C#. There needs to be a way to define a subroutine by name with arguments which kicks off the program. Static has a very specific meaning which is required for both Java and C# -- or any object oriented language for that matter. Every word and character (except for void) is "required" in some form or fashion. C# is interesting (and different from Java) where String[] args is optional and main does not have to start the program. I like these features, but to truly understand why they are optional, you need to dig pretty deep -- something that won't happen on the first day of class. In any case, for a new programmer, there will be some hand waving to say "don't worry about it now" and "we'll get to that later".

Finally, you say something about not liking semicolons. I like them because it is clear when a single function is done being written. Although I usually prefer one command per line, I'm not forced onto one line. I can pile up several commands on a single line if they are short or break it up if they are long. It all revolves around readability and maintainability when I or someone else comes back to read the stuff later.

Re:There are problems with new languages

[The_Noid]

Unless you don't assign a value at the time of definition, which is 90% of the cases.
Or you assign the return value of a method call.

In most cases you can't visually determine the type from the value assignment, so you'd have to specify the type any way. And that makes the var keyword superfluous.

Re:There are problems with new languages

[Kielistic]

I'm only trying to figure out what you want. Programming languages are too hard and your example of something that can be done differently is Lisp? Lisp, which is even harder for a human and easier for a lexer than C, is your shining example?

The problem I have with your argument is that you don't have one. "Programming languages are too hard. They should be made easier for the human at the cost of harder for the computer". That's a fine statement but it offers no insight into what you actually think you want. I know full well that programming can be hard for people to understand and see its deficiencies. I also think things like Dart are addressing those problems.

No one proposes to replace commas because we can "probably" figure it out

There is no need for commas between arguments - it's obvious from the brackets where the second invocation starts and ends and thus obvious where all the arguments go and in what order

I can't say I like your suggestion of random brackets when needed (as explained by somebody below) in place of a simple, straight-forward, natural language inspired comma delimited list. Honestly that sounds pretty terrible to work with as a human.

What makes you think arguments/parameters are a list?

Because that's exactly what they are. I don't care if you can claim they are something else. It is a list.

I suppose you might think differently after you get some experience under your belt. I thought pretty much the same way when I was a newbie at programming too.

Trite, passive-aggressive insult aside, what do you think now? Make a fully formed thought about how to make programming "better". Your examples have been shown as nonsense (or already implemented). You want things "easier" but you have no idea how to do that; you just want someone else to do it. Now when someone tells you why things are the way they are you stamp your feet and make insults. You claim to have implemented some languages in your time but you haven't shown much understanding of the theory behind it.

Re:There are problems with new languages

[goose-incarnated]

I'm only trying to figure out what you want. Programming languages are too hard and your example of something that can be done differently is Lisp? Lisp, which is even harder for a human and easier for a lexer than C, is your shining example?

Nope. Lisp is harder for those programmers already indoctrinated into imperative programming. Google for the studies that show languages like scheme being easier for people who have never programmed before. The only reason you find lisp-like syntax hard is because you are looking for all those deficiencies (like static, and commas) that you are used to.

What makes you think arguments/parameters are a list?

Because that's exactly what they are. I don't care if you can claim they are something else. It is a list.

Of course it's a list if all you know are lists - they may make more sense as a set, or a dictionary, but you wouldn't find out about that if you insist that they have to be a list. Of course it's a list if your definition of "arguments" is "list"

I suppose you might think differently after you get some experience under your belt. I thought pretty much the same way when I was a newbie at programming too.

Trite, passive-aggressive insult aside, what do you think now? Make a fully formed thought about how to make programming "better".

Now I know better - you want static and commas only because that's all you know. Many experiments and studies on the human mind show that (for example) OO is completely unintuitive to the human mind (random example - look up Donald E. Normans papers on Man/Machine interfaces).

Your examples have been shown as nonsense (or already implemented).

Nope - All you've done is say that imperative languages can't do without these thigns, which is not what I was arguing anyway - imperative languages need these crutches because of their deficiencies. GP posted a lot of insightful thoughts on this, which you dismissed with the fully untrue "already been done". Do yourself a favour and just experiment with implementing a large non-trivial system in (for example) Erlang.

You want things "easier" but you have no idea how to do that; you just want someone else to do it. Now when someone tells you why things are the way they are you stamp your feet and make insults.

I'm sorry that you really are inexperienced, but only you You claim to have implemented some languages in your time but you haven't shown much understanding of the theory behind it.

I've got all the experience and math theory behind all the automata and turing-completeness and all the other buzzwards, which is why I've experimented with different languages (both using and designing and implementing). One day you will, too.

Re:There are problems with new languages

[angel'o'sphere]

C does not have static members, static members are an OO thing. In C the "static" bit had nothing to do with where they were visible but to do with how they were placed into memory.
You are wrong. (And I did not say "memebers" I said variables and functions)

myFile.c
      int a;
      static int b;

Boss ints are in the same memory. B is invisible to the outside, that means other C files can not reference it, b can be referenced by other C files.

myOtherFile.c
      extern int a;

The extern declaration will tell the compiler "somewhere" is an int named a and the linker will find and resolve it.
      extern int b; Will also tell the compiler "somewhere is an int b" but the linker will complain and not link it, because it is static! And may only be used inside of the file "myFile.c"

Yes it does. No it does not That one reference is shared amongst all instances of that class. Do you see now why natural language isn't a good match for programming?

A static variable is a class variable. That means it belongs to the "class" not to the objects. Calling this "it is shared between all instances" is simply plain wrong or at least so misleading that it only can be used as a simple catch phrase for beginning programmer.

As I said before, you seem not read carefully: static has absolutely no meaning in OO Programmin in genereral. It only has meaning in C++, and was adopted from there by C# and Java. All other mainstream OO Languages call it what it is: "a class variable" or a "class method".

You wanted a new word but no words seem to be good enough for you.
In computer programming "shared" already has a meaning. And static is something different (which you fail to comprehend), the correct keyword instead of "static" would be "class scope".

You are the best example why I'm right.

All your assumptions what static means, ARE WRONG. Only your halfassed "oh well it is shared between all instances" is semi right. What happens if no instance is existing is the "shared variable" then gone???

All the stuff I told you, you simply can confirm by googeling and reading the relevant articles on Wikipedia and Stackoverflow.

Re:There are problems with new languages

[angel'o'sphere]

Well, for all purpose you can consider a method very similar to a function. Initialization of variables e.g. can as well be done with methods ofc.

Instead of taking over the "main" method/function into Java and C# etc. it would have been evenly convenient to either:

a) also naming the name of the start method on the commandlin (e.g.: "java my.fancy.Class", this calls the static main method, "java my.fancy.Class.startUp", this calls the "startUp" method, no main() needed)
b) simply require that the "main class" can be instanciated and use an appropriated constructor

Most other OO languages don't use the word static. As I explained in my posts it migrated from C (where it ment something utterly different) into C++ (where it either means the same as in C or the same as in Java/C# depending on context) and ended finally up in Java/C# with the "new meaning" which it got in C++ :D

I think the semicolon thing was another guy, I don't really misslike them, in fact in groovy where semicolons are not required I still wrote them for a long while.

Re:There are problems with new languages

[Kielistic]

Google for the studies that show languages like scheme being easier for people who have never programmed before

I don't care what language makes it easier to explain to someone how to write "Hello World" as their first program. What a useless metric. What matters to me is professional use. Building large, extendible and maintainable products for common use (and maintaining other people's code). Scheme and Erlang are not inherently easier than C++ or C# because you still need to understand the underlying concepts. There is no "indoctrination"; the fact that imperative "won" is pretty good evidence that the common programmer "gets" it more easily.

So your claim to fix deficiencies in modern languages is just Erlang? Yeah it really seems like you've thought this out well. Erlang is a great language for some things; terrible for others. More "intuitive" to humans is fairly easily debatable.

Again with this inexperienced crap (I think? You appear to have screwed up your post. Perhaps you could have some use of more experience using computers). As if you think some loose claim of inexperience somehow discredits what I have said and makes you right. My point still stands: most people who point out modern languages are bad haven't thought out their claim. They haven't considered what they lack or what they should have. Your handwave to convert this into a functional vs. imperative debate shows that.

Modern languages like Dart and C# allow you do do some pretty functional style programming. Maybe you should check them out. You might like them.

Re:There are problems with new languages

[Kielistic]

Originally in C static "members"

(And I did not say "memebers"[sic] I said variables and functions)

Oh really?

The limiting of scope on C static variables is not why it was named static! It was named static because of the way it was stored in memory. It is "static" for the length of the program.

A static variable is a class variable.

I know what a static variable is and I know why it is called static. The fact that some modern compilers / interpreters use lazy loading on them does not change the fact that they are meant to be "static" in memory and access to the program. Static has a meaning in this realm now. It has a contextual definition. "Class scope" is an awkward keyword (it's actually two words by the way) and does not make it any easier to explain.

What happens if no instance is existing is the "shared variable" then gone

No, it's not. And you know why? *drumrole*... Because it's statically allocated and statically accessed. That's what static means.

Re:There are problems with new languages

[angel'o'sphere]

I told you now ten times: you are wrong.

A static variable is not static for the length of the program, whatever you want to say with that.

I can assign it values as often as I want.

You are even to dumb, to copy paste my simple example of two c files into an editor and compile and link them.

Because if you would do that you had figured meanwhile: I'm right. And you are wrong.

Your last line is even more wrong and clearly states that you have not much clue about computing.

Yes, ofc the static variable still exists. Hence it is not a shared variable of the objects. And no, that is where you are wrong' in C# and Java it is not statically allocated. They live on the heap in the class. That is why it is called in computer sciense 'class variable' or 'class method'.

As I pointed out in my C examples, here my final one:
sample.c:
        int a;
        static int b;

        func() { static int c; }
------

All variables above are "static allocated". Also 'a'! And as I explained before: the static does not mean static allocated it means: only vissible in this scope.
The variable a can be referenced by any C file linked with 'sample.c'. The variable 'b' can't because the linker wont allow it, it is confinded to the sample.c/sample.o file.
The variable 'c' however is something special, and I'm tired to explain you what it does and how it works as you have shown so far: you have no clue about what you are talking and you either are to dumb or to full of hatret to comprehend what I type.

Hint: program a week in C.
Then program a week in C++.

Then: figure where C# puts its "static variables" and how Java does it ... and then please have the dignity to facepalm.

Re:There are problems with new languages

[JesseMcDonald]

Why does it make sense to reuse the void keyword which literally means "nothing"?

Because, as far as the type is concerned, it is a pointer to nothing. Given just a void pointer, the only safe assumption is that there is nothing there. It's like a pointer to a zero-length array or an empty structure. You have to perform a typecast, and thus tell the compiler that there is actually something there, before you can do anything with it.

Re:There are problems with new languages

[Kielistic]

Okay, if you're going to get insulting I'm going to stop being nice. You are wrong, you are dumb. You do not understand what static means. Perhaps it's a language barrier but you are wrong. Static does not mean constant-valued and I never said that. The memory is in one place and not deallocated.

Here is what Wikipedia has to say on it: Static Memory Allocation. That is what the static means in C and that is why it is static in OO. Because it behaves the same as it does in their example. Static has shit all to do with scope.

Here's some more Wikipedia: Static Variable. It shows that you have no idea what you are talking about. Notice how their C example doesn't even mention scope? But it does talk about how it is initialized into memory.

The fact that you claim with such authority what static means and with the most cursory of Google searches shows you are wrong is hilarious. What has your 30 years of experience been in? I hope it wasn't C because I only consider myself low-intermediate in C and I apparently understand the concepts better than your worldly experience.

Re:There are problems with new languages

[Kielistic]

Global static variables do behave differently in C. I am now guessing this is where the confusion is. I was never talking about global variables; only the local definition ones because that is where the static is drawn from for OO.

Re:There are problems with new languages

[angel'o'sphere]

Global static variables do behave differently in C. I am now guessing this is where the confusion is. I was never talking about global variables; [...]

So? Is that so?
So what exactly does this in C mean:

func() {
    static int x = 0;

    x++;
    return x;
}

only the local definition ones because that is where the static is drawn from for OO.
'x' is a local variable, and it is only accessible inside of func(). And yes you are right: it is statically allocated. So what now? Which other parts of the programm can access it?
None ... It is also "private" to func()!!!

What has that to do with OO? Nothing ... and OO did not draw its meaning from there.

OO is not C++ or Java or C#.

OO is CLOS, SmallTalk, Simula. C++ came decades later. And Java more than another decade and C# nearly even also a decade after Java. OO did not "draw" anything from static.

The mixup what static could mean, should mean, implies to mean, in this or that language started around 1980 with C++. All other OO languages before that did not use this "keyword". Because it is not the right one ;D

But I grant you now: this post of yours shows you started to think ... even as you think slowly and still need time to get further, it is a start.

Good luck on your journey into programming and the stuff behind it ,,,,

Re:There are problems with new languages

[Kielistic]

Of course it is private to func, all variables declared inside of a function in C are "private" within it. That's how scoping works. It is not private because of the static keyword. The static there is describing its storage duration/memory allocation. Now I am not entirely sure why the C devs chose static for internal linkage but I'm guessing (hoping) they had a reason that had to do with the compiler. It seems that these reasons are just glossed over anymore. Probably because modern compilers don't do it like they used to. I would love to find somebody that knows the answer to this.

Now with that said your problem with the static keyword has still been resolved. C was designed nearly half a century ago. Modern languages do not use the static keyword to define "file" level scope. They use it to define storage duration like a static variable in a C function in which it is an excellent identifier.

Re:There are problems with new languages

[goose-incarnated]

Modern languages like Dart and C# allow you do do some pretty functional style programming. Maybe you should check them out. You might like them.

That's just the thing - I have checked them out, and I have used them, and I like them just fine, so I'm not talking down at you from some ivory tower place. You really should look at the research being done with regards to human learning and cognition to understand why the current programming languages (very few new concepts in the last 20 years or so) have not kept pace with what we now know. Stagnation is not good, else we would've evolved assembler to brainfuck, and not C.

Your argument seems to be that it's okay to be using concepts from 20 years, or even 25 years ago, because what we knew then is still state of the art right now. Even the semantic web people (as hopeless as I think their research is) are trying new things. Your argument is based purely on emotion: this is what you like therefore it must be good. Current evidence isn't in your favour, which you would know had you even bothered to look it up.

Finally, you're pretty inexperienced, and me saying that is not meant to be an insult, just to highlight where your actual shortcomings are in this discussion. You are arguing from the position that you have no shortcomings, but something like inexperience is pretty easy to spot. I'm not going to reply anymore - you clearly won't change your mind no matter how many researchers publish their findings (yeah, I did language research for a few years at a science research facility, so I've read most of the publications dealing with this), and you haven't even attempted to find any programming-languages publication to check if I'm talking horseshit or actually repeating what various well-respected scientists are saying: you feel your few years of programming are enough to make you an expert, nevermind those people who devoted decades to studying just this and nothing else. So ... no point in replying to you. Take care.

Re:There are problems with new languages

[vux984]

Because, as far as the type is concerned, it is a pointer to nothing.

Its a pointer. If its initialized then it points to something. The type of that something is unknown, but its not nothing.

Given just a void pointer, the only safe assumption is that there is nothing there.

True for any pointer. :p

It's like a pointer to a zero-length array or an empty structure.

So void is a type with a sizeof (void) = 0 ? (Nope -- its either a compile time error which is sort of ok, or apparently gcc defaults to compile that to "1" which is truly horrific.)

You have to perform a typecast, and thus tell the compiler that there is actually something there, before you can do anything with it.

We know something is there, we have to typecast to tell the compiler what it is.

Working backwards, if we take the void pointer to mean a pointer to something without type information, then for consistency a void function is a function that returns a value of indeterminate type. But its not, it's a function without a return value at all. Its not semantically consistent.

There is a semantic difference between "something is there but its type is unknown" and "nothing is there at all". In C, void can mean either, depending on whether it is a void pointer, or just void.

Re:There are problems with new languages

[JesseMcDonald]

Its a pointer. If its initialized then it points to something.

No, it doesn't point to anything. It's just an address. If it pointed to something then that something would have a well-defined (non-zero) size and type.

So void is a type with a sizeof (void) = 0 ?

It should be, but some ancient versions of C allowed pointer arithmetic on void pointers as though they were pointers to bytes or characters, and support for this was retained, at least in the compiler if not the standard, for backward compatibility. The sizeof operator is defined such that (char*)(p + 1) == ((char*)p + sizeof *p), which implies that sizeof(void*) must equal sizeof(char*) for the pointer arithmetic to work out the same. No modern, well-behaved program should be doing pointer arithmetic with void pointers or using sizeof(void).

We know something is there, we have to typecast to tell the compiler what it is.

We know, but that knowledge is not represented by the void pointer type. The type says "nothing is there", and we have to override that with a typecast to say that there is something there after all.

It really seems like you want the use of "void" to be inconsistent, and are deliberately choosing an awkward interpretation (undefined type vs. the more obvious empty type) in order to make it so. The use of "void" meaning "nothing there" is perfectly consistent between void pointers, void functions, and void expressions.

Re:There are problems with new languages

[Kielistic]

You never said how to make things better. Just that research says it's bad; handwaving. I love new programming languages and I love new ideas. What gets annoying is trite "we need to stop following 20 year old conventions". We don't follow 20 year old conventions; we take what we like and change what we like. I never talked about my shortcomings and no shortcomings of my own change the fact that you still never even gave a valid example of how to make things better. I've got no problem with talking about how to make things better. What I hate is what people here call "karma-whoring" or grandstanding. The original post was basically taking a popularist opinion with incorrect reasoning to back it up. Don't go on about how the whole world is wrong when you don't have an understanding of why things are done the way they are.

Re:There are problems with new languages

[vux984]

No, it doesn't point to anything.

So a void pointer isn't a pointer. Clear as mud.

It's just an address.

Bingo! So why not reserve the keyword 'address'. And call it that? Its just an address. "address" is simple, and everyone gets it. There's no indirection operator raising questions about whether you can deference it. Its just an address. Its meaning is clear. How you would use it is clear.

It makes a hell of a lot more sense than void*.

Re:There are problems with new languages

[JesseMcDonald]

No, it doesn't point to anything. ... So a void pointer isn't a pointer. Clear as mud.

Again with the deliberately awkward interpretations. A pointer identifies a location in memory. The pointer's type gives the size of each item; the actual number of items (which can be zero) is not recorded anywhere. In the case of a void pointer either there is one item of size zero, or zero items of any size; take your pick. Either way it means "no data at this location". The existence of a pointer doesn't imply that there is anything at that location. Consider:

int array[10];
int *p = &array[10];

The variable p is a pointer to a location in memory, but it's past the end of the array. The item size is sizeof(int), but the number of items is zero. The code is perfectly legal—you're allowed to have a pointer to the location just past the end of an array—but there is nothing there. There may not even be a virtual memory mapping for that location.

The only difference between p and a void pointer, aside from pointer arithmetic, is that the compiler won't stop you from dereferencing p; you'll just get a runtime error, if you're very, very lucky.

So why not reserve the keyword 'address'. And call it that?

Perhaps because we already have this perfectly usable pointer syntax, which identifies both an address and a type, and rather than make up a completely separate "address" type and special-case everything for no reason we can just use a pointer to the existing "void" type, which already means "no data", because if we don't know the type of the data it might as well not exist as far as the compiler is concerned.

Anyone who really wants an "address" keyword for personal reasons can just write "typedef void *address".

Re:There are problems with new languages

[vux984]

Again with the deliberately awkward interpretations.

Its not 'deliberately awkward'. Its just awkward in its natural state.

In the case of a void pointer either there is one item of size zero, or zero items of any size; take your pick.

That's awkward. One item of size zero is awkward. Zero items of any size is awkward. The idea that either is valid and I can take my pick is awkward. Plus you forgot to mention that it could be many items of zero size too. But these are all just complicated ways of saying 'nothing'.

Its just plain awkward.

The code is perfectly legalâ"you're allowed to have a pointer to the location just past the end of an arrayâ"but there is nothing there.

And you did it all without void* too.

The only difference between p and a void pointer, aside from pointer arithmetic, is that the compiler won't stop you from dereferencing p; you'll just get a runtime error, if you're very, very lucky.

To paraphrase what you wrote: The only different between [other pointer type] and void*, aside from [this one difference], is that there is also [this other difference].

C also supports implicit conversion from void* to other pointer types... so that's a third difference between void* and other types of pointer.

So they are different one way, different another way, and also treated different a 3rd way.

And I'm the one being "deliberately awkward"?

and rather than make up a completely separate "address" type and special-case everything for no reason

But void* is ALREADY a special-case. It can't be dereferenced. You can't (shouldn't!) do pointer arithmetic with it. It implicitly converts to other pointer types. And every book on C requires a special section to talk about void* because its different.

Anyone who really wants an "address" keyword for personal reasons can just write "typedef void *address".

True enough, but that has nothing to do with language design.

And my goal here isn't really an argument to go back and 'fix C'; it's about designing new languages and questioning whether dragging along keywords and conventions from C really makes any sense. On the one hand its familiar for longtime programmers coming from C, on the other its needlessly obtuse for new programmers who are really just learning the new language.

Re:There are problems with new languages

[angel'o'sphere]

I give up.

You understand nothing it seems.

Now with that said your problem with the static keyword has still been resolved. C was designed nearly half a century ago. Modern languages do not use the static keyword to define "file" level scope. They use it to define storage duration like a static variable in a C function in which it is an excellent identifier. This is wrong. LAnguages running on VMs dont have any STORAGE CLASSES.

But forget it you are not even arguing for the sake of arguing but you have a complete twisted idea about how programming and compilers and for that languages work ...

Re:There are two kinds of programming languages...

[Pseudonym]

Yeah, exactly. What the writeup calls "appeasing a ceremonial type checker" is more properly called "debugging".

Don't get me wrong, I like the thrill of the chase, the satisfaction of tracking down a really hard bug, as much as anyone. But I like programming even more. Using a well-designed type checker, I can find bugs in my program and convince myself that I'm programming rather than debugging.

Commendable

[countach]

I like what I read. I'm always conflicted by my good experiences with untyped languages, compared to my good experiences with typed languages finding hard to find bugs. It's nice to see people looking at how they can be mixed. And I like they've added some stuff that Java lacks which is useful. (no such method) etc.

The trouble is: it looks too much like Java for it to be likely that anybody will bother. With all languages I usually end up thinking... is this as elegant as Scheme? No? So why bother. I think even CLOS type schemes can have the compiler do type checking, so what do we gain? Has anything ever surpassed Scheme plus whatever favorite libraries, or macro/ object collections you like? I don't think so. Scheme allows you to overlay pretty much anything onto its syntax. It always seemed like the final word to me.

Re:Commendable

[serviscope_minor]

Scheme allows you to overlay pretty much anything onto its syntax.

That, fundementally is the problem with Scheme and Lisp.

Syntax is purely an aid to human understanding. If you see for, do, while, etc you already have an idea of what't going on. In LISP and Scheme, much as in machine code you have a bunch of code (or is it data! no! it's both!) which the computer can churn through. In order to fully understand it, you have to read everything leading up to that point.

OK, that's hyperbole, but I hope you get the point.

The thing is you can overlay any syntax, and people do, because humans love syntax. The trouble is in scheme is that everyone does it differently. It's like C++ classes versus C classes. In C you can make them just fine with nested structs and function pointers. But everyone did it differently and reasing someone elses code is hard. Is this a class? Oh... looks like it, now how do I set it up. This construct function, that macro? In C++ they're all the same and you know what's going on.

A version of Dart that compiles to asm.js?

[ras]

For those of you who don't know, asm.js is a subset of JavaScript that's meant to be easy to compile. In other words if you use asm.js the code your will work in all browsers, but should run faster in some. In that FAQ they say their compiled asm.js runs at about 1/2 the speed of C, making it roughly twice as fast as JavaScript V8.

Which is wonderful, except that JavaScirpt is a prick of a language, and so I'd imagine that asm.js is a tedious, prick of a language. But Dart compiled to asm.js - sounds like a marriage made in heaven.

Re:A version of Dart that compiles to asm.js?

[MrBandersnatch]

and bugs made in hell :)

Re:A version of Dart that compiles to asm.js?

[marsu_k]

While I appreciate efforts to improve Javascript ($DEITY knows there's a lot of built-in retardness, although personally I'd appreciate most if ECMA Harmony would finally be implemented - not holding my breath though as I like living), I'm not sure I really asm.js is the way to go. However, their typing system is "interesting" - but it doesn't go far enough. I mean, it's great that you can have "intish" and "doublish" values, but why stop there? Print stringish stuff to the console, define your own objectish values in an arrayish structure, manipulate them with functionish methods - the possiblities are endless(ish)!

Type checking

[Anonymous Coward]

No type checking means worst code and more bugs.

yalwtf

[TomGreenhaw]

yet another language?

Re:There are two kinds of programming languages...

[Anonymous Coward]

Wait a minute. I'm a programmer BECAUSE I'm lazy.

Re:There are two kinds of programming languages...

[Anonymous Coward]

And then there's Haskell. A language people always *praise*!
(Also, Erlang seems to have a pretty good reputation.)

Sorry, only C-likes, with their shitty outdatedness and fuck-ugly aesthetics, get that constant bitching.

Yeah... that of course includes Dirt^WDart

Problems?

[flimflammer]

No more public-static-void-main-String[]-args just to start a program! Dart’s simple top-level main() function is all you need.

...Is this actually a deal breaker for some people in other languages?

Re:There are two kinds of programming languages...

[Anonymous Coward]

Java slave here. If I want to be lazy, I just put things in a Map. I know it's evil. EVIL. Typing is not just for you, it's for all those who come after you. It's documentation.
I find complex Javascript almost unreadable and hard to maintain.

Oh good

[Anonymous Coward]

Another piece of fluffy, superfluous tech from Google that will receive a lot of praise, while the competitors superior solutions that actually solve problems get negativity because they're not Google's tech.

Why Google always reinvents the wheel (this is just Ecmascript 6 without backward compatibility) and doesn't just use something that's proven (like Lua) is beyond me. Maybe not-invented-here syndrome.

I love how they continuously invent new tech on a whim and say it's a "standard", like Pepper, NaCl, WebM, et al, while ignoring other actual standards that fit the bill for YEARS just so when they reinvent it, people will say Google did it.

Re: What can't you do in C?

[j1m 5n0w]

Return a list from a function. Sure, you can legally do it, there's nothing in the language inherently stopping you, but experienced C programmers will avoid returning a list at all costs, because suddenly you have to care about whether the caller frees the list properly, and what if the things in the list are used elsewhere and we need to do reference counting etc.. etc... I've worked on a C codebase that was a couple hundred thousand lines of code, and I can't think of anywhere that we ever returned a list from a function. I can't think of any Haskell program more sophisticated than "hello world" that I didn't use "map" and other list functions all the time.

Ultimately, the cost of manual memory allocation isn't just the extra work you have to do to make sure you aren't leaking or corrupting memory, it's the algorithms you won't allow yourself to even consider because the memory management would just be too hard.

I'm not saying C doesn't have it's place, I'm just saying that there are software engineering costs associated with using C as opposed to a higher-level language.

var for yout types

[l3v1]

"Just experiment and use var for your types."

Well. I've been coding since I've first saw a computer (well, maybe with a few weeks delay :) ) I have yet to get to a point where I would choose a language _because_ I'd prefer those "var"s. Most things have a reason, and I've always thought of these dynamic type languages (with some exceptions of course, where you can't really do anything else) to target average people who don't want to deal with much, and who don't really create complex code. I wouldn't mind if all the world's sticky note apps would be written in Dart. Or whether checker apps. Or news ticker apps. You get my point. Otherwise, keep them out of my sight.

Re:There are two kinds of programming languages...

[gl4ss]

And then there's Python.

people bitch about python. at least I do.

                                      whitespace has effect. who has time for that..

Re:There are two kinds of programming languages...

[H0p313ss]

Those people always bitch about and those no one uses.

Since I have yet to hear any complaints about Dart, I can only assume it's in the latter category and no one cares.

We need these languages, not necessarily for working with them, but to inspire others. The experimental languages of the 60's and 70's begat Smalltalk, which influenced C++ and Objective C, they all lead nicely to Java and C#.

All of these influence the current batch of experimental languages.

What I want is the beauty of Smalltalk, the rapid development of Python, the library depth of Java, the speed of C++ and the pervasive platform of javascript.

If I could do web-client side scripting in a language like that I'd be happier than a pig in shit.

Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently. They’re not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them. About the only thing you can’t do is ignore them. Because they change things. They push the human race forward. While some may see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do.

Re:There are two kinds of programming languages...

[H0p313ss]

And then there's Python.

people bitch about python. at least I do.

                                      whitespace has effect. who has time for that..

Same, but it's almost my only complaint. Other than that it's an elegant language, my favorite for scripting.

Re:There are two kinds of programming languages...

[H0p313ss]

Yeah, exactly. What the writeup calls "appeasing a ceremonial type checker" is more properly called "debugging".

Don't get me wrong, I like the thrill of the chase, the satisfaction of tracking down a really hard bug, as much as anyone. But I like programming even more. Using a well-designed type checker, I can find bugs in my program and convince myself that I'm programming rather than debugging.

Agreed. The languages I've used the most would be Smalltalk, C++, Javascript and Java (in rough chronological order, some overlaps), two are weak typed two are strong typed.

After a day grinding out hundreds of lines of productive Java trying to do anything in javascript just makes me want to drown kittens... well perhaps kittens named Brandon Eich. (Sorry Brandon... I've just seen too many sins committed with your language.)

Dart compiles to JavaScript

[Mirar]

I found one statement interesting in the description of the language:
"Dart compiles to JavaScript"

How many other high-level languages do that?

Re:Dart compiles to JavaScript

[Anonymous Coward]

Most of them, in theory.

YAPLFLD

[SuperDre]

Yet another programming language for lazy developers.....
There are already too many flavors of developmentlanguages, everybody wants his/hers to prevail and is trying to come up with reasons why their language is better.. stop this BS.. looking at a lot of those 'spinoff' languages I mostly see stuff added in comparison to the 'standard-languages' which are clearly for lazy developers who don't know (or want to know) what they are doing.. And in the end all we end up with are slower applications even though our hardware is getting faster and faster, but due to the slow applications we hardly notice it when we upgrade hardware and software.. A great example is Android, when ported to C# (which already is also a 'slower' language/compiler as using real native compilation without a .NET framework) it was about 40%!!!! faster on average, which would mean an older device would run the same stuff just as good as a newer device with the current android, something tell's me it's a waste of my money to buy a faster device..
but then again, there are enough people who just don't give a damn..

Designing is thinking about types.

[master_p]

The article mentions that you can leave types aside for a moment, when you want to rapidly develop something.

That's the worst programming advice ever.

Good design starts from typing.

Re:Designing is thinking about types.

[Chrisq]

The article mentions that you can leave types aside for a moment, when you want to rapidly develop something.

That's the worst programming advice ever.

Good design starts from typing.

This is my feeling too, you will spend longer debugging and much longer supporting any significant sized project. However we must acknowledge that many people have an opposing view, that totally dynamically typed languages can speed up the total cycle not just initial writing.

Dart is a source code VM? Interpreter?

[Chrisq]

TFA says

Dart is a source code VM

Is this just a fancy term for an interpreter?

Re: What can't you do in C?

[Anonymous Coward]

Or return a function from a function?

Dart Is Not the Language You Think It Is.

[nospam007]

"Dart ..."

You keep using that word, I do not think it means what you think it means.

Any OO language can be used untyped

[allcoolnameswheretak]

You can treat any object-oriented language, such as Java, as an untyped/dynamic language by declaring all your variables, method parameters and return values "Object" and not using generics. It doesn't save you the typing, but the result is mostly the same. Of course, it won't allow you to do fancy Python stuff such as dynamically adding methods or values to existing objects, unless you want to get fancy with maps.

Re:Any OO language can be used untyped

[Anonymous Coward]

I don't think the majority of OO languages work the way you think they work.

But if your point is that Dart is uninteresting, I do agree.

Re:There are two kinds of programming languages...

[dreamchaser]

That must explain why so much software sucks these days, as well as all the binary bloat. Now get off my lawn.

Re: What can't you do in C?

[VortexCortex]

Return a list from a function. Sure, you can legally do it, there's nothing in the language inherently stopping you, but experienced C programmers will avoid returning a list at all costs.

Hmm, that's odd. So C has its place but it's avoided because it lacks garbage collection? My C code has automatic garbage collection and OOP facilities. It's got lists and maps, and a comprehensive collections library. It's just under 30 thousand lines of code, but then it's just a game engine. It only has to do everything the computer actually can. If you don't have these basic facilities in your C library, it's your own damn fault. Seems to me if I want I can always have it in C, there's no excuse for not having it.

My memory manager replaces the malloc / free facilities, so it can even be added to other C code-bases, hell, I use it in C++ code because it's faster than the GC in the standard library (for the way I use it). So it's not like I have to call reference counting functions; Just the GC_recycle() function, or enable it to run automatically, which blocks on malloc() / free(), and optionally gives each thread their own local GC rather than a unified approach such that part of the program can garbage collect while another keeps running.

However, when my testers bitch about stutter in Java / Android No matter how badly I want Java or JavaScript to give me control of the damn garbage collector, so it doesn't run in the middle of the rendering loop or intense action sequence, I can't have it. I have to implement an object cache atop Java and pre-allocate everything, try my hardest not to give the GC a chance to run, and if I slip up once and let that fucker have control, it's game over, literally, when the enemy attacks and the game lags for half a second.

I return lists from functions all the time you dumbass. I'm an "experienced C programmer". Stop painting with such a wide brush, you're getting the paint in you eyes.

An AC adds:

Or return a function from a function?

I throw Function pointers around like crazy, that's how efficient state machines, decision trees, or other flexible structures are formed. Hell, my Entity-like system allows Actors to composite sets of functionality as it transitions states to create efficient AI -- Just because it's fleeing doesn't mean it's still not searching for Health. It would be like if C++ let you pick which methods you inherited from multiple parents on the fly. I mean hell, returning and passing a function pointer is how I implemented multiple sorts:
list->sort( list, list->getSortRoutine( SORT_MERGE ) );
// or
myCustomRoutine = getCurrentSort();
list->sort( list, myCustomRoutine );

That first "list" being passed in the sort function pointer invocation is where your magic "this" pointer comes from in C++.

Re: What can't you do in C?

[Anonymous Coward]

So then YOU take responsibility for the list.

ListHandle* l = createList();
if(l) {
      someListPopulatingFunc(l);
      useList(l);
      destroyList(l);
}

Nimrod

[Anonymous Coward]

Nimrod is a much more capable language, and supports generating C/C++/Javascript as backend languages, too.

Re: What can't you do in C?

[jimshatt]

However, when my testers bitch about stutter in Java / Android No matter how badly I want Java or JavaScript to give me control of the damn garbage collector, so it doesn't run in the middle of the rendering loop or intense action sequence, I can't have it. I have to implement an object cache atop Java and pre-allocate everything, try my hardest not to give the GC a chance to run, and if I slip up once and let that fucker have control, it's game over, literally, when the enemy attacks and the game lags for half a second.

You could write your own garbage collector for the JVM, which gives you 100% control over when, where and how to GC.

Too many programming languages

[Anonymous Coward]

There are way too many programming languages, and the industry is already too Balkanized. We don't need a Google language too. Every company has to have their language, and everyone in open source wants to be the next Larry Wall or Guido. What happened to industry standards? Every language does more or less the same thing. Yet we have C#, Objective-C, C++, Java, Perl, Python, Ruby, Lua, PHP, and so on - all of them are basically the same, but different. Cognitively, it's difficult to even remember which language I'm using. I'd almost rather use C, LISP, FORTH, and REXX because at least they're DIFFERENT and not all the same but slightly different.

How do you find the length of a string?

strlen()
length()
string.len
string.length
string.len()
string.length()

???

Sometimes I just sit at my desk, wondering which language I'm using at the moment and how to do the simplest thing.

We need to return to INDUSTRY STANDARDS - pick a language or two and enhance them, not create new languages.

Every company has an ORM tool. (Core Data, Entity Framework, Hibernate etc) All of them do the same thing, but differently.

Every company has one (or more) MVC framework. All of them do the same thing, but differently.

Re:There are two kinds of programming languages...

[Anonymous Coward]

At first glance I thought it said, "Shart, it's not what you think it is!"

Wouldn't it just be easier ...

[johnlcallaway]

Instead of writing a new language because programmers are lazy, wouldn't it be easier to just hire good ones to begin with?? Or to offer a class that teaches them to type???

As a user of many different languages over the last 3 decades, I have always preferred the ones that require me to think about data types. In those that didn't force types, I found that things went a lot smoother if I used them anyway, or activated a switch that did require it.

In my experience, if I didn't understand what data type I needed, even if it's just 'Object', I didn't understand what I was doing anyway.

Think before coding, it saves a lot of time later because you don't have to rewrite as much shit.

Re:There are two kinds of programming languages...

[DuckDodgers]

Sometimes the type system gives more overhead than safety. A wonderful satirical example in Java: https://github.com/Mikkeren/FizzBuzzEnterpriseEdition

You also have to weigh developer feedback time. I've developed web applications with Java Struts, coding directly to the Java Servlet API, Play Framework 1.x, and Play Framework 2.x (in Java, not Scala), and Python with Twistd. In order of speed of development of correct (i.e. in production without known bugs) code, they are from fastest to slowest: Python with Twistd, Play 1.x, Play Framework 2.x, Java with the Servlet API, Java Struts. Play Framework 1.x and Python give you instant reload. You save your changes, hit F5 in your browser, and see your change immediately. Anything I built without that takes three times as long. Play Framework 2.x doesn't have it, because under the hood Play 2 uses Scala and at least on my machine, best-case-scenario a Scala recompile of modified files after I change some Java file takes 5+ seconds. With Struts and just using the Servlet API, I have to reload the damn application and that's 10 seconds or longer. It seems like a trivial thing, but it's huge.

I'd say hot reload brings Java on par with Python for development, except Python has one extra feature: the REPL. "How does X work?" type.. "Oh, that's how it works", go back to coding. With Java, even in an IDE it's "create a public static void main (String [] args) throws Exception { /* actual code I want to test */ } " and either put Imports at the top or use fully qualified package names. So the equivalent "fast try something out" I do with Python still takes four times as long.

There's a reason that Google and Facebook and Twitter all use C++ and Java behind the scenes. But there's also a reason millions of sites use PHP, Python, Ruby, and Perl up front - because the development speed is so fast that you're into your testing (and unit tests) in a third the time of the Java version. So if your Java build takes three weeks of coding the application and one week of coding the tests, and your scripting language version takes one week of coding the application and two weeks of coding the tests (to offset the weaker type system), you still get to market faster with the scripting language.

Maybe the ideal is something like Perl6 (which has optional typing but does enforce type constraints when they're listed) or Groovy (which you can convert to Java more or less as-is once your rapid development phase is over).

Re:There are two kinds of programming languages...

[DuckDodgers]

Go get Hy. https://pypi.python.org/pypi/hy (Python in a LISP-y syntax. Same libraries, same features, no whitespace worries - but the project is still in alpha.) Why should Java developers have all of the LISP fun with Clojure?

Re:There are two kinds of programming languages...

[Anonymous Coward]

Same here, except that it annoys me to the point where I don't use it. Too bad Python doesn't have a CLI switch to turn on braces instead of spaces.

Argh.

[azav]

When the FUCK can we get rid of end of line semicolons and the ugly curly braces?

If we need new symbols to designate concepts, then let's create a font for them and map them on to a keyboard.

But really, those chars simply need to die.

But how many **browser based ** languages?

[walterbyrd]

Seems to me there is all of **one** browser based programming languages in common usage. And that one language has some very serious defects which, practically, cannot be fixed.

This reminds me of BASIC

[Anonymous Coward]

Is "DART" from Dartmouth?

Re:There are two kinds of programming languages...

[ttucker]

Instant reload is important when you are programming by trial and error!

Re:There are two kinds of programming languages...

[ttucker]

It helps bad programmers to indent their code :)

Re:There are two kinds of programming languages...

[Kielistic]

I'm so glad I get to use this legacy software!

Said nobody ever.

Re:There are two kinds of programming languages...

[H0p313ss]

Same here, except that it annoys me to the point where I don't use it. Too bad Python doesn't have a CLI switch to turn on braces instead of spaces.

I am reminded of a university professor who was supposed to be teaching C/C++ to first year Comp. Sci. and spent most of one of the first lectures demonstrating that you could basically write Pascal instead and leverage the pre-processor to generate C at compile time.

Re:There are two kinds of programming languages...

[HiThere]

I've really only got two complaints with Python3:
1) It's too slow.
2) It's too hard to write fixed length blocks of data to disk.

Both of these could be addressed with optional typing, but I don't expect that to ever happen, because the trend is in the opposite direction. OTOH, any year now I expect Vala to become usable.

Type checking

[Anonymous Coward]

sometimes you just don’t feel like appeasing a ceremonial type checker

When strong type checking becomes a "way of life" for a programmer, it's not a burden. It causes certain tasks to take a little bit longer (such as typing in the code), and it makes other tasks much, much easier (such as automatically eliminating a whole class of nasty bugs).

If you use strong type checking all the time, then you'll learn how to use it quickly and efficiently. Once you reach that point, it would never occur to you to not use it, because you have years of experience knowing that it makes you more productive.

If you aren't using type checking that way, then you're doing it wrong.

Re:There are two kinds of programming languages...

[Anonymous Coward]

On 1) PyPy is MUCH faster. Unfortunately, it's only for 2.7 right now, but pypy 3k should be here real soon. It *WILL* solve that problem for you.

On 2) I suppose I can imagine that, never tried it.

But:

3) Memory overhead per object

and:

4) Lack of decent multithreaded performance

are the real Python limiters for me. Not killers, though; there are still plenty of use cases where Python is leader of the pack.

type checking alone....

[whitroth]

First, what does it provide that no other language does, or does very, very poorly, enough to make an employer want to switch?

Second, "Just experiment and use var for your types. Once the idea is tested and you’re comfortable with the design, you can add type annotations.".

ROTFLMAO!!!!!!!

Translation: it actively encourages lazy, bug-ridden code, and no, NO ONE will *ever* "go back and add type annotations". Won't happen.

                    mark

Re:There are two kinds of programming languages...

[DuckDodgers]

Instant reload is priceless when you're building something incrementally. Add this field to the database query. Add that block to the page. Add this validation to the function inputs. Add that reference to a third party library. etc... etc...

And yes, trial and error. But if a strong static type system was inherently superior to trial and error, all Java and C# production code would be bug free, right?

Re:There are two kinds of programming languages...

[ttucker]

I never said there was anything wrong with trial and error. In a manner of thinking, it is how everything gets done one way or another.

My brain just has a hard time not giving a fuck about types, because at the end of the day type does matter. It matters whether your language helps you to remember or not, regardless of if you discover type errors at run time or compile time. Personally, I just like a little help.

Re:There are two kinds of programming languages...

[dreamchaser]

I'm so glad I get to use this legacy software!

Said nobody ever.

Nor did I. I just pointed out, and rightly so, that a lot of software these days suffers from enormous bloat and lack of optimization.

Re: What can't you do in C?

[bbn]

I want to se your C code for this simple Haskell function:

f x y = x*y

When applied to just one argument:

g = f 5

You get back an one argument function that will multiply by 5:

g 4 equals 20.

h = f 10

h 4 equals 40.

Your task is to write a C function, that does not memory leak (although it is hard enough even if you are allowed to leak), that based on some parameter will return a another function that is different each time. Like in the above Haskell code, I shall be able to invoke your C function multiple times, for example with the values 5 and 10 and get back new functions that will multiply with 5 and 10. The later must of course not override the behaviour of the former.

Re:There are two kinds of programming languages...

[RulerOf]

I'm so glad I get to use this legacy software!

Said nobody ever.

Nor did I. I just pointed out, and rightly so, that a lot of software these days suffers from enormous bloat and lack of optimization.

But if it does the job, and it's fast and useful on modern hardware, who cares?

If you happen to listen to the Security Now! podcast, Steve Gibson usually complains every week or two about Chrome taking up more and more memory---like a whopping 250 MB---to display a single window with an empty tab. To that, I say back: I'm having trouble giving a flying fuck about a quarter gigabyte of RAM when EVERYTHING on my system can't even seem to gobble up HALF of the 16 gigs I have. And that's on Windows. With superfetch.

If the code runs well on a modern system, and it allows programmers to focus on performance by being lazy with memory, what the hell does it matter? This isn't 2005. People figured out that RAM is an important statistic in the computer they want to purchase, and OEMs started realizing that if they DOUBLE the memory in a computer for a pathetically small amount of money, it turns out that their products won't be titanic piles of shit.

Programmers are starting to realize that they can offload their sloppiness to memory management and focus on CPU cycles. If Chrome is the shining example of why that's a good thing, then personally, I think we're doing something right!

Perfect code isn't impossible, it's just a ton of time, work, and money. There's nothing wrong with shuffling the budget to take advantage of the realities of today.

In a word RatFOR

[niftymitch]

Dart is interesting .... the obvious question is "Why was Ratfor not popular?"
http://en.wikipedia.org/wiki/Ratfor
The next question is why and how did C++ move from a preprocessor to become one of the big boys?

The part that I find interesting is how far JS has taken the WEB. Especially given the flaws in JS. Further the serious security tangle on the WEB that even Java does not get right begs improvement at many levels and Dart seems to be a necessary stepping stone.

Re:There are two kinds of programming languages...

[DuckDodgers]

I think the ideal is a type system that is flexible enough not to restrict your design and also compiles so quickly that it doesn't slow your development. Again, I'm using examples I've personally encountered - Java and Scala (strong static typing) vs Python and Clojure (runtime typing). In those cases:

1. Java compiles fast, but the type system gets in the way and you end up writing tons of boilerplate/logistical/Design Pattern code to work around it.
2. Scala has an awesome flexible type system, but the compiler is painfully slow and you spend time waiting for compilation to finish.
3. Python and Clojure basically run instantly, but of course you get type errors at runtime. The key thing is, you get most (but not all) of the errors immediately, so you can fix them right away.

Maybe something strong but very flexible type system but with fast compilation works better - maybe Haskell, or D, but I've never used any of them to write more than the simplest toy applications.

Re:There are two kinds of programming languages...

[ttucker]

My impression is that the appeal of weak typed languages is mostly in the ability to readily convert between primitive types. The gratuitous code created by maintaining multiple variables, for example a string and a long, and having to convert between them, while handling the exception they might throw, is truly one of my most hated programming activities. I wonder though, if one is truly forced to use a scripting language to have this feature? Would it not also be possible to provide a "dynamic type", or "super primitive", that could implicitly be used anywhere that another primitive is used? If it threw an unchecked exception, it would just die suddenly and catastrophically like a scripting language... so nothing really different.

Don't ask why, but I have extensive experience programming with a language which is now called, "ASP Classic". It had an option to at least force you to declare the names of variables ("Option Explicit"), which turned out to be absurdly handy. Figuring out what was happening when you had a variable, someVariable, and the same thing, someVairable, could take hours... because there was no exception, just poorly functioning code. I hate languages where variables can appear out of nowhere, that feature should not exist anywhere.

What I am trying to say here is, why not provide strong types when it matters, and weak types for when it does not? This whole debate feels like it is between people on different planets, like it is some ideological thing with no compromised solution.

Re:There are two kinds of programming languages...

[HiThere]

OK.

PyPy might be fast enough, but I've never benchmarked it, and definitely not the version for Python3.

FWIW, it's possible to write fixed length data records in Python (including Python3). It's just a real nuisance.

OTOH 3 might be a real problem, if I got far enough into a project in Python. So far the kind of project where that would be a problem has washed out earlier on other grounds.

As for 4: Nobody seems to do multi-threading well. Python's only a bit worse than others. It's gotten to the point where I write things as multi-process instead. With ANY virtual machine, that means a lot of overhead when starting things up, and a lot of continued RAM overhead. So you avoid starting processes frequently by using something analogous to threadpools, and communicating by message passing. (There's a couple of languages that handle this aspect better, but they have other problems.)

So 5) There is no perfect language. You choose the language(s) for the project. Python3 is one of the languages that I more commonly choose. D (dmd) is another. Vala is a language that I keep my eye on, because it shows a LOT of promise. But it's been promissing for years, and every time I've tried it, there's been major problems. (I feel the run-time error messages merrit the description I've heard: "encrypted Klingon".)

Is it just me? Or does this feel like Ada?

[Jefftoe]

Not just the => stuff. And I haven't compiled Ada in twenty years but when looking at Wikipedia for dart examples I just got that feeling. Also Ada is a strongly typed language. Dart seems to have type options.... ??? Need to study further.

Re: What can't you do in C?

[Anonymous Coward]

Your Haskell probably translates what you're doing into something like this:
(I admit it can be written more elegantly in C++ using templates and operator overloading)

#include

typedef int (*FN2)(int, int);

struct delegate_fn2_1arg
{
        FN2 function;
        int arg1;
};

int call_fn2_1arg(struct delegate_fn2_1arg *s, int arg2)
{
        s->function(s->arg1, arg2);
}

int f(int x, int y)
{
        return x * y;
}

int main(void)
{
        FN2 fptr =
        struct delegate_fn2_1arg g = { &f, 5 };
        struct delegate_fn2_1arg h = { &f, 10 };

        printf("f(6, 7) = %d\n", fptr(6, 7));
        printf("g(4) = %d\n", call_fn2_1arg(&g, 4));
        printf("h(4) = %d\n", call_fn2_1arg(&h, 4));
}

Re:There are two kinds of programming languages...

[H0p313ss]

I've really only got two complaints with Python3:
1) It's too slow.
2) It's too hard to write fixed length blocks of data to disk.

Both of these could be addressed with optional typing, but I don't expect that to ever happen, because the trend is in the opposite direction. OTOH, any year now I expect Vala to become usable.

Slow compared to what? Other scripting languages? Native binaries? Or jits like Java, C# ?

Re:There are two kinds of programming languages...

[Pherdnut]

To my mind there's no point in benchmarks when I've seen competence in Rails (barely), in C#, in Python, and in JavaScript (which is my primary expertise), but never, not once have I seen a Java web app that seemed to have been written by people who had the foggiest notion of the craft of writing code and performance/maintenance were always awful. I just spent the last two days pulling apart mashed together Tomcat, spring, struts, etc... config to try to get our app working in something newer than Java 5 and on the latest version of spring rather than like 20 different ones. If you only know Java, don't defend Java. The truth is, the language isn't horrible, just a somewhat antiquated answer to the problem of getting 100 C devs to work together without a riot, but the things the community have done with/to it in complete ignorance of why they were doing it, are absolutely mind-blowing. I'm sure you CAN write a decent web app with Java, but an inherently protectionist language that actually touts verbosity as a feature aiding clarity (if you believe that, I have some lovely Ian Fleming novels translated into legalese you should enjoy) is always going to attract complete and total suckwads. As a rule I would never advocate hiring somebody who only knew Java but I wouldn't have a problem hiring another dev if s/he knew other languages and actually preferred Java because I would like to meet that person and see how they made Java work for them in a whole !@#$ing universe of complete ass-code writing cretins. And FFS, why am I looking at 6 !@#$ing xml files, 5 interfaces, and a dozen classes just to figure out who's pulling the trigger? WTF is wrong with you people? If you have no idea why you're doing what you're doing, just stop.

Re:There are two kinds of programming languages...

[H0p313ss]

Well there's the last two years of my life in a nutshell... but throw Dojo into the mix.

Fuckwads indeed.

Re:There are two kinds of programming languages...

[DuckDodgers]

I don't think that's the advantage of weaker typing at all. I think the advantage is handling common aspects of objects without having to formally verify the type. I'm going to use an example that's been done before - say you're making a video game. You have creatures and soldiers and tanks and stuff that move around on screen. In Java, the cleanest way to implement this in a type-safe way is probably the Strategy Design Pattern. You make an interface "Move". Each way of moving - walk, run, crawl, jump, walk and jump, crawl and jump, swing from fines, fly, float, etc... becomes a separate class that implements the Move interface. All of your objects that represent movable things, solder, dog, cat, Tyrannosaurus Rex, faerie, tank, hovercraft are separate classes, and each class holds a "Move" instance internally which is invoked to control how it moves. You set that Move instance when you create each object or after you create each object, so if you want to add a movement type "Skip" later you don't have to change any existing code, and so you can create a Flying T-Rex if you want, also without changing existing code.

That works, and it's type safe. But it's also more complexity (each class holds a move instance, plus the move interface). In Clojure or Python, or even if Java if you wanted to bypass type-safety, you represent soldiers, dogs, cats, dinosaurs, etc... as untyped Maps (or Hashes, if you prefer the term). The movement types are just objects you bang into the map, and you're off to the races. You're screwed if someone puts a "swing weapon" class in the map using the key you planned for Movement, so you've lost type safety. But the logic of the program is simpler. (If my example sucks, I apologize. I am not a technical writer.)

Re: What can't you do in C?

[Anonymous Coward]

Sort of, but it;s not really translation. Every function is internally represented as a set of such transformations, which may be partially applied to any number of arguments less than the total required to return a value.

Re: What can't you do in C?

[Anonymous Coward]

And the translation you propose is not nearly complete.

As a clear difference you can to this (currying) in haskell with anonymous functions.

map ((*) 2) [1, 2, 3 , 4 , 5 , 6, 7]
[2, 4, 6, 8, 10, 12, 14]