Walter Bright Wrote:

> dsimcha wrote:
> > Right, but sometimes (though certainly not always) it's better to provide a meta-feature that solves a whole bunch of problems (like better templates) and then solve the individual problems at the library level, rather than add a language feature specifically to address each need.
> 
> Yup. The hard part, though, is figuring out what the magic set of seminal features should be.
> 
> 
> > One thing D does very well is
> > allow you to do the same kind of metaprogramming solutions you would do in C++,
> > except that the result doesn't suck.  For example, std.range implements
> > functional-style lazy evaluation as a library, and does it well.  The point is
> > that, if you can't deal with the complexity of having real templates, you better
> > be prepared for the complexity created by not having them.
> 
> Right. A "simple" language pushes the complexity onto the programmer, so he has to write complicated code instead. D programs tend to be dramatically shorter than the equivalent C++ one.
> 
> 
> > Having never done it before, I really cannot imagine how people get any work done in a language that doesn't have either duck typing or good templates.  It's just too rigid.  It seems like modern statically typed languages like Java and C# end up adding tons of ad-hoc workarounds for lacking either of these as well-integrated language features.  The best/worst example is auto-boxing.
> 
> I tried programming in Java.
> 
> A friend of mine had an unexpected insight. He used Java a lot at a major corporation. He said an IDE was indispensable because with "one click" you could generate a "hundred lines of code". The light bulb came on. Java makes up for its lack of expressiveness by putting that expressiveness into the IDE!
> 
> In D, you generate that hundred lines of code with templates and mixins.

I'm a Java programmer. IMO, the biggest problem with Java is not the language expressiveness, but poorly written APIs and badly selected abstractions. The reason I can't program in Java without an IDE is (usually) not because I need to generate tons of code, but because I'm constantly looking up new method/class names, looking up packages to export and refactoring.

A lot of things that require extensive code generation do so simply because they are badly designed. Web services (SOAP based) are a good example of that. In the end, it's just reading and writing text to a socket. It could be very simple, but it isn't.

An area when I find myself using code generation a lot is exception handling. I prefer to write my code without handling exceptions at all, and then let API to generate try/catch blocks. I tweak then afterward. Thing is, Java supports runtime exceptions that don't cascade in kilobytes of mostly useless code. People just don't use them that often.

My point is, language is one thing, but "language culture" is another. For some reason Java bred a culture that encourages bloated, counter-intuitive, "enterprise" solutions. It's not inherent in the language. It has more to do with the companies that use it, core API design and design of popular libraries. At least that's the way I see it.

Roman Ivanov wrote:
> My point is, language is one thing, but "language culture" is
> another. For some reason Java bred a culture that encourages bloated,
> counter-intuitive, "enterprise" solutions. It's not inherent in the
> language. It has more to do with the companies that use it, core API
> design and design of popular libraries. At least that's the way I see
> it.

I know what you mean. I even found the file I/O Java library routines to be impenetrable.

== Quote from Roman Ivanov (x@y.z)'s article
> Walter Bright Wrote:
> > dsimcha wrote:
> > > Right, but sometimes (though certainly not always) it's better to provide a meta-feature that solves a whole bunch of problems (like better templates) and then solve the individual problems at the library level, rather than add a language feature specifically to address each need.
> >
> > Yup. The hard part, though, is figuring out what the magic set of seminal features should be.
> >
> >
> > > One thing D does very well is
> > > allow you to do the same kind of metaprogramming solutions you would do in C++,
> > > except that the result doesn't suck.  For example, std.range implements
> > > functional-style lazy evaluation as a library, and does it well.  The point is
> > > that, if you can't deal with the complexity of having real templates, you better
> > > be prepared for the complexity created by not having them.
> >
> > Right. A "simple" language pushes the complexity onto the programmer, so he has to write complicated code instead. D programs tend to be dramatically shorter than the equivalent C++ one.
> >
> >
> > > Having never done it before, I really cannot imagine how people get any work
done
> > > in a language that doesn't have either duck typing or good templates.  It's just too rigid.  It seems like modern statically typed languages like Java and C# end up adding tons of ad-hoc workarounds for lacking either of these as well-integrated language features.  The best/worst example is auto-boxing.
> >
> > I tried programming in Java.
> >
> > A friend of mine had an unexpected insight. He used Java a lot at a major corporation. He said an IDE was indispensable because with "one click" you could generate a "hundred lines of code". The light bulb came on. Java makes up for its lack of expressiveness by putting that expressiveness into the IDE!
> >
> > In D, you generate that hundred lines of code with templates and mixins.
> I'm a Java programmer. IMO, the biggest problem with Java is not the language
expressiveness, but poorly written APIs and badly selected abstractions. The reason I can't program in Java without an IDE is (usually) not because I need to generate tons of code, but because I'm constantly looking up new method/class names, looking up packages to export and refactoring.
> A lot of things that require extensive code generation do so simply because they
are badly designed. Web services (SOAP based) are a good example of that. In the end, it's just reading and writing text to a socket. It could be very simple, but it isn't.
> An area when I find myself using code generation a lot is exception handling. I
prefer to write my code without handling exceptions at all, and then let API to generate try/catch blocks. I tweak then afterward. Thing is, Java supports runtime exceptions that don't cascade in kilobytes of mostly useless code. People just don't use them that often.
> My point is, language is one thing, but "language culture" is another. For some
reason Java bred a culture that encourages bloated, counter-intuitive, "enterprise" solutions. It's not inherent in the language. It has more to do with the companies that use it, core API design and design of popular libraries. At least that's the way I see it.

Yes, but in my (possibly somewhat uninformed) opinion, the root cause of this is that Java just doesn't provide many tools for managing complexity.  Complexity has to go somewhere, and about the only tool Java provides for managing it is OO-style class hierarchies.  I have nothing against OO, classes, interfaces, inheritance, etc.  It's just that it's not the right tool for every job.  If your problem doesn't fit neatly into an OO-style class hierarchy, it will be made to fit sloppily.  In a more multi-paradigm language, you might use templates, or duck typing, or higher-order functions, or closures, or eval statements, or mixins, or macros, or whatever complexity management system maps best to the problem you're trying to solve.  In Java, by going overboard on making the core language simple, you end up pushing all the complexity into the APIs.

dsimcha wrote:
> In Java, by going overboard on making the core language simple,
> you end up pushing all the complexity into the APIs.

Yup, and that's the underlying problem with "simple" languages. Complicated code.

Walter Bright wrote:
> dsimcha wrote:
>> In Java, by going overboard on making the core language simple,
>> you end up pushing all the complexity into the APIs.
> 
> Yup, and that's the underlying problem with "simple" languages. Complicated code.

I think users of scripting languages would disagree with you.

grauzone wrote:
> Walter Bright wrote:
>> dsimcha wrote:
>>> In Java, by going overboard on making the core language simple,
>>> you end up pushing all the complexity into the APIs.
>>
>> Yup, and that's the underlying problem with "simple" languages. Complicated code.
> 
> I think users of scripting languages would disagree with you.

PHP?

Tue, 01 Dec 2009 01:08:11 -0800, Walter Bright wrote:

> grauzone wrote:
>> Walter Bright wrote:
>>> dsimcha wrote:
>>>> In Java, by going overboard on making the core language simple, you end up pushing all the complexity into the APIs.
>>>
>>> Yup, and that's the underlying problem with "simple" languages. Complicated code.
>> 
>> I think users of scripting languages would disagree with you.
> 
> PHP?

Php is a terrible joke built by a novice http://tnx.nl/php.html. Fans of e.g. ruby, python etc. could argue that their language has less corner cases and more uniform features, which makes the development more of a joy to do and code less verbose. Instead of two variations, in many cases there is only one choice - e.g.

 - type known at runtime/compile time -> known at runtime
 - generic type / ordinary type -> runtime dynamic type
 - primitives/objects -> everything is an object
 - special set of built-in operators / normal methods -> everything is a
message
 - static classes / objects -> objects (some are singletons but can
inherit from interfaces etc. unlike statics in d)
 - free functions / methods / static methods -> methods (the modules are
singleton objects -> free functions are module methods)
 - functions / delegates -> functions
 - special set of built-in control structures -> simple primitive (e.g.
recursion & library defined structures)
 - statements / expressions -> everything is an expression (this unifies
e.g. if-then-else and a ? b : c)
 - built-in AA, array, list etc. -> library defined collections
 - dozens of primitive number types -> fixed size int & float (e.g. 32bit
int and 64bit float), arbitrary precision int & float (rational type)

Overall these simplifications don't remove any crucial high level language features, in fact they make the code simpler and shorter. For instance there isn't high level code that can only be written with 8-bit byte primitives, static methods or closures, but not with 32-bit generic ints, singletons, and generic higher order functions. The only thing you lose is some type safety and efficiency.

grauzone wrote:

> Walter Bright wrote:
>> dsimcha wrote:
>>> In Java, by going overboard on making the core language simple, you end up pushing all the complexity into the APIs.
>> 
>> Yup, and that's the underlying problem with "simple" languages. Complicated code.
> 
> I think users of scripting languages would disagree with you.

Do you mean scripting languages such as Lua or ruby and python? The latter two are by no means simple languages, they pack tons of features.

retard wrote:
> Overall these simplifications don't remove any crucial high level language features, in fact they make the code simpler and shorter. For instance there isn't high level code that can only be written with 8-bit byte primitives, static methods or closures, but not with 32-bit generic ints, singletons, and generic higher order functions. The only thing you lose is some type safety and efficiency.

I'm no expert on Python, but there are some things one gives up with it:

1. the ability to do functional style programming. The lack of immutability makes for very hard multithreaded programming.

2. as you mentioned, there's the performance problem. It's fine if you don't need performance, but once you do, the complexity abruptly goes way up.

3. no contract programming (it's very hard to emulate contract inheritance)

4. no metaprogramming

5. simple interfacing to C

6. scope guard (transactional processing); Python has the miserable try-catch-finally paradigm

7. static verification

8. RAII

9. versioning

10. ability to manage resources directly

11. inline assembler

12. constants

Walter Bright wrote:
> retard wrote:
>> Overall these simplifications don't remove any crucial high level language features, in fact they make the code simpler and shorter. For instance there isn't high level code that can only be written with 8-bit byte primitives, static methods or closures, but not with 32-bit generic ints, singletons, and generic higher order functions. The only thing you lose is some type safety and efficiency.
> 
> I'm no expert on Python, but there are some things one gives up with it:
> 
> 1. the ability to do functional style programming. The lack of immutability makes for very hard multithreaded programming.
> 
> 2. as you mentioned, there's the performance problem. It's fine if you don't need performance, but once you do, the complexity abruptly goes way up.
> 
> 3. no contract programming (it's very hard to emulate contract inheritance)
> 
> 4. no metaprogramming
> 
> 5. simple interfacing to C
> 
> 6. scope guard (transactional processing); Python has the miserable try-catch-finally paradigm
> 
> 7. static verification
> 
> 8. RAII
> 
> 9. versioning
> 
> 10. ability to manage resources directly
> 
> 11. inline assembler
> 
> 12. constants

I mostly agree, but python actually has a rather elegant version of RAII.