www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The backlash against scripting languages has begun

reply Joakim <dlang joakim.fea.st> writes:
He mentions Swift, Rust, and Go as his hopes at the end, too bad 
he doesn't include D:

https://medium.com/ deathdisco/today-i-accept-that-rails-is-yesterday-s-software-b5af35c9af39

He'd probably be happy with D, particularly given Walter's stance 
on the monkey-patching that guy now rues:

"Monkey-patching has, in Ruby, been popular and powerful. It has 
also turned out to be a disaster. It does not scale, and is not 
conducive to more than one person/team working on the code base."
http://forum.dlang.org/post/jsat48$ujt$1 digitalmars.com

That blogger probably wishes he read that quote from Walter four 
years ago. ;)
May 13 2016
parent reply Chris <wendlec tcd.ie> writes:
On Friday, 13 May 2016 at 07:31:26 UTC, Joakim wrote:

 He mentions Swift, Rust, and Go as his hopes at the end, too 
 bad he doesn't include D:

 https://medium.com/ deathdisco/today-i-accept-that-rails-is-yesterday-s-software-b5af35c9af39

 He'd probably be happy with D, particularly given Walter's 
 stance on the monkey-patching that guy now rues:

 "Monkey-patching has, in Ruby, been popular and powerful. It 
 has also turned out to be a disaster. It does not scale, and is 
 not conducive to more than one person/team working on the code 
 base."
 http://forum.dlang.org/post/jsat48$ujt$1 digitalmars.com

 That blogger probably wishes he read that quote from Walter 
 four years ago. ;)


"basing themselves on interpreted, slow languages that favoured 
‘easy to learn’ over ‘easy to maintain’."

Yep. Frustration kicks in sooner or later. I always tell people 
not to use scripting languages for bigger or real world projects.
May 13 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 13 May 2016 at 09:57:16 UTC, Chris wrote:

 "basing themselves on interpreted, slow languages that favoured 
 ‘easy to learn’ over ‘easy to maintain’."


"Easy to learn" often correlates with "easy to maintain". I think 
you are referring more to static typing vs dynamic typing.

Sure, catching problems at runtime is not the best option, but 
C-like languages have plenty of sources for runtime errors, so it 
isn't that big of a difference. Especially now that gradual 
typing is becoming popular.


 Yep. Frustration kicks in sooner or later. I always tell people 
 not to use scripting languages for bigger or real world 
 projects.


You mean like gmail,  youtube, Visual Studio Code, emacs...?

Anyway, self-modifying code is in general a bad idea, except in 
situations where you build a compatibility layer. So, no, "monkey 
patching" isn't universally bad. It is only bad if you don't keep 
it on a separate layer. Patching up a runtime environment (such 
as a web browser) with polyfills makes for more maintainable code 
than versioning/feature-detecting conditionals in the core logic 
of the program.

In the real world you don't get to define your running 
environment. You adopt to the actual running environment. If you 
can get away with creating a compatibility layer then that almost 
always makes for more maintainable code. "monkey patching" is 
sometimes an effective strategy to getting that compatibility 
layer in place, or simply fixing bugs in the runtime on legacy 
platforms.
May 14 2016
parent reply Chris <wendlec tcd.ie> writes:
On Saturday, 14 May 2016 at 07:09:00 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 13 May 2016 at 09:57:16 UTC, Chris wrote:

 "basing themselves on interpreted, slow languages that 
 favoured ‘easy to learn’ over ‘easy to maintain’."


 "Easy to learn" often correlates with "easy to maintain". I 
 think you are referring more to static typing vs dynamic typing.


That was a quote from the article, those weren't my words, but 
I'd agree with them.


 Yep. Frustration kicks in sooner or later. I always tell 
 people not to use scripting languages for bigger or real world 
 projects.


 You mean like gmail,  youtube, Visual Studio Code, emacs...?



a certain language is no proof. I've an old homepage that was 
written in PHP. It works, you can add to it. But is it easy to 
maintain? Sure Google have loads of coders who can maintain even 
the messiest code base. You could write a service in Perl. That 
doesn't mean it's a good language for the task at hand.

[snip]
May 14 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 14 May 2016 at 09:59:47 UTC, Chris wrote:




I believe we have Go because C++ was stagnant, but C++14 and 
beyond has become more favourable and Go is pushed into a 
speciality niche: light weight servers.


domain and was a threat to VB?

I don't exactly know why we have Rust... Maybe because Mozilla 
likes to see themselves as Google's peer and want to have their 
own language as well? I somehow doubt that the costs of 
developing Rust will pay off for Mozilla.


 That a service is run in a certain language is no proof. I've 
 an old homepage that was written in PHP. It works, you can add 
 to it. But is it easy to maintain? Sure Google have loads of 
 coders who can maintain even the messiest code base. You could 
 write a service in Perl.


Perl and Php were never intended for writing larger programs, so 
not sure how those can be used as an example.

The trend is that scripting is taking over UI programming. For 
many applications the UI is a big chunk of the codebase. 
Recompilation just to tweak the UI is annoying so I don't expect 
this trend to change. This is an old trend too, emacs being a 
prime example.
May 14 2016
parent reply Chris <wendlec tcd.ie> writes:
On Saturday, 14 May 2016 at 10:29:59 UTC, Ola Fosheim Grøstad 
wrote:
[snip]

 That a service is run in a certain language is no proof. I've 
 an old homepage that was written in PHP. It works, you can add 
 to it. But is it easy to maintain? Sure Google have loads of 
 coders who can maintain even the messiest code base. You could 
 write a service in Perl.


 Perl and Php were never intended for writing larger programs, 
 so not sure how those can be used as an example.


Of course not, neither was Python intended to replace languages 
like C++ or Java. You mentioned projects that are successful and 
use scripting languages. Facebook uses (or used!) a lot of PHP, 
that's why I mentioned it. But none of these scripting languages 
were ever meant to be used for building large scale projects. 
People just did it, because it was so easy. Now it's come back to 
bite them.


 The trend is that scripting is taking over UI programming. For 
 many applications the UI is a big chunk of the codebase. 
 Recompilation just to tweak the UI is annoying so I don't 
 expect this trend to change. This is an old trend too, emacs 
 being a prime example.


That's a good use of scripting languages. That's where SLs 
belong, i.e. very specific domains where they make things easier.
May 16 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 16 May 2016 at 10:41:59 UTC, Chris wrote:

 Of course not, neither was Python intended to replace languages 
 like C++ or Java. You mentioned projects that are successful 
 and use scripting languages.


I don't think Python ever will replace C++ or Java, but it is 
actually a decent language when you add type annotations. 
Fortunately PyCharm supports type annotations in comments which 
makes Python2.7 much more acceptable when writing web-services in 
Python. Of course, web-services tend to resolve around checking 
data connecting to other systems, so not really self contained 
programs (most of the program "state" is in remote databases, 
http services, mem-cache servers etc).


 PHP, that's why I mentioned it. But none of these scripting 
 languages were ever meant to be used for building large scale 
 projects. People just did it, because it was so easy. Now it's 
 come back to bite them.


Yes, if you implement the system in one big monolithic 
executable. If you write many smaller independent programs that 
communicate then it works out ok. So it is somewhat context 
dependent.


 That's a good use of scripting languages. That's where SLs 
 belong, i.e. very specific domains where they make things 
 easier.


Yes, but with gradual typing, JITs and premade graphics/layout 
engines (e.g. browsers) the border between scripting and 
non-scripting is getting blurred. Like, angular2 + typescript is 
based on a scripting language, but not really in the sense of 
Perl and Php. It is moving towards a mixed domain specific 
declarative language.

You also now have something called NativeScript which makes 
native iOS apis available in javascript (and therefore in 
TypeScript/Angular) so...

Something is happening with how applications can be implemented. 
I think this trend will continue. Once you have established a 
recurring design pattern then declarative languages makes a lot 
of sense.
May 16 2016
parent Chris <wendlec tcd.ie> writes:
On Monday, 16 May 2016 at 14:07:06 UTC, Ola Fosheim Grøstad wrote:

 I don't think Python ever will replace C++ or Java, but it is 
 actually a decent language when you add type annotations. 
 Fortunately PyCharm supports type annotations in comments which 
 makes Python2.7 much more acceptable when writing web-services 
 in Python. Of course, web-services tend to resolve around 
 checking data connecting to other systems, so not really self 
 contained programs (most of the program "state" is in remote 
 databases, http services, mem-cache servers etc).


The sad thing is that people _thought_ they could use Python (and 
other SLs) to do things C++ and D etc. are better suited for. But 
people are beginning to realize that it was a mistake 
(performance, maintenance, type safety etc). It's actually not 
the SLs per se that are experiencing a backlash, it's the way 
they've been used that has come under scrutiny. I have no issues 
with Python, and I don't blame it for having been used in places 
where it shouldn't have been used in the first place.


 Yes, if you implement the system in one big monolithic 
 executable. If you write many smaller independent programs that 
 communicate then it works out ok. So it is somewhat context 
 dependent.


I've written a small CMS in PHP. Of course you _can_ do it. I 
would have preferred Lua though. For fun I set up a 
vibe.d/DerelictLua based system and the Lua code was much more 
elegant and much more concise. Lua was designed from scratch. PHP 
started out as a hack, and it shows.


[snip]
May 16 2016