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...?
So why then do we have Go, C# and Rust? 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. 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:
 So why then do we have Go, C# and Rust?
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. We have C# because Java was taking over large sections of the C++ 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