I just want to write a web client app on D for medical
institutions. It must be a complicated interface. What tools
(GUI) should I use for quick programming?
Can I somehow abstract from web programming?
Thanks in advance.
Regards, Sergey
On Wednesday, 30 April 2014 at 04:22:52 UTC, Rikki Cattermole
wrote:
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.
If somebody has some time, they could post a solution in D to
this problem:
Danny Weldon:
If somebody has some time, they could post a solution in D to
this problem:
http://codegolf.stackexchange.com/questions/26323/how-slow-is-python-really-or-how-fast-is-your-language
It all helps to get the language visible.
Here are my solutions:
On 2014-05-03 21:52, Atila Neves wrote:
For me it's the output. I don't want to see the output of other
tests when I'm debugging a failure.
That's a good point.
--
/Jacob Carlborg
On 2014-05-03 21:51, Atila Neves wrote:
This is why I started to learn Cucumber.
Cucumber is for acceptance tests. There are also functional and
integration tests.
--
/Jacob Carlborg
On 2014-05-02 19:25, brad clawsie wrote:
this has been the fundamental issue for me. its not just missing libs,
its libs that are surfaced via a C-binding, which in my limited
I've had problems with ImageMagick, basically every time. But that's the
only one I can think of, at least for now.
On Sun, 2014-05-04 at 13:44 +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 2014-05-03 21:51, Atila Neves wrote:
This is why I started to learn Cucumber.
Cucumber is for acceptance tests. There are also functional and
integration tests.
We could get into bikeshedding here,…
Cucumber
On 5/4/2014 12:34 AM, Jonathan M Davis via Digitalmars-d wrote:
Regardless, unittest blocks don't really put any restrictions on what kind of
code can go in them, and I'd prefer that that stay the case. The discussion
on parallelizing unit tests threatens that on some level, but as long as we
On Sunday, 4 May 2014 at 10:04:12 UTC, bearophile wrote:
Danny Weldon:
If somebody has some time, they could post a solution in D to
this problem:
http://codegolf.stackexchange.com/questions/26323/how-slow-is-python-really-or-how-fast-is-your-language
It all helps to get the language
Meta:
Your C++ translation: ~277ms
Your second version: ~2.34ms/round
Both D programs are translations of C++ programs.
LDC might do a better job with this.
I have developed those two programs using ldc2, so the usage of
ldc2 is encouraged, and inlining is necessary for both programs.
The Nimrod version partially unrolls the recursion 4 times. How
hard is this to do in D?
http://codegolf.stackexchange.com/questions/26459/how-high-can-you-go-a-codingalgorithms-challenge
Bye,
bearophile
On 4/30/2014 1:36 PM, Andrei Alexandrescu wrote:
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.
I am suspicious that testing networks with a unit test is an inappropriate use
of unit tests.
Unit tests
On Thursday, 1 May 2014 at 10:50:12 UTC, John Colvin wrote:
On Wednesday, 30 April 2014 at 19:25:40 UTC, Dicebot wrote:
On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg
wrote:
On 2014-04-30 11:43, Dicebot wrote:
This is common complaint I still fail to understand. I have
never
On Thursday, 1 May 2014 at 09:58:32 UTC, Jacob Carlborg wrote:
On 2014-04-30 22:11, Russel Winder via Digitalmars-d wrote:
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.
Then we need to come up with
On 5/3/2014 3:32 PM, Walter Bright wrote:
On 4/30/2014 1:36 PM, Andrei Alexandrescu wrote:
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.
I am suspicious that testing networks with a unit test is an
On 5/3/2014 6:57 PM, Nick Sabalausky wrote:
I'm not sure mock networks can really be used for testing a client-only lib of
some specific protocol. There may also be other examples.
There's also the question of whether or not D's unittest {...} should *expect*
to be limited to tests that are
On Sat, 03 May 2014 19:36:53 -0700
Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 5/3/2014 6:57 PM, Nick Sabalausky wrote:
I'm not sure mock networks can really be used for testing a
client-only lib of some specific protocol. There may also be other
examples.
On 01/05/14 21:55, Marc Schütz schue...@gmx.net wrote:
You're probably right. I thought that changed in a recent release, but
can't find it anymore.
I don't know. I wouldn't trust it. It's the behavior in Rails 3. I
haven't used Rails 4 yet.
--
/Jacob Carlborg
On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:
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
On 4/30/2014 4:17 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Wednesday, 30 April 2014 at 20:00:59 UTC, Russel Winder via
(*) Are we allowed to have gotos any more since Dijkstra's letter?
You better ask the dining philosophers.
Nah, they're too busy trying to
Am 01.05.2014 01:05, schrieb Ary Borenszweig:
On 4/30/14, 10:38 AM, Adam D. Ruppe wrote:
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Digitalmars-d wrote:
Of course, I doubt the gap will ever be closed, since Ruby's awfulness
isn't dependent on my experience level. It's not
On Wednesday, 30 April 2014 at 20:36:15 UTC, Andrei Alexandrescu
wrote:
On 4/30/14, 12:25 PM, Dicebot wrote:
On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg
wrote:
On 2014-04-30 11:43, Dicebot wrote:
This is common complaint I still fail to understand. I have
never ever
wanted to
On 2014-04-30 22:11, Russel Winder via Digitalmars-d wrote:
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.
Then we need to come up with a separate framework for doing all other
kinds of tests.
--
On 2014-04-30 22:38, Adam D. Ruppe wrote:
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)
Rails unique constraints do hit the DB, but they
On 2014-04-30 22:36, Nick Sabalausky wrote:
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).
Are you referring to if one process executes line 1 while another
executes
On Wednesday, 30 April 2014 at 19:25:40 UTC, Dicebot wrote:
On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg
wrote:
On 2014-04-30 11:43, Dicebot wrote:
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
On Wednesday, 30 April 2014 at 15:04:53 UTC, Adam D. Ruppe wrote:
On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg
wrote:
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
On 5/1/14, 6:58 AM, Jacob Carlborg wrote:
On 2014-04-30 22:11, Russel Winder via Digitalmars-d wrote:
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.
Then we need to come up with a separate framework
On Wednesday, 30 April 2014 at 17:17:02 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 30 April 2014 at 16:56:11 UTC, Nick Sabalausky
wrote:
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.
On Thursday, 1 May 2014 at 10:44:42 UTC, Jacob Carlborg wrote:
On 2014-04-30 22:38, Adam D. Ruppe wrote:
I also find myself really missing outer joins and views.
For outer joins:
1. You can always use raw SQL, also in combination with
ActiveRecord
Post.joins(:comments).joins(outer join
On Thursday, 1 May 2014 at 12:17:56 UTC, Ary Borenszweig wrote:
On 5/1/14, 6:58 AM, Jacob Carlborg wrote:
On 2014-04-30 22:11, Russel Winder via Digitalmars-d wrote:
This cannot be a good idea. If the block says unittest then
it contains
unit tests, not integration tests or system tests, just
On 5/1/14, 3:50 AM, John Colvin wrote:
On Wednesday, 30 April 2014 at 19:25:40 UTC, Dicebot wrote:
On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg wrote:
On 2014-04-30 11:43, Dicebot wrote:
This is common complaint I still fail to understand. I have never ever
wanted to run a
On Thursday, 1 May 2014 at 13:33:50 UTC, Marc Schütz wrote:
IMO the client shouldn't do any validation, unless you can
really, really trust it. That's why I like to do things the
following way:
1. user input on the client
2. post using ajax
3. server validates and stores the data
4a. if
On Thursday, 1 May 2014 at 15:11:07 UTC, Nick Sabalausky wrote:
On Thursday, 1 May 2014 at 13:33:50 UTC, Marc Schütz wrote:
IMO the client shouldn't do any validation, unless you can
really, really trust it. That's why I like to do things the
following way:
1. user input on the client
2.
On 2014-05-01 15:54, Marc Schütz schue...@gmx.net wrote:
You can also use the built-in `includes()`, which does a LEFT OUTER JOIN:
Post.includes(:comments).where(comments: {title: bar})
(It also eager-loads the comments, but this is usually desired anyway,
because an OUTER JOIN doesn't
On 2014-05-01 19:56, Marc Schütz schue...@gmx.net wrote:
Exactly. I just feel that client-side validation is unnecessary
duplication in most cases. But sure, it can be used where it makes sense.
There's a gem [1] for that. Although it seems that one is not maintained
anymore.
[1]
On Thursday, 1 May 2014 at 18:35:40 UTC, Jacob Carlborg wrote:
On 2014-05-01 15:54, Marc Schütz schue...@gmx.net wrote:
You can also use the built-in `includes()`, which does a LEFT
OUTER JOIN:
Post.includes(:comments).where(comments: {title: bar})
(It also eager-loads the comments, but
On Thursday, 1 May 2014 at 13:33:50 UTC, Marc Schütz wrote:
IMO the client shouldn't do any validation, unless you can
really, really trust it.
Client side validation is about better feedback. Today's browsers
are fast enough for doing field validation for every keystroke.
4a. if
On 30/04/14 00:09, Adam D. Ruppe wrote:
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
On Wednesday, 30 April 2014 at 05:00:47 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Digitalmars-d wrote:
Go has gained much of it's traction from provably and
consistently
producing simpler, faster and more reliable systems that C,
C++,
On Wednesday, 30 April 2014 at 04:42:09 UTC, Dicebot wrote:
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Digitalmars-d wrote:
On Tue, 2014-04-29 at 22:09 +, Adam D. Ruppe via
Digitalmars-d
wrote:
[…]
I can just get stuff done in D in a fraction of a time it
takes to do
On Wednesday, 30 April 2014 at 07:18:49 UTC, Paulo Pinto wrote:
On Wednesday, 30 April 2014 at 05:00:47 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Digitalmars-d wrote:
Go has gained much of it's traction from provably and
consistently
On Tuesday, 29 April 2014 at 17:09:53 UTC, Adam D. Ruppe wrote:
On Tuesday, 29 April 2014 at 15:55:13 UTC, Etienne wrote:
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
On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:
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
On Wednesday, 30 April 2014 at 04:21:20 UTC, Rikki Cattermole
wrote:
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
On Wednesday, 30 April 2014 at 09:41:36 UTC, Dicebot wrote:
On Wednesday, 30 April 2014 at 04:21:20 UTC, Rikki Cattermole
wrote:
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
On 4/30/2014 3:14 AM, Jacob Carlborg wrote:
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
On Wednesday, 30 April 2014 at 10:01:51 UTC, Rikki Cattermole
wrote:
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
On Wednesday, 30 April 2014 at 12:38:32 UTC, Dicebot wrote:
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
On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at 12:38:32 UTC, Dicebot wrote:
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
On 4/30/2014 1:24 AM, Russel Winder via Digitalmars-d wrote:
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.
On Wednesday, 30 April 2014 at 12:55:36 UTC, Dicebot wrote:
On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at 12:38:32 UTC, Dicebot wrote:
There are definitely several benefits of having aggregated
compile-time known list of routes. Actually I
On Wednesday, 30 April 2014 at 13:03:43 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at 12:55:36 UTC, Dicebot wrote:
On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at 12:38:32 UTC, Dicebot wrote:
There are definitely several
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Digitalmars-d wrote:
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
On Wednesday, 30 April 2014 at 13:28:28 UTC, John Colvin wrote:
On Wednesday, 30 April 2014 at 13:03:43 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at 12:55:36 UTC, Dicebot wrote:
On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at
On Wednesday, 30 April 2014 at 13:37:33 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at 13:28:28 UTC, John Colvin wrote:
On Wednesday, 30 April 2014 at 13:03:43 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at 12:55:36 UTC, Dicebot wrote:
On Wednesday, 30 April 2014 at
On Wednesday, 30 April 2014 at 04:32:33 UTC, Rikki Cattermole
wrote:
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
On Wednesday, 30 April 2014 at 12:56:03 UTC, Nick Sabalausky
wrote:
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
On Wednesday, 30 April 2014 at 04:32:37 UTC, Russel Winder via
Digitalmars-d wrote:
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
On Wednesday, 30 April 2014 at 13:48:07 UTC, Adam D. Ruppe wrote:
On Wednesday, 30 April 2014 at 04:32:33 UTC, Rikki Cattermole
wrote:
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
On Wednesday, 30 April 2014 at 13:50:18 UTC, John Colvin wrote:
On Wednesday, 30 April 2014 at 13:37:33 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at 13:28:28 UTC, John Colvin wrote:
On Wednesday, 30 April 2014 at 13:03:43 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014
On Wednesday, 30 April 2014 at 13:38:28 UTC, Adam D. Ruppe wrote:
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Digitalmars-d wrote:
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
On Wednesday, 30 April 2014 at 13:37:33 UTC, Rikki Cattermole
wrote:
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
On Wednesday, 30 April 2014 at 14:11:20 UTC, logicchains wrote:
On Wednesday, 30 April 2014 at 13:37:33 UTC, Rikki Cattermole
wrote:
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
On 4/30/14, 6:43 AM, Dicebot wrote:
On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:
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
On Wednesday, 30 April 2014 at 14:18:37 UTC, Ary Borenszweig
wrote:
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
On Wed, Apr 30, 2014 at 02:25:05PM +, Dicebot via Digitalmars-d wrote:
On Wednesday, 30 April 2014 at 14:18:37 UTC, Ary Borenszweig wrote:
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
On Wednesday, 30 April 2014 at 09:22:06 UTC, Chris wrote:
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.
I basically implemented the most important JS features for DOM
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
On Wednesday, 30 April 2014 at 12:26:06 UTC, Nick Sabalausky
wrote:
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
On 4/30/14, 11:25 AM, Dicebot wrote:
On Wednesday, 30 April 2014 at 14:18:37 UTC, Ary Borenszweig wrote:
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
On Wednesday, 30 April 2014 at 13:47:11 UTC, Ola Fosheim Grøstad
wrote:
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
On Wednesday, 30 April 2014 at 13:52:25 UTC, John Colvin wrote:
On Wednesday, 30 April 2014 at 13:38:28 UTC, Adam D. Ruppe
wrote:
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
On Wednesday, 30 April 2014 at 14:58:20 UTC, Ary Borenszweig
wrote:
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
On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:
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
On Wednesday, 30 April 2014 at 14:57:00 UTC, Adam D. Ruppe wrote:
- 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
On 4/30/2014 9:47 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Wednesday, 30 April 2014 at 12:56:03 UTC, Nick Sabalausky wrote:
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
On 4/30/2014 10:58 AM, Ary Borenszweig wrote:
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
On 4/30/14, 7:18 AM, Ary Borenszweig wrote:
On 4/30/14, 6:43 AM, Dicebot wrote:
On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:
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
On 4/30/2014 10:53 AM, Adam D. Ruppe wrote:
On Wednesday, 30 April 2014 at 12:26:06 UTC, Nick Sabalausky wrote:
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
On Wednesday, 30 April 2014 at 15:27:48 UTC, Nick Sabalausky
wrote:
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
On 4/30/2014 11:04 AM, Adam D. Ruppe wrote:
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
On 4/30/2014 12:32 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
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
On Wed, 2014-04-30 at 12:41 -0400, Nick Sabalausky via Digitalmars-d
wrote:
[…]
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
On Wednesday, 30 April 2014 at 16:56:11 UTC, Nick Sabalausky
wrote:
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
On Wed, 2014-04-30 at 05:00 +, via Digitalmars-d wrote:
[…]
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
On Wed, 30 Apr 2014 17:17:01 +, Ola Fosheim Grøstad wrote:
4. server unwraps the data and blindly inserts it into the database
u.. 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
On Wednesday, 30 April 2014 at 17:23:39 UTC, Byron wrote:
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
On Wednesday, 30 April 2014 at 17:23:49 UTC, Russel Winder via
Digitalmars-d wrote:
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
On 2014-04-30 15:38, Adam D. Ruppe wrote:
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
On 2014-04-30 11:43, Dicebot wrote:
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
On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg wrote:
On 2014-04-30 11:43, Dicebot wrote:
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
On 2014-04-30 17:04, Adam D. Ruppe wrote:
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
On Wed, 2014-04-30 at 18:04 +, via Digitalmars-d wrote:
[…]
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,
On Wednesday, 30 April 2014 at 16:02:25 UTC, Nick Sabalausky
wrote:
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
On Wed, 2014-04-30 at 21:08 +0200, Jacob Carlborg via Digitalmars-d
wrote:
[…]
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
On Wed, 2014-04-30 at 21:06 +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 2014-04-30 15:38, Adam D. Ruppe wrote:
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
On Wednesday, 30 April 2014 at 20:00:59 UTC, Russel Winder via
Digitalmars-d wrote:
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
On Wednesday, 30 April 2014 at 16:42:00 UTC, Nick Sabalausky
wrote:
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.
Am 30.04.2014 22:12, schrieb Russel Winder via Digitalmars-d:
On Wed, 2014-04-30 at 21:06 +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 2014-04-30 15:38, Adam D. Ruppe wrote:
Of course, I doubt the gap will ever be closed, since Ruby's awfulness
isn't dependent on my experience level.
1 - 100 of 137 matches
Mail list logo
