The Structured Programming Theorem (redirected from Bohm-Jacopini Theorem) from Wikipedia states: The structured program theorem is a result in programming language theory. It states that every computable function can be implemented in a programming language that combines subprograms in only three specific ways. These three control structures are:
1. Executing one subprogram, and then another subprogram (sequence)
2. Executing one of two subprograms according to the value of a boolean variable (selection)
3. Executing a subprogram until a boolean variable is true (repetition)
How does one exactly break this theorm?
It seems exaggeration and figures of speech to express the terrible state of affairs of the programming and software engineering practices cannot be performed lightly in what is supposed to be a "news for nerds" website. Let me break it down for you:
is the use of exaggeration as a rhetorical device or figure of speech. It may be used to evoke strong feelings or to create a strong impression, but is not meant to be taken literally.
Hyperboles are exaggerations to create emphasis or effect
2. Rhetoric:
The art of effective or persuasive speaking or writing, esp. the use of figures of speech and other compositional techniques
Language designed to have a persuasive or impressive effect on its audience, but is often regarded as lacking in sincerity or meaningful content.(me: this could be the hyperbolic nature of a figure of speech gets lost in the interweebz)
S: (n) trope, figure of speech, figure, image (language used in a figurative or nonliteral sense)
With that cleared up, the figure of speech -slash- hyperbolic piece rhetoric below:
cannot even do structured programming, and try every single way to break the Bohm-Jacopini Theorem using whatever du jour OOP language of the day
is meant to serve as a grotesque, pejorative description of the equally grotesque situation of programmers - both the type who know nothing but OOP languages like Java or C#, but also "old guard" ones from the procedural bygone era - who despite working with a OOP language end up writing spaghetti with meatballs code.
There are other pejorative terms floating around for a good while now: hyper-spaghetti, GOT-OOP, hyper-lasagna and the like. Even when the code has no goto statements in it, the abuse and apparent lack of coherent use in the nominal control structures mentioned by Bohm and Jacopini makes the disastrous, impenetrable code within and across classes look like the type of GOTO-ridden code Dijkstra railed against it (with Bohm and Jacopini's work as theoretical validation).
These references have existed for a good while now (and given the sentence that preceded it), my hyperbole should have been clear from its context. I guess it was not. The analogy is very clear when you have seen a mass of recently developed production code based on nothing but GOTOs on a past recent enough to have seen widespread use of OOP languages (sadly, I have).
Try that again, but without so much ad hominem, and without using "generalization" as your only argument against what was said.
It's hard to take you, and other NoSQL advocates, seriously when you don't present sound arguments.
Ad hominems. How do pot-kettle. Instead of telling me that I'm ad hominem'ing you, tell me exactly which of the accusations I made (generalizations and ridiculing) is not true. Then we talk.
Also, I'm not a NoSQL advocate at all. I'm a whatever-works advocate. For the majority of cases, for the general case, a relational database system works just fine. For a certain class of problems, it doesn't. Use the tool that is appropriate for the task.
But then again, you are free to generalize me as a NoSQL advocate if that helps you build your argument (given that generalization seems to be your forte.)
The comment you replied to provided us with all of the facts, in a coherent and intelligent manner. You, on the other hand, just threw out one insult and pathetic argument after another.
O really? If that's your understanding of presenting facts in an intelligent, coherent manner, you need to get psychiatric help. Allow me to quote that wonderful piece of intellectual work you are referring to as my last, parting shot. Feel free to stay and belabor on it as you see fit:
1. Attempt to insult via generalizations:
Then they realize that they need some way to query this data. Since most of them only seem to know JavaScript (maybe they were all web designers who pretend to be programmers?)
2. Attempt to a counter-argument by strawman (by referring to a false position NoSQL advocates have ever made):
But of course it isn't SQL! That would be incompatible with their "NoSQL" philosophy
3. Attempt to trivialize by taking a dumb thing to do and painting it as if that's what serious NoSQL advocates do in real life:
(Keep in mind that the system they're "scaling" is a blog getting 50 hits per day.)
4. Attempt to create a refutation via ridicule without substantiating data or citations to the fact:
When they find out that their NoSQL database has corrupted or lost data, they start trying to hack together application-level support for stuff like transactions and constraints.
5. Attempt to negatively compare apples and oranges without specifying a particular context, without showing numbers and while ignoring the fact that many well-published companies (Google, FB, Twitter, LinkedIn) to name a few have use non-relational stores to improve their performance numbers.
that doesn't perform any better than existing relational databases,
6. Attempt to take a few edge case (MongoDB and CouchDB) while maliciously ignoring all the other non-relational stores out there that use more familiar querying languages based on SQL (GAE's data store and GQL, Amazon BigTable restricted SQL, Oracle BerkeleyDB and its restricted SQL capabilities, all other NoSQL stores out there that you can query with XQuery.)
that uses a mangled JavaScript-inspired dialect of SQL
And this last goes to the heart of the matter. You criticize all of the NoSQL stores because a few use a JSON-based query language (which is natural if you store and query things in JSON or BSON format). And the meat of this article is about providing a unifying querying language that is based or related on Codd's relational algebra.
So pretty much you bitch about the problem... in a discussion about a solution to that problem... and where the solution closely resembles at a very mathematical level to the thing you feel more comfortable with (SQL.)
Here is a crowbar. Please use it to get your head out of your ass.
UNQL, for a post-relational world. Nice. Meanwhile 90% [citation needed] of people working with databases can't even get relational databases right.
Learning to run before learning to walk, anyone?
And we are moving into functional and functional-object-hybrid models of programming when the majority of programmers in 2011 cannot even do structured programming, and try every single way to break the Bohm-Jacopini Theorem using whatever du jour OOP language of the day. So what's your point?
If we had to wait for every moron code monkey to come up to speed, we would still be reading data off punch cards using a bastard mix of COBOL and mainframe assembly. Industrial and academic R&D and innovation forces have an obligation to move forward. Individual programmers have an obligation to educate themselves and to develop the work ethics to do things right wherever and whenever possible. Lack of the later is not reason to bog down the former.
Well, call me crazy, but the idea of NoSQL was NOT USING SQL AT ALL... now we got a language that in FACT "could be considered a superset of SQL", ok now we have to learn SQL and MORE to use a NOsql set of data. Great but let's change the name of NoSql to something else because this is more st..p thing I heard in the last years... now what.. people is going to hand out meatballs at PETA meetings....
Crazy? No. Ignorant. Yes. In essence "the idea of NoSQL was NOT USING SQL AT ALL" is simply not true. This has been mentioned for a while now, but apparently people can't seem to grasp it. NoSQL is a misnomer since the idea is not to move away from SQL but to provide data models alternative to Codd's relational model for a variety of reasons (high availability is just one of them.) I agree that the name needs to be changed, but I'd also say that Google is your friend.
This version of UnQL has no relation to an identically named unstructured data query language proposed by a University of Pennsylvania researcher over a decade ago, Phillips said.
I know it's slashdot, but c'mon. Just looking at the linked postscript file shows you a major WTF discrepancy. First the paper is from 2000, and then that paper's query language is based on algebras that do not resemble Codd's relational algebra at all. And that runs counter to this, also FTFA:
Like SQL, UnQL was built on the foundation of relational algebra, Phillips said.
The news are great. The coverage blows. It would pay to read the stuff that is being submitted as a story... just sayin...
I just don't get NoSQLers at all. Can somebody explain them to me?
So they have trouble scaling systems using existing relational databases because they don't know about indexes, or data partitioning, or how to set up proper hardware configurations for database servers. (Keep in mind that the system they're "scaling" is a blog getting 50 hits per day.)
Generalizations + lies + attempt to ridicule without facts in hand
Their solution to this problem is to avoid relational databases completely, instead opting to use so-called "NoSQL" databases that don't offer ACIDity, or basically every other useful feature of relational databases.
Apparently obvious to the fact that in many non-trivial business cases, you don't need full ACIDity and an eventually consistency model is more appropriate.
Then again, many of these NoSQLers don't even seem to know what transactions or referential integrity are in the first place, so maybe they don't even realize what they're missing.
Generalizations and unsubstantiated blanket statements about a group of software engineers for the mere sake of ridicule (this in contradiction to the first question that is dishonestly presented as a genuine question.)
When they find out that their NoSQL database has corrupted or lost data, they start trying to hack together application-level support for stuff like transactions and constraints.
Generalization, speculation.
It doesn't work, and may in fact cause more problems than it actually prevents.
Generalizations + hand waving (surprisingly, this didn't contain an instance to a "think of the children" fallacy)
Now they mistakenly think that their data has better integrity, when it reality it doesn't.
Generalization based on a claim that AFAIK has never been made (a poor man's attempt at a strawman.)
Then they realize that they need some way to query this data. Since most of them only seem to know JavaScript (maybe they were all web designers who pretend to be programmers?)
More generalizations as an attempt to ridicule or even insult (no actual, scientific and honest interest to understand the issue at hand.)
they decide to contort it into a query language.
You do have a point, ergo the need for a querying language, which pretty much the topic of TFA.
Eventually, their custom-brewed query language ends up evolving into something that's very remarkably like SQL.
That is a possibility, your point?
But of course it isn't SQL! That would be incompatible with their "NoSQL" philosophy
As it has been made apparent in the shitload of literature, interviews and presentations out there (fucking google it?), it has been acknowledge that NoSQL is a misnomer, as the intention was never to move out of SQL, but to provide alternative/competing data representations to the relational model (which provides a very good formal symbolic representation of a certain ubiquitous but not universal class of data.)
which strongly states that SQL is a horrible thing and should forever be avoided.
Says who? Cite references to this effect.
(But when confronted with this similarity, they'll backpedal and claim that the "No" in "NoSQL" means "not only", contradicting the "NoSQL means no SQL ever!" claims they'd made the week before.)
Red herring, strawman. I short, generalizing stupidity.
In the end, they've spent a lot of time and effort creating a "database" system that doesn't adhere to the ACID principles in any sensible way
Because full ACIDity is not desirable in certain classes of problems. Where have you been all this time?
Yeah, but he has an entire Marin county valley named after him in Northern California. Smith Ranch Road became Lucas Valley Road west of Highway 101. This while still being alive. Usually, people don't have things named after them until they are dead. (presidential libraries excepted).
Having the county name a geographical region after you is a success.
'It's crazy, we buy proprietary [and] we don't understand what it is we're buying into,' he said. 'It works great for an application, and then you come to conflict and you spend the rest of your time trying to modify it to actually do what it should do.'
This sounds like every corporation where I have ever worked.
Some companies experience a lot more pain than others when it comes to that, though.
As a IT worker who can't find a new job and who does not work in SIlicon Valley or the West coast of the US at all, while you may have it good my career is basically gone now. I have kept up to date, I have paid my dues, but here their isn't that marvelous growth their is out your way. Having just run out of unemployment and literally having no way to live anymore because I just can't seem to get hired in the field at all (& lack experience for anything else). I can say that you should care, because except for a bit of fate on your part you could be me and just as equally in need of help right now.
I feel for you because I've also worked in IT. And because of what you are going through is the main reason I've left IT (IT meaning enterprise computing and IT operations.) I'm still in software, but not in IT. And I'll be out of it if I can help it.
I started seeing the writings on the wall since the dot-com era, and they have been reinforced by outsourcing, and the continous automation of enterprise computing.
In IT is no longer sufficient to keep up to date, but to be exceptional (and to be in the right geographical place as not all regional IT markets are the same). And I think to seek to be exceptional (not to be, but to seek to be, to put the effort to be) is mandatory in engineering, and in software in particular. But the ROI in IT/Enterprise computing is dubious at best. One has to be exceptional and a specialist on specific niches (and versatile at the same time) to ensure a modicum of job opportunities. IT might have the lowest barrier of entries in all types of software work, but it is certainly the one with the most dubious ROI when it comes to the cost in time and money for keeping one's career afloat.
Good luck, and I hope you improve your situation. My advice. Get out of IT and get into non-IT software jobs if you can.
> I am not saying I am better than anybody else
Yes you are.
No he's not. He's simply saying that for those job/career specific conditions, he has done choices that allows him to fare better (possibly with the hope of others might benefit with his annecdotes.) The type of moral implications attached to his post are a function of the reader, not the poster.
$16k is... pre-tax, in some places, at a fairly low to very low standard of living
Bullshit.
"Low standard of living" my hairy ass. I am married, I keep rent paid, (never late for 5 years, HDTV, car insurance, electricity, land line phone, cell phones w/ unlimited data, 10Mbps internet connection, 3 computers, plenty of meat in the fridge, and the food plentiful.
You know what I take home each month? 1135. Yes, we live in a 1bdrn apt, but both of our cars are paid for, and rent is paid for a year in advance. Do I do this with assistance? NO. I have a 50" HDTV, a computer that would likely kick yours into the dirt, an internet connected blu-ray player, and a home network for multimedia support. All of this on less then $13620/ yr take home. You can't make it on $16000/yr my ass. It is easily doable.
Questions:
1. How long have you been doing this?
2. Before you started doing this, how much did you earn, did you have any savings?
3. Do you have any savings now?
4. Do you have any non-government assisted medical insurance, dental?
5. The $1135/moth you are making, is that by both of you, or by you alone? If the later, how much does your partner make?
6. Do you have kids? If so, can you break down the expenses for them, and do they have non-government assisted medical coverage? If not, do you think you can meet ends once you have them?
7. How much rent do you pay, and where?
8. Do you get a return from the IRS? Or do you have to pay additionally when you file your income tax? Or do you call it even with the tax collectors?
9. More importantly, where do you live and how old are both of you?
Can it be that instead of having interbred, we merely share a common distant ancestor?
In that case, the genes would also be found in the "African" populations. Since that is not the case (according to the findings), then the most pausible alternative is that indeed, there was interbreeding between out-of-Africa H. Sapiens and H. Neanderthalis (most likely very early on in the H. Sapiens expansion out of Africa.)
I was in downtown Boston on the 4th of July weekend, and happened upon a unique memorial: it was six four-sided pillars, each about 50 feet high, of clear glass. Pretty, actually. Then I looked closer to see what was etched into the glass. It was a collection of numbers, almost like serial numbers, or concentration camp IDs. My wife nearly collapsed at the realization. All those people, dead, because soldiers were "following orders."
A -human's- first order of responsibility is to do what's right.
Did that include the dog tags of those who died following orders on D-Day?
Oh yes, you are right, lambdas got dropped and pushed to version 8. I would have much preferred that now than strings in switch statements (a stupid idea IMO).
In practice, however, Java anonymous inner classes can be used in largely the same way as C# anonymous delegates - they're only slightly more verbose, and the only other practical difference is that they close over values of variables, not locations - which doesn't matter for a lot of scenarios.
Hmmm, no. I've had to deal with anonymous classes in the distant and no-so distant past. And affter working with lambdas in Lisp, JavaScript and Groovy, they simply do not compare from the point of view (and inherent cost) of day to day coding.
I'm going to have to disagree with you on this (see the areas in bold). Not to tooth my own horn, but I've done almost nothing but Java development since 99, including web application and systems/network protocol development, library development, and (most relevant to this topic) Swing development. I can tell you with 100% experience-backed, with severe from-the-trenches bruises that they are *not*slightly more verbose.
Non-trivial anonymous classes in lieu of lambdas and closures are horrendously verbose. Horrendous, abominable. No way around these monstrosities when creating action listeners and thread workers in Swing. Outside of Swing, in the realm of server side development, sometimes you can see opportunities to factor out exception and transcation handlers as lambdas to reduce boilerplate, but the verbosity of anonymous classes makes it horrendously hard. Only one time I've been able to pull that off cleanly despite the verbosity. For all other cases, we might as well deal with the typical Java boilerplate or use AOP under the hoods, or deal with them with a mix of Java and Groovy.
And even in Java 8 (there's no lambdas in Java 7), there are no function types.
True that - at least under the hood. And that is because the JVM does not have a notion of function handlers. Any lambda, whether in Java 8, Scala or Clojure, must under the hood resolve to a functor object (most likely an instance of an anonymous class) implementing a SAM (single abstract method.)
Unless the JVM is revamped with some type of bytecode op that represents a function reference type, no language on top of the JVM, be it Scala, Java 8, Groovy, Jython, JRuby, Clojure, Jaskell, JScheme, will ever be able to avoid implement a lambda as something other than an instance of a SAM. Ever.
But just because a lambda in the JVM will most likely never be a true function type (but a functor object), that doesn't stop Clojure, Jaskell or JScheme from being functional languages, does it?
Likewise, a lambda in Java 8 will be, under the hoods, a functor. But that, to me, it is irrelevant, based on the analogies drawn in the previous paragraph.
In everyday-coding practice (which is all that matters ultimately), it is the syntactic support that helps a programmer treat a piece of computation as a type, without having to deal with the plumbing and book keeping that comes with its true functor nature, that's what matters.
Interface types with a single member method are used instead, and lambdas are desugared to anonymous inner class instances implementing them.
Exactly, just like with Closure or JScheme. And that doesn't affect their nature as functional programming languages.
And if that doesn't affect that, then obviously it is not a relevant factor in the "functionness" of a programming language in general. It would be illogical, if we use that factor alone, to say that such a factor puts Java 8's "functionness" into question, but that it has no such effect on Clojure and JScheme's nature.
Logically, then other - possibly context-specific - factors must come into play.
Ergo, it is both reasonable and useful to argue for the classification
By "pragmatic" I mean definition that lets you make some useful distinction. Under your "liberal" definition, both Haskell and C# are functional languages, but Java is not - but in practice, C# is much, much closer to Java than Haskell.
It does not matter if C# is much closer to Java than Haskell, for a language is not measured as functional as a function of its closeness to Haskell, or Lisp or whatever.
You measure a language as being functional by its transparent and convenient support (from the syntactic point of view) of functions as first-order entities.
Syntactically, C# support functions, including closures and lambdas as first-order entities. Java does not (at least Java pre 7). Both are close to each other in evolution, but they have this fundamental distinction when it comes to functional programming.
Case in point. C++ is not functional, but C++0x is, and the later is immediately derived from the former. Closeness is not what you use to measure if a language aligns or supports a particular programming paradigmn (.ie. C vs C++ or Ada 83 vs Ada 2005 with respect to Object Orientation support.)
So that "liberal" definition does not lead to any useful distinction, and then why bother making it at all?
So, you don't think that making a distinction between languages, however close they are, in terms of support of functions as first-class types (or lack thereof) is not useful?
That's an interesting rethorical world you live in buddy.
Soon he'll say something about all hackers being Mexican Muslims.
Correction: China's Offshored Evolutionist Homosexual Socialist Mexican Muslims. When we build the ultimate boogey men, we gotta take all the way baby!
I mean, sure, technically it is - if you use the pedantic definition of "functional" which is "has functions as first-class values". A more pragmatic definition revolves around things like immutability, rich type systems (ADTs etc) and related features (like pattern matching) and various other bits. By that criteria, no, JS is not a Functional language.
If by pragmatic you mean pedantic (or yours) and by pedantic you mean liberal/open, then maybe you have a point. Either that or you have a pretty funny dictionary.
But no more so than other mainstream languages like Python or Ruby, and they aren't "functional languages" either.
Why not? A language with complete and transparent support for functions as first-class types is a functional language. It might not be a pure functional one, but that's still irrelevant since pure FPLs are a subset of FPLs.
The word "Linux" can be used to describe just the kernel alone, or the GNU/Linux (to use Stallman's nomenclature, which Linus Torvalds rejects) system in general
Android and TiVo demonstrate why Stallman is right on this issue. Nobody can deny that Android and TiVo are using Linux as a kernel, but the userland is completely different and certainly isn't GNU. Gone are the days when you could assume that any computer running Linux would also be running GNU.
A distinction that is mostly irrelevant for most people, even most developers (if you count them as people:P)
That's what the author meant, and most people (who even know what Linux is in the first place) take as understood.
Most people on/. -- not most people in general. People may have heard of "Linux," not know exactly what it is, then hear "ANDROID IS LINUX" and immediately think that it must be the same as Fedora or Ubuntu. That kind of confusion is not a good thing for anyone.
Adobe isn't moving away from the Linux community. Rather, the company is refocusing its efforts into the emerging Linux-based space found in mobile products.
So you're going to market Dreamweaver and Illustrator/Photoshop as the latest greatest dev tool for building apps? Why do I get the feeling academia would really embrace that...
How did you get to that conclusion from what he wrote? Strawman much?
android didn't do anything good for linux, if anything it just made another incompatible implementation of the same platform. wake me up when i can run android app on my linux desktop without needing to run it in some virtual machine.
adobe i don't even wanna comment about. i avoid them more carefully than entrance to hell.
Oh really, so do you think you could have taken RHL or Ubuntu and popularize Linux as a mobile OS? Also, the statement is stupid. It is not a question of whether X has done anything good for Linux, but whether Linux has done anything good for X. And it has. Linux has allowed to create a good mobile platform (Android) which is far more open than the competition (the closed-source iOS).
Asking or saying whether Android has done anything good for Linux is as stupid as saying that inkjets and laser printers (and any Linux-based embedded system for that matter) haven't done anything good for Linux. Plain retarded fanboyism.
Because there are Apps that would work in either environment just fine. Just because you can think of a case that won't work doesn't mean that all cases don't work.
And that doesn't mean that *your* case is the general case either. Besides, why would people want to develop apps that run on both Android and Linux on a desktop? The majority of the linux user base is either in the mobile arena (via Android) or in the server arena. The desktop arena is irrelevant and provides no business case to develop for it.
The android platform, not your PC, is the Linux desktop. Period.
If you approach the problem with a proper design methodology that generates a thorough set of use-cases before writing the first requirement, the solution falls out of the regs and obvious behaviors.
And, if you build into that an ability to adapt the system to changing regulations, you've handled the most obvious case, in which regulations change, which they do, continually.
To "a thorough set of use-cases before writing the first requirement", that's the most naive, most impractical stupidest thing I've heard, a blurp out of academic void. This is the number one mistake people in software engineering do, believing that this is possible. In fact, good software engineering recognizes this, and what you just suggested is anathema to it.
Except with the most trivial of cases or in systems that strictly autonomous that interface with physical environments for which you have a model, requirements exist a-priori... ALWAYS.
We are talking about systems that interface with people, business, and processes (internal and external) governed by law, contractual agreements, human behavior and market forces that can change at any time and for which no model exist (unlike models of physical phenomena.). These can change (and due change) by priorities greater than the ones driving the development of a system.
And this does not count deadlines to deliver that typically exist to get something going and that are non-negotiable. Yeah, non-negotiable. You can get a legislative deadline to implement something just to be allowed to operate (think HIPAA or SOX), or mandated by business imperatives that can make or break a company.
And we, software engineers, have to cope with that change because that's what we get paid the big bucks for. With that in mind, it is obvious that it is impossible to do what you suggest: to get a through set of use-cases before writing the first requirement. In fact, many of the requirements and use-cases only become known as progress is made. This is true for any complex system.
Moreover, it flies in the face of agile development, rapid prototyping, or the older-but-always-good iterative/spiral models.
You pretty much suggested that we do waterfall. Way to go bro.
Slashdot Mirror
wooosh!
The Structured Programming Theorem (redirected from Bohm-Jacopini Theorem) from Wikipedia states: The structured program theorem is a result in programming language theory. It states that every computable function can be implemented in a programming language that combines subprograms in only three specific ways. These three control structures are: 1. Executing one subprogram, and then another subprogram (sequence) 2. Executing one of two subprograms according to the value of a boolean variable (selection) 3. Executing a subprogram until a boolean variable is true (repetition) How does one exactly break this theorm?
It seems exaggeration and figures of speech to express the terrible state of affairs of the programming and software engineering practices cannot be performed lightly in what is supposed to be a "news for nerds" website. Let me break it down for you:
1. Hyperbole:
is the use of exaggeration as a rhetorical device or figure of speech. It may be used to evoke strong feelings or to create a strong impression, but is not meant to be taken literally. Hyperboles are exaggerations to create emphasis or effect
2. Rhetoric:
3. Figurative speech:
S: (n) trope, figure of speech, figure, image (language used in a figurative or nonliteral sense)
With that cleared up, the figure of speech -slash- hyperbolic piece rhetoric below:
cannot even do structured programming, and try every single way to break the Bohm-Jacopini Theorem using whatever du jour OOP language of the day
is meant to serve as a grotesque, pejorative description of the equally grotesque situation of programmers - both the type who know nothing but OOP languages like Java or C#, but also "old guard" ones from the procedural bygone era - who despite working with a OOP language end up writing spaghetti with meatballs code.
There are other pejorative terms floating around for a good while now: hyper-spaghetti, GOT-OOP, hyper-lasagna and the like. Even when the code has no goto statements in it, the abuse and apparent lack of coherent use in the nominal control structures mentioned by Bohm and Jacopini makes the disastrous, impenetrable code within and across classes look like the type of GOTO-ridden code Dijkstra railed against it (with Bohm and Jacopini's work as theoretical validation).
These references have existed for a good while now (and given the sentence that preceded it), my hyperbole should have been clear from its context. I guess it was not. The analogy is very clear when you have seen a mass of recently developed production code based on nothing but GOTOs on a past recent enough to have seen widespread use of OOP languages (sadly, I have).
Try that again, but without so much ad hominem, and without using "generalization" as your only argument against what was said.
It's hard to take you, and other NoSQL advocates, seriously when you don't present sound arguments.
Ad hominems. How do pot-kettle. Instead of telling me that I'm ad hominem'ing you, tell me exactly which of the accusations I made (generalizations and ridiculing) is not true. Then we talk.
Also, I'm not a NoSQL advocate at all. I'm a whatever-works advocate. For the majority of cases, for the general case, a relational database system works just fine. For a certain class of problems, it doesn't. Use the tool that is appropriate for the task.
But then again, you are free to generalize me as a NoSQL advocate if that helps you build your argument (given that generalization seems to be your forte.)
The comment you replied to provided us with all of the facts, in a coherent and intelligent manner. You, on the other hand, just threw out one insult and pathetic argument after another.
O really? If that's your understanding of presenting facts in an intelligent, coherent manner, you need to get psychiatric help. Allow me to quote that wonderful piece of intellectual work you are referring to as my last, parting shot. Feel free to stay and belabor on it as you see fit:
1. Attempt to insult via generalizations:
Then they realize that they need some way to query this data. Since most of them only seem to know JavaScript (maybe they were all web designers who pretend to be programmers?)
2. Attempt to a counter-argument by strawman (by referring to a false position NoSQL advocates have ever made):
But of course it isn't SQL! That would be incompatible with their "NoSQL" philosophy
3. Attempt to trivialize by taking a dumb thing to do and painting it as if that's what serious NoSQL advocates do in real life:
(Keep in mind that the system they're "scaling" is a blog getting 50 hits per day.)
4. Attempt to create a refutation via ridicule without substantiating data or citations to the fact:
When they find out that their NoSQL database has corrupted or lost data, they start trying to hack together application-level support for stuff like transactions and constraints.
5. Attempt to negatively compare apples and oranges without specifying a particular context, without showing numbers and while ignoring the fact that many well-published companies (Google, FB, Twitter, LinkedIn) to name a few have use non-relational stores to improve their performance numbers.
that doesn't perform any better than existing relational databases,
6. Attempt to take a few edge case (MongoDB and CouchDB) while maliciously ignoring all the other non-relational stores out there that use more familiar querying languages based on SQL (GAE's data store and GQL, Amazon BigTable restricted SQL, Oracle BerkeleyDB and its restricted SQL capabilities, all other NoSQL stores out there that you can query with XQuery.)
that uses a mangled JavaScript-inspired dialect of SQL
And this last goes to the heart of the matter. You criticize all of the NoSQL stores because a few use a JSON-based query language (which is natural if you store and query things in JSON or BSON format). And the meat of this article is about providing a unifying querying language that is based or related on Codd's relational algebra.
So pretty much you bitch about the problem... in a discussion about a solution to that problem... and where the solution closely resembles at a very mathematical level to the thing you feel more comfortable with (SQL.)
Here is a crowbar. Please use it to get your head out of your ass.
UNQL, for a post-relational world. Nice. Meanwhile 90% [citation needed] of people working with databases can't even get relational databases right. Learning to run before learning to walk, anyone?
And we are moving into functional and functional-object-hybrid models of programming when the majority of programmers in 2011 cannot even do structured programming, and try every single way to break the Bohm-Jacopini Theorem using whatever du jour OOP language of the day. So what's your point?
If we had to wait for every moron code monkey to come up to speed, we would still be reading data off punch cards using a bastard mix of COBOL and mainframe assembly. Industrial and academic R&D and innovation forces have an obligation to move forward. Individual programmers have an obligation to educate themselves and to develop the work ethics to do things right wherever and whenever possible. Lack of the later is not reason to bog down the former.
Well, call me crazy, but the idea of NoSQL was NOT USING SQL AT ALL... now we got a language that in FACT "could be considered a superset of SQL", ok now we have to learn SQL and MORE to use a NOsql set of data. Great but let's change the name of NoSql to something else because this is more st..p thing I heard in the last years... now what.. people is going to hand out meatballs at PETA meetings ....
Crazy? No. Ignorant. Yes. In essence "the idea of NoSQL was NOT USING SQL AT ALL" is simply not true. This has been mentioned for a while now, but apparently people can't seem to grasp it. NoSQL is a misnomer since the idea is not to move away from SQL but to provide data models alternative to Codd's relational model for a variety of reasons (high availability is just one of them.) I agree that the name needs to be changed, but I'd also say that Google is your friend.
splitenz writes:
"Hoping to unify the growing but disparate market of NoSQL databases, the creators behind CouchDB and SQLite have introduced a new query language for the format, called UnQL (Unstructured Data Query Language — .PS). It has Microsoft's backing."
Then, FTA (right at the bottom of it):
This version of UnQL has no relation to an identically named unstructured data query language proposed by a University of Pennsylvania researcher over a decade ago, Phillips said.
I know it's slashdot, but c'mon. Just looking at the linked postscript file shows you a major WTF discrepancy. First the paper is from 2000, and then that paper's query language is based on algebras that do not resemble Codd's relational algebra at all. And that runs counter to this, also FTFA:
Like SQL, UnQL was built on the foundation of relational algebra, Phillips said.
The news are great. The coverage blows. It would pay to read the stuff that is being submitted as a story... just sayin...
I just don't get NoSQLers at all. Can somebody explain them to me? So they have trouble scaling systems using existing relational databases because they don't know about indexes, or data partitioning, or how to set up proper hardware configurations for database servers. (Keep in mind that the system they're "scaling" is a blog getting 50 hits per day.)
Generalizations + lies + attempt to ridicule without facts in hand
Their solution to this problem is to avoid relational databases completely, instead opting to use so-called "NoSQL" databases that don't offer ACIDity, or basically every other useful feature of relational databases.
Apparently obvious to the fact that in many non-trivial business cases, you don't need full ACIDity and an eventually consistency model is more appropriate.
Then again, many of these NoSQLers don't even seem to know what transactions or referential integrity are in the first place, so maybe they don't even realize what they're missing.
Generalizations and unsubstantiated blanket statements about a group of software engineers for the mere sake of ridicule (this in contradiction to the first question that is dishonestly presented as a genuine question.)
When they find out that their NoSQL database has corrupted or lost data, they start trying to hack together application-level support for stuff like transactions and constraints.
Generalization, speculation.
It doesn't work, and may in fact cause more problems than it actually prevents.
Generalizations + hand waving (surprisingly, this didn't contain an instance to a "think of the children" fallacy)
Now they mistakenly think that their data has better integrity, when it reality it doesn't.
Generalization based on a claim that AFAIK has never been made (a poor man's attempt at a strawman.)
Then they realize that they need some way to query this data. Since most of them only seem to know JavaScript (maybe they were all web designers who pretend to be programmers?)
More generalizations as an attempt to ridicule or even insult (no actual, scientific and honest interest to understand the issue at hand.)
they decide to contort it into a query language.
You do have a point, ergo the need for a querying language, which pretty much the topic of TFA.
Eventually, their custom-brewed query language ends up evolving into something that's very remarkably like SQL.
That is a possibility, your point?
But of course it isn't SQL! That would be incompatible with their "NoSQL" philosophy
As it has been made apparent in the shitload of literature, interviews and presentations out there (fucking google it?), it has been acknowledge that NoSQL is a misnomer, as the intention was never to move out of SQL, but to provide alternative/competing data representations to the relational model (which provides a very good formal symbolic representation of a certain ubiquitous but not universal class of data.)
which strongly states that SQL is a horrible thing and should forever be avoided.
Says who? Cite references to this effect.
(But when confronted with this similarity, they'll backpedal and claim that the "No" in "NoSQL" means "not only", contradicting the "NoSQL means no SQL ever!" claims they'd made the week before.)
Red herring, strawman. I short, generalizing stupidity.
In the end, they've spent a lot of time and effort creating a "database" system that doesn't adhere to the ACID principles in any sensible way
Because full ACIDity is not desirable in certain classes of problems. Where have you been all this time?
that uses a mangled
Yeah, but he has an entire Marin county valley named after him in Northern California. Smith Ranch Road became Lucas Valley Road west of Highway 101. This while still being alive. Usually, people don't have things named after them until they are dead. (presidential libraries excepted).
Having the county name a geographical region after you is a success.
Stalingrad?
True.
'It's crazy, we buy proprietary [and] we don't understand what it is we're buying into,' he said. 'It works great for an application, and then you come to conflict and you spend the rest of your time trying to modify it to actually do what it should do.'
This sounds like every corporation where I have ever worked.
Some companies experience a lot more pain than others when it comes to that, though.
As a IT worker who can't find a new job and who does not work in SIlicon Valley or the West coast of the US at all, while you may have it good my career is basically gone now. I have kept up to date, I have paid my dues, but here their isn't that marvelous growth their is out your way. Having just run out of unemployment and literally having no way to live anymore because I just can't seem to get hired in the field at all (& lack experience for anything else). I can say that you should care, because except for a bit of fate on your part you could be me and just as equally in need of help right now.
I feel for you because I've also worked in IT. And because of what you are going through is the main reason I've left IT (IT meaning enterprise computing and IT operations.) I'm still in software, but not in IT. And I'll be out of it if I can help it.
I started seeing the writings on the wall since the dot-com era, and they have been reinforced by outsourcing, and the continous automation of enterprise computing.
In IT is no longer sufficient to keep up to date, but to be exceptional (and to be in the right geographical place as not all regional IT markets are the same). And I think to seek to be exceptional (not to be, but to seek to be, to put the effort to be) is mandatory in engineering, and in software in particular. But the ROI in IT/Enterprise computing is dubious at best. One has to be exceptional and a specialist on specific niches (and versatile at the same time) to ensure a modicum of job opportunities. IT might have the lowest barrier of entries in all types of software work, but it is certainly the one with the most dubious ROI when it comes to the cost in time and money for keeping one's career afloat.
Good luck, and I hope you improve your situation. My advice. Get out of IT and get into non-IT software jobs if you can.
> I am not saying I am better than anybody else Yes you are.
No he's not. He's simply saying that for those job/career specific conditions, he has done choices that allows him to fare better (possibly with the hope of others might benefit with his annecdotes.) The type of moral implications attached to his post are a function of the reader, not the poster.
$16k is... pre-tax, in some places, at a fairly low to very low standard of living
Bullshit. "Low standard of living" my hairy ass. I am married, I keep rent paid, (never late for 5 years, HDTV, car insurance, electricity, land line phone, cell phones w/ unlimited data, 10Mbps internet connection, 3 computers, plenty of meat in the fridge, and the food plentiful. You know what I take home each month? 1135. Yes, we live in a 1bdrn apt, but both of our cars are paid for, and rent is paid for a year in advance. Do I do this with assistance? NO. I have a 50" HDTV, a computer that would likely kick yours into the dirt, an internet connected blu-ray player, and a home network for multimedia support. All of this on less then $13620/ yr take home. You can't make it on $16000/yr my ass. It is easily doable.
Questions:
1. How long have you been doing this?
2. Before you started doing this, how much did you earn, did you have any savings?
3. Do you have any savings now?
4. Do you have any non-government assisted medical insurance, dental?
5. The $1135/moth you are making, is that by both of you, or by you alone? If the later, how much does your partner make?
6. Do you have kids? If so, can you break down the expenses for them, and do they have non-government assisted medical coverage? If not, do you think you can meet ends once you have them?
7. How much rent do you pay, and where?
8. Do you get a return from the IRS? Or do you have to pay additionally when you file your income tax? Or do you call it even with the tax collectors?
9. More importantly, where do you live and how old are both of you?
Thanks.
Can it be that instead of having interbred, we merely share a common distant ancestor?
In that case, the genes would also be found in the "African" populations. Since that is not the case (according to the findings), then the most pausible alternative is that indeed, there was interbreeding between out-of-Africa H. Sapiens and H. Neanderthalis (most likely very early on in the H. Sapiens expansion out of Africa.)
I was in downtown Boston on the 4th of July weekend, and happened upon a unique memorial: it was six four-sided pillars, each about 50 feet high, of clear glass. Pretty, actually. Then I looked closer to see what was etched into the glass. It was a collection of numbers, almost like serial numbers, or concentration camp IDs. My wife nearly collapsed at the realization. All those people, dead, because soldiers were "following orders."
A -human's- first order of responsibility is to do what's right.
Did that include the dog tags of those who died following orders on D-Day?
In practice, however, Java anonymous inner classes can be used in largely the same way as C# anonymous delegates - they're only slightly more verbose, and the only other practical difference is that they close over values of variables, not locations - which doesn't matter for a lot of scenarios.
Hmmm, no. I've had to deal with anonymous classes in the distant and no-so distant past. And affter working with lambdas in Lisp, JavaScript and Groovy, they simply do not compare from the point of view (and inherent cost) of day to day coding.
I'm going to have to disagree with you on this (see the areas in bold). Not to tooth my own horn, but I've done almost nothing but Java development since 99, including web application and systems/network protocol development, library development, and (most relevant to this topic) Swing development. I can tell you with 100% experience-backed, with severe from-the-trenches bruises that they are *not* slightly more verbose.
Non-trivial anonymous classes in lieu of lambdas and closures are horrendously verbose. Horrendous, abominable. No way around these monstrosities when creating action listeners and thread workers in Swing. Outside of Swing, in the realm of server side development, sometimes you can see opportunities to factor out exception and transcation handlers as lambdas to reduce boilerplate, but the verbosity of anonymous classes makes it horrendously hard. Only one time I've been able to pull that off cleanly despite the verbosity. For all other cases, we might as well deal with the typical Java boilerplate or use AOP under the hoods, or deal with them with a mix of Java and Groovy.
And even in Java 8 (there's no lambdas in Java 7), there are no function types.
True that - at least under the hood. And that is because the JVM does not have a notion of function handlers. Any lambda, whether in Java 8, Scala or Clojure, must under the hood resolve to a functor object (most likely an instance of an anonymous class) implementing a SAM (single abstract method.)
Unless the JVM is revamped with some type of bytecode op that represents a function reference type, no language on top of the JVM, be it Scala, Java 8, Groovy, Jython, JRuby, Clojure, Jaskell, JScheme, will ever be able to avoid implement a lambda as something other than an instance of a SAM. Ever.
But just because a lambda in the JVM will most likely never be a true function type (but a functor object), that doesn't stop Clojure, Jaskell or JScheme from being functional languages, does it?
Likewise, a lambda in Java 8 will be, under the hoods, a functor. But that, to me, it is irrelevant, based on the analogies drawn in the previous paragraph.
In everyday-coding practice (which is all that matters ultimately), it is the syntactic support that helps a programmer treat a piece of computation as a type, without having to deal with the plumbing and book keeping that comes with its true functor nature, that's what matters.
Interface types with a single member method are used instead, and lambdas are desugared to anonymous inner class instances implementing them.
Exactly, just like with Closure or JScheme. And that doesn't affect their nature as functional programming languages.
And if that doesn't affect that, then obviously it is not a relevant factor in the "functionness" of a programming language in general. It would be illogical, if we use that factor alone, to say that such a factor puts Java 8's "functionness" into question, but that it has no such effect on Clojure and JScheme's nature.
Logically, then other - possibly context-specific - factors must come into play.
Ergo, it is both reasonable and useful to argue for the classification
By "pragmatic" I mean definition that lets you make some useful distinction. Under your "liberal" definition, both Haskell and C# are functional languages, but Java is not - but in practice, C# is much, much closer to Java than Haskell.
It does not matter if C# is much closer to Java than Haskell, for a language is not measured as functional as a function of its closeness to Haskell, or Lisp or whatever.
You measure a language as being functional by its transparent and convenient support (from the syntactic point of view) of functions as first-order entities.
Syntactically, C# support functions, including closures and lambdas as first-order entities. Java does not (at least Java pre 7). Both are close to each other in evolution, but they have this fundamental distinction when it comes to functional programming.
Case in point. C++ is not functional, but C++0x is, and the later is immediately derived from the former. Closeness is not what you use to measure if a language aligns or supports a particular programming paradigmn (.ie. C vs C++ or Ada 83 vs Ada 2005 with respect to Object Orientation support.)
So that "liberal" definition does not lead to any useful distinction, and then why bother making it at all?
So, you don't think that making a distinction between languages, however close they are, in terms of support of functions as first-class types (or lack thereof) is not useful?
That's an interesting rethorical world you live in buddy.
"Convene the dang committee!"
Soon he'll say something about all hackers being Mexican Muslims.
Correction: China's Offshored Evolutionist Homosexual Socialist Mexican Muslims. When we build the ultimate boogey men, we gotta take all the way baby!
JavaScript is not any more functional than C#.
I mean, sure, technically it is - if you use the pedantic definition of "functional" which is "has functions as first-class values". A more pragmatic definition revolves around things like immutability, rich type systems (ADTs etc) and related features (like pattern matching) and various other bits. By that criteria, no, JS is not a Functional language.
If by pragmatic you mean pedantic (or yours) and by pedantic you mean liberal/open, then maybe you have a point. Either that or you have a pretty funny dictionary.
But no more so than other mainstream languages like Python or Ruby, and they aren't "functional languages" either.
Why not? A language with complete and transparent support for functions as first-class types is a functional language. It might not be a pure functional one, but that's still irrelevant since pure FPLs are a subset of FPLs.
It's spelled bauxite. I don't think you are as learned as you appear to be.
Because an occasional spelling error is a certain, bulletproof indicator of a person's learning (or lack thereof) </rollseyes>
The word "Linux" can be used to describe just the kernel alone, or the GNU/Linux (to use Stallman's nomenclature, which Linus Torvalds rejects) system in general
Android and TiVo demonstrate why Stallman is right on this issue. Nobody can deny that Android and TiVo are using Linux as a kernel, but the userland is completely different and certainly isn't GNU. Gone are the days when you could assume that any computer running Linux would also be running GNU.
A distinction that is mostly irrelevant for most people, even most developers (if you count them as people:P)
That's what the author meant, and most people (who even know what Linux is in the first place) take as understood.
Most people on /. -- not most people in general. People may have heard of "Linux," not know exactly what it is, then hear "ANDROID IS LINUX" and immediately think that it must be the same as Fedora or Ubuntu. That kind of confusion is not a good thing for anyone.
See my response above.
Adobe isn't moving away from the Linux community. Rather, the company is refocusing its efforts into the emerging Linux-based space found in mobile products.
So you're going to market Dreamweaver and Illustrator/Photoshop as the latest greatest dev tool for building apps? Why do I get the feeling academia would really embrace that...
How did you get to that conclusion from what he wrote? Strawman much?
android didn't do anything good for linux, if anything it just made another incompatible implementation of the same platform. wake me up when i can run android app on my linux desktop without needing to run it in some virtual machine.
adobe i don't even wanna comment about. i avoid them more carefully than entrance to hell.
Oh really, so do you think you could have taken RHL or Ubuntu and popularize Linux as a mobile OS? Also, the statement is stupid. It is not a question of whether X has done anything good for Linux, but whether Linux has done anything good for X. And it has. Linux has allowed to create a good mobile platform (Android) which is far more open than the competition (the closed-source iOS).
Asking or saying whether Android has done anything good for Linux is as stupid as saying that inkjets and laser printers (and any Linux-based embedded system for that matter) haven't done anything good for Linux. Plain retarded fanboyism.
Because there are Apps that would work in either environment just fine. Just because you can think of a case that won't work doesn't mean that all cases don't work.
And that doesn't mean that *your* case is the general case either. Besides, why would people want to develop apps that run on both Android and Linux on a desktop? The majority of the linux user base is either in the mobile arena (via Android) or in the server arena. The desktop arena is irrelevant and provides no business case to develop for it.
The android platform, not your PC, is the Linux desktop. Period.
If you approach the problem with a proper design methodology that generates a thorough set of use-cases before writing the first requirement, the solution falls out of the regs and obvious behaviors.
And, if you build into that an ability to adapt the system to changing regulations, you've handled the most obvious case, in which regulations change, which they do, continually.
To "a thorough set of use-cases before writing the first requirement", that's the most naive, most impractical stupidest thing I've heard, a blurp out of academic void. This is the number one mistake people in software engineering do, believing that this is possible. In fact, good software engineering recognizes this, and what you just suggested is anathema to it.
Except with the most trivial of cases or in systems that strictly autonomous that interface with physical environments for which you have a model, requirements exist a-priori... ALWAYS.
We are talking about systems that interface with people, business, and processes (internal and external) governed by law, contractual agreements, human behavior and market forces that can change at any time and for which no model exist (unlike models of physical phenomena.). These can change (and due change) by priorities greater than the ones driving the development of a system.
And this does not count deadlines to deliver that typically exist to get something going and that are non-negotiable. Yeah, non-negotiable. You can get a legislative deadline to implement something just to be allowed to operate (think HIPAA or SOX), or mandated by business imperatives that can make or break a company.
And we, software engineers, have to cope with that change because that's what we get paid the big bucks for . With that in mind, it is obvious that it is impossible to do what you suggest: to get a through set of use-cases before writing the first requirement. In fact, many of the requirements and use-cases only become known as progress is made. This is true for any complex system.
Moreover, it flies in the face of agile development, rapid prototyping, or the older-but-always-good iterative/spiral models.
You pretty much suggested that we do waterfall. Way to go bro.