问:
Advice for designing API request rate limiter?
I'm in the planning stages of a web application that makes heavy use of data retrieved from a third party's REST API. This data is cached on the server and requested by clients via AJAX. The REST API has a rate limit, and I plan on using the token bucket scheme to adhere to it. However, I'm having trouble coming up with a thread-safe way of storing the bucket value. Because of this, I'm considering two technologies for my server-side needs. I only program as a hobby so...bear with me.

PHP

Here, I considered putting the bucket variable in the APCu cache, but I'm not entirely sure how thread-safe that is. I imagine a scenario: there is one token left in the bucket. Client A pulls the data from the cache, then client B immediately after. A notices there is one left, and subtracts a token, then B does the same, the bucket is at -1 and both think they're clear to request. If a bunch of threads do this, I break the limit. Is this a realistic scenario? Is there any better way to implement this API limit on a site-wide (not per-user) basis? I'd rather not resort to an outside script.

node.js

Node seems like it would be perfect, given the site architecture, but it's a huge shift in thinking. It has only one thread of execution, and there are also global vars that the docs say are local to the module. I assume that 'local to the module' means its available to only that module, but 'global' means any time that one module comes up in the event queue the global var will be there. Is this the case? If so, when the bucket is empty and the module must wait to place the request, that will block everything else node is doing, won't it? And if there are multiple node.js instances running, the global isn't shared between them, is it? I've seen several npm packages for rate limiting, but they all seem to be per-user.

I have some other questions about node as well, but this post is long enough already.

Any advice?

答:
.net has the SemaphoreSlim class for this type of thing, you can use the singleton pattern to make it global. the ConcurrentQueue and other objects can help as well.

However, you are still left with the problem of what are you doing with the extra requests above the rate limit.

I would recommend you look into Message Queue frameworks such as msmq, rabbit, zeroMq etc to help with overall architecture.

What you ideally want to achieve is a single queue that your application can post requests to with multiple rate limited worker processes (in whatever technology) which pull and deal with the requests.

These worker apps don't fit well with web hosting platforms like IIS, PHP or NodeJS. I would suggest a windows service. (but then im .net) it seems a unix daemon is the equivilant in the USSR and you can make use node to make one:
 (https://www.digitalocean.com/community/tutorials/how-to-write-a-linux-daemon-with-node-js-on-a-vps)

also see this question for why this is hard to do in JS

https://stackoverflow.com/questions/555191/javascript-semaphore-test-and-set-lock

PHP however does have a semaphore implemenation

http://php.net/manual/en/intro.sem.php


问:
Parameter management in OOP application
I'm writing a medium size OOP application in C++ as a way to practice OOP principles.

I have several classes in my project, and some of them need to access run-time configuration parameters. These parameters are read from several sources during application start-up.  Some are read from a config file in the users home-dir, some are command line arguments (argv).

So I created a class ConfigBlock. This class reads all the parameter sources and stores it in an appropriate data structure. Examples are path- and filenames which can be changed by user in the config file, or the --verbose CLI flag. Then, one can call ConfigBlock.GetVerboseLevel() in order to read this specific parameter.

My question: Is it good practice to collect all such runtime config data in one class?

Then, my classes need access to all these parameters. I can think of several ways to achieve this, but I'm not sure which one to take. A class' constructor can be a given a reference to my ConfigBlock, like

```<code>public:
    MyGreatClass(ConfigBlock &config);
</code>```

Or they just include a header "CodingBlock.h" which contains a definition of my CodingBlock:

```<code>extern CodingBlock MyCodingBlock;
</code>```

Then, only the classes .cpp file needs to include and use the ConfigBlock stuff.

The .h file does not introduce this interface to the user of the class.
However, the interface to ConfigBlock is still there, however, it's hidden from the .h file.

Is it good to hide it this way?

I want the interface to be as small as possible, but in the end, I guess every class which needs config parameters has to have a connection to my ConfigBlock. But, what should this connection look like?

答:
I'm quite the pragmatist, but my main concern here is that you might be allowing this ConfigBlock to dominate your interface designs in a possibly bad way. When you have something like this:

```<code>explicit MyGreatClass(const ConfigBlock& config);
</code>```

... a more appropriate interface might be like this:

```<code>MyGreatClass(int foo, float bar, const string& baz);
</code>```

... as opposed to just cherry-picking these foo/bar/baz fields out of a massive ConfigBlock.

Lazy Interface Design

On the plus side, this kind of design makes it easy to design a stable interface for your constructor, e.g., since if you end up needing something new, you can just load that into a ConfigBlock (possibly without any code changes) and then cherry-pick whatever new stuff you need without any kind of interface change, only a change to the implementation of MyGreatClass.

So it's both kind of a pro and con that this frees you of designing a more carefully thought-out interface that only accepts inputs it actually needs. It applies the mindset of, "Just give me this massive blob of data, I'll pick out what I need from it" as opposed to something more like, "These precise parameters are what this interface needs to work."

So there are definitely some pros here, but they might be heavily outweighed by the cons.

Coupling

In this scenario, all such classes being constructed from a ConfigBlock instance end up having their dependencies look like this:

This can become a PITA, for example, if you want to unit test Class2 in this diagram in isolation. You might have to superficially simulate various ConfigBlock inputs containing the relevant fields Class2 is interested in to be able to test it under a variety of conditions.

In any kind of new context (whether unit test or whole new project), any such classes can end up becoming more of a burden to (re)use, as we end up having to always bring ConfigBlock along for the ride, and setting it up accordingly.

Reusability/Deployability/Testability

Instead if you design these interfaces appropriately, we can decouple them from ConfigBlock and end up with something like this:

If you notice in this above diagram, all the classes become independent (their afferent/outgoing couplings reduce by 1).

This leads to a lot more independent classes (at least independent of ConfigBlock) which can be a lot easier to (re)use/test in new scenarios/projects.

Now this Client code ends up being the one that has to depend on everything and assemble it all together. The burden ends up being transferred to this client code to read the appropriate fields from a ConfigBlock and pass them into the appropriate classes as parameters. Yet such client code is generally narrowly-designed for a specific context, and its potential for reuse is typically going to be zilch or close anyway (it might be your application's main entry point function or something like that).

So from a reusability and testing standpoint, it can help to make these classes more independent. From an interface standpoint for those using your classes, it can also help to explicitly state what parameters they need instead of just one massive ConfigBlock which models the whole universe of data fields required for everything.

Conclusion

In general, this kind of class-oriented design which depends on a monolith which has everything needed tends to have these kinds of characteristics. Their applicability, deployability, reusability, testability, etc. can get significantly degraded as a result. Yet they can kind of simplify the interface design if we attempt a positive spin on it. It's up to you to measure those pros and cons and decide whether the trade-offs are worth it. Typically it's much safer to err against this kind of design where you're cherry-picking from a monolith in classes that are generally intended to model a more general and widely-applicable design.

Last but not least:

extern CodingBlock MyCodingBlock;

... this is potentially even worse (more skewed?) in terms of the characteristics described above than the dependency injection approach, as it ends up coupling your classes not only to ConfigBlocks, but directly to a specific instance of it. That further degrades applicability/deployability/testability.

My general advice would to err on the side of designing interfaces which don't depend on these kinds of monoliths to provide their parameters, at least for the most generally-applicable classes you design. And avoid the global approach without dependency injection if you can unless you really have a very strong and confident reason not to avoid it.

ContentLicense: CC BY-SA 3.0

Title: Parameter management in OOP application

Body:
I'm quite the pragmatist, but my main concern here is that you might be allowing this ConfigBlock to dominate your interface designs in a possibly bad way. When you have something like this:

explicit MyGreatClass(const ConfigBlock& config);

... a more appropriate interface might be like this:

MyGreatClass(int foo, float bar, const string& baz);

... as opposed to just cherry-picking these foo/bar/baz fields out of a massive ConfigBlock.

Lazy Interface Design

On the plus side, this kind of design makes it easy to design a stable interface for your constructor, e.g., since if you end up needing something new, you can just load that into a ConfigBlock (possibly without any code changes) and then cherry-pick whatever new stuff you need without any kind of interface change, only a change to the implementation of MyGreatClass.

So it's both kind of a pro and con that this frees you of designing a more carefully thought-out interface that only accepts inputs it actually needs. It applies the mindset of, "Just give me this massive blob of data, I'll pick out what I need from it" as opposed to something more like, "These precise parameters are what this interface needs to work."

So there are definitely some pros here, but they might be heavily outweighed by the cons.

Coupling

In this scenario, all such classes being constructed from a ConfigBlock instance end up having their dependencies look like this:

This can become a PITA, for example, if you want to unit test Class2 in this diagram in isolation. You might have to superficially simulate various ConfigBlock inputs containing the relevant fields Class2 is interested in to be able to test it under a variety of conditions.

In any kind of new context (whether unit test or whole new project), any such classes can end up becoming more of a burden to (re)use, as we end up having to always bring ConfigBlock along for the ride, and setting it up accordingly.

Reusability/Deployability/Testability

Instead if you design these interfaces appropriately, we can decouple them from ConfigBlock and end up with something like this:

If you notice in this above diagram, all the classes become independent (their afferent/outgoing couplings reduce by 1).

This leads to a lot more independent classes (at least independent of ConfigBlock) which can be a lot easier to (re)use/test in new scenarios/projects.

Now this Client code ends up being the one that has to depend on everything and assemble it all together. The burden ends up being transferred to this client code to read the appropriate fields from a ConfigBlock and pass them into the appropriate classes as parameters. Yet such client code is generally narrowly-designed for a specific context, and its potential for reuse is typically going to be zilch or close anyway (it might be your application's main entry point function or something like that).

So from a reusability and testing standpoint, it can help to make these classes more independent. From an interface standpoint for those using your classes, it can also help to explicitly state what parameters they need instead of just one massive ConfigBlock which models the whole universe of data fields required for everything.

Conclusion

In general, this kind of class-oriented design which depends on a monolith which has everything needed tends to have these kinds of characteristics. Their applicability, deployability, reusability, testability, etc. can get significantly degraded as a result. Yet they can kind of simplify the interface design if we attempt a positive spin on it. It's up to you to measure those pros and cons and decide whether the trade-offs are worth it. Typically it's much safer to err against this kind of design where you're cherry-picking from a monolith in classes that are generally intended to model a more general and widely-applicable design.

Last but not least:

extern CodingBlock MyCodingBlock;

... this is potentially even worse (more skewed?) in terms of the characteristics described above than the dependency injection approach, as it ends up coupling your classes not only to ConfigBlocks, but directly to a specific instance of it. That further degrades applicability/deployability/testability.

My general advice would to err on the side of designing interfaces which don't depend on these kinds of monoliths to provide their parameters, at least for the most generally-applicable classes you design. And avoid the global approach without dependency injection if you can unless you really have a very strong and confident reason not to avoid it.


答:
PHP

Your cache read/write is a critical section. You'll need to protect it with your choice of mutual exclusion to prevent the false read you describe. For better or worse, locking in PHP isn't straightforward. The cross-platform solution uses a file (guaranteed to cause grief if your server gets busy). Beyond that it depends on both the OS and server configuration. You can read more here: https://stackoverflow.com/a/2921596/7625.

Node.js

Since Node is single-threaded, you don't need a lock unless you execute an async operation (I/O and related). This doesn't necessarily solve all your problems, however. Read more below.

All

As described, you have a looming big problem. I see a hunch when you say, "...that will block everything else node is doing, won't it?" That's not the exact problem -- you can create a non-blocking wait. But does waiting solve your problems? Not really. If your site is really busy, each waiting request increases the chance the next request will have to wait. The requests are piling up... If there's enough traffic, the waits will get longer and longer. There will be timeouts. There will be hand-wringing. There will be tears.

This is an equal opportunity problem. Neither PHP or Node are immune. (In fact, everyone's vulnerable given a throttled resource and the approach you describe.) A message queue doesn't save you. All a message queue gets you is a bunch of queued requests that are waiting. We need a way to dequeue those requests!

Luckily, this can be pretty straight-forward if we push more responsibility to the browser. With a little re-jiggering, the response back to the browser can contain a status and an optional result. On the server, send a "success" status and result if you get an API token. Otherwise, send a "not yet" status. In the browser, if the request is successful proceed as normal. If not, proceed as you see fit. If you're sending requests asynchronously, you can retry in a half second, then a full second, then... There are great opportunities for giving the user feedback. Beyond great feedback, this approach also keeps server resources to a minimum. The server isn't punished for the third party API's bottleneck.

The approach isn't perfect. One not-so-nice feature is that requests aren't guaranteed to resolve in the order received. Since it's a bunch of browsers trying and retrying, a really unlucky user could continually lose their turn. Which brings me to the penultimate solution...

Open Your Wallet

I'm guessing that your third party API is throttled because it's free! (or inexpensive) If you really want to wow your users, consider paying for better service. Instead of engineering your way out of the problem (which is sorta cool, sorta chintzy), fix the issue with cash. Remember, many, many operations that run on-the-cheap feel cheap. If you want to keep your users, you don't want that.

Title: Advice for designing API request rate limiter?

Body:
I'm in the planning stages of a web application that makes heavy use of data retrieved from a third party's REST API. This data is cached on the server and requested by clients via AJAX. The REST API has a rate limit, and I plan on using the token bucket scheme to adhere to it. However, I'm having trouble coming up with a thread-safe way of storing the bucket value. Because of this, I'm considering two technologies for my server-side needs. I only program as a hobby so...bear with me.

PHP

Here, I considered putting the bucket variable in the APCu cache, but I'm not entirely sure how thread-safe that is. I imagine a scenario: there is one token left in the bucket. Client A pulls the data from the cache, then client B immediately after. A notices there is one left, and subtracts a token, then B does the same, the bucket is at -1 and both think they're clear to request. If a bunch of threads do this, I break the limit. Is this a realistic scenario? Is there any better way to implement this API limit on a site-wide (not per-user) basis? I'd rather not resort to an outside script.

node.js

Node seems like it would be perfect, given the site architecture, but it's a huge shift in thinking. It has only one thread of execution, and there are also global vars that the docs say are local to the module. I assume that 'local to the module' means its available to only that module, but 'global' means any time that one module comes up in the event queue the global var will be there. Is this the case? If so, when the bucket is empty and the module must wait to place the request, that will block everything else node is doing, won't it? And if there are multiple node.js instances running, the global isn't shared between them, is it? I've seen several npm packages for rate limiting, but they all seem to be per-user.

I have some other questions about node as well, but this post is long enough already.

Any advice?


问:
Integrate NuGet Package Restore feature into checkout process
There are some situations where I have no internet connection and so I am forced to work offline. Usually it would look like this: I get connected, do a checkout from source control server, and move out of office.
The NuGet packages stay on the server, because I have enabled Package Restore and should have opened Visual Studio and fired a build at least once, to download them.

Before using NuGet we had the package management integrated using SVN externals. The required assemblies were automatically downloaded during checkout. But this system has some limitations, I'd like to get rid off.

The prefered way to use Package Restore would be to execute it on checkout or update.
Is there a way doing so, using hooks for SVN (TortoiseSVN) or GIT (TortoiseGIT, Github for Windows) as version control system?

答:
For Git you can use a post-commit hook.  To do so, you would create an executable script named post-checkout in the .git/hooks folder in the repository.  In the file, you would put the following:

```<code>/path/to/nuget.exe restore /path/to/solutionfile
</code>```

On Linux/Mac, do the following instead:

```<code>#/bin/sh
mono /path/to/nuget.exe restore /path/to/solutionfile
</code>```

and it should work.

This will be automatically executed after the repository has been checked out.  To see more info about the nuget restore command, see here.

Body:
For Git you can use a post-commit hook.  To do so, you would create an executable script named post-checkout in the .git/hooks folder in the repository.  In the file, you would put the following:

/path/to/nuget.exe restore /path/to/solutionfile

On Linux/Mac, do the following instead:

#/bin/sh
mono /path/to/nuget.exe restore /path/to/solutionfile

and it should work.

This will be automatically executed after the repository has been checked out.  To see more info about the nuget restore command, see here.


问:
Legitimate "real work" in a constructor?
I am working on a design, but keep hitting a roadblock. I have a particular class (ModelDef) that is essentially the owner of a complex node tree built by parsing an XML schema (think DOM). I want to follow good design principles (SOLID), and ensure that the resulting system is easily testable. I have every intention of using DI to pass dependencies into the constructor of ModelDef  (so that these can easily be swapped out, if need be, during testing).

What I'm struggling with, though, is the creation of the node tree. This tree is going to be made up entirely of simple "value" objects which will not need to be independently tested. (However, I may still pass an Abstract Factory into ModelDef to assist with the creation of these objects.)

But I keep reading that a constructor should not do any real work (e.g. Flaw: Constructor does Real Work). This makes perfect sense to me if "real work" means constructing heavy-weigh dependent objects that one might later want to stub out for testing. (Those should be passed in via DI.)

But what about light-weight value objects such as this node tree? The tree has to be created somewhere, right? Why not via the constructor of ModelDef (using, say, a buildNodeTree() method)?

I don't really want to create the node tree outside of ModelDef and then pass it in (via constructor DI), because creating the node tree by parsing the schema requires a significant amount of complex code -- code that needs to be thoroughly tested. I don't want to relegate it to "glue" code (which should be relatively trivial, and will likely not be directly tested).

I have thought of putting the code to create the node tree in a separate "builder" object, but hesitate to call it a "builder", because it doesn't really match the Builder Pattern (which seem to be more concerned with eliminating telescoping constructors). But even if I called it something different (e.g. NodeTreeConstructor), it still feels like a bit of a hack just to avoid having the ModelDef constructor build the node tree. It has to be built somewhere; why not in the object that's going to own it?

答:
You already give the best reasons to not do this work in the ModelDef constructor:

There's nothing "lightweight" about parsing an XML document into a node tree.

There's nothing obvious about a ModelDef that says it can only be created from an XML document.

It sounds like your class should have a variety of static methods like ModelDef.FromXmlString(string xmlDocument), ModelDef.FromXmlDoc(XmlDoc parsedNodeTree), etc.


答:
And, besides what Ross Patterson suggested, consider this position which is the exact opposite:

Take maxims such as "Thou Shalt Not Do Any Real Work In Thy Constructors" with a grain of salt.

A constructor is, really, nothing but a static method.  So, structurally, there is really not much difference between:

a) a simple constructor and a bunch of complex static factory methods, and

b) a simple constructor and a bunch of more complex constructors.

A considerable part of the negative sentiment towards doing any real work in constructors comes from a certain period of the history of C++ when there was debate as to precisely what state the object will be left in if an exception is thrown within the constructor, and whether the destructor should be invoked in such an event.  That part of the history of C++ is over, and the issue has been settled, while in languages like Java there never was any issue of this kind to begin with.

My opinion is that if you simply avoid using new in the constructor, (as your intention to employ Dependency Injection indicates,) you should be fine.  I laugh at statements like "conditional or looping logic in a constructor is a warning sign of a flaw".

Besides all that, personally, I would take the XML parsing logic out of the constructor, not because it is evil to have complex logic in a constructor, but because it is good to follow the "separation of concerns" principle.  So, I would move the XML parsing logic into some separate class altogether, not into some static methods that belong to your ModelDef class.

Amendment

I suppose that if you have a method outside of ModelDef which creates a ModelDef from XML, you will need to instantiate some dynamic temporary tree data structure, populate it by parsing your XML, and then create your new ModelDef passing that structure as a constructor parameter.  So, that could perhaps be thought of as an application of the "Builder" pattern. There is a very close analogy between what you want to do and the String & StringBuilder pair. However, I have found this Q&A which seems to disagree, for reasons which are not clear to me: Stackoverflow - StringBuilder and Builder Pattern.  So, to avoid a lengthy debate over here as to whether the StringBuilder does or does not implement the "builder" pattern, I would say feel free to be inspired by how StrungBuilder works in coming up with a solution that suits your needs, and postpone calling it an application of the "Builder" pattern until that little detail has been settled.

See this brand new question: Programmers SE: Is “StringBuilder” an application of the Builder Design Pattern?

Title: Legitimate "real work" in a constructor?

Body:
I am working on a design, but keep hitting a roadblock. I have a particular class (ModelDef) that is essentially the owner of a complex node tree built by parsing an XML schema (think DOM). I want to follow good design principles (SOLID), and ensure that the resulting system is easily testable. I have every intention of using DI to pass dependencies into the constructor of ModelDef  (so that these can easily be swapped out, if need be, during testing).

What I'm struggling with, though, is the creation of the node tree. This tree is going to be made up entirely of simple "value" objects which will not need to be independently tested. (However, I may still pass an Abstract Factory into ModelDef to assist with the creation of these objects.)

But I keep reading that a constructor should not do any real work (e.g. Flaw: Constructor does Real Work). This makes perfect sense to me if "real work" means constructing heavy-weigh dependent objects that one might later want to stub out for testing. (Those should be passed in via DI.)

But what about light-weight value objects such as this node tree? The tree has to be created somewhere, right? Why not via the constructor of ModelDef (using, say, a buildNodeTree() method)?

I don't really want to create the node tree outside of ModelDef and then pass it in (via constructor DI), because creating the node tree by parsing the schema requires a significant amount of complex code -- code that needs to be thoroughly tested. I don't want to relegate it to "glue" code (which should be relatively trivial, and will likely not be directly tested).

I have thought of putting the code to create the node tree in a separate "builder" object, but hesitate to call it a "builder", because it doesn't really match the Builder Pattern (which seem to be more concerned with eliminating telescoping constructors). But even if I called it something different (e.g. NodeTreeConstructor), it still feels like a bit of a hack just to avoid having the ModelDef constructor build the node tree. It has to be built somewhere; why not in the object that's going to own it?


问:
Create an item in two different table with auto-increment C# SQL
First of all, let me apologize because I know my question will be very confusing since my English is pretty bad.

I am working on a project for a company, mainly create a system to take care for their good, using MVVM C#

My MS SQL database looks like this

So I have auto-increment for both Bike-id and Contact-id. Each time I want to retrieve database from 3 tables, I have to make a join with Linq then get data using webservice, pretty complicated since I can use Lambda for toffee. It works but it messed up.

Furthermore, it is getting more complicated when I want to create bikes from a Contact, I dont want to tell people "hey each time you create a bike, you have to give me a ContactId". Im currently using .Max() or .First() to get a most recent ID, but then it is not flexible. How could I implement that when people click on a List of Contact, if they want to use a contact for creating a new bike, they can just click on a button, the system will know they have chosen that ContactId?

Also, when people create a new bike, I will let them go to the page with full of text box to fill out, of course there could be a new ContactId with a new items, but they are 2 different tables, how do I let it know that I am creating an Item for this ContactId.

Again, Im sorry to confuse you guys since my question it is very unpercisely. But please help me out of this.

答:
I have a couple of comments that might help:

I have to make a join with Linq

This sounds expensive - are you really pulling all records from all 3 tables into your program just so you can do a join?  It would be much better to do that directly in SQL:

```<code>SELECT b.brand
    ,c.NAME
    ,p.city
FROM bikes b
JOIN Contact c ON b.ownerID = c.ownerID
JOIN Postcode p ON c.postCode = p.postCode
WHERE c.ownerID = @ownerID
</code>```

If I were to create a Bike record, I would definitely say "hey, you have to tell me the ownerID".  Of course, in my program I would create a drop down list with the name of the owner shown to the user and the ownerID as the value returned.

If you were using HTML, it might look something like

```<code><select>
    <option value='1'>Bob Smith</option>
    <option value='2'>John Doe</option>
</select>
</code>```

One final note - it is a very common problem to want to create a record then immediately get the primary key.  In Sql Server you can do that with code like:

```<code>int newContactID = -1;
string name = "bob";
string phoneNo = "555-1212";
string connString = ConfigurationManager.ConnectionStrings["LocalSqlServer"].ConnectionString;
using (SqlConnection conn = new SqlConnection(connString))
{
    conn.Open();

    string sql = @"
INSERT INTO Contact (
    NAME
    ,phoneNo
    ,...
    )
VALUES (
    @name
    ,@phoneNo...
    );

SELECT SCOPE_IDENTITY()
";
    using (SqlCommand cmd = new SqlCommand(sql, conn))
    {
        cmd.CommandType = System.Data.CommandType.Text;
        cmd.Parameters.Add(new SqlParameter("@name", name));
        cmd.Parameters.Add(new SqlParameter("@phoneNo", phoneNo));

        newContactID = Int32.Parse((cmd.ExecuteScalar()).ToString());
    }
}
</code>```

Body:
I have a couple of comments that might help:

I have to make a join with Linq

This sounds expensive - are you really pulling all records from all 3 tables into your program just so you can do a join?  It would be much better to do that directly in SQL:

SELECT b.brand
    ,c.NAME
    ,p.city
FROM bikes b
JOIN Contact c ON b.ownerID = c.ownerID
JOIN Postcode p ON c.postCode = p.postCode
WHERE c.ownerID = @ownerID

If I were to create a Bike record, I would definitely say "hey, you have to tell me the ownerID".  Of course, in my program I would create a drop down list with the name of the owner shown to the user and the ownerID as the value returned.

If you were using HTML, it might look something like

<select>
    <option value='1'>Bob Smith</option>
    <option value='2'>John Doe</option>
</select>

One final note - it is a very common problem to want to create a record then immediately get the primary key.  In Sql Server you can do that with code like:

int newContactID = -1;
string name = "bob";
string phoneNo = "555-1212";
string connString = ConfigurationManager.ConnectionStrings["LocalSqlServer"].ConnectionString;
using (SqlConnection conn = new SqlConnection(connString))
{
    conn.Open();

    string sql = @"
INSERT INTO Contact (
    NAME
    ,phoneNo
    ,...
    )
VALUES (
    @name
    ,@phoneNo...
    );

SELECT SCOPE_IDENTITY()
";
    using (SqlCommand cmd = new SqlCommand(sql, conn))
    {
        cmd.CommandType = System.Data.CommandType.Text;
        cmd.Parameters.Add(new SqlParameter("@name", name));
        cmd.Parameters.Add(new SqlParameter("@phoneNo", phoneNo));

        newContactID = Int32.Parse((cmd.ExecuteScalar()).ToString());
    }
}


问:
What does it mean when data is scalar?
I don't know what scalar means exactly, but I'm trying to see if I'm thinking about it correctly. Does scalar relate to arbitrariness where the type of data could be any type, or a system is not able to know what the data is in advance. </p>

答:
The word scalar derives from the Latin word scalaris, an adjectival form of scala (Latin for "ladder"). The English word "scale" also comes from scala. Source

A Scalar is a variable that holds an individual value.

For example:

Scalar Variable:
Say that you are trying to represent the names of various students as a set of variables. Each of the individual variables is a scalar variable as follow

```<code>NAME01="Zara"
NAME02="Qadir"
NAME03="Mahnaz"
NAME04="Ayan"
NAME05="Daisy"
</code>```

Scalar Functions: SQL scalar functions return a single value, based on the input value.

```<code>UCASE() - Converts a field to upper case
LCASE() - Converts a field to lower case
</code>```

Title: What does it mean when data is scalar?

Body:
The word scalar derives from the Latin word scalaris, an adjectival form of scala (Latin for "ladder"). The English word "scale" also comes from scala. Source

A Scalar is a variable that holds an individual value.

For example:

Scalar Variable:
Say that you are trying to represent the names of various students as a set of variables. Each of the individual variables is a scalar variable as follow

NAME01="Zara"
NAME02="Qadir"
NAME03="Mahnaz"
NAME04="Ayan"
NAME05="Daisy"

Scalar Functions: SQL scalar functions return a single value, based on the input value.

UCASE() - Converts a field to upper case
LCASE() - Converts a field to lower case


问:
Microservices architecture and bounded contexts
In the past few days I've been reading some things about microservices architecture. I didn't get the whole point yet, since I'm just starting with this, but there's one point which caught my attention. In some sense it seems to me that microservices are a concrete way to leverage the idea of Bounded Contexts from DDD.

I mean, microservices as I understood, are full applications, loosely coupled, which are self-contained. Usually each microservice is developed by its own team, has its own codebase and are deployed independently. In the end they work together to form the full software being developed.

This really seems like bounded contexts. Of course, bounded contexts are more like a concept. Microservices seems to be one way of implementing that concept in practice.

Is that right? Microservices can be thought just as a particular way of applying the idea of bounded contexts from DDD? If not, why is that? I believe that if that's not the case, understanding why might improve both the understanding of bounded contexts and microservices.

答: Bounded Contexts and Microservices are similar but (from my understanding) a Bounded Context can consist of several Microservices.  From Martin Fowler's description of the Bounded Context, each rectangle in the bounded contexts of his illustration could be one Microservice, so you'd conceivably have one for Tickets, one for defects, etc.  Or several of these services could be combined into a larger Microservice, all the way up to one Microservice for the entire Bounded Context.</p>


答:
Microservices can be thought just as a particular way of applying the idea of bounded contexts from DDD?

They way you are asking the question you are implying a strong relationship between microservices and bounded contexts. I thing that is a misunderstanding (but maybe that's not really what you meant, just how the words came out).

I would rather say that microservices could be a good fit for implementing your bounded context if you are implementing DDD.

Remember, not every project uses DDD (and most that do, properly doesn't do it properly anyway). In these cases microservices can be applicable.

Title: Microservices architecture and bounded contexts

Body:
In the past few days I've been reading some things about microservices architecture. I didn't get the whole point yet, since I'm just starting with this, but there's one point which caught my attention. In some sense it seems to me that microservices are a concrete way to leverage the idea of Bounded Contexts from DDD.

I mean, microservices as I understood, are full applications, loosely coupled, which are self-contained. Usually each microservice is developed by its own team, has its own codebase and are deployed independently. In the end they work together to form the full software being developed.

This really seems like bounded contexts. Of course, bounded contexts are more like a concept. Microservices seems to be one way of implementing that concept in practice.

Is that right? Microservices can be thought just as a particular way of applying the idea of bounded contexts from DDD? If not, why is that? I believe that if that's not the case, understanding why might improve both the understanding of bounded contexts and microservices.


问:
How to approach syntax errors when developing a lexical analyser?
I am writing an interpreted domain-specific language for my application. Each statement is parsed and executed as soon as lexical analyser decides that the end of statement is reached. It's handling one token at a time and makes recursive calls evaluating expressions and reducing current token stack.

It intuitively makes sense for the parser to first check for syntax errors before actually interpreting and executing the code, but I was thinking that it might be another way of handling this.

What if syntax were checked just before the code in question needs to be executed? This means that actually flagging code for invalid syntax wouldn't happen until the problematic code is actually reached. This also means that if the code is faulty, but shouldn't be executed, we can raise non-fatal warnings instead of errors to notify the programmer, but let the code execute anyway.

Take for instance this code:

```<code> 1. new $a = 2
 2. new $b = 3
 3.
 4. while ($a < 10) {
 5.     $a += 3
 6.     $b += 2
 7.
 8.     if ($b < 5) {
 9.         $b =
10.     }
11. }
12.
13. printout($a)
14. printout($b)
</code>```

As one line is typed in after another, standard interpreter would execute first two lines, but error would be raised on line 9, as no value is being assigned to $b and the process would terminate due to fatal error.

This approach outputs:

```<code>SyntaxError at line 9: $b = ; - Expression expected
Process terminated with exit code 1
</code>```

If the parser checks syntax one line at the time, expression $b < 5 never evaluates to true, and faulty code never executes. Its syntax is still checked and raises a warning flag.

This approach outputs:

```<code>SyntaxWarning at line 9: $b = ; - Expression expected
SyntaxWarning at line 9: $b = ; - Expression expected
SyntaxWarning at line 9: $b = ; - Expression expected
11
9
</code>```

If the faulty code needs to be executed, SyntaxErrors would be raised unconditionally. The only difference would be when the code doesn't execute. Language is written for graphics generation/manipulation software.

Should I be including syntax warnings in my interpreter or should I let faulty code always terminate the execution? What factors should influence this decision?

答:
There's really only one factor to consider, which is how safe it is for your program to ABEND or produce incomplete or invalid results.

One end of the spectrum is that it's just an annoyance.  People run their programs and discover that they didn't get the results they expected and then have to track down the cause, maybe having to dig through megabytes of data that have a syntax error message buried in it.  There's no real harm done, but it could pose a personal safety problem if your users are psychotic and know your home address.  :-)

The other is that it causes real damage, which is where you want to take an all-or-nothing approach.  If the domain for your language involves a process of brewing chemicals where the finished product is inert but one of the intermediate products is toxic, an ABEND at the wrong point could leave a vat of toxic sludge to be dealt with.  In a case like that, you want to be as sure as possible that the program has a good chance of finishing before you start running it.

Doing one or the other shouldn't have a huge impact on your development.  A parser that produces a parse tree can simply return some indication that there was an error, which makes the decision to proceed or stop easy.  Those that execute the statements as it finds them would need a switch to prevent that.  To prevent execution of an invalid program, you'd then need to parse it twice: once with execution disabled and, if the parser had no complaints about the input, again with it enabled.

My own take on this is that if you can provide a way for the people using your language to validate their programs without executing them, you should do so.  Manipulating graphics isn't safety-critical, but the people who have to build and integrate systems using your language will want to do that.  The process of getting from development to production is increasingly automated, and providing a programmatic way to throw up a roadblock when there's a detectable problem is nothing but a positive.


问:
Using a "strong" type system in the real world, say, for large-scale web-apps?
I know this is a very broad, ambiguous, and possibly philosophical question. To an extent, that the most important keyword in the question - "strong" type system - itself, is ill-defined. So, let me try to explain what I mean.

Overall context for the question

We've been building a very large scale web-app in Ruby on Rails and we've been generally happy about our stack. When we want to, we can ship stuff really fast - something that works for 90% of the "business" case, without worrying too much about 10% edge cases. On the other hand, with the help of code-reviews & test-coverage, we can be slow & deliberate and make sure we cover all bases - again, only in situations that merit such closer scrutiny & safety.

However, as the team grows, I've started getting uncomfortable with the lack of a "safety net" baked right into our stack.

We recently started doing some native Android development on Java. And I was (pleasantly) reminded of the safety provided by a compiled/static/strongly-typed language.

Mis-spelled variables, wrong data types, incorrect function invocations, and a host of trivial errors are caught by your IDE itself. All because the IDE can hook into the compiler and verify certain aspects of program "correctness".

Need to change a function signature? Easy. The compiler+IDE can help you spot ALL call sites.

Need to ensure that certain exceptions are always handled? Checked exceptions to your rescue.

Now, while these safety features have their advantages, I'm well aware of their disadvantages as well. More so, in the world of "boilerplate heavy" Java. Therefore, instead of Java, I've started looking at the slew of modern, "strongly typed" languages that people have started working on these days. For example: Scala, Rust, Haskell, etc. What interests me most is the power of their type systems and static/compile-time checks.

Now, the question

How do I use these powerful type systems and static/compile-time features in larger applications?

For example, how would I move beyond the standard "hello world" kind of introductions to these powerful features? One that uses a a rich type system to model a business-domain problem? Does the type system help, or hinder, when you're in the 30,000 LOC+ zone? What happens to the safety net provided by these type systems (and compile-time checks) when your system interacts with the weakly typed outside world, eg. via JSON or XML APIs, various data stores, user input, etc.

答:
As a .net programmer who works on web applications a lot I see both the typed C# and untyped Javascript side of things.

I'm not sure I've seen any literature about the questions you ask. With a typed language you take all these things for granted. With an untyped one you see defining the types as unnecessary overhead.

Personally, I don't think you can deny that a strongly typed language offers the benefits you describe at a very low cost (compared to writing equivalent unit tests). Interacting with weakly typed systems usually involves generic types, such as Arrays or Dictionaries of Objects, such as DataReader, or creative use of string or the new dynamic class. Essentially it all works, you just get a runtime error instead of compile time.

If you want to write a very short program, maybe defining a function in a couple of lines to work with a larger application, then you simply don't have room to declare classes. Surely this is the niche untyped languages such as JS occupy?


答:
While not a direct answer (since I haven't worked on +30.000 LOC code bases in haskell yet :(..), I implore you to check out https://www.fpcomplete.com/business/resources/case-studies/ which features a lot of case-studies of haskell in actual industry settings.

Another good article is IMVU, that describe their experience changing to haskell - http://engineering.imvu.com/2014/03/24/what-its-like-to-use-haskell/.

From personal experience in larger applications, the type-system very much helps you, especially if you try to encode as much as you can in types. The true power is really obvious when it comes to refactoring things - meaning maintenance and such become a much less worrisome task.

I'm gonna dump a couple of links to resources that I recommend, since you are asking quite a lot of questions at once:

Small series on common optimizations, in haskell

Thinking in types

Since you are in the web dev world, I suggest checking out Yesod, which is one of the very amazing web frameworks in haskell (features type-safe routes, and a lot more).

As a closing remark, regarding dealing with the outside world is done in several ways. There are libraries to make sure things on your end are type safe, like Aeson for JSON, Esqueleto for SQL and many more.

Title: Using a "strong" type system in the real world, say, for large-scale web-apps?

Body:
I know this is a very broad, ambiguous, and possibly philosophical question. To an extent, that the most important keyword in the question - "strong" type system - itself, is ill-defined. So, let me try to explain what I mean.

Overall context for the question

We've been building a very large scale web-app in Ruby on Rails and we've been generally happy about our stack. When we want to, we can ship stuff really fast - something that works for 90% of the "business" case, without worrying too much about 10% edge cases. On the other hand, with the help of code-reviews & test-coverage, we can be slow & deliberate and make sure we cover all bases - again, only in situations that merit such closer scrutiny & safety.

However, as the team grows, I've started getting uncomfortable with the lack of a "safety net" baked right into our stack.

We recently started doing some native Android development on Java. And I was (pleasantly) reminded of the safety provided by a compiled/static/strongly-typed language.

Mis-spelled variables, wrong data types, incorrect function invocations, and a host of trivial errors are caught by your IDE itself. All because the IDE can hook into the compiler and verify certain aspects of program "correctness".

Need to change a function signature? Easy. The compiler+IDE can help you spot ALL call sites.

Need to ensure that certain exceptions are always handled? Checked exceptions to your rescue.

Now, while these safety features have their advantages, I'm well aware of their disadvantages as well. More so, in the world of "boilerplate heavy" Java. Therefore, instead of Java, I've started looking at the slew of modern, "strongly typed" languages that people have started working on these days. For example: Scala, Rust, Haskell, etc. What interests me most is the power of their type systems and static/compile-time checks.

Now, the question

How do I use these powerful type systems and static/compile-time features in larger applications?

For example, how would I move beyond the standard "hello world" kind of introductions to these powerful features? One that uses a a rich type system to model a business-domain problem? Does the type system help, or hinder, when you're in the 30,000 LOC+ zone? What happens to the safety net provided by these type systems (and compile-time checks) when your system interacts with the weakly typed outside world, eg. via JSON or XML APIs, various data stores, user input, etc.


答:
I'll give a short answer due to my lack of time at the moment, but I'm currently working on two big projects (> 100.000 LOC in Haskell) - flowbox.io and luna-lang.org. We use Haskell for all the parts, including the backend, compiler of our programming language and even the webGL based GUI. I have to admit that the strong type system and the "dependent type"-like machinery can guide you and save you from burden and hassle known from other languages. We use the types very extensively and everything that could be checked in compile time, is done so. In fact, during the last 3 years of development, we never, ever encountered any runtime error or stack overflow (and this is something really incredible). The only errors are obvious logic errors made by programmers. A lot of people tell, that if something compiles in Haskell, it just works and you should be pretty sure it will not blow in your face some day. This is true for most of the situations and when you know the language well and know what to avoid (like unimplemented typeclass methods), you'll be safe and gain big profits from the type system.

Answering the first part of the question: You can learn about these powerful type system features reading some great blogs, like:

Bartosz Milewski blog

Edward Kmett's one

or Gabriel Gonzales one

In fact, there are a lot of other nice blogs out there (like planet Haskell). Anyway, the best method to really understand the advanced type systems is to develop a useful open source library. We (at Flowbox & New Byte Order) are releasing a lot of libraries (you can find them at Hackage), so if you don't have an idea what to develop, you can always involve into our projects – just email me whenever you want (mail available at luna-lang.org).

ContentLicense: CC BY-SA 4.0


答:
Where can one read about how to use these powerful type systems and
  static/compile-time features in larger applications?

from previous answer https://www.fpcomplete.com/business/resources/case-studies/

How does one move beyond the standard "hello world" kind of
  introductions to these powerful features?

it's really like any other language to build up strength

How can one use a rich type system to model a business-domain problem?

By using Abstract Data Types, or more generally polymorphism

Does the type system help, or hinder, when you're in the 30,000 LOC+
  zone?

It helps all the way. the type system helps you write the code as it tells you the shape of the result you want to have. Actually Agda write code for you.

PS: do not make the mistake of having a type system and having to write the types yourself, which is idiotic : computer can do it for you.

What happens to the safety net provided by these type systems (and
  compile-time checks) when your system interacts with the weakly typed
  outside world, eg. via JSON or XML APIs, various data stores, user
  input, etc.

It's great, as knowing the structure of values via types means the computer can infer a way to write (de)serializer for you.

If you really want to know about types and abstraction, the best introduction is On Understanding Types,
Data Abstraction, and Polymorphism

It's a paper, not a case study with pretty pictures, but it's enlightening


答:
I believe your question is a catgory error. In short, microservices are a way of organizing your architecture, while bounded contexts are a way of organizing the classes/objects you manipulate in code. There may be a one-to-one correlation between the two, or there may not be. There is certainly no necessary connection between the concepts.

If I may borrow Martin Fowler's example of bounded contexts:

In this case, bounded contexts simply tells us that we need a different Product class in the sales context than we do in the support context. That doesn't tell us where or how these classes should be stored or retrieved. For example:

This can be implemented without microservices at all. If this is a simple rich client application that never talks to the internet, obviously microservices won't make a lot of sense.

You can implement this with one microservice per context. Perhaps the sales and support contexts are each represented by a single database, and each database has a single microservice. Then you would talk to the sales microservice to get your SalesProduct, and the support microservice to get your SupportProduct.

Alternatively, you can implement this with one microservice per object type. There may be a product database that stores both the sales and support info, and you can ask the microservice for one or the other version of the Product. Or maybe you only ask it for a blob of info, and using that blob to instantiate a SupportProduct versus a SalesProduct is done somewhere else.


答:
What I've Seen:

I've worked a few large Ruby web applications (Rails), one large Haskell web application, and several smaller ones. With that experience I have to say that life working on the Haskell applications is much easier than in Rails in respects such as maintenance and lower learning curve. I am of the opinion that these benefits are both due to Haskell's type system and functional programming style. However, unlike many, I believe that the "static" part of the type system is just a huge convenience in that there is still benefit to be had when using dynamic contracts.

What I believe

There is nice package called Contracts Ruby which goes along way in providing some of the main features that I feel help Haskell projects achieve better maintenance characteristics. Contracts Ruby performs its checks at run-time so it is best when paired with high test converge but it still does provide the same in-line documentation and expression of intent and meaning as using type annotations in languages such as Haskell.

Anwser to Question

To answer the questions posed above, there are many places where one can become familiar with Haskell and other languages with advanced type systems. However, and to be perfectly honest, while these sources of documenation are excellent in their own right they all seem a bit underwhelming when compared to the plethora of documentation and practical advice found in Ruby, Python, Java and other such languages. In any case, Real World Haskell is getting old but is still a good resource.

Category Theory

If you choose Haskell you will run into large amounts of literature discussing Category theory. IMHO category theory is useful but not necessary. Given it prevalence in the Haskell community its is easy to conflate the pro's and cons of types with feelings about the practicality of Category theory. Its helpful to remember they are two different things, that is to say that implementations guided by Category theory can be done in dynamically typed languages just as well as static (modulo the benefits the type system provides). Advanced type systems in general are not bound to Category theory and Category theory is not bound to type systems.

More on Types

As you learn more about programming with types and the techniques therein (which happens quite quickly because its fun) you are going to want to express more with the type system. In that case I would look into to some of the following resource and join me in making tool vendors aware that we want industrial quality tools with these features only packaged into something that exposes an easy to use interface (like Contracts Ruby):

Introduction to Programming in ATS

LiquidHaskell Refinement Types via SMT and Predicate Abstraction

Type-Driven Development with Idris


答:
Well, weak vs. strong typing is pretty vaguely defined. Further, since closest there is to a general use of 'strong typing' is to refer things that make it difficult to cast types, that leaves nothing further to describe even stronger type systems. It's like saying if you can carry less than 30 lbs you are weak, and everyone who can lift more is in the same category of 'strong' - a misleading distinction.

So I prefer the definition:

Weakly typed systems use types to prevent you from doing certain things (like mistakes)

Strongly typed systems use types to do things for you

What do I mean by do things for you? Well, let's examine writing an image conversion API in the Servant framework (in Haskell, but you don't really need to know it to follow along, you'll see...)

{-# LANGUAGE
    TypeOperators,
    DataKinds
    #-}

import Codec.Picture
import Data.Proxy
import Network.Wai.Handler.Warp (run)
import Servant
import Servant.JuicyPixels

main :: IO ()
main = run 8001 conversion
```

<p>This is saying that we want some modules including the Servant package and the JuicyPixels plugin to Servant, and that the main entrypoint of the program is to run the 'conversion' function on port 8001 as the server using the Warp backend. Ignore the language bit.</p>

<pre class="lang-hs prettyprint-override"><code>conversion :: Application
conversion = serve (Proxy :: Proxy ConversionApi) handler
</code>```

This is saying that the conversion function is a server where the API must match type 'ConversionApi' and the requests are handled by the function handler

type ConversionApi
     = ReqBody '[BMP, GIF, JPEG 50, PNG, TIFF, RADIANCE] DynamicImage
    :> Post '[BMP, GIF, JPEG 50, PNG, TIFF, RADIANCE] DynamicImage
```

<p>This is specifying the <code>ConvesionApi</code> type. It says that we should accept incoming content types specified by the list '[BMP,GIF,JPEG 50, PNG, TIFF, RADIANCE], and handle them as a DynamicImage, and that we should return a DynamicImage converted into the same range of content types. Don't worry exactly about what :> means, just think of it as happy magic for now.</p>

<p>So, given my preferred definition, a weakly typed system can now ensure things like:</p>

<ul>
<li>You don't return the wrong outgoing content type</li>
<li>You don't parse the incoming request as the wrong content type</li>
<li>If our server was more complicated, it would prevent us from creating malformed URIs, but we're not actually returning any HTML pages to contain links (and the type ensures that we can't!)</li>
<li>A really ambitious weak typing system might even check to make sure we're exhaustively handling all the incoming and outgoing content types, allowing the type to also act as a specification document instead of just a constraint.</li>
</ul>

<p>All lofty goals, but not actually enough to qualify as a strongly typed system, given the above definition. And now we have to get to the <em>hard</em> part of actually writing code that follows this specification. In a really <em>strong</em> type system, we write:</p>

<pre class="lang-hs prettyprint-override"><code>handler = return
</code>```

And then we're done. That's it, there isn't any more code to write. This is a fully operational web server (modulo any typos I missed). The type has told the compiler everything it needs to create our web server from the types and the packages (modules technically) that we defined and imported.

So, how do you learn to do this at the major application scale? Well, it's really not much different from using them in smaller scale applications. Types that are absolutes don't care how much code is written relating to them.

Run time type inspection is something you're probably going to want to avoid, because that carves away a huge amount of the benefit and allows types to make your project more complicated to work with, rather than having types simplify things.

As such, it's mostly just a matter of practice modelling things with types. The two main ways of modelling things (or building things in general) are bottom up and top down. Top down starts with the highest level of operations, and as you build the model you have parts where you are deferring the modelling until later. Bottom up modelling means you start with base operations, just like you start with base functions, then build larger and larger models until you have fully captured the operation of the project. Bottom up is more concrete and likely faster to build, but top down may better inform your lower level models as to how they need to actually behave.

Types are how programs relate to math, literally, so there isn't really an upper bound on how complicated they can get, or a point where you can be 'done' learning about them. Virtually all of the resources outside higher level university courses are all dedicated to how types work in some particular language, so you need to decide that as well.

As best I can offer, types can be stratified like so:

Very weakly typed, things like JavaScript where [] + {} is defined

Weakly typed like Python, where you can't do [] + {}, but that isn't checked until you try

Weakly typed like C or Java, where you can't do [] + {}, but that's checked at compile time, however you don't have the more advanced type features

Straddling the border between weakly and strongly typed, such as C++ template metaprogramming, and simpler Haskell code where types are only enforcing properties.

Fully into Strongly typed, like more complicated Haskell programs where types do things, as shown above

The very strongly typed, like Agda or Idris, where types and values interact and can constrain each other. This is as strong as type systems get, and programming in them is the same as writing mathematical proofs about what your program does. Note: coding in Agda it is not literally writing mathematical proofs, types are mathematical theories, and functions with those types are constructive examples proving those theories.

Generally, the further down this list you go, the more that types can do for you, but by the very bottom, you're climbing into the stratosphere and the air is getting a bit thin - the package ecosystem is much smaller and you'll have to write more things yourself vs having found a relevant library. The barrier to entry also goes higher as you go down, as you have to actually understand the type system enough to write large scale programs.

Body:
Well, weak vs. strong typing is pretty vaguely defined. Further, since closest there is to a general use of 'strong typing' is to refer things that make it difficult to cast types, that leaves nothing further to describe even stronger type systems. It's like saying if you can carry less than 30 lbs you are weak, and everyone who can lift more is in the same category of 'strong' - a misleading distinction.

So I prefer the definition:

Weakly typed systems use types to prevent you from doing certain things (like mistakes)

Strongly typed systems use types to do things for you

What do I mean by do things for you? Well, let's examine writing an image conversion API in the Servant framework (in Haskell, but you don't really need to know it to follow along, you'll see...)

{-# LANGUAGE
    TypeOperators,
    DataKinds
    #-}

import Codec.Picture
import Data.Proxy
import Network.Wai.Handler.Warp (run)
import Servant
import Servant.JuicyPixels

main :: IO ()
main = run 8001 conversion

This is saying that we want some modules including the Servant package and the JuicyPixels plugin to Servant, and that the main entrypoint of the program is to run the 'conversion' function on port 8001 as the server using the Warp backend. Ignore the language bit.

conversion :: Application
conversion = serve (Proxy :: Proxy ConversionApi) handler

This is saying that the conversion function is a server where the API must match type 'ConversionApi' and the requests are handled by the function handler

type ConversionApi
     = ReqBody '[BMP, GIF, JPEG 50, PNG, TIFF, RADIANCE] DynamicImage
    :> Post '[BMP, GIF, JPEG 50, PNG, TIFF, RADIANCE] DynamicImage

This is specifying the ConvesionApi type. It says that we should accept incoming content types specified by the list '[BMP,GIF,JPEG 50, PNG, TIFF, RADIANCE], and handle them as a DynamicImage, and that we should return a DynamicImage converted into the same range of content types. Don't worry exactly about what :> means, just think of it as happy magic for now.

So, given my preferred definition, a weakly typed system can now ensure things like:

You don't return the wrong outgoing content type

You don't parse the incoming request as the wrong content type

If our server was more complicated, it would prevent us from creating malformed URIs, but we're not actually returning any HTML pages to contain links (and the type ensures that we can't!)

A really ambitious weak typing system might even check to make sure we're exhaustively handling all the incoming and outgoing content types, allowing the type to also act as a specification document instead of just a constraint.

All lofty goals, but not actually enough to qualify as a strongly typed system, given the above definition. And now we have to get to the hard part of actually writing code that follows this specification. In a really strong type system, we write:

handler = return

And then we're done. That's it, there isn't any more code to write. This is a fully operational web server (modulo any typos I missed). The type has told the compiler everything it needs to create our web server from the types and the packages (modules technically) that we defined and imported.

So, how do you learn to do this at the major application scale? Well, it's really not much different from using them in smaller scale applications. Types that are absolutes don't care how much code is written relating to them.

Run time type inspection is something you're probably going to want to avoid, because that carves away a huge amount of the benefit and allows types to make your project more complicated to work with, rather than having types simplify things.

As such, it's mostly just a matter of practice modelling things with types. The two main ways of modelling things (or building things in general) are bottom up and top down. Top down starts with the highest level of operations, and as you build the model you have parts where you are deferring the modelling until later. Bottom up modelling means you start with base operations, just like you start with base functions, then build larger and larger models until you have fully captured the operation of the project. Bottom up is more concrete and likely faster to build, but top down may better inform your lower level models as to how they need to actually behave.

Types are how programs relate to math, literally, so there isn't really an upper bound on how complicated they can get, or a point where you can be 'done' learning about them. Virtually all of the resources outside higher level university courses are all dedicated to how types work in some particular language, so you need to decide that as well.

As best I can offer, types can be stratified like so:

Very weakly typed, things like JavaScript where [] + {} is defined

Weakly typed like Python, where you can't do [] + {}, but that isn't checked until you try

Weakly typed like C or Java, where you can't do [] + {}, but that's checked at compile time, however you don't have the more advanced type features

Straddling the border between weakly and strongly typed, such as C++ template metaprogramming, and simpler Haskell code where types are only enforcing properties.

Fully into Strongly typed, like more complicated Haskell programs where types do things, as shown above

The very strongly typed, like Agda or Idris, where types and values interact and can constrain each other. This is as strong as type systems get, and programming in them is the same as writing mathematical proofs about what your program does. Note: coding in Agda it is not literally writing mathematical proofs, types are mathematical theories, and functions with those types are constructive examples proving those theories.

Generally, the further down this list you go, the more that types can do for you, but by the very bottom, you're climbing into the stratosphere and the air is getting a bit thin - the package ecosystem is much smaller and you'll have to write more things yourself vs having found a relevant library. The barrier to entry also goes higher as you go down, as you have to actually understand the type system enough to write large scale programs.


问:
How does my computer associate a keystroke with a set of pixels corresponding to the keystroke letter on-screen?
For most applications, when you type a key on your keyboard it often prints onto screen the letter corresponding to the keystroke.

By "printing" I mean the set of pixels associated with the keystroke gets displayed on-screen.

How does your computer translate the keyboard input into the pixels you see on the screen?

答:
It has nothing to do with Unicode. Unicode (at least, the core part of it) is simply a mapping from numbers to characters.

What you're looking for is called a font. Quoth Wikipedia:

A computer font (or font) is an electronic data file containing a set of glyphs, characters, or symbols such as dingbats. Although the term font first referred to a set of metal type sorts in one style and size, since the 1990s it is generally used to refer to a scalable set of digital shapes that may be printed at many different sizes.


答:
Each letter on the keyboard corresponds to a number that has been assigned to it called a scan code.  The operating system software maps this scan code to a Unicode, so when a particular scan code is typed, it knows which character to use.

Unicode is just a standard that allows the computer to associate each character with a number that never changes.  This number is different from the scan code, and there are enough numbers in Unicode to assign numbers to the characters in many different languages.

The actual display of the character is carried out with a "font."  In its simplest terms, a font just tells the computer which pixels to turn on or off for a given character.

Title: How does my computer associate a keystroke with a set of pixels corresponding to the keystroke letter on-screen?

Body:
For most applications, when you type a key on your keyboard it often prints onto screen the letter corresponding to the keystroke.

By "printing" I mean the set of pixels associated with the keystroke gets displayed on-screen.

How does your computer translate the keyboard input into the pixels you see on the screen?


问:
Object with Customized Properties and Methods
A project I am working on currently models Order information. Right now, there is one class with a bunch of properties and functions that all of orders have in common. In addition, some of our users have customized properties and/or functions on top of the base order. Some of those customized properties are shared between multiple users and some are unique to a given user. The class has nearly 50 different properties, but a given user might only be using 20 or so of those properties.

I'd like to redesign it so that the base properties/functions are separate from the customized properties/functions, but I don't know how to approach this. I thought about inheriting the base class, but a user might have 3 or 4 different customized properties. There is no clear inheritance among the customized properties. I looked into the decorator pattern, but the interface is changing, so that doesn't seem to fit.

Is there any way to accomplish this without having the monolithic class?

Examples:

```<code>Base Properties - OrderID, OrderDate, AccountId, etc.
Customized Properties - BackOrdered, PONumber, ContactPerson
Base Functions - PlaceOrder, CancelOrder
Customized Functions - AddContact, DiscountPriceByPercent
</code>```

So, some users might only have the base, one user might have the base + BackOrdered, and another user might have base + BackOrdered + PONumber.

This problem isn't unique to orders, I have the same problem with other objects in the project. I'm looking more for an architecture/pattern to solve the general case than for a way to handle orders.

答:
If performance is the main goal, then i would go for the monolithic solution. If flexibility is the one, then may be you can use a dictionary called 'CustomProps' with the name and value of the custom properties and another called 'CustomFuncs' with the name and function you want to call.

Now you can make a getter/setter with a string name and a object value, find the property and cast the value. For the functions analog with a string name and an function/action/delegate, that you can call. If they need parameters, this can be enhanced for it.

Clearly, this will not be the fastest, but very flexible...


答:
I just started working on the core team of a large platform written in Scala.  You can look at successful open source applications, like Scalatra, Play, or Slick to see how they handle some of your more detailed questions about interactions with dynamic data formats.

One of the great advantages we've found of the strong typing of Scala is in user education.  The core team can make decisions and enforce those decisions in the type system, so when other teams who are much less familiar with the design principles have to interact with the system, the compiler corrects them, and the core team is not constantly correcting things in pull requests.  This is a huge advantage in a large system.

Of course, not all design principles can be enforced in a type system, but the stronger your type system, the more design principles you can enforce in the compiler.

We can also make things easier for users.  Often to them they are just working with regular collections or case classes, and we are converting it to JSON or whatever automatically as needed for network transport.

Strong typing also helps make differentiations between things like unsanitized and sanitized input, which can help with security.

Strong typing also helps your tests be more focused on your actual behavior, instead of needing a bunch of tests that just test your types.  It makes testing much more pleasant, more focused, and therefore more effective.

The main disadvantage is unfamiliarity with the language and the language paradigm, and that is correctable with time.  Other that, we have found it well worth the effort.


问:
Avoiding constructors with many arguments
So I have a factory which creates objects of different classes.
The possible classes are all derived from an abstract ancestor.
The factory has a configuration file (JSON syntax) and decides which class to create, depending on the user's configuration.

To achieve this, the factory uses boost::property_tree for JSON-parsing.
He walks through the ptree and decides which concrete object to create.

However, the product-objects have many fields (attributes).
Depending on the concrete class, the object has about 5-10 attributes, in the future maybe even more.

So I'm not sure how the constructor of the objects should look like.
I can think of two solutions:

1) The product's constructor expects every attribute as a parameter, thus, the constructor will end up with 10+ parameters. This will be ugly and lead to long, unreadable code lines. However, advantage is that the factory can parse the JSON and invoke the constructor with the correct parameters. The product class does not need to know that it has been created due to JSON configuration. It does not need to know there is JSON or configuration involved at all.

2) The product's constructor only expects one argument, the property_tree object. Then it can parse the needed information. If am information in the config is missing or out-of-bounds, each product class can react properly.
The factory does not need to know what arguments are needed by the several products. The factory also does not need to know how to react in case of wrong configuration. And the constructor interface is unified and small.
But, as a disadvantage, the product needs to extract the needed information from the JSON, thus, it knows how it is constructed.

I tend to prefer solution 2).
However, I'm not sure if this is good factory pattern.
It feels somehow wrong letting the product know that it is created with JSON configuration.
On the other side, new products can be introduced very simple.

Any opinions on that?

答:
I wouldn't do option 2, because then you have forever convolved your object's construction with boost property tree parsing. If you're comfortable with a class that needs that many parameters, you should be comfortable with a constructor that needs that many parameters, such is life!

If your main concern is code readability, you can use the builder pattern, it's basically the c++/java stopgap for lack of named arguments. You end up with things that look like this:

```<code>MyObject o = MyObject::Builder()
               .setParam1(val1)
               .setParam2(val2)
               .setParam3(val3)
             .build();
</code>```

So now MyObject will have a private constructor, that gets called in Builder::build. The nice thing is that that will be the only place you ever have to call a constructor with 10 parameters. The boost property tree factory will use the builder, and subsequently if you want to construct a MyObject directly or from a different source, you would go through the builder. And the builder basically lets you clearly name each parameter as you pass it in, so it's more readable. This obviously adds some boilerplate, so you'll have to decide if it's worth it compared to just calling the messy constructor, or lumping together some of your existing parameters into structs, etc. Just throwing another option on the table.

https://en.wikipedia.org/wiki/Builder_pattern#C.2B.2B_Example

Body:
I wouldn't do option 2, because then you have forever convolved your object's construction with boost property tree parsing. If you're comfortable with a class that needs that many parameters, you should be comfortable with a constructor that needs that many parameters, such is life!

If your main concern is code readability, you can use the builder pattern, it's basically the c++/java stopgap for lack of named arguments. You end up with things that look like this:

MyObject o = MyObject::Builder()
               .setParam1(val1)
               .setParam2(val2)
               .setParam3(val3)
             .build();

So now MyObject will have a private constructor, that gets called in Builder::build. The nice thing is that that will be the only place you ever have to call a constructor with 10 parameters. The boost property tree factory will use the builder, and subsequently if you want to construct a MyObject directly or from a different source, you would go through the builder. And the builder basically lets you clearly name each parameter as you pass it in, so it's more readable. This obviously adds some boilerplate, so you'll have to decide if it's worth it compared to just calling the messy constructor, or lumping together some of your existing parameters into structs, etc. Just throwing another option on the table.

https://en.wikipedia.org/wiki/Builder_pattern#C.2B.2B_Example


问:
Is the strong exception safety guarantee with a pass-by-value argument which can throw on destruction possible?
Suppose you have a type with a throwing destructor, and a function receiving it by value.

Can that operation ever provide anything better than the basic exception guarantee?

Or formulated differently, may one disregard the destruction of the argument which was passed by value when determining whether an operation has commmit-and-rollback-semantics?

```<code>#include <cstdlib>

struct X {
    ~X() noexcept(0) {
        if(rand()%6 == 0) throw 0;
    }
    // some state
};

void update(database db, X arg) noexcept;

X x;
update(db, x);
</code>```

Personally, based on the definition from wikipedia

Strong exception safety, also known as commit or rollback semantics: Operations can fail, but failed operations are guaranteed to have no side effects, so all data retain their original values

I don't think it's useful to describe update as being strongly exception-safe, even though the function itself cannot even throw.

I would appreciate either someone showing me the folly of my current understanding, or giving a better argument.

答:
Technically speaking, it can perhaps provide the strong exception guarantee. Meaningfully, it can only provide the strong exception guarantee in the trivial case where it does nothing.

Herb Sutter talks about a similar (and more intuitive case) where a function takes an argument by value that has a throwing copy constructor. You can label such a function noexcept. Technically, the exception occurs in the "glue" between the calling code and the called function, not inside the function itself. That's the case here as well. Since the exception is not technically thrown inside update, you could (perhaps) argue that update itself does not generate the error and therefore can offer the strong exception guarantee.

Practically speaking, if update does anything, then calling it (and doing nothing else) can lead to the state of the world changing and an exception being thrown, breaking the strong exception guarantee.


问:
Do I need to know servlets and JSP to learn spring or hibernate or any other java web frameworks?
I've been asking a lot of people where to start learning java web development, I already know core java (Threading,Generics,Collections, a little experience with (JDBC)) but I do not know JSPs and servlets. I did my fair share of  development with several web based applications using PHP for server-side and  HTML,CSS,Javascript,HTML5 for client side.

Most people that I asked told me to jump right ahead to Hibernate while some told me that I do not need to learn servlets and jsps and I should immediately study the Spring framework. Is this true? do I not need to learn servlets and JSPs to learn hibernate or Spring?

All of their answers confused me and now I am completely lost what to learn or study. I feel that if I skipped learning JSP and servlets I would missed a lot of important concepts
that will surely help me in the future.

So the question, do I need to have foundation/know servlets and JSP to learn spring or hibernate or any other java web frameworks.?

答:
it seems like you are stuck on an issue that I faced recently. My goal was to learn server-side development with Java. So, I started off with servlets, understood their working and wrote some simple programs to run on the TomCat server. TomCat, is a pre-requisite. You should definitely be familiar with TomCat if you wanna proceed further.
As far as struts2 or Spring are concerned, struts2 and spring are frameworks built on servlets, which makes having a deep understanding of servlets essential if you want to be strong at the basics. I started off with Java Brains tutorials. For a beginner, these tutorials are amazing. Some works by Jakob Jenkov on his blog are really amazing too. Struts2 and Spring do become simpler when you know servlets. As far as hibernate is concerned, I suggest you to start off with being really familiar with JDBC. Go stepwise, servlets , struts ,  JDBC , Spring , Hibernate . Hope my answer helps :) .</p>


问:
Is "StringBuilder" an application of the Builder Design Pattern?
Is the "Builder" pattern restricted to addressing the "telescoping constructor" anti-pattern, or can it be said to also address the more general problem of complicated creation of immutable objects?

The StringBuilder class has the word "builder" in its name, but it has nothing to do with telescoping constructors, it simply helps us collect all the data that we need to pass to the constructor of an immutable object.

To me it appears like the answer is a very clear "yes", but there appears to be some disagreement on the topic, so I was hoping that someone could perhaps clarify it.

I was answering this question: Programmers SE: Legitimate “real work” in a constructor? where the OP wants to create a (presumably immutable) object containing a complex tree, and the idea of the "builder" pattern popped up, and while researching it I found this Q&A which seems to say that "StringBuilder" style of object creation is not an application of the "Builder" pattern, for reasons which are not clear to me: Stackoverflow - StringBuilder and Builder Pattern. (Those answering that question failed to make a convincing point as far as I can tell.)

答:
A StringBuilder is similar to a the Builder Pattern, but does not share much with the GoF description of this design pattern. The original point of the design pattern was

Separate the construction of a complex object from its representation so that the same construction process can create different representations.

— from Design Patterns, by Gamma, Helm, Johnson, Vlissides.

(note: “complex” primarily means “composed of multiple parts”, not necessarily “complicated” or “difficult”)

The “different representations” is key here. E.g. assuming this construction process:

interface ArticleBuilder {
  void addTitle(String title);
  void addParagraph(String paragraph);
}

void createArticle(ArticeBuilder articleBuilder) {
  articleBuilder.addTitle("Is String Builder an application of ...");
  articleBuilder.addParagraph("Is the Builder Pattern restricted...");
  articleBuilder.addParagraph("The StringBuilder class ...");
}
```

<p>we might end up with a <code>HtmlDocument</code> or a <code>TexDocument</code> or a <code>MarkdownDocument</code> depending on what concrete implementation is provided:</p>

<pre class="lang-java prettyprint-override"><code>class HtmlDocumentBuilder implements ArticleBuilder {
  ...
  HtmlDocument getResult();
}

HtmlDocumentBuilder b = new HtmlDocumentBuilder();
createArticle(b);
HtmlDocument dom = b.getResult();
</code>```

So one central point of the Builder pattern is polymorphism. The Design Patterns book compares this pattern to the Abstract Factory:

Abstract Factory is similar to the Builder in that it too may construct complex objects. The primary difference is that the Builder pattern focuses on constructing a complex object step by step. […] Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately.

— from Design Patterns, by Gamma, Helm, Johnson, Vlissides.

This step-by-step aspect has then become the more popular aspect of the Builder pattern, so that in common parlance the Builder pattern is understood like this:

Split construction of an object into multiple steps. This allows us to use named arguments or optional parameters even in languages that do not support these features.

Wikipedia defines the pattern like this:

The builder pattern is an object creation software design pattern. Unlike the abstract factory pattern and the factory method pattern whose intention is to enable polymorphism, the intention of the builder pattern is to find a solution to the telescoping constructor anti-pattern[citation needed]. […]

The builder pattern has another benefit. It can be used for objects that contain flat data (html code, SQL query, X.509 certificate...), that is to say, data that can't be easily edited. This type of data cannot be edited step by step and must be edited at once. The best way to construct such an object is to use a builder class.[citation needed]

— from Builder Pattern on Wikipedia, by various contributors.

So as we can see, there is no truly common understanding of which pattern this name refers to, and in some points different definitions even contradict one another (e.g. regarding the relevance of polymorphism for Builders).

The only common property of the StringBuilder with various interpretations of the pattern is that the product is created step by step rather than in one go. It does not meet a strict reading of the GoF definition of the design pattern, but please note that design patterns are malleable concepts meant to facilitate communication. I would continue to call StringBuilder an example of the Builder Pattern, albeit an atypical one – the main reason for that structure in Java is performant concatenation in the presence of immutable strings, but not some interesting object-oriented design.

Body:
A StringBuilder is similar to a the Builder Pattern, but does not share much with the GoF description of this design pattern. The original point of the design pattern was

Separate the construction of a complex object from its representation so that the same construction process can create different representations.

— from Design Patterns, by Gamma, Helm, Johnson, Vlissides.

(note: “complex” primarily means “composed of multiple parts”, not necessarily “complicated” or “difficult”)

The “different representations” is key here. E.g. assuming this construction process:

interface ArticleBuilder {
  void addTitle(String title);
  void addParagraph(String paragraph);
}

void createArticle(ArticeBuilder articleBuilder) {
  articleBuilder.addTitle("Is String Builder an application of ...");
  articleBuilder.addParagraph("Is the Builder Pattern restricted...");
  articleBuilder.addParagraph("The StringBuilder class ...");
}

we might end up with a HtmlDocument or a TexDocument or a MarkdownDocument depending on what concrete implementation is provided:

class HtmlDocumentBuilder implements ArticleBuilder {
  ...
  HtmlDocument getResult();
}

HtmlDocumentBuilder b = new HtmlDocumentBuilder();
createArticle(b);
HtmlDocument dom = b.getResult();

So one central point of the Builder pattern is polymorphism. The Design Patterns book compares this pattern to the Abstract Factory:

Abstract Factory is similar to the Builder in that it too may construct complex objects. The primary difference is that the Builder pattern focuses on constructing a complex object step by step. […] Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately.

— from Design Patterns, by Gamma, Helm, Johnson, Vlissides.

This step-by-step aspect has then become the more popular aspect of the Builder pattern, so that in common parlance the Builder pattern is understood like this:

Split construction of an object into multiple steps. This allows us to use named arguments or optional parameters even in languages that do not support these features.

Wikipedia defines the pattern like this:

The builder pattern is an object creation software design pattern. Unlike the abstract factory pattern and the factory method pattern whose intention is to enable polymorphism, the intention of the builder pattern is to find a solution to the telescoping constructor anti-pattern[citation needed]. […]

The builder pattern has another benefit. It can be used for objects that contain flat data (html code, SQL query, X.509 certificate...), that is to say, data that can't be easily edited. This type of data cannot be edited step by step and must be edited at once. The best way to construct such an object is to use a builder class.[citation needed]

— from Builder Pattern on Wikipedia, by various contributors.

So as we can see, there is no truly common understanding of which pattern this name refers to, and in some points different definitions even contradict one another (e.g. regarding the relevance of polymorphism for Builders).

The only common property of the StringBuilder with various interpretations of the pattern is that the product is created step by step rather than in one go. It does not meet a strict reading of the GoF definition of the design pattern, but please note that design patterns are malleable concepts meant to facilitate communication. I would continue to call StringBuilder an example of the Builder Pattern, albeit an atypical one – the main reason for that structure in Java is performant concatenation in the presence of immutable strings, but not some interesting object-oriented design.


答:
Sounds to me that the custom properties are about order processing state.

Make a state diagram of your order process. Design classes that move the Order from one state to another, for example from a backordered state to a shipped state. The core Order would be contained w/in each as it is going through that particular state change.

There may also be a class that captures the various states an order has gone through as it goes from a new order, filled, paid, shipped, et cetera. Whether this "checklist" is an integral part of the Order class is a matter for your design analysis to resolve. There may be an OrderProcessor that drives an order through the state labyrinth.

P.S.

My answer sounds quite similar to @Ewan answer, e.g. "order can have different things happen to them" However I want to emphasize the states with transitions between them explicitly defined as opposed to discrete "services" with no defined relationships.

In other words to ship an order it must be in a certain state (filled, let's say) and by design we know it went through all the required states up to the current state. Otherwise every unrelated "service" would have to evaluate the order for its entire state-chain, potentially sending it back to "fix it" - a potentially recursive bowl of mush.

Title: Object with Customized Properties and Methods

Body:
A project I am working on currently models Order information. Right now, there is one class with a bunch of properties and functions that all of orders have in common. In addition, some of our users have customized properties and/or functions on top of the base order. Some of those customized properties are shared between multiple users and some are unique to a given user. The class has nearly 50 different properties, but a given user might only be using 20 or so of those properties.

I'd like to redesign it so that the base properties/functions are separate from the customized properties/functions, but I don't know how to approach this. I thought about inheriting the base class, but a user might have 3 or 4 different customized properties. There is no clear inheritance among the customized properties. I looked into the decorator pattern, but the interface is changing, so that doesn't seem to fit.

Is there any way to accomplish this without having the monolithic class?

Examples:

```<code>Base Properties - OrderID, OrderDate, AccountId, etc.
Customized Properties - BackOrdered, PONumber, ContactPerson
Base Functions - PlaceOrder, CancelOrder
Customized Functions - AddContact, DiscountPriceByPercent
</code>```

So, some users might only have the base, one user might have the base + BackOrdered, and another user might have base + BackOrdered + PONumber.

This problem isn't unique to orders, I have the same problem with other objects in the project. I'm looking more for an architecture/pattern to solve the general case than for a way to handle orders.


答:
First, I feel like there is a confusion in answers between weakly typed versus strongly typed, and static versus dynamically typed. Link the OP provided clearly makes the distinction :

A strong type system is a type system that has a compile-time restriction or run-time feature that you find attractive.

A weak type system is a type system which lacks that restriction or feature.

For example, C, C++ and Java are statically typed since variables are typed at compile time. Yet, C and C++ can be considered weakly typed because the language allow to bypass restrictions using void * pointers and casts.More on this topic.

On this distinction, strong typing can only be better. The earlier the fail, the better.

However, on writing large programs, I don't think type system plays an important role. Linux kernel is ten million LOC written in C and assembly and is considered a very stable program, it's miles away from my 200 Java lines that are probably full of security holes. Similarly, although dynamically typed "script languages" suffer a bad reputation when it comes to writing large programs, there is occasionally proof it's undeserved (such as Python Django, over 70k LOC)

In my opinion, it's all about quality standard. The responsibility for scalability of large applications should only be held by the programmers and the architects and their will to make the application clean, tested, well documented etc.