Discussion:
D For A Web Developer
(too old to reply)
James via Digitalmars-d
2014-04-29 14:41:17 UTC
Permalink
I have a friend that is a web developer. I, however want to
collaborate with him, so I am trying to get him to learn D. I
don't know how to persuade him! How can D be used to greatly
assist an HTML5/JavaScript web developer? I decided to go here to
get some good answers. How can D be used to interopt with modern
web development?
Etienne via Digitalmars-d
2014-04-29 15:17:08 UTC
Permalink
I have a friend that is a web developer. I, however want to collaborate
with him, so I am trying to get him to learn D. I don't know how to
persuade him! How can D be used to greatly assist an HTML5/JavaScript
web developer? I decided to go here to get some good answers. How can D
be used to interopt with modern web development?
You should ask this in
http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/

But while we're here, maybe you could send him a link to
http://vibed.org/ along with a link to
http://dlang.org/phobos/std_algorithm.html that he could read when he
has 10 minutes

I don't know how else you could convince him. Possibly benchmarks?

http://atilanevesoncode.wordpress.com/2013/12/05/go-vs-d-vs-erlang-vs-c-in-real-life-mqtt-broker-implementation-shootout/

Or an example of a dynamic web project backend?

https://github.com/rejectedsoftware/vibe.d/tree/master/examples/web
He might not be so familiar with type safety though, so then your
arguments will have to be more technical - type safety is the only way
you can ever scale a project because most bugs are caught by the compiler.

He can keep using his front-end libraries too. Browsers don't run D
code, they simply request bytes from it.

Good luck!
Chris via Digitalmars-d
2014-04-29 16:10:24 UTC
Permalink
Post by Etienne via Digitalmars-d
Post by James via Digitalmars-d
I have a friend that is a web developer. I, however want to
collaborate
with him, so I am trying to get him to learn D. I don't know
how to
persuade him! How can D be used to greatly assist an
HTML5/JavaScript
web developer? I decided to go here to get some good answers.
How can D
be used to interopt with modern web development?
You should ask this in
http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/
But while we're here, maybe you could send him a link to
http://vibed.org/ along with a link to
http://dlang.org/phobos/std_algorithm.html that he could read
when he has 10 minutes
I don't know how else you could convince him. Possibly
benchmarks?
http://atilanevesoncode.wordpress.com/2013/12/05/go-vs-d-vs-erlang-vs-c-in-real-life-mqtt-broker-implementation-shootout/
Or an example of a dynamic web project backend?
https://github.com/rejectedsoftware/vibe.d/tree/master/examples/web
He might not be so familiar with type safety though, so then
your arguments will have to be more technical - type safety is
the only way you can ever scale a project because most bugs are
caught by the compiler.
He can keep using his front-end libraries too. Browsers don't
run D code, they simply request bytes from it.
Good luck!
Agree. Give vibe.d a try. If your friend uses dub to build it, it
should be pretty easy to get started. A basic server app is very
simple and straight forward to implement with vibe.d. Once the
server is running he can use his existing html / js files (the
server app just, well, "serves" them), or he can do more fancy
script like stuff with diet templates:

http://vibed.org/docs#html-templates
and
http://vibed.org/templates/diet

And yes, vibe.d is by an order of magnitude faster than your
usual web infrastructures.
Adam D. Ruppe via Digitalmars-d
2014-04-29 15:27:07 UTC
Permalink
I recently started a Ruby on Rails job and using it makes me
really, really miss the high productivity and ease of use D
offers. (And, of course, a dynamic site in D runs about 3x faster
out of the box than hello world served by Rails, zero effort in
optimization. And "rake test", just shoot me, I'd rather rebuild
a C++ project from scratch, at least that'll finish before the
heat death of the universe.)
Etienne via Digitalmars-d
2014-04-29 15:55:11 UTC
Permalink
I recently started a Ruby on Rails job and using it makes me really,
really miss the high productivity and ease of use D offers. (And, of
course, a dynamic site in D runs about 3x faster out of the box than
hello world served by Rails, zero effort in optimization. And "rake
test", just shoot me, I'd rather rebuild a C++ project from scratch, at
least that'll finish before the heat death of the universe.)
That's funny b/c most people say RoR made them love web development. If
the D community could organize itself the same way RoR is around web
dev, I doubt any other web scripting language could pursue existence.
H. S. Teoh via Digitalmars-d
2014-04-29 16:46:09 UTC
Permalink
Post by Etienne via Digitalmars-d
I recently started a Ruby on Rails job and using it makes me really,
really miss the high productivity and ease of use D offers. (And, of
course, a dynamic site in D runs about 3x faster out of the box than
hello world served by Rails, zero effort in optimization. And "rake
test", just shoot me, I'd rather rebuild a C++ project from scratch,
at least that'll finish before the heat death of the universe.)
That's funny b/c most people say RoR made them love web development.
[...]

That's not what I hear. My cousin, who does RoR, hates it with a
passion, and wishes she could get out of it. But unfortunately, she
can't.

I don't use RoR personally, though, so I can't speak for it myself.


T
--
I see that you JS got Bach.
Adam D. Ruppe via Digitalmars-d
2014-04-29 17:09:53 UTC
Permalink
Post by Etienne via Digitalmars-d
That's funny b/c most people say RoR made them love web
development.
That's probably because they went into it with very little
experience with the alternatives. I was spoiled by my web.d and
friends, as well as knowing how to use a real relational
database, so getting on the Rails to me is like going back into
the stone age.

But if you came from mysql 3 and PHP 4 or some other primitive
trash, RoR might seem like the best thing ever.

I do kinda like the rails console repl tho. Of course, I kinda
have that with cgi.d too, you can call its methods on the regular
command line pretty easily, but that doesn't let you build up
state as easily for quick changes and I do like that. (Maybe I'll
offer such with my script.d, should be easy to add :P)

the rest of it tho is just awful.
Chris via Digitalmars-d
2014-04-30 09:22:05 UTC
Permalink
Post by Adam D. Ruppe via Digitalmars-d
Post by Etienne via Digitalmars-d
That's funny b/c most people say RoR made them love web
development.
That's probably because they went into it with very little
experience with the alternatives. I was spoiled by my web.d and
friends, as well as knowing how to use a real relational
database, so getting on the Rails to me is like going back into
the stone age.
But if you came from mysql 3 and PHP 4 or some other primitive
trash, RoR might seem like the best thing ever.
I do kinda like the rails console repl tho. Of course, I kinda
have that with cgi.d too, you can call its methods on the
regular command line pretty easily, but that doesn't let you
build up state as easily for quick changes and I do like that.
(Maybe I'll offer such with my script.d, should be easy to add
:P)
the rest of it tho is just awful.
Is there any documentation for web.d, including example apps?
I'm using vibe.d at the moment and rolled my own customized DOM
tree stuff (that was before I knew dom.d existed). I basically
implemented the most important JS features for DOM manipulation
and added stuff I'd always wanted in JS.
Adam D. Ruppe via Digitalmars-d
2014-04-30 14:48:46 UTC
Permalink
Post by Chris via Digitalmars-d
Is there any documentation for web.d, including example apps?
Not much, I've done some before but it is pretty scattered and I
don't even know where it all is right now.
Post by Chris via Digitalmars-d
I basically implemented the most important JS features for DOM
manipulation and added stuff I'd always wanted in JS.
Yeah, dom.d is kinda my magical group of nice convenience too.
The .addChild() helper makes building a tree in code so simple
that I rarely even thing about innerHTML anymore.

addChild takes a tag name and two child strings which are
customized based on the tag name:

addChild("a", "Link test", "http://link-target.com/"); // makes
<a href="httpp....">Link test</a>

addChild("span", "foo", "bar"); // makes <span
class="bar">foo</span>

addChild("div", Html("<b>lol</b>")); // <div><b>lol</b></div>

(normally, the second argument is innerText and the third
argument is the big customization point.)


dom.d's Form class makes them stupid-simple to use too.


auto form = document.requireSelector!Form("#my-form");
form.setValue("something", "else");


setValue finds the element with that particular name and sets teh
value based on what it is. So if it is an <input>, it sets value.
If it is a <textarea>, it sets innerText. If it is <select>, it
sets the attribute on the right <option>, or can add an option if
needed. It can also implicitly create a hidden element if needed.

The Link class has a similar function for link URL params.



And, of course, these can be done in a loop:


void forwardParams() {
foreach(k, v; cgi.post)
form.setValue(k, v);
}

so simple!
Nick Sabalausky via Digitalmars-d
2014-04-29 17:45:19 UTC
Permalink
Post by Etienne via Digitalmars-d
I recently started a Ruby on Rails job and using it makes me really,
really miss the high productivity and ease of use D offers. (And, of
course, a dynamic site in D runs about 3x faster out of the box than
hello world served by Rails, zero effort in optimization. And "rake
test", just shoot me, I'd rather rebuild a C++ project from scratch, at
least that'll finish before the heat death of the universe.)
That's funny b/c most people say RoR made them love web development. If
the D community could organize itself the same way RoR is around web
dev, I doubt any other web scripting language could pursue existence.
Ruby on Rails popularized MVC web frameworks, and that was a significant
step forward from the stuff that came before, like PHP, ASP or even
arguably ASP.NET (or *shudder* ColdFusion). I think that's always been
RoR's main benefit and appeal.

But since then, every other language under the sun (or rather, under
florescent lights?) has grown its own MVC web framework, so Rails's
biggest distinguishing characteristic now is just that it's in Ruby. And
Ruby is kinda famous for having little significance outside of Rails
itself. (Although, I did find Rake quite beneficial in an older project
with a rather complex build. Course, these days D/Phobos has gotten good
enough I'd just do a build script in D.)

At least that's my impression of Ruby and Rails.
Paulo Pinto via Digitalmars-d
2014-04-29 18:04:18 UTC
Permalink
Post by Nick Sabalausky via Digitalmars-d
Post by Etienne via Digitalmars-d
I recently started a Ruby on Rails job and using it makes me really,
really miss the high productivity and ease of use D offers. (And, of
course, a dynamic site in D runs about 3x faster out of the box than
hello world served by Rails, zero effort in optimization. And "rake
test", just shoot me, I'd rather rebuild a C++ project from scratch, at
least that'll finish before the heat death of the universe.)
That's funny b/c most people say RoR made them love web development. If
the D community could organize itself the same way RoR is around web
dev, I doubt any other web scripting language could pursue existence.
Ruby on Rails popularized MVC web frameworks, and that was a significant
step forward from the stuff that came before, like PHP, ASP or even
arguably ASP.NET (or *shudder* ColdFusion). I think that's always been
RoR's main benefit and appeal.
But since then, every other language under the sun (or rather, under
florescent lights?) has grown its own MVC web framework, so Rails's
biggest distinguishing characteristic now is just that it's in Ruby. And
Ruby is kinda famous for having little significance outside of Rails
itself. (Although, I did find Rake quite beneficial in an older project
with a rather complex build. Course, these days D/Phobos has gotten good
enough I'd just do a build script in D.)
At least that's my impression of Ruby and Rails.
I was already doing RoR back in 1999, but it was with our own in-house
TCL Apache/IIS module in a Portuguese startup, far far away from Silicon
Valley and loosely based in AOL Server concepts.

We eventually moved into .NET, at the time only known to Microsoft
partners like our mother company, before it was announced to the world.

It was a very good learning experience, building a whole stack from the
ground up, back in the early web days.

We already had Active Record and MVC with security layers and
scaffolding, just in TCL and unknown to the world.

--
Paulo
Russel Winder via Digitalmars-d
2014-04-29 19:15:19 UTC
Permalink
On Tue, 2014-04-29 at 20:04 +0200, Paulo Pinto via Digitalmars-d wrote:
[
]
Post by Paulo Pinto via Digitalmars-d
I was already doing RoR back in 1999, but it was with our own in-house
TCL Apache/IIS module in a Portuguese startup, far far away from Silicon
Valley and loosely based in AOL Server concepts.
[
]
Post by Paulo Pinto via Digitalmars-d
We already had Active Record and MVC with security layers and
scaffolding, just in TCL and unknown to the world.
Californians insist that everything is invented in California, and all
other USAnians believe them. It is about time Europeans stopped
believing them. Especially as everything in the future will be invented
in China.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
ketmar via Digitalmars-d
2014-04-29 16:02:38 UTC
Permalink
On Tue, 29 Apr 2014 11:55:11 -0400
Post by Etienne via Digitalmars-d
That's funny b/c most people say RoR made them love web development.
If the D community could organize itself the same way RoR is around
web dev, I doubt any other web scripting language could pursue
existence.
no, please, no! the latest thing D needs is a bunch of php-coders!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140429/fedfd6f7/attachment.sig>
Jacob Carlborg via Digitalmars-d
2014-04-29 19:06:59 UTC
Permalink
I recently started a Ruby on Rails job and using it makes me really,
really miss the high productivity and ease of use D offers.
I'm curious to why you think D is more productive and easier to use.
--
/Jacob Carlborg
Adam D. Ruppe via Digitalmars-d
2014-04-29 22:09:57 UTC
Permalink
Post by Jacob Carlborg via Digitalmars-d
I'm curious to why you think D is more productive and easier to use.
A lot of things, mostly focusing around having the compiler to
help refactor with confidence (the importance of this really
can't be understated) and having libraries that fit better. The
speed is a nice bonus too, having to spend half a minute just
waiting for the tests to run really grates me.

But wrt libraries, ActiveRecord is unbelievably awful, for
example. It is a bad idea from the ground up: why, oh why are we
reinventing the database? erb templates are painful to use too,
and so is the routing. I don't understand why routing isn't done
automatically for the common case.

The scaffolding is a pain too. Contrast to what web.d does: given
a function signature, it automatically generates a form for it
(using type information to select correct widgets) and can format
the response in several forms automatically including plain text,
html list, html table, json, xml, csv, and a custom template.

Maybe Rails can do this stuff and I'm too much of a n00b, but the
other experienced team members say the way we're doing it is
pretty standard and I'm just not impressed.

I can just get stuff done in D in a fraction of a time it takes
to do even less in RoR.
Russel Winder via Digitalmars-d
2014-04-30 04:19:04 UTC
Permalink
On Tue, 2014-04-29 at 22:09 +0000, Adam D. Ruppe via Digitalmars-d
wrote:
[
]
Post by Adam D. Ruppe via Digitalmars-d
I can just get stuff done in D in a fraction of a time it takes
to do even less in RoR.
This is the stuff marketing campaigns are made from. As well as
informing the cabal that is this mailing list, there needs to be tweets,
Facebook, G+, and proper publishing articles of people switching from
RoR, Grails, Django to web.d and vibe.d and discovering (measured and
guaranteed) significant performance benefits in both time to market and
run time.

Go has gained much of it's traction from provably and consistently
producing simpler, faster and more reliable systems that C, C++, Python,
etc. and getting articles about the success out there. HN is all very
well but it is really another inward looking cabal. Articles about
rewrites of systems written in sober yet humorous tones presenting real
benefits will over a period of a couple of year generate a groundswell
of support.

D may be a lot older than Go, but there is a lot to be learned from the
way non-Google folk created the "buzz" for Go by doing and publishing
data about, as well as chatting on the mailing list. It also helped that
a faction in Canonical switched from Python to Go and got on and did
things that contributed positively to Ubuntu. Whatever your feelings
towards Canonical and Ubuntu, their use of Go has contributed strongly
to the progress and acceptance of the language.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Rikki Cattermole via Digitalmars-d
2014-04-30 04:22:51 UTC
Permalink
It may be a good time to repeat, we need a marketing manager for
D!
Somebody really really needs to focus on getting us out there.
Dicebot via Digitalmars-d
2014-04-30 04:42:08 UTC
Permalink
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Post by Russel Winder via Digitalmars-d
On Tue, 2014-04-29 at 22:09 +0000, Adam D. Ruppe via
Digitalmars-d
[
]
Post by Adam D. Ruppe via Digitalmars-d
I can just get stuff done in D in a fraction of a time it
takes to do even less in RoR.
This is the stuff marketing campaigns are made from. As well as
informing the cabal that is this mailing list, there needs to
be tweets,
Facebook, G+, and proper publishing articles of people
switching from
RoR, Grails, Django to web.d and vibe.d and discovering
(measured and
guaranteed) significant performance benefits in both time to
market and
run time.
I have a friend who has switched to vibe.d after being Erlang
Cowboy devoted user for years. Trying to convince him to write an
article about it but no luck so far :( Reason to switch in two
words : "static typing".
via Digitalmars-d
2014-04-30 05:07:57 UTC
Permalink
Post by Dicebot via Digitalmars-d
I have a friend who has switched to vibe.d after being Erlang
Cowboy devoted user for years. Trying to convince him to write
an article about it but no luck so far :( Reason to switch in
two words : "static typing".
Yes, static typing is a main selling point. I would also consider
switching to D or Go for webstuff if it was production
ready/supported. But they will need to reach Java maturity to
gain traction in a wider audience...
Paulo Pinto via Digitalmars-d
2014-04-30 07:25:10 UTC
Permalink
Post by Dicebot via Digitalmars-d
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Post by Russel Winder via Digitalmars-d
On Tue, 2014-04-29 at 22:09 +0000, Adam D. Ruppe via
Digitalmars-d
[
]
Post by Adam D. Ruppe via Digitalmars-d
I can just get stuff done in D in a fraction of a time it
takes to do even less in RoR.
This is the stuff marketing campaigns are made from. As well as
informing the cabal that is this mailing list, there needs to
be tweets,
Facebook, G+, and proper publishing articles of people
switching from
RoR, Grails, Django to web.d and vibe.d and discovering
(measured and
guaranteed) significant performance benefits in both time to
market and
run time.
I have a friend who has switched to vibe.d after being Erlang
Cowboy devoted user for years. Trying to convince him to write
an article about it but no luck so far :( Reason to switch in
two words : "static typing".
I do like dynamic typed languages, but mostly for prototyping,
scripting and tiny scale projects.

The type of code that we get to write at enterprise level, static
typing is very valuable, specially given how management tends to
enforce "write code not tests" and the skillset of certain
developers across regions.

Code bases being worked on with 30+ developers across multiple
sites get fragile very easily.

--
Paulo
via Digitalmars-d
2014-04-30 05:00:46 UTC
Permalink
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Post by Russel Winder via Digitalmars-d
Go has gained much of it's traction from provably and
consistently
producing simpler, faster and more reliable systems that C,
C++, Python,
etc. and getting articles about the success out there.
Python is simpler than Go for web. There is a reason for why Go
is still not in production on App Engine, you end up with more
convoluted code as far as I can tell. Faster, yep.
Paulo Pinto via Digitalmars-d
2014-04-30 07:18:17 UTC
Permalink
On Wednesday, 30 April 2014 at 05:00:47 UTC, Ola Fosheim GrÞstad
Post by Dicebot via Digitalmars-d
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Post by Russel Winder via Digitalmars-d
Go has gained much of it's traction from provably and
consistently
producing simpler, faster and more reliable systems that C,
C++, Python,
etc. and getting articles about the success out there.
Python is simpler than Go for web. There is a reason for why Go
is still not in production on App Engine, you end up with more
convoluted code as far as I can tell. Faster, yep.
Only because developers don't reach for PyPy and Cython as much
as they should, rather re-writing everything from scratch and
they stating how they are impressed by Go.
Mengu via Digitalmars-d
2014-04-30 08:54:52 UTC
Permalink
Post by Paulo Pinto via Digitalmars-d
On Wednesday, 30 April 2014 at 05:00:47 UTC, Ola Fosheim GrÞstad
Post by Dicebot via Digitalmars-d
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Post by Russel Winder via Digitalmars-d
Go has gained much of it's traction from provably and
consistently
producing simpler, faster and more reliable systems that C,
C++, Python,
etc. and getting articles about the success out there.
Python is simpler than Go for web. There is a reason for why
Go is still not in production on App Engine, you end up with
more convoluted code as far as I can tell. Faster, yep.
Only because developers don't reach for PyPy and Cython as much
as they should, rather re-writing everything from scratch and
they stating how they are impressed by Go.
thank god i'm not the only one who thinks like that. rob pike
mentioned that there are much more conversion of python / ruby
developers than c / c++ developers. and as we all know the
reason is the speed and there's a trade off. they're trading
beauty, elegance, simplicity with ugly speed. i also think many
go users are caught NIH syndrome. they are re-inventing
everything. heck, they are even re-inventing nginx, redis, etc.
because they are _not written_ in go.

on ruby on rails side, it is fairly very easy. i've built apps
with rails and i've always been happy with it. some apps used
rails defaults, some apps were very customised. the thing with
ror is that it is never getting in your way when you open up your
editor and start building your application and that's what i look
for in a web framework.
Russel Winder via Digitalmars-d
2014-04-30 17:23:41 UTC
Permalink
On Wed, 2014-04-30 at 05:00 +0000, via Digitalmars-d wrote:
[
]
Post by via Digitalmars-d
Python is simpler than Go for web. There is a reason for why Go
is still not in production on App Engine, you end up with more
convoluted code as far as I can tell. Faster, yep.
I disagree. A good Python Web application would be using Flask, Bottle,
Tornado, Pyramid, Django as a framework and a design and idioms to suit.
A good Go Web application has a very different architecture, design and
code idioms due to the use of CSP via the goroutines. I do non-HTTP
networking rather than HTTP networking and end up with very different
solutions to the same problem using Python and Go. If QtD were in a
better state I could do a D version

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
via Digitalmars-d
2014-04-30 18:04:29 UTC
Permalink
On Wednesday, 30 April 2014 at 17:23:49 UTC, Russel Winder via
Post by Russel Winder via Digitalmars-d
Tornado, Pyramid, Django as a framework and a design and idioms
I've looked closely at Django. I find it more convenient to use
smaller independent libraries inspired by Django than using the
framework itself.

The problem with frameworks that are supposed to support a plugin
architecture is that they become complex and not very
transparent. That makes debugging harder, and you need to debug
because plugins don't always integrate well with each other. So
at the end of the day you spend time struggling with debugging
complex mechanics that you only need to support plugins. With a
more nimble environment you spend less time debugging (or trying
to figure out what a plugin actually does) and more time coding
stuff that fits the requirements.

Frameworks requires you to invest time, that can pay off, but
frameworks have trouble moving with the times so
 that investment
does not pay off long term when you realize that you need to
switch to a different framework.

As an example: some of the frameworks I've looked at predated
UTF-8 and contains an insane amount of code just for dealing with
different character sets. The same is true for the client side.
Some of the javascript frameworks contains a silly amount of code
for dealing with IE6 and other browsers that you can safely
ignore

Post by Russel Winder via Digitalmars-d
A good Go Web application has a very different architecture,
design and code idioms due to the use of CSP via the goroutines.
Well, I only know Go from Google App Engine. Browse the
hello-world tutorial and you'll see that the Python version is
more legible (?):

https://developers.google.com/appengine/docs/go/gettingstarted/introduction

https://developers.google.com/appengine/docs/python/gettingstartedpython27/introduction
Russel Winder via Digitalmars-d
2014-04-30 20:00:50 UTC
Permalink
On Wed, 2014-04-30 at 18:04 +0000, via Digitalmars-d wrote:
[
]
Post by via Digitalmars-d
I've looked closely at Django. I find it more convenient to use
smaller independent libraries inspired by Django than using the
framework itself.
If you have a "full stack" solution to a problem then Django does work
quite well, however most of my use is far from "full stack" so Flask,
Bottle, Twisted and Tornado are my "go to" (*) Python frameworks
Post by via Digitalmars-d
The problem with frameworks that are supposed to support a plugin
architecture is that they become complex and not very
transparent. That makes debugging harder, and you need to debug
because plugins don't always integrate well with each other. So
at the end of the day you spend time struggling with debugging
complex mechanics that you only need to support plugins. With a
more nimble environment you spend less time debugging (or trying
to figure out what a plugin actually does) and more time coding
stuff that fits the requirements.
For "lightweight" problems, "full stack" frameworks are a disaster.
Hence the "lightweight" frameworks. Flask + SQLAlchemy is a very popular
combination. I'm not sure what the D equivalent is but I guess it is
vibe.d + ???.

[
]
Post by via Digitalmars-d
Well, I only know Go from Google App Engine. Browse the
hello-world tutorial and you'll see that the Python version is
I treat GAE as an anti-pattern.



(*) Are we allowed to have gotos any more since Dijkstra's letter?
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
via Digitalmars-d
2014-04-30 20:17:50 UTC
Permalink
On Wednesday, 30 April 2014 at 20:00:59 UTC, Russel Winder via
Post by Russel Winder via Digitalmars-d
If you have a "full stack" solution to a problem then Django
does work
quite well, however most of my use is far from "full stack" so
Depends on what "full stack" is meant to cover. I haven't found a
single full-fledged forum software framework for Python, but
plenty for PhP. So in the end "full stack" isn't really enough.
You still end up having to integrate with "foreign" systems.
Post by Russel Winder via Digitalmars-d
Flask,
Bottle, Twisted and Tornado are my "go to" (*) Python frameworks
Ok, those are so lightweight that they are very close to being
libraries.
Post by Russel Winder via Digitalmars-d
For "lightweight" problems, "full stack" frameworks are a
disaster.
Yeah, but I think they are a disaster because they don't follow
the times. :-) Lightweight do, well at least they are remade or
forked.
Post by Russel Winder via Digitalmars-d
Post by via Digitalmars-d
Well, I only know Go from Google App Engine. Browse the
hello-world tutorial and you'll see that the Python version is
I treat GAE as an anti-pattern.
Hehe, but webapp2 + jinja2 isn't all that different from Flask
and Bottle (which also can run on GAE).

I am under the impression that Go for GAE is written by the Go
Team? So it shouldn't be an anti-pattern
 (?)
Post by Russel Winder via Digitalmars-d
(*) Are we allowed to have gotos any more since Dijkstra's
letter?
You better ask the dining philosophers.
Jacob Carlborg via Digitalmars-d
2014-04-30 07:14:33 UTC
Permalink
A lot of things, mostly focusing around having the compiler to help
refactor with confidence (the importance of this really can't be
understated) and having libraries that fit better.
I think one of the great things about Rails and Ruby is all the
libraries and plugins that are available. If I want to do something, in
RoR there's a big chance there's already a library for that. In D,
there's a big chance I need to implement it myself.
The speed is a nice
bonus too, having to spend half a minute just waiting for the tests to
run really grates me.
Yeah, it's sucks that Rails is so slow to boot. But unit tests in D suck
as well. I mean, how do I run a single unit test in D? Also, my text
editor (TextMate) already has support for the unit tests frameworks used
in Ruby.
But wrt libraries, ActiveRecord is unbelievably awful, for example. It
is a bad idea from the ground up: why, oh why are we reinventing the
database?
How do you mean? It just adds an object oriented layer on top of it.
BTW, what should I use in D. I need a library that is database
independent and I don't want to write SQL for the common use cases?
erb templates are painful to use too
I prefer HAML (similar to Jade in vibe.d) but I don't think it's that
bad. What do you use?
, and so is the routing. I
don't understand why routing isn't done automatically for the common case.
I don't know how you do you're routing but the first thing I do when
generating a new Rails application is to remove the default routing. The
default routing opens every public method in a controller to be a
routing end point. It's a complete mess.
The scaffolding is a pain too. Contrast to what web.d does: given a
function signature, it automatically generates a form for it (using type
information to select correct widgets) and can format the response in
several forms automatically including plain text, html list, html table,
json, xml, csv, and a custom template.
There's a plugin [1] for Rails for generating a form based on a type. I
don't understand how anyone can manage without that. It can
automatically respond in a couple of formats as well. By default JSON,
XML and Erb template. The most basic example will look something like this:

class FoosController < ApplicationController
respond_to :json, :xml

def index
respond_with Foo.all
end
end
Maybe Rails can do this stuff and I'm too much of a n00b, but the other
experienced team members say the way we're doing it is pretty standard
and I'm just not impressed.
Sure, it depends on what's "standard". Only using what's installed by
default. Then yes, perhaps that's standard. But it's not always the best
idea. At my previous work I did quite a lot different compared to the
"experienced" team members.
I can just get stuff done in D in a fraction of a time it takes to do
even less in RoR.
You don't think that's because you're used D for quite a while and
developed your own web framework. Compared to Rails where you're
completely new.

The biggest problem I have with D is have to do everything myself. I'm
getting a bit tired of that.

[1] https://github.com/plataformatec/simple_form
--
/Jacob Carlborg
Dicebot via Digitalmars-d
2014-04-30 09:43:29 UTC
Permalink
But unit tests in D suck as well. I mean, how do I run a single
unit test in D?
This is common complaint I still fail to understand. I have never
ever wanted to run a single unit test, why would one need it? If
running all module tests at once creates problems than either
module is too big or unit tests are not really unit tests.
Ary Borenszweig via Digitalmars-d
2014-04-30 14:18:35 UTC
Permalink
But unit tests in D suck as well. I mean, how do I run a single unit
test in D?
This is common complaint I still fail to understand. I have never ever
wanted to run a single unit test, why would one need it? If running all
module tests at once creates problems than either module is too big or
unit tests are not really unit tests.
When I have a bug in my code I usually add a test for it so it never
happens again.

Because it's a bug, I might need to debug it. So I add a couple of
"writefln" instead of using a debugger (it's faster and I get formatted
results easier).

Now, if I run all tests I will get output from all the tests, not the
one I'm trying to debug. That's really annoying.
Dicebot via Digitalmars-d
2014-04-30 14:25:05 UTC
Permalink
On Wednesday, 30 April 2014 at 14:18:37 UTC, Ary Borenszweig
Post by Ary Borenszweig via Digitalmars-d
When I have a bug in my code I usually add a test for it so it
never happens again.
Because it's a bug, I might need to debug it. So I add a couple
of "writefln" instead of using a debugger (it's faster and I
get formatted results easier).
Now, if I run all tests I will get output from all the tests,
not the one I'm trying to debug. That's really annoying.
Output from the failing test will always be the last one in
console. Pipe to tail -> profit. This sounds as pure aesthetics
issue.
H. S. Teoh via Digitalmars-d
2014-04-30 14:35:30 UTC
Permalink
Post by Ary Borenszweig via Digitalmars-d
When I have a bug in my code I usually add a test for it so it never
happens again.
Because it's a bug, I might need to debug it. So I add a couple of
"writefln" instead of using a debugger (it's faster and I get
formatted results easier).
Now, if I run all tests I will get output from all the tests, not the
one I'm trying to debug. That's really annoying.
Output from the failing test will always be the last one in console. Pipe to
tail -> profit. This sounds as pure aesthetics issue.
What I usually do is to be writefln at the start and end of the failing
test, so I know exactly which part of the output belongs to the failure:

unittest {
writeln("Starting failing test");

... // stuff
writeln("debug value = %s", ...);
... // stuff

writeln("End failing test");
}

Then just pipe it to:

sed -ne/^Starting\ failing\ test/,/^End\ failing\ test/p

and you're good to go. :-) (The "End" message is there so that you're
sure the failure is coming from this test, not somewhere else, and also
serves as an indicator of when the problem gets fixed and it moves on to
the next test.)


T
--
It's amazing how careful choice of punctuation can leave you hanging:
Ary Borenszweig via Digitalmars-d
2014-04-30 14:58:18 UTC
Permalink
Post by Ary Borenszweig via Digitalmars-d
When I have a bug in my code I usually add a test for it so it never
happens again.
Because it's a bug, I might need to debug it. So I add a couple of
"writefln" instead of using a debugger (it's faster and I get
formatted results easier).
Now, if I run all tests I will get output from all the tests, not the
one I'm trying to debug. That's really annoying.
Output from the failing test will always be the last one in console.
Pipe to tail -> profit. This sounds as pure aesthetics issue.
That's good.

What if you have tests against a database that where each take some
time? I don't want to wait for the whole tests to run...
Dicebot via Digitalmars-d
2014-04-30 15:04:46 UTC
Permalink
On Wednesday, 30 April 2014 at 14:58:20 UTC, Ary Borenszweig
Post by Ary Borenszweig via Digitalmars-d
That's good.
What if you have tests against a database that where each take
some time? I don't want to wait for the whole tests to run...
Tests with I/O are not unit tests. And built-in D feature is not
called unit-or-somet-other-tests. For integration testing you
need some different approach where being able to run separate
cases is indeed useful. But it is not a fault of D _unit_ test
design.
Nick Sabalausky via Digitalmars-d
2014-04-30 15:47:51 UTC
Permalink
Post by Ary Borenszweig via Digitalmars-d
What if you have tests against a database that where each take some
time? I don't want to wait for the whole tests to run...
Collapse block, [Home], [Shift]-[Down] (select), [Ctrl]-/ (comment)

;)

Just FWIW, though. I'm not arguing for or against an ability to run
specific unittests.
Andrei Alexandrescu via Digitalmars-d
2014-04-30 15:53:38 UTC
Permalink
Post by Ary Borenszweig via Digitalmars-d
But unit tests in D suck as well. I mean, how do I run a single unit
test in D?
This is common complaint I still fail to understand. I have never ever
wanted to run a single unit test, why would one need it? If running all
module tests at once creates problems than either module is too big or
unit tests are not really unit tests.
When I have a bug in my code I usually add a test for it so it never
happens again.
Because it's a bug, I might need to debug it. So I add a couple of
"writefln" instead of using a debugger (it's faster and I get formatted
results easier).
Now, if I run all tests I will get output from all the tests, not the
one I'm trying to debug. That's really annoying.
Yah, naming unittests is key here. With names one can specify which to
run/not run, regex patterns (i.e. "run only quick*") etc. -- Andrei
Jacob Carlborg via Digitalmars-d
2014-04-30 19:08:14 UTC
Permalink
This is common complaint I still fail to understand. I have never ever
wanted to run a single unit test, why would one need it? If running all
module tests at once creates problems than either module is too big or
unit tests are not really unit tests.
Why would I run more tests than I have to? BTW, I would probably use the
"unittest" keyword for other kinds of tests than unit tests as well.
--
/Jacob Carlborg
Dicebot via Digitalmars-d
2014-04-30 19:25:39 UTC
Permalink
Post by Jacob Carlborg via Digitalmars-d
Post by Dicebot via Digitalmars-d
This is common complaint I still fail to understand. I have
never ever
wanted to run a single unit test, why would one need it? If
running all
module tests at once creates problems than either module is
too big or
unit tests are not really unit tests.
Why would I run more tests than I have to?
Because you hardly notice difference between 0.1 and 0.5 seconds
Post by Jacob Carlborg via Digitalmars-d
BTW, I would probably use the "unittest" keyword for other
kinds of tests than unit tests as well.
This is main problem with your expectations I think.
Andrei Alexandrescu via Digitalmars-d
2014-04-30 20:36:16 UTC
Permalink
Post by Dicebot via Digitalmars-d
Post by Jacob Carlborg via Digitalmars-d
This is common complaint I still fail to understand. I have never ever
wanted to run a single unit test, why would one need it? If running all
module tests at once creates problems than either module is too big or
unit tests are not really unit tests.
Why would I run more tests than I have to?
Because you hardly notice difference between 0.1 and 0.5 seconds
*cough* std.datetime *cough* :o)

One good example is networking tests - if I worked on an airplane I'd
love to not test tests that need connectivity with a simple regex.


Andrei
Nick Sabalausky via Digitalmars-d
2014-04-30 20:38:55 UTC
Permalink
Post by Andrei Alexandrescu via Digitalmars-d
One good example is networking tests - if I worked on an airplane I'd
love to not test tests that need connectivity with a simple regex.
The biggest thing for me has been unittests in third party libraries
(hence the idiom of -version=unittest_myProjectName, but sometimes libs
don't do that). Although I seem to remember being told there's a way
around that, some hook into the unittest system or something.
Russel Winder via Digitalmars-d
2014-04-30 20:11:18 UTC
Permalink
On Wed, 2014-04-30 at 21:08 +0200, Jacob Carlborg via Digitalmars-d
wrote:
[
]
Post by Jacob Carlborg via Digitalmars-d
Why would I run more tests than I have to? BTW, I would probably use the
"unittest" keyword for other kinds of tests than unit tests as well.
This cannot be a good idea. If the block says unittest then it contains
unit tests, not integration tests or system tests, just unit tests.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Nick Sabalausky via Digitalmars-d
2014-04-30 12:26:04 UTC
Permalink
Post by Jacob Carlborg via Digitalmars-d
There's a plugin [1] for Rails for generating a form based on a type. I
don't understand how anyone can manage without that. It can
automatically respond in a couple of formats as well. By default JSON,
Automatic forms generated from a type are nice for quick-n-dirty stuff,
but I find they tend to work against (or at least be much less useful
for) the tweaking and customization usually needed in public-facing
production sites.

So I started doing it in reverse:

Instead of defining the form in the server-side code and then awkwardly
trying to make it generate the HTML I want, I just define the form in
HTML. (Or rather, in an HTML template that's still more-or-less valid
HTML, with a few additional non-standard tags to help with metadata like
"how to validate this field").

Then I use Adam's dom.d (in non-strict mode) to read the HTML form
template (preserving the templating stuff), and automatically infer
everything I need to automate the form's behavior (and to strip out the
non-standard metadata I added).

I've been pretty happy with that so far. It combines the DRY simplicity
of "define a form in ONE place and it 'just works'" with the full power
and control of hand-written HTML.

What I really need to do is fully de-entange that stuff from my
cluttered mess of a homemade web framework
<https://github.com/Abscissa/SemiTwistWeb> and release as a separate
cleaned-up lib.
Adam D. Ruppe via Digitalmars-d
2014-04-30 14:53:26 UTC
Permalink
On Wednesday, 30 April 2014 at 12:26:06 UTC, Nick Sabalausky
Post by Nick Sabalausky via Digitalmars-d
Automatic forms generated from a type are nice for
quick-n-dirty stuff, but I find they tend to work against (or
at least be much less useful for) the tweaking and
customization usually needed in public-facing production sites.
Aye, I rarely use my automatic forms on live sites either.... but
they are really nice for backend CRUD stuff or a quick-n-dirty
first-draft.

Sometimes though, I can get away with just modifying an automatic
form and kinda want to make web.d 2.0 better at that.
Post by Nick Sabalausky via Digitalmars-d
Instead of defining the form in the server-side code and then
awkwardly trying to make it generate the HTML I want, I just
define the form in HTML. (Or rather, in an HTML template that's
still more-or-less valid HTML, with a few additional
non-standard tags to help with metadata like "how to validate
this field").
Yes, rox rox rox.

This is what my html.d originally was for btw, expanding
non-standard tags. Many of them are obsolete now tho, I use html5
attributes instead. Of course, html.d also includes other cool
stuff like CSS expansion and JS foreach macros too, as we fairly
recently talked about.
Post by Nick Sabalausky via Digitalmars-d
Then I use Adam's dom.d (in non-strict mode) to read the HTML
form template (preserving the templating stuff)
I use strict mode for that stuff, keep in mind strict mode is
about well-formedness, not validation. So it accepts custom tags
and attributes easily enough.
Nick Sabalausky via Digitalmars-d
2014-04-30 16:02:23 UTC
Permalink
Post by Nick Sabalausky via Digitalmars-d
Then I use Adam's dom.d (in non-strict mode) to read the HTML form
template (preserving the templating stuff)
I use strict mode for that stuff, keep in mind strict mode is about
well-formedness, not validation. So it accepts custom tags and
attributes easily enough.
Well, I've been using mustache-d as my main templating engine, which is
just a general text preprocessor (Although I'm kinda eyeing that other
text preprocessor that uses actual D code). IIRC, I think there were
some cases where the my templates involved some non-well-formedness that
the DOM's non-strict mode was perfectly happy with. Whatever it was, I'm
sure there was *something* I was doing that strict mode was tripping up
on. May have been an old version of the DOM, too.

Granted there are still things I have to refrain from doing in my HTML
form templates because it would violate well-formedness *too much* even
for an ultra-relaxed HTML DOM. But those cases always have other
(arguably more sanitary) ways to accomplish the same thing.
Adam D. Ruppe via Digitalmars-d
2014-04-30 20:05:01 UTC
Permalink
On Wednesday, 30 April 2014 at 16:02:25 UTC, Nick Sabalausky
Post by Nick Sabalausky via Digitalmars-d
Well, I've been using mustache-d as my main templating engine,
which is just a general text preprocessor (Although I'm kinda
eyeing that other text preprocessor that uses actual D code).
ah, I see. BTW, fun fact: dom.d can understand ASP and PHP style
tags. You need to set a special callback or call
enableAddingSpecialTagsToDom() before parse, (The latter will
also enable storing comments, <! stuff> and <?stuff>) but then it
will work.

I did that to enable dual-use templates that have some PHP code
too. But it might be interesting to use for template stuff too...

BTW (ok this whole post is turning out to be a series of BTWs),
web.d also has a template function that is dom-aware which I
think is potentially very interesting.

Like it could see <span>{$foo}</span> and be aware to add a class
to that span or something. Or it could automatically wrap
variables in spans iff that makes sense in the html context.

Stuff I've never really used despite writing this some time
ago... but I still think there's some potential to all this.
Post by Nick Sabalausky via Digitalmars-d
Granted there are still things I have to refrain from doing in
my HTML form templates because it would violate well-formedness
*too much* even for an ultra-relaxed HTML DOM. But those cases
always have other (arguably more sanitary) ways to accomplish
the same thing.
yea
Adam D. Ruppe via Digitalmars-d
2014-04-30 15:04:52 UTC
Permalink
Post by Jacob Carlborg via Digitalmars-d
I think one of the great things about Rails and Ruby is all the
libraries and plugins that are available. If I want to do
something, in RoR there's a big chance there's already a
library for that. In D, there's a big chance I need to
implement it myself.
I like implementing things myself :P

That's the question I dread most at meetings now: "is there a gem
for this?" idk, in the time it takes to search for and evaluate
third party code, I could have just written it myself. Especially
since libraries almost always need some kind of customization for
our specific case anyway!

There's a few exceptions where something is hard to write, but
most things just aren't that hard.
Post by Jacob Carlborg via Digitalmars-d
But unit tests in D suck as well.
A big difference though is the compiler helps you a lot in D. In
Ruby, for example, the main reason we use the unit tests (so far)
is to help ensure consistency after refactoring something. It
catchings things like a renaming we missed, or a removed method
still in use.

In D, you just recompile and those things are found almost
instantly without needing to actually run any code.
Post by Jacob Carlborg via Digitalmars-d
How do you mean? It just adds an object oriented layer on top
of it.
They deliberately avoid the most important parts of a relational
database:

http://guides.rubyonrails.org/migrations.html

"The Active Record way claims that intelligence belongs in your
models, not in the database. As such, features such as triggers
or foreign key constraints, which push some of that intelligence
back into the database, are not heavily used."

ORM is something I only like in very small quantities, but
ActiveRecord uses it for *everything*, well, except for the
things it doesn't even support.

The problem here is one of encapsulation and of correctness. If
something bypasses the model - which is required for tasks the
library doesn't even support and also likely to happen if there's
a second app using the data - all kinds of stuff can get in there
that is bad.

You also have problems like race conditions:

account = BankAccount.find(1)
account.balance -= 10
account.save!

What if two of those run concurrently? I searched the web quickly
for this and haven't found a good answer yet...

Then, with referential integrity, the docs suggest DIY or getting
some third party gem, because their godawful library doesn't
really support it. The best it does is offer you a square wheel
with the dependent thing. Stupid stupid stupid.


When you actually use the database as it is intended, it takes
care of these things for you with very easy syntax that works
across business logic languages. Nothing new to learn there.
Post by Jacob Carlborg via Digitalmars-d
BTW, what should I use in D. I need a library that is database
independent and I don't want to write SQL for the common use
cases?
idk, I use my database.d which has a little bit of overlap with
what active record does, but since I generally see ORM as being a
nasty anti-pattern and horribly leaky abstraction, I didn't go
far with it.

There's really nothing to fear with writing SQL, except the cases
where the language sucks. (UPDATE and INSERT being so different,
and the solutions being different for the various vendors, ugh.
That's why I made my DataObject, it gathers the changes together
then issues one of those commands. It can also be gotten from a
query, making it a kind of simple active record:

auto obj = mysql.queryDataObject("select * from foo limit
1").front;
obj.whatever = "something";
obj.commitChanges(); // calls UPDATE foo SET whatever='something'
WHERE id = ?

which also works on joined queries on MySQL btw and offers easy
support for multiple primary keys or ones not named "id" (as an
argument to commitChanges), something active record as far as i
can tell doesn't even try to do, but it doesn't try to fetch
child objects or anything like that.

I have considered adding child object fetching, but I don't
really see the need, it is easy to write a method that does that
if you want to.)
Post by Jacob Carlborg via Digitalmars-d
I prefer HAML (similar to Jade in vibe.d) but I don't think
it's that bad. What do you use?
The ruby thing looks like this <span class="foo"><%= @some_value
%></span>.

For my D stuff, I have two options:

1) create the HTML right in D using dom.d. I like to use this for
objects that know how to format themselves and output strictly
semantic XML/HTML. The visual styling is then done with CSS. This
works better than you might expect!

2) web.d also has a fairly simple replacement system too:

<span class="foo">{$some_value}</span>

it also supports inserting partials

<div html-from="{$dynamic_html}"></div> or <include partial="foo"
/>, though the include thing takes a wee bit of helper code from
the app because it needs to find the html somewhere.

And the variable replacement can be piped: {$some_count|plural
user users} for example, which is kinda cool.

It does NOT support intertwined code. Other things are done with
attributes, such as class="if-logged-in" or <ul from="data_thing"
/> (infinitely extensible with the server-side DOM).
Post by Jacob Carlborg via Digitalmars-d
I don't know how you do you're routing but the first thing I do
when generating a new Rails application is to remove the
default routing. The default routing opens every public method
in a controller to be a routing end point. It's a complete mess.
It looks like this

root "home#index"

get "/users/login", to: "users#login"

namespace :admin do
resources :users do
resources :children
end
end


and so on. It isn't awful (especially now that I get what they
mean by "resources"), but my web.d rarely uses explicit routing
at all, it figures it out automatically by the names, protection
level, and types of child members.
Post by Jacob Carlborg via Digitalmars-d
There's a plugin [1] for Rails for generating a form based on a
type. I don't understand how anyone can manage without that.
thx, I'll take a gander.
Post by Jacob Carlborg via Digitalmars-d
It can automatically respond in a couple of formats as well. By
default JSON, XML and Erb template. The most basic example will
Responding with json, xml, and html Just Work with web.d, it
figures it out from the static type of the function return value.
Post by Jacob Carlborg via Digitalmars-d
You don't think that's because you're used D for quite a while
and developed your own web framework. Compared to Rails where
you're completely new.
Yes, obviously that's some of it, but there's other things that I
don't expect to change, especially things like runtime errors for
what the D compiler would catch.

I had to rename a thing last night. Took two hours to do the db
migrations and then rename the classes and update all the files.
I'm still not completely sure I did it right too! I've done
similar things in D in about 5 minutes, the compiler catches
everything so I have confidence.
Post by Jacob Carlborg via Digitalmars-d
The biggest problem I have with D is have to do everything
myself. I'm getting a bit tired of that.
i love that, different strokes i guess.
Nick Sabalausky via Digitalmars-d
2014-04-30 16:41:57 UTC
Permalink
A big difference though is the compiler helps you a lot in D. In Ruby,
for example, the main reason we use the unit tests (so far) is to help
ensure consistency after refactoring something. It catchings things like
a renaming we missed, or a removed method still in use.
This has a lot to do with why I don't buy the common argument that
dynamic languages are all about "just getting shit done".

Anytime I use them, they just create more work for me. Writing more
sanity checks. More hours debugging. More work to optimize hotspots.
More time figuring out Tracebacks I'm getting from code I didn't even
write or from tools I'm simply trying to install. Etc.
In D, you just recompile and those things are found almost instantly
without needing to actually run any code.
Gotta love it :)
Russel Winder via Digitalmars-d
2014-04-30 17:11:39 UTC
Permalink
On Wed, 2014-04-30 at 12:41 -0400, Nick Sabalausky via Digitalmars-d
wrote:
[
]
Post by Nick Sabalausky via Digitalmars-d
This has a lot to do with why I don't buy the common argument that
dynamic languages are all about "just getting shit done".
Interesting use of the word shit. I tend to find that the average
programmer produces shit code in whatever language they use. This is a
sad reflection on the whole of computing.
Post by Nick Sabalausky via Digitalmars-d
Anytime I use them, they just create more work for me. Writing more
sanity checks. More hours debugging. More work to optimize hotspots.
More time figuring out Tracebacks I'm getting from code I didn't even
write or from tools I'm simply trying to install. Etc.
Using a static language mindset when working with a dynamic language has
this effect. Likewise the reverse, using a dynamic language mindset with
a static language.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Adam D. Ruppe via Digitalmars-d
2014-04-30 20:28:31 UTC
Permalink
On Wednesday, 30 April 2014 at 16:42:00 UTC, Nick Sabalausky
Post by Nick Sabalausky via Digitalmars-d
Anytime I use them, they just create more work for me.
def. I like them in small quantities - heck, I'm written dynamic
types and scripting languages for D! But they cause me pain
pretty quickly.
Jacob Carlborg via Digitalmars-d
2014-04-30 19:53:53 UTC
Permalink
Post by Adam D. Ruppe via Digitalmars-d
I like implementing things myself :P
That's the question I dread most at meetings now: "is there a gem for
this?" idk, in the time it takes to search for and evaluate third party
code, I could have just written it myself. Especially since libraries
almost always need some kind of customization for our specific case anyway!
I don't agree with this.
Post by Adam D. Ruppe via Digitalmars-d
A big difference though is the compiler helps you a lot in D. In Ruby,
for example, the main reason we use the unit tests (so far) is to help
ensure consistency after refactoring something. It catchings things like
a renaming we missed, or a removed method still in use.
Then you're not using unit tests correctly ;)
Post by Adam D. Ruppe via Digitalmars-d
In D, you just recompile and those things are found almost instantly
without needing to actually run any code.
Yeah, sometimes it would be nice with static typing.
Post by Adam D. Ruppe via Digitalmars-d
http://guides.rubyonrails.org/migrations.html
"The Active Record way claims that intelligence belongs in your models,
not in the database. As such, features such as triggers or foreign key
constraints, which push some of that intelligence back into the
database, are not heavily used."
I don't really agree with that. Although I'm not a fan of store
procedures/functions in the database. But I don't mind foreign key
constraints. We used that at my previous work. Via a gem :)
Post by Adam D. Ruppe via Digitalmars-d
ORM is something I only like in very small quantities, but ActiveRecord
uses it for *everything*, well, except for the things it doesn't even
support.
The problem here is one of encapsulation and of correctness. If
something bypasses the model - which is required for tasks the library
doesn't even support and also likely to happen if there's a second app
using the data - all kinds of stuff can get in there that is bad.
account = BankAccount.find(1)
account.balance -= 10
account.save!
I think most Rails application are run single threaded. But with
multiple processes instead.
Post by Adam D. Ruppe via Digitalmars-d
What if two of those run concurrently? I searched the web quickly for
this and haven't found a good answer yet...
Then, with referential integrity, the docs suggest DIY or getting some
third party gem, because their godawful library doesn't really support
it. The best it does is offer you a square wheel with the dependent
thing. Stupid stupid stupid.
All libraries have positive and negative sides.
Post by Adam D. Ruppe via Digitalmars-d
idk, I use my database.d which has a little bit of overlap with what
active record does, but since I generally see ORM as being a nasty
anti-pattern and horribly leaky abstraction, I didn't go far with it.
Using a random D module for this doesn't feel very comfortable, no
offense. No documentation, no way to find examples and so on.
Post by Adam D. Ruppe via Digitalmars-d
There's really nothing to fear with writing SQL, except the cases where
the language sucks.
ActiveRecord will hide all the ugliness of SQL. Properly escape values,
to type conversions, time zone conversions and so on. It's also database
independent.
Post by Adam D. Ruppe via Digitalmars-d
(UPDATE and INSERT being so different, and the
solutions being different for the various vendors, ugh. That's why I
made my DataObject, it gathers the changes together then issues one of
those commands. It can also be gotten from a query, making it a kind of
auto obj = mysql.queryDataObject("select * from foo limit 1").front;
obj.whatever = "something";
obj.commitChanges(); // calls UPDATE foo SET whatever='something' WHERE
id = ?
which also works on joined queries on MySQL btw and offers easy support
for multiple primary keys or ones not named "id" (as an argument to
commitChanges), something active record as far as i can tell doesn't
even try to do, but it doesn't try to fetch child objects or anything
like that.
I have considered adding child object fetching, but I don't really see
the need, it is easy to write a method that does that if you want to.)
Post by Jacob Carlborg via Digitalmars-d
I prefer HAML (similar to Jade in vibe.d) but I don't think it's that
bad. What do you use?
1) create the HTML right in D using dom.d. I like to use this for
objects that know how to format themselves and output strictly semantic
XML/HTML. The visual styling is then done with CSS. This works better
than you might expect!
Are you using some kind of proxy for this or are you pushing back the
view layer to the model?
Post by Adam D. Ruppe via Digitalmars-d
<span class="foo">{$some_value}</span>
it also supports inserting partials
<div html-from="{$dynamic_html}"></div> or <include partial="foo" />,
though the include thing takes a wee bit of helper code from the app
because it needs to find the html somewhere.
Well, that's the same as in Rails. The HAML version would be:

<div html-from="#{@dynamic_html}"></div> or = render "foo". In Rails the
partial is just a template prefixed with an underscore. It fill find it
relative to the controller's view directory.
Post by Adam D. Ruppe via Digitalmars-d
And the variable replacement can be piped: {$some_count|plural user
users} for example, which is kinda cool.
I'm not sure I understand this piping.
Post by Adam D. Ruppe via Digitalmars-d
It does NOT support intertwined code. Other things are done with
attributes, such as class="if-logged-in" or <ul from="data_thing" />
(infinitely extensible with the server-side DOM).
What do you mean with "intertwined code"?
Post by Adam D. Ruppe via Digitalmars-d
It looks like this
root "home#index"
get "/users/login", to: "users#login"
namespace :admin do
resources :users do
resources :children
end
end
and so on. It isn't awful (especially now that I get what they mean by
"resources"), but my web.d rarely uses explicit routing at all, it
figures it out automatically by the names, protection level, and types
of child members.
In Rails that would be:

match ":controller(/:action(/:id))"

So "/foo/bar/1" would route to "bar" action in the FooController with
"1" assigned as the "id" parameter in "params". Only works with public
methods. I really hate this. It quickly becomes a big mess.

You can also do a catch all route:

match "*path" => "home#page_not_found"
Post by Adam D. Ruppe via Digitalmars-d
Responding with json, xml, and html Just Work with web.d, it figures it
out from the static type of the function return value.
In my experience it's rarely so easy. Most of the time I need to do some
customization of the format anyway so the built-in formatting isn't
suitable.
Post by Adam D. Ruppe via Digitalmars-d
Yes, obviously that's some of it, but there's other things that I don't
expect to change, especially things like runtime errors for what the D
compiler would catch.
Yes, sure.
Post by Adam D. Ruppe via Digitalmars-d
i love that, different strokes i guess.
I don't mind it but sometimes I just want to get some work done. I mean,
I've started out (or planed to) with some project in D but then I needed
to create all the support libraries and tools so I've almost forgot what
I was going to do in the first place.

I want to use Sass, CoffeeScript and HAML. But I don't want to write
three compilers just to do some web development.
--
/Jacob Carlborg
Nick Sabalausky via Digitalmars-d
2014-04-30 20:36:16 UTC
Permalink
Post by Jacob Carlborg via Digitalmars-d
Post by Adam D. Ruppe via Digitalmars-d
account = BankAccount.find(1)
account.balance -= 10
account.save!
I think most Rails application are run single threaded. But with
multiple processes instead.
Aren't you talking about databases? Single-threading won't save you from
races there unless the DBMS itself is single-threaded (which would be a
pretty undesirable DBMS).

Or does the ORM above automatically lock the row/table behind-the-scenes?
Adam D. Ruppe via Digitalmars-d
2014-04-30 20:38:34 UTC
Permalink
Post by Jacob Carlborg via Digitalmars-d
I don't really agree with that. Although I'm not a fan of store
procedures/functions in the database. But I don't mind foreign
key constraints. We used that at my previous work. Via a gem :)
Yeah, foreign keys are really an absolute must. So are uniqueness
constraints. Rails can kinda do these, but in its own reinvented
ways that don't actually hit the DB (at least not without add on
gems)

I also find myself really missing outer joins and views.
Post by Jacob Carlborg via Digitalmars-d
I think most Rails application are run single threaded. But
with multiple processes instead.
That doesn't change the race condition because the database is
still shared across those processes. With a regular SQL query,
the database guarantees consistent, atomic operations in the DB
engine itself, but with active record pattern, you give that
up... while still having the shared data.

It was a thing like this that recently took a bitcoin exchange
down. Literally the textbook example of concurrency, but most
these modern newfangled frameworks get it wrong.
Post by Jacob Carlborg via Digitalmars-d
Using a random D module for this doesn't feel very comfortable,
no offense. No documentation, no way to find examples and so on.
Yeah, I wrote these for myself and put them on the web just in
case somebody else finds them useful, but it is really a
take-it-or-leave-it thing to me. Even in my book when I talked
about some of these libs, I focused on lessons learned when
writing them more than the actual usage - my thought is then
maybe people can do their own thing instead of downloading my
stuff and using it straight up.
Post by Jacob Carlborg via Digitalmars-d
ActiveRecord will hide all the ugliness of SQL.
It also hides all the beauty of it :(
Post by Jacob Carlborg via Digitalmars-d
Properly escape values
If you're escaping values, unless you're writing some low level
database library, you're almost certainly doing it wrong.

I agree that using raw SQL with something like the PHP4 method of
string concatenation is a huge pain and awful, as well as
inefficient and insecure. But that's also the wrong way to do it
and any non-crippled database API or library offers ways to
separate the sql code and data cleanly and easily.
Post by Jacob Carlborg via Digitalmars-d
Are you using some kind of proxy for this or are you pushing
back the view layer to the model?
CSS is the view in that scenario. The HTML the object returns is
just its fields wrapped up in tags and classes. Works really
well, for my last big job, the designer worked almost exclusively
in CSS and we got a lot of stuff done.
Post by Jacob Carlborg via Digitalmars-d
I'm not sure I understand this piping.
It calls functions on the variable. So like {$foo|capitalize}
would be kinda like <%= capitalize(foo) %>. The plural example
uses arguments to the function too so we can customize the words
if it is plural or no.
Post by Jacob Carlborg via Digitalmars-d
What do you mean with "intertwined code"?
<html><% some ruby here %></html>

I hate that stuff, especially when the view starts doing implicit
database queries! Defeats the whole point of MVC separation if
you ask me.
Post by Jacob Carlborg via Digitalmars-d
match "*path" => "home#page_not_found"
Aye, web.d calls a method called catchAll for those too.
Post by Jacob Carlborg via Digitalmars-d
I don't mind it but sometimes I just want to get some work
done. I mean, I've started out (or planed to) with some project
in D but then I needed to create all the support libraries and
tools so I've almost forgot what I was going to do in the first
place.
meh, with my libs, they might not be accessible to others, being
poorly documented and all, but I know them and have used them for
almost everything that's come up over the years. So for me,
getting work done means spending an hour using D instead of days
searching the web for some gem that won't even work right anyway.
Adam D. Ruppe via Digitalmars-d
2014-04-30 13:38:27 UTC
Permalink
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Post by Russel Winder via Digitalmars-d
This is the stuff marketing campaigns are made from.
Eh, like Jacob said later, I don't think this is a totally fair
comparison cuz I'm a world class D expert but a RoR n00b, so
there's naturally some difference in speed there.

Of course, I doubt the gap will ever be closed, since Ruby's
awfulness isn't dependent on my experience level. It's not like
it will ever get static typing even if I used it all the time. It
won't get faster. ActiveRecord won't get sane.

But still, one person's productivity is too subjective to focus a
lot on IMO.
John Colvin via Digitalmars-d
2014-04-30 13:52:24 UTC
Permalink
Post by Dicebot via Digitalmars-d
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Post by Russel Winder via Digitalmars-d
This is the stuff marketing campaigns are made from.
Eh, like Jacob said later, I don't think this is a totally fair
comparison cuz I'm a world class D expert but a RoR n00b, so
there's naturally some difference in speed there.
Of course, I doubt the gap will ever be closed, since Ruby's
awfulness isn't dependent on my experience level. It's not like
it will ever get static typing even if I used it all the time.
It won't get faster. ActiveRecord won't get sane.
But still, one person's productivity is too subjective to focus
a lot on IMO.
Calculated dishonesty is healthy in a marketing campaign :p
Wyatt via Digitalmars-d
2014-04-30 15:00:03 UTC
Permalink
On Wednesday, 30 April 2014 at 13:38:28 UTC, Adam D. Ruppe
Post by Adam D. Ruppe via Digitalmars-d
But still, one person's productivity is too subjective to
focus a lot on IMO.
Calculated dishonesty is healthy in a marketing campaign :p
Put another way, one data point is not data but a lot of them is.
Every anecdote carries some weight.

And even as one person, there are probably a non-trivial number
of people who think roughly the same way and would benefit
from...err, from being proselytised? ;)

-Wyatt
Jacob Carlborg via Digitalmars-d
2014-04-30 19:06:48 UTC
Permalink
Of course, I doubt the gap will ever be closed, since Ruby's awfulness
isn't dependent on my experience level. It's not like it will ever get
static typing even if I used it all the time. It won't get faster.
ActiveRecord won't get sane.
Ruby has gotten faster in each release.
--
/Jacob Carlborg
Russel Winder via Digitalmars-d
2014-04-30 20:12:10 UTC
Permalink
On Wed, 2014-04-30 at 21:06 +0200, Jacob Carlborg via Digitalmars-d
Post by Jacob Carlborg via Digitalmars-d
Of course, I doubt the gap will ever be closed, since Ruby's awfulness
isn't dependent on my experience level. It's not like it will ever get
static typing even if I used it all the time. It won't get faster.
ActiveRecord won't get sane.
Ruby has gotten faster in each release.
Especially if you run JRuby on the JVM :-)
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Paulo Pinto via Digitalmars-d
2014-04-30 20:25:29 UTC
Permalink
Post by Russel Winder via Digitalmars-d
On Wed, 2014-04-30 at 21:06 +0200, Jacob Carlborg via Digitalmars-d
Post by Jacob Carlborg via Digitalmars-d
Of course, I doubt the gap will ever be closed, since Ruby's awfulness
isn't dependent on my experience level. It's not like it will ever get
static typing even if I used it all the time. It won't get faster.
ActiveRecord won't get sane.
Ruby has gotten faster in each release.
Especially if you run JRuby on the JVM :-)
Or shell out money for an AOT compiler like RubyMotion.
Ary Borenszweig via Digitalmars-d
2014-04-30 23:05:08 UTC
Permalink
Post by Dicebot via Digitalmars-d
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Of course, I doubt the gap will ever be closed, since Ruby's awfulness
isn't dependent on my experience level. It's not like it will ever get
static typing even if I used it all the time.
Nah, that will never happen. But you can get very close (
http://crystal-lang.org/ ), although you loose some dynamism at runtime...
Nick Sabalausky via Digitalmars-d
2014-04-29 15:27:59 UTC
Permalink
I have a friend that is a web developer. I, however want to collaborate
with him, so I am trying to get him to learn D. I don't know how to
persuade him! How can D be used to greatly assist an HTML5/JavaScript
web developer? I decided to go here to get some good answers. How can D
be used to interopt with modern web development?
Show him forum.dlang.org (written in D) and point out that modern
HTML5/JS sites are freaking horrid. </admitted-curmudgeon>
JN via Digitalmars-d
2014-04-29 19:48:39 UTC
Permalink
Post by Nick Sabalausky via Digitalmars-d
Show him forum.dlang.org (written in D) and point out that
modern HTML5/JS sites are freaking horrid.
</admitted-curmudgeon>
forum.dlang.org is written in HTML/JS too.
Nick Sabalausky via Digitalmars-d
2014-04-30 01:57:06 UTC
Permalink
Post by JN via Digitalmars-d
Post by Nick Sabalausky via Digitalmars-d
Show him forum.dlang.org (written in D) and point out that modern
HTML5/JS sites are freaking horrid. </admitted-curmudgeon>
forum.dlang.org is written in HTML/JS too.
Anything on the web involves HTML, the difference is whether the HTML is
the platform (ie HTML5) or just the renderer.

And forum.dlang.org uses very little JS (and only optionally). It's
certainly not built out of JS.
ketmar via Digitalmars-d
2014-04-29 14:51:15 UTC
Permalink
On Tue, 29 Apr 2014 14:41:17 +0000
James via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
just show him vibe.d. it's what node.js wants to be, but failed. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140429/aa3487e6/attachment.sig>
Rikki Cattermole via Digitalmars-d
2014-04-30 02:43:41 UTC
Permalink
Post by James via Digitalmars-d
I have a friend that is a web developer. I, however want to
collaborate with him, so I am trying to get him to learn D. I
don't know how to persuade him! How can D be used to greatly
assist an HTML5/JavaScript web developer? I decided to go here
to get some good answers. How can D be used to interopt with
modern web development?
If you want to show him what's possible with D, just show him
Cmsed[0] ;)
All I'm saying is, if you ever not want to write ajax code again,
Cmsed is your friend [1].

[0] https://github.com/rikkimax/Cmsed
[1] https://gist.github.com/rikkimax/11043210
Adam D. Ruppe via Digitalmars-d
2014-04-30 03:09:42 UTC
Permalink
On Wednesday, 30 April 2014 at 02:43:43 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
All I'm saying is, if you ever not want to write ajax code
again, Cmsed is your friend [1].
My web.d does some javascript generation too.

D:
import arsd.web;
class Foo : ApiProvider {
export int add(int a, int b) { return a+b; }
}
mixin FancyMain!Foo;

Javascript:

Foo.add(1, 2).get(alert); // calls alert(3) when it returns

The generated JS code creates an object with the same name as the
D class with all the export functions as methods that return a
proxy object, setting the arguments. You can then modify it and
eventually fire off the request with methods like get, getSync,
and getHtml which take a function to call with the result.

Just one of the many things I miss when doing RoR instead of D :(
Rikki Cattermole via Digitalmars-d
2014-04-30 03:20:15 UTC
Permalink
Post by Adam D. Ruppe via Digitalmars-d
On Wednesday, 30 April 2014 at 02:43:43 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
All I'm saying is, if you ever not want to write ajax code
again, Cmsed is your friend [1].
My web.d does some javascript generation too.
import arsd.web;
class Foo : ApiProvider {
export int add(int a, int b) { return a+b; }
}
mixin FancyMain!Foo;
Foo.add(1, 2).get(alert); // calls alert(3) when it returns
The generated JS code creates an object with the same name as
the D class with all the export functions as methods that
return a proxy object, setting the arguments. You can then
modify it and eventually fire off the request with methods like
get, getSync, and getHtml which take a function to call with
the result.
Just one of the many things I miss when doing RoR instead of D
:(
We should probably work together on this sort of stuff! As we
seem to have similar ideas
Adam D. Ruppe via Digitalmars-d
2014-04-30 04:12:58 UTC
Permalink
On Wednesday, 30 April 2014 at 03:20:16 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
We should probably work together on this sort of stuff! As we
seem to have similar ideas
Yea, I wrote my version several years ago (IIRC 2009 or early
2010) and since then D has grown as has my knowledge of it. I
kinda want to write a web.d 2.0 that cleans everything up but eh
I have a lot of things I want to do and web.d 1.0 works so no big
rush.

The 1.0 has a lot of cool stuff though, like it can avoid JS
calls by referencing the result of another function in the URL,
all pretty transparently. So like if you wrote, in JS:

Foo.add(Foo.add(1,2), 3).get(alert), it should only result in one
HTTP request. The proxy object when used as an argument just
emits an indirect reference through magic URL params. Kinda cool,
though it doesn't go as far as I'd like.


Among what I'd like to clean in web.d 2.0:

web.d supports what it calls "ApiObjects", which map to RESTful
uris:

class Poo : ApiObject {
this(ApiProvider parent, string identifier) {}
auto GET() { }
auto POST() {} // etc
auto bar() {}
}

If you went to:

/Poo/cool-beans

it would call (new Poo(parent, "cool-beans")).GET(). Then
/Poo/a/bar calls new Poo("a").bar and so on.

The problem is this is really reliant on things like the ending
slash, and it issues redirects to force it to be there or not be
there.

The implementation is also kinda buggy in general, it is supposed
to beautifully nest, but it only kinda does. Getting an index of
all things also doesn't work quite right, you have to write a
separate method for that.

So I'd like to clean all that up and actually design it instead
of growing on cool hacks as they come to mind.

Nested ApiProviders don't work exactly right either. They are
supposed to do a chain of magic:

class Foo : ApiProvider { auto whatever() {} }
class Bar : ApiProvider {
alias Foo foo;
}

Then, /foo/whatever does (new Foo((new Bar))).whatever. That part
works. The things is each class can also provide a postProcess
method to modify the document after it is generated. That's
*supposed* hit everything, but sometimes it doesn't, I think it
only works two levels deep right now, really hairy implementation.

The other problem is the Javascript generator doesn't really
understand nesting. Ideally, nested ApiProviders are made
available through dots and nested ApiObjects are workable through
JS proxy objects.

This looks like what you managed to do so that's cool.


I also need to clean up the reflection generation to make it
easier to use and make path info accessible outside just the
automatic routing (or the low level Cgi.pathInfo which doesn't
tell you where it starts!).

Reflection should be generated once upon startup then reused
forever as an immutable object. Currently, reflection is
partially regenerated on each request - eek.


I also wrote a _register*Processor family fairly recently (like
December 2012) that kinda obviates the old postProcess and back
in January this year, changed the session to put it all in
cookies instead of files. That stuff is awesome, so much better
than the old way. Should consider doing them from the ground up
now!

(Also, ironically, I was a big pusher for UDAs for web.d... but I
barely actually used them after they were made available. I
really wanted to put them on parameters tho, otherwise convention
over configuration is kinda how i play it LOLOL)



oh yeah and it could be documented somewhere other than my brain,
the sloppy source, and random forum posts so ppl can know about
it all. but meh.

All that said, it manages to get the job done for me so I'm not
in a huge rush to actually fix any of it.
Russel Winder via Digitalmars-d
2014-04-30 04:32:28 UTC
Permalink
On Wed, 2014-04-30 at 04:12 +0000, Adam D. Ruppe via Digitalmars-d
wrote:
[
]
Post by Adam D. Ruppe via Digitalmars-d
Yea, I wrote my version several years ago (IIRC 2009 or early
2010) and since then D has grown as has my knowledge of it. I
kinda want to write a web.d 2.0 that cleans everything up but eh
I have a lot of things I want to do and web.d 1.0 works so no big
rush.
I disagree. The lesson from the Bottle/Flask/Tornado experience over the
last few years is that it is always better to be working on the next
version rather than just stick to maintaining the current version.

Yes for using 1.0 on the current jobs, but definitely yes to starting on
2.0 now, especially if there are other to join in and help with the
work.

Web is not my area per se and I don't have a web-related project I can
pin helping out with this effort on, but I would encourage you to work
on 2.0.

I will have to be looking at Python's asyncio which is Python's "play"
in the arena that Twisted used to be king; more vibe.d than web.d.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Rikki Cattermole via Digitalmars-d
2014-04-30 04:32:31 UTC
Permalink
Post by Adam D. Ruppe via Digitalmars-d
On Wednesday, 30 April 2014 at 03:20:16 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
We should probably work together on this sort of stuff! As we
seem to have similar ideas
Yea, I wrote my version several years ago (IIRC 2009 or early
2010) and since then D has grown as has my knowledge of it. I
kinda want to write a web.d 2.0 that cleans everything up but
eh I have a lot of things I want to do and web.d 1.0 works so
no big rush.
The 1.0 has a lot of cool stuff though, like it can avoid JS
calls by referencing the result of another function in the URL,
Foo.add(Foo.add(1,2), 3).get(alert), it should only result in
one HTTP request. The proxy object when used as an argument
just emits an indirect reference through magic URL params.
Kinda cool, though it doesn't go as far as I'd like.
web.d supports what it calls "ApiObjects", which map to RESTful
class Poo : ApiObject {
this(ApiProvider parent, string identifier) {}
auto GET() { }
auto POST() {} // etc
auto bar() {}
}
/Poo/cool-beans
it would call (new Poo(parent, "cool-beans")).GET(). Then
/Poo/a/bar calls new Poo("a").bar and so on.
The problem is this is really reliant on things like the ending
slash, and it issues redirects to force it to be there or not
be there.
The implementation is also kinda buggy in general, it is
supposed to beautifully nest, but it only kinda does. Getting
an index of all things also doesn't work quite right, you have
to write a separate method for that.
So I'd like to clean all that up and actually design it instead
of growing on cool hacks as they come to mind.
Nested ApiProviders don't work exactly right either. They are
class Foo : ApiProvider { auto whatever() {} }
class Bar : ApiProvider {
alias Foo foo;
}
Then, /foo/whatever does (new Foo((new Bar))).whatever. That
part works. The things is each class can also provide a
postProcess method to modify the document after it is
generated. That's *supposed* hit everything, but sometimes it
doesn't, I think it only works two levels deep right now,
really hairy implementation.
The other problem is the Javascript generator doesn't really
understand nesting. Ideally, nested ApiProviders are made
available through dots and nested ApiObjects are workable
through JS proxy objects.
This looks like what you managed to do so that's cool.
I also need to clean up the reflection generation to make it
easier to use and make path info accessible outside just the
automatic routing (or the low level Cgi.pathInfo which doesn't
tell you where it starts!).
Reflection should be generated once upon startup then reused
forever as an immutable object. Currently, reflection is
partially regenerated on each request - eek.
I also wrote a _register*Processor family fairly recently (like
December 2012) that kinda obviates the old postProcess and back
in January this year, changed the session to put it all in
cookies instead of files. That stuff is awesome, so much better
than the old way. Should consider doing them from the ground up
now!
(Also, ironically, I was a big pusher for UDAs for web.d... but
I barely actually used them after they were made available. I
really wanted to put them on parameters tho, otherwise
convention over configuration is kinda how i play it LOLOL)
oh yeah and it could be documented somewhere other than my
brain, the sloppy source, and random forum posts so ppl can
know about it all. but meh.
All that said, it manages to get the job done for me so I'm not
in a huge rush to actually fix any of it.
It does look like web.d was a bit of a precursor to Cmsed
(unintentionally) strangely enough.
Although I definitely would like to hear more about asynchronous
javascript instead of my synchronous based code and how I can
combine it at some point.
Adam D. Ruppe via Digitalmars-d
2014-04-30 13:48:07 UTC
Permalink
On Wednesday, 30 April 2014 at 04:32:33 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Although I definitely would like to hear more about
asynchronous javascript instead of my synchronous based code
and how I can combine it at some point.
The way it works in mine is the proxy object sets a kinda magical
helper value in the URL params, telling it to evaluate the named
function instead of just trying to convert the data to the right
time.

So for that one, the regular might be /add?a=1&b=2. With the
nested call, we want a={the result of /add?a=1&b=2)&b=3.

So it passes it as something like this: "/add?" +
urlencode("a=/add?a=1&a=2") + "&b=2&a-type=ServerResult";

So the special "a-type=" tells it that a should not be converted
to an integer, but instead parsed and called.

The same url parser deconstructs it into a function call and gets
the data out (currently, the implementation does it through
string intermediaries for ease; it almost literally replaces that
with the result in the URL, then re-parses it).

This avoids extra calls to the server since it is all done in one
set. There's also ways to filter the results that way, for
example running a querySelector() call on the server to filter a
HTML result for JS.



Then, the JS call itself is either synchronous or asynchronous.
The sync calls are done with the .getSync method. This generally
sucks so I rarely use it, but one cool thing about it is
exceptions from the D side are propagated to the Javascript side,
making error handling natural. (This is also the way my web.d.php
works - it uses PHP's version of opDispatch to make a little
class that translate's PHP function calls to http requests for
talking to the server. It always uses synchronous calls.... which
sucks btw, but it is awfully easy to use: $a = $Foo->add(1,
2).getSync();)

The asynch ones just do pretty regular AJAX requests with a
callback. The only thing that's interesting is I used the apply
function in JS to make it kinda nice:

return callback.apply(callbackThis, ourArguments);

So things like this kinda works sanely, arguments you pass are
forwarded, etc.


function someFunction(something, another, result) {}

Foo.add(1,2).get(someFunction, "hey", this); // will call
someFunction("hey", this, 3);


Naturally, there's on error callbacks too that can work the same
way. D exceptions are passed as JS objects. (Indeed, in general,
all the results from D are passed as objects, it does some
JSON.parse action on the JS side and automatic serialization on
the D side so many things just work.)
Rikki Cattermole via Digitalmars-d
2014-04-30 13:58:33 UTC
Permalink
Post by Adam D. Ruppe via Digitalmars-d
On Wednesday, 30 April 2014 at 04:32:33 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Although I definitely would like to hear more about
asynchronous javascript instead of my synchronous based code
and how I can combine it at some point.
The way it works in mine is the proxy object sets a kinda
magical helper value in the URL params, telling it to evaluate
the named function instead of just trying to convert the data
to the right time.
So for that one, the regular might be /add?a=1&b=2. With the
nested call, we want a={the result of /add?a=1&b=2)&b=3.
So it passes it as something like this: "/add?" +
urlencode("a=/add?a=1&a=2") + "&b=2&a-type=ServerResult";
So the special "a-type=" tells it that a should not be
converted to an integer, but instead parsed and called.
The same url parser deconstructs it into a function call and
gets the data out (currently, the implementation does it
through string intermediaries for ease; it almost literally
replaces that with the result in the URL, then re-parses it).
This avoids extra calls to the server since it is all done in
one set. There's also ways to filter the results that way, for
example running a querySelector() call on the server to filter
a HTML result for JS.
Then, the JS call itself is either synchronous or asynchronous.
The sync calls are done with the .getSync method. This
generally sucks so I rarely use it, but one cool thing about it
is exceptions from the D side are propagated to the Javascript
side, making error handling natural. (This is also the way my
web.d.php works - it uses PHP's version of opDispatch to make a
little class that translate's PHP function calls to http
requests for talking to the server. It always uses synchronous
calls.... which sucks btw, but it is awfully easy to use: $a =
$Foo->add(1, 2).getSync();)
The asynch ones just do pretty regular AJAX requests with a
callback. The only thing that's interesting is I used the apply
return callback.apply(callbackThis, ourArguments);
So things like this kinda works sanely, arguments you pass are
forwarded, etc.
function someFunction(something, another, result) {}
Foo.add(1,2).get(someFunction, "hey", this); // will call
someFunction("hey", this, 3);
Naturally, there's on error callbacks too that can work the
same way. D exceptions are passed as JS objects. (Indeed, in
general, all the results from D are passed as objects, it does
some JSON.parse action on the JS side and automatic
serialization on the D side so many things just work.)
I see I see. I was assuming there wasn't too much changed on the
server side. And mostly in javascript. Netherless quite
interesting and advanced usage.
Perhaps it could spawn some changes to the router. And hence the
ajax route generation.
Rikki Cattermole via Digitalmars-d
2014-04-30 04:52:04 UTC
Permalink
On Wednesday, 30 April 2014 at 04:32:37 UTC, Russel Winder via
Post by Russel Winder via Digitalmars-d
On Wed, 2014-04-30 at 04:12 +0000, Adam D. Ruppe via
Digitalmars-d
[
]
Post by Adam D. Ruppe via Digitalmars-d
Yea, I wrote my version several years ago (IIRC 2009 or early
2010) and since then D has grown as has my knowledge of it. I
kinda want to write a web.d 2.0 that cleans everything up but
eh I have a lot of things I want to do and web.d 1.0 works so
no big rush.
I disagree. The lesson from the Bottle/Flask/Tornado experience
over the
last few years is that it is always better to be working on the
next
version rather than just stick to maintaining the current
version.
Yes for using 1.0 on the current jobs, but definitely yes to
starting on
2.0 now, especially if there are other to join in and help with
the
work.
Web is not my area per se and I don't have a web-related
project I can
pin helping out with this effort on, but I would encourage you
to work
on 2.0.
I will have to be looking at Python's asyncio which is Python's
"play"
in the arena that Twisted used to be king; more vibe.d than
web.d.
I've been working on Cmsed/Dvorm/Dakka specifically in the mind
of a rather (major) web service. Haven't started it yet, but
possibly next semester.
I'm of the opinion that we all need to work together to get a
damn nice web service framework together.
I split up my ORM for this purpose so even if you don't want to
use Cmsed you can use it at least. Won't be very nice for normal
Vibe users though.

I really do want help, Dakka (Actor framework) needs somebody who
knows threading/networking communication. I'll eventually get it
communicating with other nodes but.. Will opensource if there is
interest.

Dvorm needs work to make it be usable with relational databases.
At worse that means I need OpenDBX dlls for 32/64bit (wasn't as
easy to compile as I thought).
The hardest part really is how to handle indexes.

Cmsed needs documentation by the bucket load. Its also blocked at
the moment on dub to make it sensible to do reloading of
templates/routes/models. Which will change the way you structure
it.

Cmsed is already at the point of comparable to other web service
frameworks in most other languages.
Russel Winder via Digitalmars-d
2014-04-30 05:24:55 UTC
Permalink
On Wed, 2014-04-30 at 04:52 +0000, Rikki Cattermole via Digitalmars-d
wrote:
[
]
Post by Rikki Cattermole via Digitalmars-d
I've been working on Cmsed/Dvorm/Dakka specifically in the mind
of a rather (major) web service. Haven't started it yet, but
possibly next semester.
I'm of the opinion that we all need to work together to get a
damn nice web service framework together.
I would say from anecdotal observation, so no real significance, that
most languages end up with a number of frameworks:

1A. Full stack Web framework.
1B. Lightweight HTTP framework.
2A. Full feature networking framework.
2B. Lightweight networking framework.

In 1A we have JavaEE, Spring, RoR, Django, Grails, etc. In 2B we have
Sinatra, Ratpack, Flask, Bottle, etc. For 2A there is Twisted and 2B
asyncio (showing my Python bias here :-)
Post by Rikki Cattermole via Digitalmars-d
I split up my ORM for this purpose so even if you don't want to
use Cmsed you can use it at least. Won't be very nice for normal
Vibe users though.
Grails is doing this at last (necessitated by supporting NoSQL as well
as SQL in the full stack). This is a positive aspect of "componentizing"
such large frameworks.
Post by Rikki Cattermole via Digitalmars-d
I really do want help, Dakka (Actor framework) needs somebody who
knows threading/networking communication. I'll eventually get it
communicating with other nodes but.. Will opensource if there is
interest.
I would love to help here, and indeed on a review of std.parallelism,
but I have committed my time to a revamp of GPars for Groovy 2.3 and
Java 8, so cannot take on another big task in the short term.
Post by Rikki Cattermole via Digitalmars-d
Dvorm needs work to make it be usable with relational databases.
At worse that means I need OpenDBX dlls for 32/64bit (wasn't as
easy to compile as I thought).
The hardest part really is how to handle indexes.
Pass I'm afraid, I cannot contribute on this front at all.
Post by Rikki Cattermole via Digitalmars-d
Cmsed needs documentation by the bucket load. Its also blocked at
the moment on dub to make it sensible to do reloading of
templates/routes/models. Which will change the way you structure
it.
Is it viable for Dub to support this? Is someone working on it to create
a pull request? Can SCons be an alternative here?
Post by Rikki Cattermole via Digitalmars-d
Cmsed is already at the point of comparable to other web service
frameworks in most other languages.
So why would I use it rather than RoR, Grails, Django, Java EE, Spring?
Not entirely a rhetorical question. It is good to know early in
development why it is worth doing the development rather than using
pre-existing tools.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Rikki Cattermole via Digitalmars-d
2014-04-30 05:42:51 UTC
Permalink
On Wednesday, 30 April 2014 at 05:25:15 UTC, Russel Winder via
Post by Russel Winder via Digitalmars-d
On Wed, 2014-04-30 at 04:52 +0000, Rikki Cattermole via
Digitalmars-d
[
]
Post by Rikki Cattermole via Digitalmars-d
I've been working on Cmsed/Dvorm/Dakka specifically in the
mind of a rather (major) web service. Haven't started it yet,
but possibly next semester.
I'm of the opinion that we all need to work together to get a
damn nice web service framework together.
I would say from anecdotal observation, so no real
significance, that
1A. Full stack Web framework.
1B. Lightweight HTTP framework.
2A. Full feature networking framework.
2B. Lightweight networking framework.
In 1A we have JavaEE, Spring, RoR, Django, Grails, etc. In 2B
we have
Sinatra, Ratpack, Flask, Bottle, etc. For 2A there is Twisted
and 2B
asyncio (showing my Python bias here :-)
Post by Rikki Cattermole via Digitalmars-d
I split up my ORM for this purpose so even if you don't want
to use Cmsed you can use it at least. Won't be very nice for
normal Vibe users though.
Grails is doing this at last (necessitated by supporting NoSQL
as well
as SQL in the full stack). This is a positive aspect of
"componentizing"
such large frameworks.
Post by Rikki Cattermole via Digitalmars-d
I really do want help, Dakka (Actor framework) needs somebody
who knows threading/networking communication. I'll eventually
get it communicating with other nodes but.. Will opensource if
there is interest.
I would love to help here, and indeed on a review of
std.parallelism,
but I have committed my time to a revamp of GPars for Groovy
2.3 and
Java 8, so cannot take on another big task in the short term.
Post by Rikki Cattermole via Digitalmars-d
Dvorm needs work to make it be usable with relational
databases. At worse that means I need OpenDBX dlls for
32/64bit (wasn't as easy to compile as I thought).
The hardest part really is how to handle indexes.
Pass I'm afraid, I cannot contribute on this front at all.
Post by Rikki Cattermole via Digitalmars-d
Cmsed needs documentation by the bucket load. Its also blocked
at the moment on dub to make it sensible to do reloading of
templates/routes/models. Which will change the way you
structure it.
Is it viable for Dub to support this? Is someone working on it
to create
a pull request? Can SCons be an alternative here?
I have already posted on the dub forum about this, Sonke Ludwig
said he would be working on variables which will at least allow
for copying libraries templates ext.
Post by Russel Winder via Digitalmars-d
Post by Rikki Cattermole via Digitalmars-d
Cmsed is already at the point of comparable to other web
service frameworks in most other languages.
So why would I use it rather than RoR, Grails, Django, Java EE,
Spring?
Not entirely a rhetorical question. It is good to know early in
development why it is worth doing the development rather than
using
pre-existing tools.
Because Vibe already supports a good amount of functionality I am
already a step up (like file uploading and templates).
I have a wiki page to what I currently have done vs what I want
to do [0].

I really need to do another release of it and Dvorm and give a
better indication of what it can do.
I posted somewhere else some of the more advanced functionality
being ajax generation from routes/models [1]. But I really need
some sort of time cost research to reference with regards to how
much time it could save (I also need this for a research paper).

I basically had to make my own web service framework primarily
because from my experience and knowledge of what currently is
available, nothing meet my requirements. It would be more work
creating it in other languages than to just do it in D from the
start.

Not to mention I can get pretty good performance out of D in both
memory and requests/second. Now if only I could get the ram
requirement to compile Cmsed below half a gig I'd be alright (a
long shot given my CTFE usage).

[0] https://github.com/rikkimax/Cmsed/wiki/Road-map
[1] https://gist.github.com/rikkimax/11043210
Nick Sabalausky via Digitalmars-d
2014-04-30 12:56:00 UTC
Permalink
Post by Russel Winder via Digitalmars-d
I would say from anecdotal observation, so no real significance, that
1A. Full stack Web framework.
1B. Lightweight HTTP framework.
2A. Full feature networking framework.
2B. Lightweight networking framework.
In 1A we have JavaEE, Spring, RoR, Django, Grails, etc. In 2B we have
Sinatra, Ratpack, Flask, Bottle, etc. For 2A there is Twisted and 2B
asyncio (showing my Python bias here :-)
That does seem to happen.

FWIW, IMO the big selling point of D is it's fairly unique knack for
letting you eat your cake and still have it. I rather like to think we
can manage merging the "full stacks" with the "lightweights".
via Digitalmars-d
2014-04-30 13:47:10 UTC
Permalink
On Wednesday, 30 April 2014 at 12:56:03 UTC, Nick Sabalausky
Post by Nick Sabalausky via Digitalmars-d
FWIW, IMO the big selling point of D is it's fairly unique
knack for letting you eat your cake and still have it. I rather
like to think we can manage merging the "full stacks" with the
"lightweights".
Ugh, avoid the full stacks like the plague. They tend to be
lockin solutions. Reminds me of Tango in D1 where you risked
pulling in all kinds of dependencies.

You might dislike this, but I think nimble servers and clean
separation with javascript heavy clients are the future.

What I don't want:

- I have started to avoid server processing of forms,
javascript/ajax gives better user experience.

- I avoid advanced routing, it adds little and leads to harder to
maintain code, give me a regexp based routing table in one
location binding request-handlers.

- Server side generation should be kept minimal, prevents caching.

- Would never consider using serverside javascript generation.

What I do want:

- Transparent fast distributed in-memory database with logging to
a exchangable backing store and with consistency guarantees.

- No filesystem dependencies.
Adam D. Ruppe via Digitalmars-d
2014-04-30 14:57:00 UTC
Permalink
On Wednesday, 30 April 2014 at 13:47:11 UTC, Ola Fosheim GrÞstad
Post by via Digitalmars-d
You might dislike this, but I think nimble servers and clean
separation with javascript heavy clients are the future.
- I have started to avoid server processing of forms,
javascript/ajax gives better user experience.
I don't really agree, I do as much work as I can on the server, I
like the AJAX stuff to be as stupid simple as setting innerHTML.
(Indeed, web.d's automatic javascript has helper functions for
this: Server.getSomeData(args).useToReplace(some_element); )

It makes it a lot simpler and gives good compatibility since the
client is pretty thin.
Post by via Digitalmars-d
- I avoid advanced routing, it adds little and leads to harder
to maintain code, give me a regexp based routing table in one
location binding request-handlers.
aye, I think routing is generally ridiculous.
Post by via Digitalmars-d
- Server side generation should be kept minimal, prevents
caching.
That's not really true. You can cache individual parts on the
server and in some cases, cache the whole page on the client too.

Of course, doing things on the server may not need to be cached
anyway because you don't have the lag of a million http requests
in putting it together.
via Digitalmars-d
2014-04-30 15:18:21 UTC
Permalink
Post by Adam D. Ruppe via Digitalmars-d
Post by via Digitalmars-d
- Server side generation should be kept minimal, prevents
caching.
That's not really true. You can cache individual parts on the
server and in some cases, cache the whole page on the client
too.
Mhh
 I think there are several different types of files and
caching strategies:

1. static files (the ones that never change can be stored at edge
caches)

2. pregenerated files (files served from Amazon AWS, Google Cloud
Storage, CDNs)

3. proxy cachable files / client cachable files

4. server memcached files

5. fully dynamic files

Ola.
Nick Sabalausky via Digitalmars-d
2014-04-30 15:27:45 UTC
Permalink
On 4/30/2014 9:47 AM, "Ola Fosheim GrÞstad"
Post by Nick Sabalausky via Digitalmars-d
FWIW, IMO the big selling point of D is it's fairly unique knack for
letting you eat your cake and still have it. I rather like to think we
can manage merging the "full stacks" with the "lightweights".
Ugh, avoid the full stacks like the plague. They tend to be lockin
solutions. Reminds me of Tango in D1 where you risked pulling in all
kinds of dependencies.
You might dislike this, but I think nimble servers and clean separation
with javascript heavy clients are the future.
That definitely is the direction things are moving right now. Granted, I
don't like it, but you're right it's undoubtedly the popular direction
and it's unlikely to slow or reverse anytime soon.

That said, I don't have an issue with fat clients in general. I usually
tend to prefer them (ex: desktop email client). Just not when the "fat
client" happens to be inside a web browser, because that tends to not be
"fat" client so much as "needlessly bloated" client with an awkward,
temperamental UI (example: MS Word and OpenOffice have never lost one
keystroke for me from a network hiccup or anything equally trivial).
- I have started to avoid server processing of forms, javascript/ajax
gives better user experience.
JS can definitely help improve the UX of form validation, no doubt about
that, but it's important to remember that server-side validation is
still necessary anyway, regardless of what you do on the client.
- I avoid advanced routing, it adds little and leads to harder to
maintain code, give me a regexp based routing table in one location
binding request-handlers.
Same here. I don't like having my available HTTP interfaces scattered
across my codebade, and I definitely don't like having them implicit
based on member-function visibility (I've used such frameworks before.
Not personally my cup of tea).

What I *do* love is having a canonical table defining my entire HTTP
interface in one easy location. The extra typing or non-DRYness of that
is a mere triviality in my experience (and I'm normally a huge DRY buff).
- Server side generation should be kept minimal, prevents caching.
Ehh, yes and no. Server side generation is usually fine, just not when
it's done more often than necessary. And traditional server-side web
technologies definitely tend to do it more than necessary,

For example, consider a page containing a blog post with (non-Disqus)
user comments:

It's a complete waste for the server to regenerate such a page upon
every request, PHP/ASP-style. That's because it doesn't *change* upon
every viewing - it only changes on every post and edit (and not even
every one of those, if there's enough comments to trigger paging).

So unless the page's rate of comment "submissions/edits" approaches the
rate of comment "views" (unlikely...except maybe on YouTube ;) ), then
it's best to re-generate upon posts/edits and then cache that. So you
still get caching benefits, but with no need to make *all* the clients
duplicate the exact same page-generating effort as each other upon every
viewing.

Supporting login stuff (ex: "Hello, [your name here]! Logout?") doesn't
really mess this up either. The vast majority of the page can still be
cached by the server. Then, "generating" it for each user doesn't need
to be anything more resource-intensive than this:

void loginUser(string name)
{
session.user.loggedIn = true;
session.user.name = name;

// Whatever template engine you want:
session.user.loggedInUI =
`Hello <b>`~name~`</b>! <a href="/logout">Logout</a>`;
}

enum commonLoggedOutUI =
`Login: <form>Username:<input...> Pass:<input...></form>`;

void showMyPage(OutRange response, User user)
{
// myPage was automatically split into parts A and B
// last time it was updated:

response.put(myPagePartA);

if(session.user.loggedIn)
response.put(session.user.loggedInUI);
else
response.put(commonLoggedOutUI);

response.put(myPagePartB);
}
- Would never consider using serverside javascript generation.
Heh, I've actually done that on old-style ASP (ages ago). It was both
confusing and interesting.
- Transparent fast distributed in-memory database with logging to a
exchangable backing store and with consistency guarantees.
- No filesystem dependencies.
I'll take those, plus a large vanilla latte, please. :) "Thank you, come
again!"
via Digitalmars-d
2014-04-30 16:32:29 UTC
Permalink
On Wednesday, 30 April 2014 at 15:27:48 UTC, Nick Sabalausky
Post by Nick Sabalausky via Digitalmars-d
That definitely is the direction things are moving right now.
Granted, I don't like it, but you're right it's undoubtedly the
popular direction and it's unlikely to slow or reverse anytime
soon.
I'm not sure if I like it either, but I think websites are
getting more usable now. For a while it was a shitty stuttering
mess of HTML and JS that made me longing for an AntiWeb browser
with community maintained per-site AI that turns the horrible
HTML-mess into semantic markup that you can style yourself. I
actually have a file called antiweb.d here
 ;)

I also had high hopes for XSLT. I remember requiring
studentprojects to serve XML from the server, and transform it to
HTML using XSLT in the browser back in 2002 or so. And XSLT
support was actually quite good, at least until the mobile shit
hit the fan. Unfortunately connections were still slow so XSLT
based rendering had to wait until the whole XML was downloaded.
Today I think it might work out quite nicely, but I doubt anyone
even remembers that browser can do XSLT today. Actually, I am not
even sure if they all still support it?

The weird thing is that SEO and search engine priorities are the
ones that keep the dynamic websites from going fully dynamic by
their anti-dynamic measures (punishing non-static content) and
they are also the ones that are pushing semantic markup such as
itemscope/itemprop microdata.

On the other side of the fence the Wordpress authors are having a
lot of power. Whatever Wordpress makes easy will dominate a large
portion of the web. I think that is so sad, because the Wordpress
codebase is
 err
 junk. I am not even going to use the term «a
pile of junk» which would suggest that there is some sense of
structure to it. I think it is more like a scattered mutating
spaghetti dinner gone terribly wrong, slowly emerging from every
toilet in every household taking over the earth
 like the classic
horror movies from the 1950s.
Post by Nick Sabalausky via Digitalmars-d
JS can definitely help improve the UX of form validation, no
doubt about that, but it's important to remember that
server-side validation is still necessary anyway, regardless of
what you do on the client.
Yup. So a must have is a good infrastructure for specifying
database invariants and transactions. Ideally it should execute
like a stored procedure thus leaving the server logic pretty
clean.
Post by Nick Sabalausky via Digitalmars-d
What I *do* love is having a canonical table defining my entire
HTTP interface in one easy location. The extra typing or
non-DRYness of that is a mere triviality in my experience (and
I'm normally a huge DRY buff).
Yep, it also acts like always-up-to-date documentation when you
come back to the source code 6 months later trying to figure out
the main structure.
Post by Nick Sabalausky via Digitalmars-d
So unless the page's rate of comment "submissions/edits"
approaches the rate of comment "views" (unlikely...except maybe
on YouTube ;) ), then it's best to re-generate upon posts/edits
and then cache that. So you still get caching benefits, but
with no need to make *all* the clients duplicate the exact same
page-generating effort as each other upon every viewing.
Well, I would probably use JS
 ;-)

But I am pragmatic. Caching and pregeneration can lead to bugs
and complications. So it is usually a good idea to just do a
dynamic version first and then add caching when needed.

I also sometimes use a dynamic template during development, and
then just save a static version for release if I know that it
won't change.
Post by Nick Sabalausky via Digitalmars-d
I'll take those, plus a large vanilla latte, please. :) "Thank
you, come again!"
You're welcome!

I think it is realistic now for smaller sites (say 1-8 servers)
where you have enough RAM to hold perhaps 10 times the
information the site will ever provide. One should be able to
sync 8 servers that have relative few write operations easily.
So, reading the log might take some time during startup, but with
an efficient format
 it probably could complete quickly for 1GB
of data.
Nick Sabalausky via Digitalmars-d
2014-04-30 16:56:08 UTC
Permalink
On 4/30/2014 12:32 PM, "Ola Fosheim GrÞstad"
On the other side of the fence the Wordpress authors are having a lot of
power. Whatever Wordpress makes easy will dominate a large portion of
the web. I think that is so sad, because the Wordpress codebase is
 err

junk.
I've used Wordpress. Its codebase isn't the only thing bad about it ;)
I am not even going to use the term «a pile of junk» which would
suggest that there is some sense of structure to it. I think it is more
like a scattered mutating spaghetti dinner gone terribly wrong, slowly
emerging from every toilet in every household taking over the earth

like the classic horror movies from the 1950s.
Sounds pretty much exactly what I'd expect from just about any PHP-based
application. :/
Post by Nick Sabalausky via Digitalmars-d
JS can definitely help improve the UX of form validation, no doubt
about that, but it's important to remember that server-side validation
is still necessary anyway, regardless of what you do on the client.
Yup. So a must have is a good infrastructure for specifying database
invariants and transactions. Ideally it should execute like a stored
procedure thus leaving the server logic pretty clean.
I have to admit I've been in the habit of avoiding anything beyond basic
SELECT/INSERT/UPDATE/DELETE and CREATE TABLE. Not that I haven't used
them, but I really should have more familiarity with the other stuff
than I do. Ugh, but SQL can be such a pain, especially with all the
vendor differences, and when compared to accomplishing something in
whatever language I'm invoking SQL from.
via Digitalmars-d
2014-04-30 17:17:01 UTC
Permalink
On Wednesday, 30 April 2014 at 16:56:11 UTC, Nick Sabalausky
Post by Nick Sabalausky via Digitalmars-d
Sounds pretty much exactly what I'd expect from just about any
PHP-based application. :/
Modern PHP isn't so bad. I can write acceptable code in PHP.
Though, I only do so when there is no other option, since it is
the least desirable option next to Perl. The good thing about PHP
is that default installs tend to have good C libraries. I think
it would have died without that.

So, if PHP is ok then it must be the PHP programmers that are to
blame. I shudder to think what happens with a niche community if
they pick it as the next fad
 It could destroy any upcoming
programming community with spaghetti-hell. Are you sure you want
to market D as a web platform?
Post by Nick Sabalausky via Digitalmars-d
familiarity with the other stuff than I do. Ugh, but SQL can be
such a pain, especially with all the vendor differences, and
when compared to accomplishing something in whatever language
I'm invoking SQL from.
You can implement it in the ORB or wherever unit that provides
transactions. I was more pointing to what I find useful
conceptually in terms of layers:

1. user input on the client
2. validate on client
3. post using ajax
4. server unwraps the data and blindly inserts it into the
database
5. if transaction fails, notify client, goto 1
6. done.

Another good reason for fat clients is that the edit/run cycle is
tighter and it is easier to run a debugger on it. It makes sense
to put most of the code where you can mutate it easily.
Byron via Digitalmars-d
2014-04-30 17:23:39 UTC
Permalink
4. server unwraps the data and blindly inserts it into the database
ummmm...... wtf? This is why hackers keep stealing my credit card....

Client side validation should only be used for giving users immediate fed
back and saving cycles. You do know I can look at your js, find all of
your ajax calls and send what ever data I want right..
via Digitalmars-d
2014-04-30 17:40:57 UTC
Permalink
Post by Byron via Digitalmars-d
Client side validation should only be used for giving users
immediate fed
back and saving cycles. You do know I can look at your js, find all of
your ajax calls and send what ever data I want right..
If the security model depends on code being hidden then there is
something very wrong with it.

The database should do all the veracity checks and apply all the
consistency constraints. The server should merely prepare the
data. If any constraints triggers the transaction is rolled back.

This becomes even more important when you have multiple servers
and versions of the server software maintained by various
divisions writing to the same database.
Adam D. Ruppe via Digitalmars-d
2014-04-30 13:54:14 UTC
Permalink
On Wednesday, 30 April 2014 at 04:32:37 UTC, Russel Winder via
Post by Russel Winder via Digitalmars-d
The lesson from the Bottle/Flask/Tornado experience over the
last few years is that it is always better
to be working on the next version rather than just
stick to maintaining the current version.
Maybe, but in general, I write what I use, and right now I don't
have any significant new D web projects in the pipeline. I still
have a couple old ones going, but the new boss said no in
switching to D from Ruby (the rest of the team doesn't know it),
so the question now is: do I want to spend my nights writing
something I won't be using right now or doing something else?

for now, the answer is doing something else. That might change
eventually tho.
Post by Russel Winder via Digitalmars-d
in the arena that Twisted used to be king; more vibe.d than
web.d.
I think the vibe.d folks are doing pretty cool work too.
Actually, my web.d could arguably be used with vibe.d; a vibe
backend for my cgi.d is a realistic possibility, and then web.d
is a pretty straight-forward add-on on top of that. In fact, it
might not even be very hard, I just haven't tried yet.

(And the other libs are already independent, I think Nick uses my
dom.d with vibe already.)

Though, my little httpd isn't awful so again, "works for me" is a
lot of inertia to overcome.
Dicebot via Digitalmars-d
2014-04-30 04:10:13 UTC
Permalink
On Wednesday, 30 April 2014 at 02:43:43 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Post by James via Digitalmars-d
I have a friend that is a web developer. I, however want to
collaborate with him, so I am trying to get him to learn D. I
don't know how to persuade him! How can D be used to greatly
assist an HTML5/JavaScript web developer? I decided to go here
to get some good answers. How can D be used to interopt with
modern web development?
If you want to show him what's possible with D, just show him
Cmsed[0] ;)
All I'm saying is, if you ever not want to write ajax code
again, Cmsed is your friend [1].
[0] https://github.com/rikkimax/Cmsed
[1] https://gist.github.com/rikkimax/11043210
Having a quick look at Cmsed I must admit I like plain vibe.d
much more despite the added features :( Forced module coupling
and OO-heavy design is big loss compared to design simplicity and
independence of base vibe.d modules.

For example I can't imagine a single case when I'd prefer
class-based route definition to stock delegate-based.
Rikki Cattermole via Digitalmars-d
2014-04-30 04:21:18 UTC
Permalink
Post by Adam D. Ruppe via Digitalmars-d
On Wednesday, 30 April 2014 at 02:43:43 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Post by James via Digitalmars-d
I have a friend that is a web developer. I, however want to
collaborate with him, so I am trying to get him to learn D. I
don't know how to persuade him! How can D be used to greatly
assist an HTML5/JavaScript web developer? I decided to go
here to get some good answers. How can D be used to interopt
with modern web development?
If you want to show him what's possible with D, just show him
Cmsed[0] ;)
All I'm saying is, if you ever not want to write ajax code
again, Cmsed is your friend [1].
[0] https://github.com/rikkimax/Cmsed
[1] https://gist.github.com/rikkimax/11043210
Having a quick look at Cmsed I must admit I like plain vibe.d
much more despite the added features :( Forced module coupling
and OO-heavy design is big loss compared to design simplicity
and independence of base vibe.d modules.
For example I can't imagine a single case when I'd prefer
class-based route definition to stock delegate-based.
The classes are unfortunately just a container for routes. So if
you got a better way, that can provide the same functionality,
I'd love for a plan on how to do it!

Basically my idea is that you register as little as possible.
That was why I went with a class for routes.

I'm really gunning for less, simpler = more. And for medium-large
sites thats kinda important.
Dicebot via Digitalmars-d
2014-04-30 09:41:35 UTC
Permalink
On Wednesday, 30 April 2014 at 04:21:20 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Post by Dicebot via Digitalmars-d
Having a quick look at Cmsed I must admit I like plain vibe.d
much more despite the added features :( Forced module coupling
and OO-heavy design is big loss compared to design simplicity
and independence of base vibe.d modules.
For example I can't imagine a single case when I'd prefer
class-based route definition to stock delegate-based.
The classes are unfortunately just a container for routes. So
if you got a better way, that can provide the same
functionality, I'd love for a plan on how to do it!
Basically my idea is that you register as little as possible.
That was why I went with a class for routes.
I'm really gunning for less, simpler = more. And for
medium-large sites thats kinda important.
Why can't stand-alone annotated function be a valid route? Route
is pretty much method + url + handler and first two can be
inferred by convention in many cases (as done in vibe.web.rest &
Co).

Right now your approach actually results in more code than stock
vibe.d (stand-alone function + explicit route registration).
Rikki Cattermole via Digitalmars-d
2014-04-30 10:01:50 UTC
Permalink
Post by Dicebot via Digitalmars-d
On Wednesday, 30 April 2014 at 04:21:20 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Post by Dicebot via Digitalmars-d
Having a quick look at Cmsed I must admit I like plain vibe.d
much more despite the added features :( Forced module
coupling and OO-heavy design is big loss compared to design
simplicity and independence of base vibe.d modules.
For example I can't imagine a single case when I'd prefer
class-based route definition to stock delegate-based.
The classes are unfortunately just a container for routes. So
if you got a better way, that can provide the same
functionality, I'd love for a plan on how to do it!
Basically my idea is that you register as little as possible.
That was why I went with a class for routes.
I'm really gunning for less, simpler = more. And for
medium-large sites thats kinda important.
Why can't stand-alone annotated function be a valid route?
Route is pretty much method + url + handler and first two can
be inferred by convention in many cases (as done in
vibe.web.rest & Co).
The only way I know of that doesn't result in a container is
registerRoutes!"mymodule"; Instead of registerRoute!MyRoute;

Now if I could get access to a list of all the modules and hence
all routes at CTFE then that wouldn't be an issue. Same deal for
models.

Basically give me a way that doesn't impose upon the user to
manually register a route and the symbol is available at CTFE,
then I'll use it.

I just don't know it.

There is some benefits of having a container for routes however.
Being able to add UDAs to that group of routes. I.e. Don't
generate javascript, give them a name/grouping.
While its possible without it, its a bit more distinct.
Dicebot via Digitalmars-d
2014-04-30 12:38:30 UTC
Permalink
On Wednesday, 30 April 2014 at 10:01:51 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Post by Dicebot via Digitalmars-d
Why can't stand-alone annotated function be a valid route?
Route is pretty much method + url + handler and first two can
be inferred by convention in many cases (as done in
vibe.web.rest & Co).
The only way I know of that doesn't result in a container is
registerRoutes!"mymodule"; Instead of registerRoute!MyRoute;
Well you need to specify this only once with root module (usually
app.d) supplied as a parameter. You can query all imported
modules recursively from it.
Post by Rikki Cattermole via Digitalmars-d
Now if I could get access to a list of all the modules and
hence all routes at CTFE then that wouldn't be an issue. Same
deal for models.
This can't be done with same guarantees as runtime reflection
because of separate compilation. Requirement to transitively to
import everything from root module is necessary. I don't see it
much of a burden though.
Post by Rikki Cattermole via Digitalmars-d
There is some benefits of having a container for routes however.
Being able to add UDAs to that group of routes. I.e. Don't
generate javascript, give them a name/grouping.
While its possible without it, its a bit more distinct.
There are definitely several benefits of having aggregated
compile-time known list of routes. Actually I have added it as
one of examples for my DConf talk just yesterday :) This list,
however, can possibly be built automatically via reflection
provided single root entry point.

I think good flexible framework should provide user both options
and infer as much as possible by convention.
Rikki Cattermole via Digitalmars-d
2014-04-30 12:52:35 UTC
Permalink
Post by Dicebot via Digitalmars-d
There are definitely several benefits of having aggregated
compile-time known list of routes. Actually I have added it as
one of examples for my DConf talk just yesterday :) This list,
however, can possibly be built automatically via reflection
provided single root entry point.
I think good flexible framework should provide user both
options and infer as much as possible by convention.
Hmm interesting idea, although I'd feel a lot happier about it if
the compiler was able to (with a switch most likely) infer/create
automatically package.d files with auto import of all sub modules
if it doesn't exist.
Dicebot via Digitalmars-d
2014-04-30 12:55:35 UTC
Permalink
On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Post by Dicebot via Digitalmars-d
There are definitely several benefits of having aggregated
compile-time known list of routes. Actually I have added it as
one of examples for my DConf talk just yesterday :) This list,
however, can possibly be built automatically via reflection
provided single root entry point.
I think good flexible framework should provide user both
options and infer as much as possible by convention.
Hmm interesting idea, although I'd feel a lot happier about it
if the compiler was able to (with a switch most likely)
infer/create automatically package.d files with auto import of
all sub modules if it doesn't exist.
Sounds like typical use case for imaginary dub plugin system.
Rikki Cattermole via Digitalmars-d
2014-04-30 13:03:42 UTC
Permalink
Post by Dicebot via Digitalmars-d
On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Post by Dicebot via Digitalmars-d
There are definitely several benefits of having aggregated
compile-time known list of routes. Actually I have added it
as one of examples for my DConf talk just yesterday :) This
list, however, can possibly be built automatically via
reflection provided single root entry point.
I think good flexible framework should provide user both
options and infer as much as possible by convention.
Hmm interesting idea, although I'd feel a lot happier about it
if the compiler was able to (with a switch most likely)
infer/create automatically package.d files with auto import of
all sub modules if it doesn't exist.
Sounds like typical use case for imaginary dub plugin system.
Perhaps but in the compiler, the file system wouldn't actually be
changed. And the explicit package.d files would merely be
overrides.
John Colvin via Digitalmars-d
2014-04-30 13:28:26 UTC
Permalink
On Wednesday, 30 April 2014 at 13:03:43 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Post by Dicebot via Digitalmars-d
On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Post by Dicebot via Digitalmars-d
There are definitely several benefits of having aggregated
compile-time known list of routes. Actually I have added it
as one of examples for my DConf talk just yesterday :) This
list, however, can possibly be built automatically via
reflection provided single root entry point.
I think good flexible framework should provide user both
options and infer as much as possible by convention.
Hmm interesting idea, although I'd feel a lot happier about
it if the compiler was able to (with a switch most likely)
infer/create automatically package.d files with auto import
of all sub modules if it doesn't exist.
Sounds like typical use case for imaginary dub plugin system.
Perhaps but in the compiler, the file system wouldn't actually
be changed. And the explicit package.d files would merely be
overrides.
There's nothing stopping you from automatically making a
temporary directory structure for building. No need to alter it
in-place.
Rikki Cattermole via Digitalmars-d
2014-04-30 13:37:32 UTC
Permalink
Post by John Colvin via Digitalmars-d
On Wednesday, 30 April 2014 at 13:03:43 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Post by Dicebot via Digitalmars-d
On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Post by Dicebot via Digitalmars-d
There are definitely several benefits of having aggregated
compile-time known list of routes. Actually I have added it
as one of examples for my DConf talk just yesterday :) This
list, however, can possibly be built automatically via
reflection provided single root entry point.
I think good flexible framework should provide user both
options and infer as much as possible by convention.
Hmm interesting idea, although I'd feel a lot happier about
it if the compiler was able to (with a switch most likely)
infer/create automatically package.d files with auto import
of all sub modules if it doesn't exist.
Sounds like typical use case for imaginary dub plugin system.
Perhaps but in the compiler, the file system wouldn't actually
be changed. And the explicit package.d files would merely be
overrides.
There's nothing stopping you from automatically making a
temporary directory structure for building. No need to alter it
in-place.
The way this discussion is going I'll have a new build manager
built specifically for web development. This is where I'm gonna
say 'no'.

Hmm now if only I understand assembly better. And was able to
write a JIT then maybe. Maybe then I could implement my evil
ideas.
John Colvin via Digitalmars-d
2014-04-30 13:50:17 UTC
Permalink
On Wednesday, 30 April 2014 at 13:37:33 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Post by John Colvin via Digitalmars-d
On Wednesday, 30 April 2014 at 13:03:43 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Post by Dicebot via Digitalmars-d
On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki
Post by Rikki Cattermole via Digitalmars-d
Post by Dicebot via Digitalmars-d
There are definitely several benefits of having aggregated
compile-time known list of routes. Actually I have added
it as one of examples for my DConf talk just yesterday :)
This list, however, can possibly be built automatically
via reflection provided single root entry point.
I think good flexible framework should provide user both
options and infer as much as possible by convention.
Hmm interesting idea, although I'd feel a lot happier about
it if the compiler was able to (with a switch most likely)
infer/create automatically package.d files with auto import
of all sub modules if it doesn't exist.
Sounds like typical use case for imaginary dub plugin system.
Perhaps but in the compiler, the file system wouldn't
actually be changed. And the explicit package.d files would
merely be overrides.
There's nothing stopping you from automatically making a
temporary directory structure for building. No need to alter
it in-place.
The way this discussion is going I'll have a new build manager
built specifically for web development. This is where I'm gonna
say 'no'.
Hmm now if only I understand assembly better. And was able to
write a JIT then maybe. Maybe then I could implement my evil
ideas.
A JIT for D? That would be many, many man-years of work.
Rikki Cattermole via Digitalmars-d
2014-04-30 14:00:25 UTC
Permalink
Post by John Colvin via Digitalmars-d
On Wednesday, 30 April 2014 at 13:37:33 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Post by John Colvin via Digitalmars-d
On Wednesday, 30 April 2014 at 13:03:43 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Post by Dicebot via Digitalmars-d
On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki
Post by Rikki Cattermole via Digitalmars-d
Post by Dicebot via Digitalmars-d
There are definitely several benefits of having
aggregated compile-time known list of routes. Actually I
have added it as one of examples for my DConf talk just
yesterday :) This list, however, can possibly be built
automatically via reflection provided single root entry
point.
I think good flexible framework should provide user both
options and infer as much as possible by convention.
Hmm interesting idea, although I'd feel a lot happier
about it if the compiler was able to (with a switch most
likely) infer/create automatically package.d files with
auto import of all sub modules if it doesn't exist.
Sounds like typical use case for imaginary dub plugin
system.
Perhaps but in the compiler, the file system wouldn't
actually be changed. And the explicit package.d files would
merely be overrides.
There's nothing stopping you from automatically making a
temporary directory structure for building. No need to alter
it in-place.
The way this discussion is going I'll have a new build manager
built specifically for web development. This is where I'm
gonna say 'no'.
Hmm now if only I understand assembly better. And was able to
write a JIT then maybe. Maybe then I could implement my evil
ideas.
A JIT for D? That would be many, many man-years of work.
Nah written in D. But in saying that, it would probably be one of
the first languages I'd have a go at.
Etienne via Digitalmars-d
2014-04-30 14:51:45 UTC
Permalink
Post by John Colvin via Digitalmars-d
A JIT for D? That would be many, many man-years of work.
Wrong!

It would be quite easy. I've figured it out myself.

I've thought of using Pegged with PEG/BNF ParseTrees, made faster using
ParseTree serialization matched to the source's CRC32-encoding for
memoization, with a multi-threaded model of tree-generation when
branching in Or! steps.

Then, the interpretation stage can re-create the D environment with hash
maps of a "Entity" Variant of D types, functions, values and
instantiations added with their respective identifiers, each as a single
Entity struct containing their instructions as a simple array.

e.g. struct Entity { Entity[] scope; Entity[] instructions }

Once that's done, you should have all your types and objects in
HashMaps, ready to execute with an entry point. You move through the
instructions with a foreach loop by looking up function calls and
expecting the appropriate return type.

Call me crazy, but I think typed variants would be easier and faster to
handle than the regular casting methods that interpreted languages use
currently.

Anyway, the hardest part again would be to write a good garbage collector.
logicchains via Digitalmars-d
2014-04-30 14:11:19 UTC
Permalink
On Wednesday, 30 April 2014 at 13:37:33 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Hmm now if only I understand assembly better. And was able to
write a JIT then maybe. Maybe then I could implement my evil
ideas.
You don't necessarily need to understand assembly to write a JIT.
You could instead have your bytecode take the form of D functions
(such as int16 addI16(int16 a, int16 b), for instance) so you're
essentially generating an array of D functions then iterating
over them evaluating them. This would obviously be slower than
generating assembly directly, but would still be faster than an
interpreter, and you could still do some optimisation on it.
Rikki Cattermole via Digitalmars-d
2014-04-30 14:17:32 UTC
Permalink
Post by John Colvin via Digitalmars-d
On Wednesday, 30 April 2014 at 13:37:33 UTC, Rikki Cattermole
Post by Rikki Cattermole via Digitalmars-d
Hmm now if only I understand assembly better. And was able to
write a JIT then maybe. Maybe then I could implement my evil
ideas.
You don't necessarily need to understand assembly to write a
JIT. You could instead have your bytecode take the form of D
functions (such as int16 addI16(int16 a, int16 b), for
instance) so you're essentially generating an array of D
functions then iterating over them evaluating them. This would
obviously be slower than generating assembly directly, but
would still be faster than an interpreter, and you could still
do some optimisation on it.
Been there. Drunmeta [0]. Theres a reason why I'm not going down
that road anymore ;)

[0] https://github.com/rikkimax/drunmeta
Continue reading on narkive:
Loading...